@darwin: okay, so: (1) cljs devtools = pretty-printed data in console; javascript names in stackframe, javascript data in view source (2) dirac devtools = pretty-printed data in console; pretty-printed names in stackframe; pretty-printed data in view source ?
atleast the vars are observable in the "scope" sidebar, so it's not a complete loss; I can tolerate this
alright, so cljs devtools works fine in remote debugging
and it's awesome
dirac, I guess dirac I'll give up
@darwin: https://github.com/binaryage/cljs-oops/search?p=2&q=ocall&utf8=%E2%9C%93 <-- is there a list of examples for how to use ocall ? the readme.md has screenshots of oget/oset! , but I can't find docs ofr ocall anywhere
not exactly, cljs-devtools is a collection of enhancements that can be implemented in javascript, for example :formatters feature leverages Custom Formatters subsystem available in Chrome DevTools since 2015: https://github.com/binaryage/cljs-devtools/blob/master/docs/faq.md
Dirac is a full-blown fork of Chrome DevTools which adds stuff which cannot be implemented directly
custom formatters are currently presented in console and “scope” view of “Sources Panel”, they are not presented as inline data in source view
Dirac modifies DevTools to additionally present them in source view
yes, I didn’t document it yet, it works similar to javascript .call, it does “this” retargeting, which is something you would normally do by hand: https://github.com/binaryage/cljs-oops/releases/tag/v0.5.0 you can get some inspiration here: https://github.com/binaryage/cljs-oops/blob/master/test/src/tests/oops/main.cljs#L291
@darwin : cljs devtools, by itself, suprisingly does alot; if you were to estimate, how many times harder is groking dirac codebase than groking cljs devtools codebase ?
(dirac seems too hard to jump in; I'm considering hacking on cljs dev tools myself for mobile needs)
why don’t you just look?
As you can guess Dirac is definitely more complex, but both are quite compex
cljs-devtools taps into ClojureScript internals a lot
@darwin: my question definitely looks lazy, but it's because I know so little about devtool internals that I'm not even sure how to estimate it
I think you need a goal first, a feature you want to implement, a bug you want to fix maybe, it does not make sense to me just to read the code for the sake of it
@darwin: I'll think of a featureI absolutely need, then I'll look intto cljs devtools