I've done a lot of library work lately where Cmds and Subs haven't been a part of the project, so yes, in a project where the main way to run your code is through fuzz tests, breakpoints would be immensively helpful.
That being said, having a Debug.breakpoint function is just a convenience, not a necessity. mandag 24. oktober 2016 19.34.53 UTC+2 skrev Nick H følgende: > > Don't forget, the time-travelling debug mode is coming in 0.18. Do you > think setting breakpoints like this is still going to be useful? > > On Mon, Oct 24, 2016 at 5:59 AM, Robin Heggelund Hansen < > [email protected] <javascript:>> wrote: > >> Elm, as great as it is, doesn't save you from debugging every once in a >> while. The one option we have now, is logging. Logging is great, but it can >> quickly become painful in loops. Since Elm compiles to a single JS file >> with long mangled names, setting a breakpoint from the code would sometimes >> be the simplest way to properly debug your code. The generated JS isn't >> that hard to understand either, it's a series of vars and function calls >> for the most part. >> >> lørdag 22. oktober 2016 13.49.52 UTC+2 skrev John Orford følgende: >>> >>> It never occurred to me to debug the generated JS... can you sketch out >>> your use case a bit more? >>> >>> On Sat, 22 Oct 2016 at 11:19 Robin Heggelund Hansen <[email protected]> >>> wrote: >>> >>>> While I spend a lot less time debugging in Elm than in JS, sometimes >>>> it's useful to debug the generated Javascript. >>>> >>>> This would be greatly simplified, if it was possible to add a >>>> `debugger;` statement to the code. >>>> >>>> What do people think of a new function added to the Debug module of >>>> elm-lang/core, called breakpoint. It would work like the identity >>>> function, >>>> but also include the `debugger;` statement, causing a breakpoint to happen >>>> when the browsers dev-tools are open. >>>> >>>> used like: >>>> >>>> ``` >>>> faultyFunction a b = >>>> let >>>> _ = Debug.breakpoint () >>>> in >>>> a + b >>>> ``` >>>> >>>> Granted, this would cause a breakpoint to happen in the actual >>>> Debug.breakpoint function, but since that function is very small, stepping >>>> out of it is no big deal. The only other option I can think of is compiler >>>> support, but I'm unsure how hard this would be to include. >>>> >>>> Opinions? >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Elm Discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
