With the JavaScript target, trace does not include file/line information

[Pauan]

Haxe code:

trace("hi!");

Expected JavaScript output:

console.log("Foo.hx:1: " + "hi!");

Actual JavaScript output:

console.log("hi!");

According to the Haxe manual, the trace call should include location information, such as Test.hx:11, but with the JavaScript target it does not.

Printing the location is such a useful feature when using the trace function in multiple places when debugging.

And there shouldn't be any performance penalty because Haxe can inline the location information into the call to console.log

I know that you can use haxe.Log.trace("hi!"), which correctly logs the location info, but that's a lot less convenient than trace("hi!")

Fixing this issue also has another benefit: if you use trace on an enum (or any type which implements toString), it will print the raw JavaScript object, because it doesn't call toString on the enum. But with the expected JavaScript output it would pretty-print the enum, which is much nicer.

[Pauan]

@Simn Thanks a lot! ❤️

[ncannasse]

Please note that doing also breaks the ability to inspect objects using google console, since we only print the string representation of the object and not the object itself. I would vote for undoing this change.

…

On Wed, Aug 2, 2017 at 9:53 AM, Pauan ***@***.***> wrote: @Simn <https://github.com/simn> Thanks a lot! ❤️ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6467 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwOnlgC-UI0CtCQCa8uWkGE2ig-1oks5sUCrvgaJpZM4Ojh1b> .

[aduros]

I would also vote for undoing since with source maps enabled the Haxe line numbers are already shown, and you can click on the line number to navigate to that file.

[Simn]

I wasn't aware of the inspection problem. In that case I agree we should revert.

[kevinresol]

Please note that doing also breaks the ability to inspect objects using
google console, since we only print the string representation of the object
and not the object itself. I would vote for undoing this change.

js.Browser.console.log is the proper way to inspect objects.
trace should behave consistently across platforms.

[Pauan]

@ncannasse With the old behavior, if you used trace with 2+ arguments (e.g. trace(foo, bar)) anywhere in your program, it caused all trace to stringify + print file/line information.

In other words, the only time when trace did not stringify is if you consistently used only a single argument everywhere.

So if you want trace to not stringify, then it should never stringify under any circumstances, rather than stringifying sometimes and not other times.

Also, not printing file/line information may be okay with browsers, but it's bad with Node.

[ncannasse]

@Pauan then I think it's a "bug" that needs to be fixed, for instance by translating multiple arguments traces to console.log([foo,bar])

[ncannasse]

And for Node sourcemap support, looks like there is https://github.com/evanw/node-source-map-support

[Pauan]

@ncannasse It should probably be console.log(foo, bar) instead.

And that library only works for thrown exceptions, not for console.log

[Pauan]

I thought of a solution to this problem. Rather than generating this:

console.log("Foo.hx:1: " + "hi!");

Instead generate this:

console.log("Foo.hx:1:", "hi!");

console.log automatically adds a space between arguments, so it no longer needs a space at the end of Foo.hx:1:

In the browser you will still get inspectability for objects, and in Node you'll get file/line numbers.

This also works with multiple arguments:

console.log("Foo.hx:1:", "hi!", "other hi!");

[nadako]

See also #5639