Hi Darren,
Stepping through the generated code with a conventional debugger (e.g.
in chrome) is not very informative at all; you won't be able to
reconcile the SJS code you're stepping over by looking at what is
being executed. The level of abstraction of the generated code is such
that even source maps wouldn't be much help enabling a conventional
debugger, so we have no plans of supporting them.
We *do* have good exception support in SJS:
When an exception is thrown, SJS provides a proper SJS stack trace
that spans asynchronous invocations, and (for conductance) even spans
client and server. So e.g. if in your browser you make an asynchronous
call to some function on the server, and deep down in the server code
this throws an exception, then you'll get to see the whole
client+server stack trace in the client.
We did initially have plans to write a custom debugger that allows
stepping through SJS code but this work has been put on the back
burner as we found that in practice, for dynamic languages, editing
the code and inserting 'console.log'-style debugging is a good
alternative. Adding statements like
if (some_condition) console.log("variable xxx is now #{xxx .. @inspect}")
allows for very targeted debugging without having to step through tons of code.
Another debugging trick that SJS has up its sleeve is that you can
easily slow code down by inserting 'hold(xxx)' statements in strategic
places. This makes it e.g. possible to better isolate race conditions
in concurrent code paths.
Cheers,
Alex
> --
> You received this message because you are subscribed to the Google Groups
> "StratifiedJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
stratifiedjs...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.
--
Alexander Fritze
http://onilabs.com