By the way I pushed a release (`0.2.0`) version this weekend @qqq
@richiardiandrea : I feel guilty about the fact I'm not even paying you for support contract. // Github needs to implement this feature.
@qqq I am sure we can arrange some way if you really want to ah ah
I would actually be okay if, every time my boot project pulls a dependency, it pays the dev team behind the dependency $1.00 in dogecoin or something.
That's a neat idea
or maybe not every pull (since it's automatic), but something like "boot -pay-all-the-devs-because-my-code-just-did-something-awesome-and-I'm-in-a-really-good-mood"
A boot task that pays you some small amount every time it pulls a new dep is cool
the tech is theoretically all there; we just need every dependency to attach a bitcoin address to it
the main problem is probably the lack of devs owning bitcoins (I certainly own none)
Yeah but coinbase is big enough I guess
FYI I'm running all the latest versions, but I'm on Linux, and while Dirac indicates it connected successfully, the developer console is blank.
So I can't use it. š
Here are two related errors adjacent in the logs: <http://desktop_window_tree_host_x11.cc|desktop_window_tree_host_x11.cc>(1882)] Not implemented reached in void views::DesktopWindowTreeHostX11::MapWindow(ui::WindowShowState)
And: [<http://browser_plugin_guest.cc|browser_plugin_guest.cc>(443)] Attempting to require callback on nonexistent surface
Some more log digging inside Chromium reveal the following messages: at Object.Protocol.InspectorBackendExtensionMode.loadFromExtensionIfNeeded (inspector.js:4597)
@danielsz this sounds like an older version of Chromium in play
are you sure you are running the latest canary?
On Linux, there is no Canary.
I run Chromium Version 56.0.2924.87 (64-bit)
this wonāt work, you have to stick with the bleeding edge: https://github.com/binaryage/dirac/blob/master/docs/faq.md#why-should-i-use-recent-chrome-canary-with-dirac-devtools
my travis builds run on ubuntu and test against: Google Chrome: 58.0.3007.0 (Developer Build) (64-bit)
https://travis-ci.org/binaryage/dirac#L777
ah, it is debian
Ah, OK, that's nice to know. There is a dev package in Arch too. I better test it with that, then.
there used to be google-chrome-unstable
package, not sure about your Arch tough
https://www.ubuntuupdates.org/package/google_chrome/stable/main/base/google-chrome-unstable
also dirac releases contain direct links to precompiled likely-compatible linux versions, see Rolling DevTools sections: https://github.com/binaryage/dirac/releases
Oh, thanks, that's nice too. It's kind of interesting (and a bit crazy) to keep up with the changes. For you it must be even more annoying to have these APIs constantly changing, no?
it's been a challenge, ideas welcome š
Well, at least your name is apt, as befits the father of evolution.
I suppose at one point things will slow down.
I mean, that's how things work, don't they?
well, the devtools activity has beeb quite busy and there are no signs of a slowdown[1], but I hope protocol changes will be less frequent because now they commit to support node.js as well, which forces them to maintain more stable api between the frontend (UI) and backend (debugger) [1] https://github.com/binaryage/dirac/commits/devtools
Interesting. Out of curiosity, what's your view on weasel + piggieback? Is it a good foundation? Are they evolving too?
I sometimes hear they it's brittle, but I don't have much experience with them.
I donāt know full context, I came to ClojureScript from Javascript, never did any Java + Clojure before, unfortunately piggieback and weasel were solutions how to bolt CLJS REPL functionality on top of existing Clojure infrastructure, which required some hacks
for me piggieback is so ācleverā to the level it is incomprehensible for me, nREPL also adds a lot of complexity, but it is flexible
I did a brain dump here: https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#piggieback--weasel
all these tools and libraries have place and were super-important in the early days at least
You're the man. Fantastic document. @cemerick used to write some early foundational clojurescript, he's a great guy but not always easy to follow, I remember struggling with piggieback.
Sometimes I wonder if at some stage someone will decide to rewrite those foundations because that person thinks he can improve on it. If it makes sense, if it's worth it, maybe someone will do that.
I think there is inherent complexity in the task of building a full-featured ClojureScript REPL. A rewrite could make individual parts more understandable from REPL developerās point of view, but not much better from end-userās point of view. So it not worth it IMO.
I get that. It makes sense, and probably it's the reason nobody made the foolish attempt. Self-hosted Clojurescript is full of promises in terms of simpler tooling, but that's theory at this point I guess.
Looks much better after installing google-chrome-dev on Arch. š
in general I think good amount of tooling should be part of core development so that it is built on solid foundations and provides best user/developer-experience possible, but I think we donāt have man power for that right now, a single person (dnolen) cannot possibly handle everything, so he lets community to figure out more high-level tooling, like figwheel
it is good, but might be overhelming for new comers, especially people coming from Javascript without prior exposure to Java
Still trying to figure out why I see "Please install Dirac Runtime into your app and enable the :repl feature" despite running the (cljs-devtools) and (dirac) tasks in my boot pipleline.
I see Agent connected in the console.
Iām not familiar with boot tasks, try to install dirac by hand in your app
just calling dirac.runtime.core/install! or something like that
Ah, awesome, let me try that.
https://github.com/binaryage/dirac/blob/master/docs/installation.md#installation-from-code
(not a new release, just fixed the link)