dirac

Dirac v1.7.2 is out: https://github.com/binaryage/dirac/releases/tag/v1.7.2
richiardiandrea 2017-02-08T02:57:46.002005Z

By the way I pushed a release (`0.2.0`) version this weekend @qqq

qqq 2017-02-08T03:14:45.002006Z

@richiardiandrea : I feel guilty about the fact I'm not even paying you for support contract. // Github needs to implement this feature.

richiardiandrea 2017-02-08T03:15:49.002007Z

@qqq I am sure we can arrange some way if you really want to ah ah

qqq 2017-02-08T03:16:13.002008Z

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.

richiardiandrea 2017-02-08T03:16:35.002009Z

That's a neat idea

qqq 2017-02-08T03:17:51.002010Z

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"

richiardiandrea 2017-02-08T03:19:18.002011Z

A boot task that pays you some small amount every time it pulls a new dep is cool

qqq 2017-02-08T03:20:05.002012Z

the tech is theoretically all there; we just need every dependency to attach a bitcoin address to it

qqq 2017-02-08T03:20:18.002013Z

the main problem is probably the lack of devs owning bitcoins (I certainly own none)

richiardiandrea 2017-02-08T03:26:16.002014Z

Yeah but coinbase is big enough I guess

danielsz 2017-02-08T05:27:12.002015Z

@darwin I encountered the same error as @adamfrey , the one that says "Uncaught TypeError: Cannot read property 'addExtensions' of undefined", source: <chrome-devtools://devtools/bundled/devtools_compatibility.js> (57)

danielsz 2017-02-08T05:28:35.002016Z

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.

danielsz 2017-02-08T05:28:48.002017Z

So I can't use it. šŸ˜ž

danielsz 2017-02-08T05:30:07.002018Z

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)

danielsz 2017-02-08T05:30:23.002019Z

And: [<http://browser_plugin_guest.cc|browser_plugin_guest.cc>(443)] Attempting to require callback on nonexistent surface

danielsz 2017-02-08T22:19:41.002039Z

Some more log digging inside Chromium reveal the following messages: at Object.Protocol.InspectorBackendExtensionMode.loadFromExtensionIfNeeded (inspector.js:4597)

2017-02-08T22:20:26.002040Z

@danielsz this sounds like an older version of Chromium in play

2017-02-08T22:20:40.002041Z

are you sure you are running the latest canary?

danielsz 2017-02-08T22:21:08.002042Z

On Linux, there is no Canary.

danielsz 2017-02-08T22:21:15.002043Z

I run Chromium Version 56.0.2924.87 (64-bit)

2017-02-08T22:22:14.002044Z

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

2017-02-08T22:23:18.002046Z

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

2017-02-08T22:24:01.002047Z

ah, it is debian

danielsz 2017-02-08T22:24:23.002048Z

Ah, OK, that's nice to know. There is a dev package in Arch too. I better test it with that, then.

2017-02-08T22:25:35.002052Z

there used to be google-chrome-unstable package, not sure about your Arch tough

2017-02-08T22:26:28.002054Z

also dirac releases contain direct links to precompiled likely-compatible linux versions, see Rolling DevTools sections: https://github.com/binaryage/dirac/releases

danielsz 2017-02-08T22:30:26.002056Z

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?

2017-02-08T22:31:17.002057Z

it's been a challenge, ideas welcome šŸ™‚

danielsz 2017-02-08T22:33:46.002058Z

Well, at least your name is apt, as befits the father of evolution.

danielsz 2017-02-08T22:34:27.002059Z

I suppose at one point things will slow down.

danielsz 2017-02-08T22:34:43.002060Z

I mean, that's how things work, don't they?

2017-02-08T22:37:07.002061Z

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

danielsz 2017-02-08T22:44:41.002063Z

Interesting. Out of curiosity, what's your view on weasel + piggieback? Is it a good foundation? Are they evolving too?

danielsz 2017-02-08T22:47:55.002065Z

I sometimes hear they it's brittle, but I don't have much experience with them.

2017-02-08T22:49:21.002066Z

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

2017-02-08T22:50:41.002067Z

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

2017-02-08T22:52:16.002070Z

all these tools and libraries have place and were super-important in the early days at least

danielsz 2017-02-08T22:54:39.002071Z

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.

danielsz 2017-02-08T22:57:19.002072Z

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.

2017-02-08T23:02:42.002074Z

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.

danielsz 2017-02-08T23:07:08.002075Z

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.

danielsz 2017-02-08T23:34:26.002076Z

Looks much better after installing google-chrome-dev on Arch. šŸ™‚

2017-02-08T23:35:16.002077Z

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

2017-02-08T23:35:49.002078Z

it is good, but might be overhelming for new comers, especially people coming from Javascript without prior exposure to Java

danielsz 2017-02-08T23:35:54.002079Z

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.

danielsz 2017-02-08T23:36:07.002080Z

I see Agent connected in the console.

2017-02-08T23:37:50.002081Z

Iā€™m not familiar with boot tasks, try to install dirac by hand in your app

2017-02-08T23:38:04.002082Z

just calling dirac.runtime.core/install! or something like that

danielsz 2017-02-08T23:38:19.002083Z

Ah, awesome, let me try that.

2017-02-08T23:40:29.002088Z

(not a new release, just fixed the link)