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

@darwin I encountered the same error as @adamfrey , the one that says "Uncaught TypeError: Cannot read property 'addExtensions' of undefined", source: (57)

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: (1882)] Not implemented reached in void views::DesktopWindowTreeHostX11::MapWindow(ui::WindowShowState)

And: [(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)