Strange trace() behavior

Hello there !

Tell me please, has anyone already met a trace() issue…?

I have no more trace() when compiling with :

lime build flash -DmyProject

Furthermore, when I compile with :

lime test flash -DmyProject

The console, receive the previous “asked” trace().

I explain :
If I compile first with…

lime test flash -DmyProject -DmyWantedTraces

…I need to compile a second time with :

lime test flash -DmyProject -DmyWantedTraces

…before the traces will be sent to the console.
or if I compile second with…

lime test flash -DmyProject -DmyOtherWantedTraces

…I will receive the first -DmyWantedTraces

Never had such strange behaviors.


ps/ My haxelib is updated.
ps2/ While typing, the shortcut [:] when you just want a breakline, is a mess.

In the newest version of Lime, it tries to follow the Flash trace log and output it into the console window (similar to how desktop and other targets work)

The default Haxe traces go on the window instead. I think that -Dhaxetrace switches the behavior to tracing on the window instead. Your feedback is helpful because I hope that we can improve the tracing behavior so it definitely matches with the run you are doing. Is more than one window running at once?

Perhaps we should clear the Flash trace log output file before running, so we can be sure we don’t output anything old by accident

To tell you more, I have upgraded the haxelib last night and have worked a few hours - that means a lot of compile Flash/HTML5 - before that sudden trace() miss on Flash standalone (debug/not-debug) platform.

It’s true, I have often, if not always, a lot of previous compiled window, but my traces were up-to-date.
And that sudden issue, may have occured after a whole computer reboot.

I must admit, I haven’t take the time to learn to compile from FlashDevelop and observe the trace within, nor be used to see them on the console with test…
I just use the console to “flag” the wanted traces() and check them on the player or brower.


Thanks my codangel ! :blush: