[js std] trace improvements

[clemos]

in https://github.com/HaxeFoundation/haxe/blob/development/std/js/Boot.hx#L47-L65

• the feature that checks / logs to a div#haxe:trace should be moved to a legacy class, and included only if -D legacy-trace or similar
• __string_rec should be used only in this case (ie: when the console is not used)
• in the other case, when logging to the console, we should pass v and i.customParams as-is, and let the JS environment deal with displaying the data

If you want, I can make a PR with that improvement.

[nadako]

I agree about haxe:trace/jsfl stuff, that looks out of place, but I'm not sure about __string_rec. On one hand, passing objects to console will enable nice features of browser consoles such as object inspection, but on the other - it'll print some stuff like enums in an ugly way (or am I wrong and it'll use the toString method?)

[clemos]

IMHO it's fine to output the raw / native value "by default", and have something very light in haxe.Boot. Enums are usually understandable, even this way (and inspectable).
Then we can provide other logger methods with more features (nicer enums, ...), that could be activated either with a compiler flag (-debug ?), or with using standard override haxe.Log.trace = haxe.ConsoleLogger.factory({ prettyEnums:true}) haxe.DomLogger.factory({selector:"#haxe:trace"}) or something.

[nadako]

That makes sense to me, but I don't know who's the one to make the call about it. @ncannasse ?

[clemos]

While we're at it, I was wondering if it would be feasible to inline the call to console.log to benefit from sourcemaps in Developer Tools.

[nadako]

Not sure if that's possible, since haxe.Log.trace is a dynamic method and hence is not inlineable.

[nadako]

Actually, I think we could just generate console.log calls even if there's more than one argument to trace, unless haxe.Log.trace is directly used, hmm...

[nadako]

I'm gonna proceed cleaning this up, starting by removing haxe:trace and jsfl stuff.

[Simn]

Can this be closed?

[Simn]

Let me know if there's something left to do here.

[nadako]

The idea was to try generating console.log("Main.hx:42", a, b, c) for trace(a, b, c) instead of full-fledged haxe.Log.trace(...), but that's not too important I think.

[back2dos]

Ping @mastef. IIRC he had very strong feelings about this ^^

[mastef]

I think it would be fantastic if trace would natively pass through to console.log - including the line numbers / source map information.

Currently it's a pity that trace transforms everything to strings before pushing it to the browser console, losing all the nice debugging and inspection features the browser natively provides for objects. And replicating the magic trace behaviour with macros proved quite an interesting challenge, as you need rest arguments capability + trailing pos. It's possible, but tricky to get right from what I recall.

So it would be great to have this functionality natively instead. ( And if somebody really requires string literals output to console, then a switch could be provided. )

I remember there was a macro version somewhere of this - and one approach made it into this gist. And then there is also this fine library.