dirac 2017-05-04

@ksmithbaylor has joined the channel

I'm having some trouble using dirac with my figwheel project. Does anyone have time to help me out?

sorry, not right now, maybe in 2hrs

did you follow dirac-sample project?

does it work for you?

Thanks! I've tried to incorporate the config from that project, but I'm fairly new to Clojure/ClojureScript and some of it is going over my head.

I've got a :repl profile with the config from the sample project.

maybe you could simply share it on github, I would clone it and test on my machine, and help to fix it

running lein repl successfully starts the dirac agent, but I'm not sure where figwheel comes in. Do I still run lein figwheel?

Sure! that would be awesome if you've got some time. It's an electron project, originally forked from https://github.com/Gonzih/cljs-electron

I replaced the Procfile with an npm start command. I'll add some notes to my readme about how to start up the project

to answer your question, yes, you still run lein figwheel, but figwheel should be configure just to hot-reloading, you don’t want figwheel’s REPL

Yeah, I set :repl false in the figwheel config.

but I’m not sure about figwheel in electron context

I just pushed up a dirac branch to my project with my initial attempts

Yeah, it's a bit weird. if you have yarn (https://yarnpkg.com/en/docs/install) installed, you can start figwheel along with a process that starts/stops electron with yarn start

after doing lein deps and yarn install at the project root

ok, looking at it, don’t have run-p, ah, ok

I'm coming from the JS world, so yarn was the most natural way for me to set up the dev processes

ok, no prob, I’ve heard good things about it

yeah 🙂

thanks for taking the time, by the way!

So the electron process code is under electron_src, and the frontend code is under ui_src.

There's also dev_src, which I haven't touched from the boilerplate. I'm not quite sure what its role is, but it starts figwheel/watch-and-reload so I suspect that may be what I'm missing.

well you have to start electron’s V8 with debugger port enabled, I don’t see it in the yarn start output

and then use normal chrome canary + dirac devtools extension to connect to it

I'll add the remote debugging flag

should be something like --remote-debugging-port=9222

yep, I just added it. let's see....

No luck after refreshing the dirac instance I have running from canary

that flag didn’t work, if it worked, this should be reachable: http://localhost:9222/json

I actually do get a response from that url:

[ {
   "description": "",
   "faviconUrl": "",
   "id": "1d1cce81-40d3-4809-b1dd-9f63ffc6b32b",
   "title": "New Tab",
   "type": "page",
   "url": ""
}, {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/d5d08ac7-2968-4426-bccb-4c4d8b4cf46b",
   "id": "d5d08ac7-2968-4426-bccb-4c4d8b4cf46b",
   "title": "#",
   "type": "page",
   "url": "",
   "webSocketDebuggerUrl": ""
}, {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/2d33482d-4781-40d2-887c-30f3547cf252",
   "id": "2d33482d-4781-40d2-887c-30f3547cf252",
   "title": "Dirac DevTools",
   "type": "background_page",
   "url": "",
   "webSocketDebuggerUrl": ""
}, {
   "description": "",
   "id": "1bbec51e-5363-4601-bec0-d83e7ef362c5",
   "title": "Worker pid:21621",
   "type": "service_worker",
   "url": ""
}, {
   "description": "",
   "id": "ac371b30-1c12-4c5d-ab87-5ff531c65d3f",
   "title": "Worker pid:21621",
   "type": "service_worker",
   "url": ""
} ]

ok, good, so I did, something wrong

Although canary is also running with remote debugging enabled. Should I turn that off?

push your changes pls

Okay, I'll push it up

you want dirac to connect to electron’s V8

So I just quit chrome canary, and the localhost:9222/json no longer returns a response. So it doesn't seem like Electron has remote debugging enabled after all

aha, so it was your canary

Oh, I did the switch wrong

hang on

ok, no problem, I really have to run (literally)

will be back in 1,5 hrs

there we go! Sorry to keep you. I'll play with it some, I think you've got me going in the right direction

you have to make electrong expose remote debugging protocol at port 9222

That's working now 🙂

and then dirac will attempt to connect to it

good luck, in troubles try to look here as well: https://github.com/binaryage/dirac/blob/master/docs/node.md and in the FAQ

internal devtools console of Dirac window could also give you some more info

So by opening http://localhost:3449/index.html in canary, dirac is able to connect (with some obvious errors like require is not defined since it's no longer in electron). So that's good news! Just need to figure out how to bridge over to my other V8 instance.

This is so cool 😄

is there something around for build clojurescript projects using npm or yarn already?

@richiardiandrea not that I know of. I am still using leiningen, and just scripting it with yarn. But I know there's a lot of activity around tools like lumo that should theoretically provide a completely jvm-less build process for cljs

@ksmithbaylor thanks for confirming!

@darwin so, quick update. I was able to connect to my electron process by going to http://localhost:9222 directly from canary (in a new tab). So remote debugging is definitely on and listening on the correct port. But Dirac still does not connect to it. I hovered over the tooltip (which had a red !), and saw the following error message:

I confirmed that the debugger id (e5d4a406...) was the same one that showed up in the URL when I opened it in a new tab.

Even though http://localhost:9222/json does in fact return json

My context list from that endpoint looks like:

[ {
   "description": "",
   "id": "e5d4a406-fcc3-4a7e-8859-1494c3daeee3",
   "title": "YNAB Helper",
   "type": "page",
   "url": "file:///Users/kevin/main/code/ynab-reports-cljs/resources/public/index.html"
} ]

Is the fact that it's a file:// url messing it up?

I don’t know, but you are correct that the code you pointed out is responsible from selecting correct backend-url from the JSON

recently I have added a support for node situation, but I’ve never tested it with electron

but we can select it manually as well, let me look it up[

Seems like if another condition were added to that or to account for this case, it might help

yes, currently dirac looks at your “app’s web page url” and tries to find a record in that JSON which matches it

the problem with node was that the record had file-system path instead of url, if I recall correctly

and with electron it is I guess something similar

it does not match perfectly according to dirac rules

The html page is served from the filesystem, but loading that url (file:///Users/kevin/main/code/ynab-reports-cljs/resources/public/index.html) in a new tab does load the page

Strange, it does match that URL exactly

that does not work in this case, :url of your electron’s context is file:///Users/darwin/farm/ynab-reports-cljs/resources/public/index.html

so it falls back to node-js resolution, as you correctly figured out

so we need to add special case there, or make the main resolution more flexible

oh, got it.

but I can give you a work around for now

open it in your canary in a blank window as normal url

replace extension id with your dirac extension id, and ws parameter with ws parameter you can see in the JSON

this should start it, but then you will probably have another problem - V8 in electron is probably quite old (several months) but devtools code in dirac is bleeding edge

you might need to downgrade dirac extension to similar version of your debugger protocol

have to go, will be back in 30mins

Okay, thanks again!

I’m back again, did it work?

this url somewhat works for me

I had to step away, and I'm having trouble spinning everything up again.

it still spits some compatibility errors

Do I need to start figwheel first, or lein repl?

important point is to close Electron’s app devtools

only one debugger protocol client can be connected

I had to start canary with a different remote debugger port (I chose 9223) in order for my electron context to show up as inspectable from localhost:9222

you don’t need to open debugger port on canary (in your scenario)

that’s needed only in normal scenario where you are connecting back to the same canary to debug pages in

There we go! I think I'm seeing the same thing you are now. Some compatibility issues, but mostly working!

I see: Request Overlay.enable failed

and: Request Overlay.setShowViewportSizeOnResize failed

I think downgrading dirac to match the V8 in electron should resolve that, right?

yep, I'm seeing those two as well

yes, depends how old it is, devtools support node.js since january

if it is older than that, you are probably out of luck

I'll check

also you have to run lein repl with dirac agent installed inside your nrepl server

and that does not seem to be the case in current code

wait, I will run it on the side

hmm. I thought that's what my :repl settings did

Is there a way to avoid needing to run lein figwheel and lein repl separately?

ok, repl works, I just thought you have it inside your yarn start

I mean Dirac’s REPL was able to connect to lein repl+dirac-agent

it has some problem with source maps as well….

right. I'll add it to my yarn start to automate it. Any difference as far as which one needs to run first? (figwheel vs repl)

I got tons of errors

Yeah, same here 😕

I may not have source maps configured in my project

there should be no difference

figwheel is your compiler, so it should finish its job before you load the page, repl is independent

to fix the source-maps issue, you would need to somehow tell electron to put there relative urls instead of full file-system paths

or maybe cljs compier

Would it work to make them inline source maps?

to inline source-maps you would have use my patch CLJS-1902

I'll try the separate sourcemap server approach

node.js had the same issue

Figwheel doesn't like :source-map-asset-path:

hm, that’s figwheel’s problem, it should be just a warning

Seems like it's changed to :source-map-path recently

those are different options

it is not used very often, for me this was the first case I needed it

looks like upgrade to chrome 58 is a work in progress: https://github.com/electron/electron/tree/chrome58

which would be 58.0.3029.96

but they are not there yet, so right now you should try to go with some earlier versions

Yeah. Well I think I'm in good shape for now, sans a few minor issues. Thank you so much for taking the time to help me out!

I’m glad I could help, I was curious myself, unfortunately I’ve never tried dirac + electron, and probably nobody else

lol yeah

it's a subset of a subset of a small community

so you are exploring wild area here 🙂 and give that you just started with cljs and whole tooling around it, well played 🙂

haha thanks

also electron, devtools and chrome are all in constant flux, that does not add to robustness 🙂

so expect breakages along the way, the most important is to keep versions relatively close together, here you must follow electron

So out of curiosity, do you know of any other ways I could get a nicer cljs repl than the built-in terminal one? I'm mostly fine with the normal cljs devtools, and was mostly looking to dirac to get a nicer gui experience for my repl

Since this is sort of unknown territory, I may stick with the normal cljs devtools and (now that I have nrepl working) explore other options for a repl

maybe in this case I would stick with Figwheel’s Terminal REPL

and use embedded electron’s devtools

you will avoid a lot of headaches

btw. I just checked navigator.userAgent in that electron app: “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) ynab-helper/0.1.0 Chrome/56.0.2924.87 Electron/1.6.7 Safari/537.36”

Chrome/56.0.2924.87 is damn old

lol yeah

in internet years at least 😛

one last recommendation: you definitely want to use https://github.com/binaryage/cljs-devtools

yep! I'm already using that, and it's awesome! The "What's next?" at the bottom is what lead me to dirac

✅ 1

@salax has joined the channel

Hey @darwin, I’ve put my current tooling in a gist. Would you mind gaze on it and tell me what you think about this current setup? It’s rather scarse so a reader with no prior context would find it uneasy to grasp but I think you’ll understand this better than I ^^

(ha yeah, a link would be helpful ^^)

doesn’t re-frisk support preloads? that would be useful for :advanced builds

@piotr2b it looks good to me, I haven’t had chance to use re-frisk yet, also reloaded.repl is a new thing to me, will look into that

Indeed, you’re right about preloads for re-frisk. I opened an issue to ask them about it.

thanks for your review 🙂

np, good luck and keep us updated about cool tools you find