5 ms·

Well ... sort of. The Clojure debugging story is still only OK and under development. Any ClojureScript debugging story really should integrate with existing to

Well ... sort of. The Clojure debugging story is still only OK and under development. Any ClojureScript debugging story really should integrate with existing tools - I have some ideas about that brewing here: http://dev.clojure.org/display/design/ClojureScript+Debugger http://dev.clojure.org/display/design/ClojureScript+Debugger

jlongster 15y ago
Ah, I see. I'd probably take the route of allowing ClojureScript to be run as normal Clojure, but I guess the problem is that you don't have access to the browser environment. Debugging browser-based apps can be tricky because of that.
- asmala 15y ago
  Actually, to a large extent you can have access to the browser environment. See e.g. the ClojureScript One video and guide: http://www.clojurescriptone.com/ http://www.clojurescriptone.com/.
gruseom 15y ago
We've written a Parenscript/JS debugger that runs in Emacs and interacts with V8 via Node.js as an Emacs subprocess. We started off using the JSON debugging protocol you mention on that linked page, but had to abandon it because it insisted on printing large arrays in their entirety, which hangs V8 if you ever encounter a large array as a local variable. In the end, we found V8's in-process debugging API much easier to work with. The JSON protocol is just a (bloated) wrapper around that, which gives less control and doesn't work particularly well. (I'm not aware of any systems out there that actually use it.) Of course, if you drop the JSON wrapper, you have to write your own server-side code and pass your own messages to the client. But in return, you have fewer hoops to jump through, and it felt to me like less overall work to make a good debugging client this way. The in-process API isn't documented but it isn't hard to figure out from the V8 source.
dangoor 15y ago
Another option is source mapping, allowing the browser's tools to map from the JavaScript that is running over to the original source files (with line and column mapping). Some support for that has landed in WebKit, and we have patches for some integration in Firefox (remarkably enough with the same file format!)

jlongster 15y ago

Ah, I see. I'd probably take the route of allowing ClojureScript to be run as normal Clojure, but I guess the problem is that you don't have access to the browser environment. Debugging browser-based apps can be tricky because of that.

asmala 15y ago
Actually, to a large extent you can have access to the browser environment. See e.g. the ClojureScript One video and guide: http://www.clojurescriptone.com/ http://www.clojurescriptone.com/.

gruseom 15y ago

We've written a Parenscript/JS debugger that runs in Emacs and interacts with V8 via Node.js as an Emacs subprocess. We started off using the JSON debugging protocol you mention on that linked page, but had to abandon it because it insisted on printing large arrays in their entirety, which hangs V8 if you ever encounter a large array as a local variable. In the end, we found V8's in-process debugging API much easier to work with. The JSON protocol is just a (bloated) wrapper around that, which gives less control and doesn't work particularly well. (I'm not aware of any systems out there that actually use it.) Of course, if you drop the JSON wrapper, you have to write your own server-side code and pass your own messages to the client. But in return, you have fewer hoops to jump through, and it felt to me like less overall work to make a good debugging client this way. The in-process API isn't documented but it isn't hard to figure out from the V8 source.

dangoor 15y ago

Another option is source mapping, allowing the browser's tools to map from the JavaScript that is running over to the original source files (with line and column mapping). Some support for that has landed in WebKit, and we have patches for some integration in Firefox (remarkably enough with the same file format!)