__line_number__ and __filename__
What is the reasoning behind wanting this data? For example, in exceptional cases you should be creating errors which already have stacks containing this information. -Gus ----
I am debugging existing code that I have modularized, and am class'izing that has unittests and it just would have been very useful to have this facility.
On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray <aaronngray.lists at gmail.com>
wrote:
I am debugging existing code that I have modularized, and am class'izing that has unittests and it just would have been very useful to have this facility.
In a browser, console.log is usually associated with the file and line number anyway; which includes using devtools with node.... but it would be handy for logging. with V8 there is console.trace; which spits out the stack trace too... before I discovered that I did a logging function like...
(from stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception ) function stackTrace() { var err = new Error(); return err.stack; } // parse stack to get frame-1 online
// or maybe just frame-1... function stackTrace() { var err = new Error(); return err.stack.split( "\n" )[1]; }
function stacktrace() { function st2(f) { return !f ? [] : st2(f.caller).concat([f.toString().split('(')[0].substring(9) + '('
- f.arguments.join(',') + ')']); } return st2(arguments.callee.caller); }
EDIT 2 (2017) :
In all modern browsers you can simply call: console.trace(); (MDN Reference)
Although I do still miss just being able to get FILE and LINE
On Fri, 24 Aug 2018 at 04:56, J Decker <d3ck0r at gmail.com> wrote:
On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray <aaronngray.lists at gmail.com> wrote:
I am debugging existing code that I have modularized, and am class'izing that has unittests and it just would have been very useful to have this facility.
In a browser, console.log is usually associated with the file and line number anyway; which includes using devtools with node.... but it would be handy for logging. with V8 there is console.trace; which spits out the stack trace too... before I discovered that I did a logging function like...
(from stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception ) function stackTrace() { var err = new Error(); return err.stack; } // parse stack to get frame-1 online
// or maybe just frame-1... function stackTrace() { var err = new Error(); return err.stack.split( "\n" )[1]; }
function stacktrace() { function st2(f) { return !f ? [] : st2(f.caller).concat([f.toString().split('(')[0].substring(9) + '(' + f.arguments.join(',') + ')']); } return st2(arguments.callee.caller); }
EDIT 2 (2017) :
In all modern browsers you can simply call: console.trace(); (MDN Reference)
Yes slightly long winded to say the least :)
Although I do still miss just being able to get FILE and LINE
Yeah it should be easy to have such stuff compiled by JIT
Aaron
Did nobody see my email? There is already a mechanism in the works for exposing this kind of metadata:
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta
On Fri, 24 Aug 2018 at 16:34, Peter Jaszkowiak <p.jaszkow at gmail.com> wrote:
Did nobody see my email? There is already a mechanism in the works for exposing this kind of metadata:
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta
Thanks, thats probably okay for the filename but for line number information that does not realy look too applicable and ideally both have a simular mechanism.
Le 24 août 2018 à 05:55, J Decker <d3ck0r at gmail.com> a écrit :
On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray <aaronngray.lists at gmail.com <mailto:aaronngray.lists at gmail.com>> wrote: I am debugging existing code that I have modularized, and am class'izing that has unittests and it just would have been very useful to have this facility. In a browser, console.log is usually associated with the file and line number anyway; which includes using devtools with node.... but it would be handy for logging. with V8 there is console.trace; which spits out the stack trace too... before I discovered that I did a logging function like...
(from stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception, stackoverflow.com/questions/591857/how-can-i-get-a-javascript-stack-trace-when-i-throw-an-exception ) function stackTrace() { var err = new Error(); return err.stack; } // parse stack to get frame-1 online
// or maybe just frame-1... function stackTrace() { var err = new Error(); return err.stack.split( "\n" )[1]; }
function stacktrace() { function st2(f) { return !f ? [] : st2(f.caller).concat([f.toString().split('(')[0].substring(9) + '(' + f.arguments.join(',') + ')']); } return st2(arguments.callee.caller); }
EDIT 2 (2017) :
In all modern browsers you can simply call: console.trace(); (MDN Reference)
Although I do still miss just being able to get FILE and LINE
See also:
tc39/proposal-error-stacks, tc39/proposal-error-stacks
If/when that proposal is implemented, you'll have a simple way to get a structured representation of the trace:
System.getTrace(new Error)
from which you can much more easily extract line number, filename, etc.
What does line number, or filename for that matter, mean when a file has gone through one or more transpilation and/or minification passes? Is the notion that the first processor that touches the file would substitute those values?
Bob
Ideally at some point we won't be using transpilers anymore ;)
Realistically, the engine would give back file name and line number (and hopefully character offset) of the code from the fully translated, fully minified, actual logic that the engine loaded. Source maps could be used to convert that obscure value back into actual original source code locations. It would also be nice if there were a way to perform a lookup at runtime, a function that takes a function and returns the internal Location object for that function.
Its not rocket science :)
I'm not a fan of adding these to the language when stacks are almost assuredly coming (time appears to be the limiting factor), and those would address most things.
Apart from that, the binary AST proposal handles most things like line mapping support (as a right-after-MVP thing), and it'd function much like how Java bytecode supports location data inline as well.
Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com
I wondering what people think about the idea of proposing being able to get the line number and filename of executing code in the code ? Maybe with something simular to C preprocessors line_number and filename. Or as subobjects of global ?