[JS target] Unfriendly trace messages.

[Sławomir Mazgaj]

Hello fellow Haxe developers. Recently I've encounter some issues regarding traces in JS.

TL;DR

As codebase is getting bigger traces are no longer simple `console.log()` calls but they're using shared `js_Boot__trace()` function and it's pain to debug.

So here's the full story:

Starting with just 2 classes, Main and Lulz.

class Main

{

public function new()

{

trace("Oh! Hai!");

var lulz:Lulz = new Lulz();

}

static function main()

{

new Main();

}

}

class Lulz

{

public function new()

{

trace("Well, Hello there!");

}

}

After compilation I'm getting nice traces in JS console.

Not bad, but compiling with `-debug` flag is even better:

This is awesome, I don;t need to look at ugly JS code and clicking this thing on the right is taking me right away to proper .hx class. Neat and super useful for debugging.

Now lets FF a bit. Project is using some other libs and codebase is getting bigger and bigger.

So what do we have now?

Uh, oh! What ?

So now instead of my dummy files it's pointing to Boot.hx all the time (where the console log is). I can see the class name and line in the message now but this is super annoying during debugging. I can no longer click but have to manually browse to this file if I want to set breakpoint etc.

Does any one came across same thing or do know how to avoid this kind of behaviour?

Any help would be appreciated.

Cheers,

Slawek

[Ian Harrigan]

This might help: http://old.haxe.org/doc/cross/trace

Cheers,

Ian 

[Dan Korostelev]

I think this is a classic "console.log wrapping" problem which can be side-stepped by using the "blackboxing" feature of chrome/firefox debuggers. One problem with that is the fact that at least chrome only allows blackboxing a whole .js file, so you have to put your custom log wrapper function in a separate .js file and then assign it to haxe.Log.trace. Here's an example that works for me: https://gist.github.com/nadako/11f53e8e084d89c6a29d

I blackboxed the "custom-log.js" file so it doesn't go into it to look for a real position of a trace. This also works well in conjunction with source mapping.

среда, 10 февраля 2016 г., 17:58:36 UTC+3 пользователь Sławomir Mazgaj написал:

[Sławomir Mazgaj]

Thanks Ian,

unfortunately introducing custom function is giving similar results (which is the right, sight thingy is pointing now to custom function instead).

[Sławomir Mazgaj]

@Dan.

That's exactly what I was looking for. Thanks for explanation and working example. I'm not very familiar with JS so I didn't know it's "console.log wrapping" problem. I made separate js file, blackboxed it and working like a charm. Big Thanks!