HN user

jpmonettas

58 karma
Posts2
Comments14
View on HN

Thanks! I started with cljfx and then moved to pure javafx, first because it wasn't straight forward for me to understand the performance overhead of cljfx under different scenarios (when using subscriptions and contexts), and second because I want to drag as few dependencies as possible so they don't conflict with debuggee one's.

Cool! I wrote something on the same spirit but for Clojure, called FlowStorm http://www.flow-storm.org/

For instrumentation, instead of an instrumenting agent it uses a fork of the official Clojure compiler (in Clojure you can easily swap compilers at dev) that adds extra bytecode. What is interesting about recording Clojure programs execution is that most values are immutable, so you can snapshot them by just retaining the pointers.

Edit: Since the OP demo is about exploring a web app for people interested in this topics I'm leaving a demo of FlowStorm debugging a web app also https://www.youtube.com/watch?v=h8AFpZkAwPo

Author here. Thanks for the feedback! and yeah I agree adding those features to the landing page is a good idea. I'll add them.

Regarding tools that offer similar capabilities in other languages, I'm not aware, and I have my opinion on why this could be https://github.com/jpmonettas/flow-storm-debugger#arent-omni... but I could be wrong.

But there are time travel debuggers for other languages for sure, and some omniscient debuggers too, but with different capabilities.

Nice, thanks for the links.

Yeah I don't know how stickers trace code, but FlowStorm tracing debugger takes advantage of the immutable data structures used everywhere and by default in Clojure. You can then instrument entire code bases, run them, and tracing is just a matter of retaining(leaking) pointers of every intermediate expression so the GC doesn't collect them. I don't think this is possible when working with mutable objects, since then only way would be to somehow serialize the objects involved at every step so you can analyze the data later, which is prohibitively expensive in most situations.