Haxe debugging?

[HaxeIsGreat]

Hello,

As of today, is there any mean by which we can debug Haxe directly from the IDE (for example IJ IDEA).

If not, is it possible to debug it in the browser dev tools with source maps?

Thanks.

[Philippe Elsass]

Haxe JS target with -debug includes sourcemaps by default and are supported by most modern browsers.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[Mark Knol]

You also might want to checkout https://haxe.org/manual/debugging-javascript.html

[Greybeard]

IntelliJ IDEA (with the Haxe plugin) has two methods of debugging Haxe code: Flash and C++ targets (or openFL and hxcpp, if you prefer).  There are instructions how to set up debugging for hxcpp at the plugin web-site: http://intellij-haxe.org/wiki/debugging  Note that debugging does not work with the free IDEA Community Edition; you must download IDEA Ultimate Edition or use an Early Access Program (EAP) edition, both of which can be downloaded for free at JetBrains web site: http://www.jetbrains.com/idea   (Ultimate is for a thirty-day evaluations.  EAP requires updating every 30 days.)

Jason Sturges' video instructions for setting up debugging for Flash can be found at https://youtu.be/kvFg1Zee4h4  They are for macOS, but they are largely the same on Windows.  (On Windows, after you download AIR, you will have to associate the debug player with the .SWF extension manually, because the SWF is launched by name.)

If you need help getting it working, you can find me on gitter (HaxeFoundation/haxe) as EricBishton and/or the Haxe slack channel (haxe.slack.com) as Eric Bishton.  (Or here, but I usually only get the daily digest.)

Good Luck!

-Eric

[Jeff Ward]

FYI for anyone coming across this thread, keep in mind that debugging (breakpoints, stepping through code) is a runtime feature. Since Haxe is the language (that merely compiles to other languages and bytecodes), there's technically no such thing as "debugging in Haxe."

So the question is, do you want to debug your Haxe program in the js runtime, or the hxcpp runtime, or the neko runtime, etc, etc...

Just to add to the hxcpp notes above: there is also my plugin for Visual Studio Code: https://github.com/jcward/vscode-hxcpp-debug -- it's not on the vscode marketplace yet as it's still in prototype stage. Both the intellij and vscode plugins rely on the hxcpp-debugger library. You could test debugging with the hxcpp-debugger's CLI mode (to ensure your project is instrumented properly) before then trying to get either IDE working.

Best,

-Jeff

[Greybeard]

On Thursday, September 28, 2017 at 12:55:11 PM UTC-7, Jeff Ward wrote:

FYI for anyone coming across this thread, keep in mind that debugging (breakpoints, stepping through code) is a runtime feature. Since Haxe is the language (that merely compiles to other languages and bytecodes), there's technically no such thing as "debugging in Haxe."

While you are technically correct, what people usually mean when they say "debugging in Haxe" is that they are looking at, stepping through, and inspecting variables in their original Haxe sources, and not the generated back-end code.

 

So the question is, do you want to debug your Haxe program in the js runtime, or the hxcpp runtime, or the neko runtime, etc, etc...

IMO, the better way to think of this is which target do you want to debug.  It /shouldn't/ matter, but it does.

 

Just to add to the hxcpp notes above: there is also my plugin for Visual Studio Code: https://github.com/jcward/vscode-hxcpp-debug -- it's not on the vscode marketplace yet as it's still in prototype stage. Both the intellij and vscode plugins rely on the hxcpp-debugger library.

Glad to hear it.

 

You could test debugging with the hxcpp-debugger's CLI mode (to ensure your project is instrumented properly) before then trying to get either IDE working.

I wholeheartedly concur that testing your debug setup with the CLI before trying to get your IDE to work is a great idea and will save you hours (days?) of heartache.

 

Be good,

-Eric

[szczepan]

I wonder from time to time, mostly just before falling asleep (instead of counting those sheep jumping over a fence), if it would be possible to "instrument" a Haxe code through macros in such a way, that would enable to track all the invocations changing state (variables)? Wrapping every expression in some "debug function" should allow to make breakpoints at runtime but those are useless without a way to inspect runtime values... Just wondering. ;)

[Greybeard]

That's more or less what hxcpp and hxcpp-debugger do.  hxcpp inserts (C++) macros into the generated C++ code, and each time that the macro is called, the breakpoint list is checked to see if the code should stop.  Inspecting values is done through reflection and toString() on the classes (toString() is run on a debugger thread, instead of the stopped app thread(s)).

-Eric

[HaxeIsGreat]

But that'd not mean I can step into the original haxe code right? That just means I can step into the generated code, which might be a bit messy.

[Jeff Ward]

I work with the JS target at work daily, and I honestly prefer source maps off. The JS code is very readable, with very few mappings to get used to (enums become arrays, _gthis, array iteration is always while, etc.) By contrast, when I've used source maps, there were times when it wasn't exactly on the line I thought, or it didn't show me the variable names I expected -- I found it overall more confusing.

But, the chrome debug tools are very, very good, and the target language very similar, so maybe I'd feel differently about other targets.

If I recall, with my hxcpp vscode plugin, you step through haxe code, and some variables are named correctly, but you do see a lot of tmp variables.