Sayid Viability for CLJS?
Opened this issue · 11 comments
It appears that sayid does not currently support CLJS. Is there any technical reason for this? If not, I may be interested in helping make CLJS happen.
I think it's possible, but there's at least a couple different ways I could imagine it working. The first design question is whether you would want Sayid to straddle both the server and client, or if the clj and cljs would be separate. I'm struggling to come up with the right words to lay out my thoughts concisely.
By "straddle the server and client", I mean in a typical clj/cljs web-dev scenario, would you want a single instance of Sayid running on the jvm that can collect data from both the server and browser simultaneously and then display both in a single buffer? OR, "if the clj and cljs would be separate", then you would have Sayid running in only one environment, or two independent instances, each in their respective environment.
I've done a good amount of work in cljs, but am not nearly as familiar with the inner workings of all the various cljs REPLs. Implementing integrations for one may not cover all of them. Maybe other complications? I'm not sure.
👍 . Thanks for the info. I'm looking at the possibility of making a graphical front end for Sayid. Not entirely sure if I'll get support to do that, but if I do I'll be trying to contribute back Sayid for CLJS.
@JJ-Atkinson What would host the gui front-end? Browser?
Feel free to hit me up with any/all questions that I might be able to help with.
Not exactly sure. Either JFX or browser. In either case the viewer architecture will be a thin client sending back requests to the internal data of sayid. I find myself writing cljs programs alot though, and having a really good debugger would be the bomb :)
@JJ-Atkinson I just remembered that I'd seen this on reddit last year. Seems worth checking out before making any major time investments. I haven't used it, but README is impressive and compelling.
Very cool, I hadn't seen that yet. I'm trying it today as a daily driver :). Unfortunately it's still missing what I think could be the coolest feature: entire traces of a function call with multiple views. e.g. flame graph, tree view, timing, etc, and integration with something like reveal for value display.
@JJ-Atkinson @bpiel
I've been playing around with getting https://github.com/philoskim/debux to save it's output instead of printing it directly. The idea is to get something like https://github.com/day8/re-frame-debux that's not generic and not married to re-frame, so it can be displayed in Reveal or Portal or something new.
Sayid seems to do a similar thing, but coming at it from the top-down perspective, similar to flow-storm, but with no cljs support.
It seems to me that we all want basically the same things, but have implemented different ways to get there and built on top of dependencies that could be pulled out.
I still don't have a fully formed idea where to go from here but it seems to me like there is a common core in all of this, somewhere. I think we could all benefit if we could find that core and build on top of that instead of having multiple libs that can't use each others features.
common core in all of this
Yes, definitely. I have a uncontrollable tendency to always dig for better abstractions, so I'm with you. I think my dream scenario would involve some kind of common protocol&formats for omniscient debugging (not my term, but the most applicable one, as far as I can tell). The language server protocol and debug adapter protocol seem to have some traction, but of course, the debug component is focused on step-through debugging (which I have no interest in).
https://microsoft.github.io/debug-adapter-protocol/
I still don't have a fully formed idea where to go from here
I don't either. Although, out of necessity, I'm doing some vaguely related experiments that may or may not yield something in this area some day. A bit of a tangent, but: I'm working on a distributed VM, using clojure&rust. Debugging rust is notoriously difficult, so I've sometimes had some super-hacky things going on where I'm able to pipe trace data, captured in rust, out to a clojure/jvm instance and then use sayid (and emacs) to examine the trace tree. Naturally, as the project proceeds, I'll make further investments in this area. Because I'd want to maximize re-usability across the platforms I'm using (clojure, rust and this VM), I'd need some standardized protocol&formats that would be friendly to each of those.
find that core
I guess what I'm trying to say is: I understand and agree with you. And, maybe I'm even working on this, in my own way. But, unfortunately, nothing I'm doing is likely to help anyone anytime soon, and I'm not available to put any significant time toward anything else. But, I still enjoy the discussions!
@Cyrik I pretty much agree. I'm interested in putting some time towards that project and making it OSS. Unfortunately I'm tied up right now with R&D for an underlying project, and any time I throw this direction is dependent on success of the R&D project. I'm about 3 months away from any serious time commitment. Though, I'm more than willing to chat and maybe see if we can't identify what the fully formed idea would look like. Something that you may be interested in: https://opentracing.io
@bpiel @JJ-Atkinson so because there weren't enough tracing implementations, I wrote omni-trace ...
kidding aside, I was playing around with Sayid as cljc files and wasn't getting anyway, so I started from scratch. The current idea is to get some more functionality in and then try to get the tracing part to be pluggable.
I'm open to suggestions/requests