Mapping a JS stack-trace back to Elm

[Seanny123]

I’m trying to get started on the huge project called Sketch-n-Sketch. I found some behaviour which causes an error, which I can see in the Chrome developer console. The error is cause by the program creating some invalid SVG output. I can click the stack-trace to find where the error is caused on in the JS output file, however I’m having a hard time finding where the error is being caused in the Elm code.

How does one typically map from a JS error to an Elm file?

What I’ve tried

I feel like I might be asking for an Elm debugging tutorial, since I’ve only written small programs while going through the Elm tutorial. I’ve seen you can apparently use elm-make --debug, but when I try to do this, a bunch of ports aren’t found. So I think it doesn’t apply to this case? However, the project seems to be sprinkled with Debug.log and Debug.crash statements, so maybe there’s so may to get this to work?

I also know that currently source-maps don’t exist for Elm, which is how I usually accomplished this when I used TypeScript.

[Seanny123]

As a kind of non-answer which solved, my problem, I now understand how Debug.log() can be used to do basic print debugging. This in turn allowed me to figure out which files were being called. Specifically, given the utility function in Utils.elm:

log : String -> ()
log s = Debug.log s ()

You can add:

let _ in Utils.log "debug msg" in

Basically anywhere in your code to get output to the web console. This seems obvious in hindsight, but for some reason it wasn’t clear to me initially?

I don’t know how I got this idea it depended on the --debug build option, but it doesn’t.

[akoppela]

Why not use Debug.log directly?

[jerith]

Yeah, the fact that --debug isn’t needed to turn on Debug.log has been hard for me to remember too. I’ve had some debug statements show up in profiling, even (since toString is expensive for large data structures). So I wonder if Debug.log should be a no-op without --debug … ?

[mattpiz]

I don’t know what the future of elm 0.19 will be, but at the current state of elm debugger I think we should keep it in normal compilation, especially since now we also have the --optimize option.

The performance cost implied by the --debug option (which keep the full history of events) is simply to high to only allow Debug.log in this mode.

Maybe --debug should be --time-travel.

[crazymykl]

Maybe --debug should be --time-travel .

I disagree with this nomenclature; the debugger no longer allows actual time travel, only rewinding to view past states.

[Viir]

the debugger no longer allows actual time travel, only rewinding to view past states.

Did it support branching off in the past? Or something else that is not supported anymore?

[rupert]

Did it support branching off in the past? Or something else that is not supported anymore?

It used to, but someone went back in time and distracted the developer with a shiny new project as he was about to submit that patch, and it never made it into the release.

[jerith]

Yeah, I was glad to see that --optimize turns of Debug.* in 0.19.

[mattpiz]

Maybe --record then is better. Though I could argue that the best time travel scenarios are the one that do not change past events