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
My project is here: https://github.com/ksmithbaylor/ynab-reports-cljs
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
https://github.com/binaryage/dirac-sample/blob/master/project.clj#L162
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!
sure, np
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
oh, ok! I'm adding flags to electron's V8 here: https://github.com/ksmithbaylor/ynab-reports-cljs/blob/master/electron_src/electron/core.cljs#L22
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": "<https://www.google.com/favicon.ico>",
"id": "1d1cce81-40d3-4809-b1dd-9f63ffc6b32b",
"title": "New Tab",
"type": "page",
"url": "<chrome://newtab/>"
}, {
"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": "<chrome-extension://kbkdngfljkchidcjpnfcgcokkbhlkogi/devtools/front_end/inspector.html?devtools_id=1&dirac_flags=111111111&ws=localhost%3A9222%2Fdevtools%2Fpage%2F1d1cce81-40d3-4809-b1dd-9f63ffc6b32b&backend_api=1&backend_css=1>",
"webSocketDebuggerUrl": "<ws://localhost:9222/devtools/page/d5d08ac7-2968-4426-bccb-4c4d8b4cf46b>"
}, {
"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": "<chrome-extension://kbkdngfljkchidcjpnfcgcokkbhlkogi/background.html>",
"webSocketDebuggerUrl": "<ws://localhost:9222/devtools/page/2d33482d-4781-40d2-887c-30f3547cf252>"
}, {
"description": "",
"id": "1bbec51e-5363-4601-bec0-d83e7ef362c5",
"title": "Worker pid:21621",
"type": "service_worker",
"url": "<https://www.google.com/_/chrome/newtab-serviceworker.js>"
}, {
"description": "",
"id": "ac371b30-1c12-4c5d-ab87-5ff531c65d3f",
"title": "Worker pid:21621",
"type": "service_worker",
"url": "<https://www.google.com/_/chrome/newtab-serviceworker.js>"
} ]
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
no
Okay, I'll push it up
you want dirac to connect to electron’s V8
pushed
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
not electron
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
I’m back
Hey!
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?
Relevant code in dirac is here: https://github.com/binaryage/dirac/blob/274b3e3a3d8127bc13f5ea5a28e15b40e51e2ac2/src/background/dirac/background/debugging.cljs#L74
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
here I try to do exact :url match: https://github.com/binaryage/dirac/blob/master/src/background/dirac/background/debugging.cljs#L71
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
and node-js resolution, takes only :type
“node” contexts for consideration:
https://github.com/binaryage/dirac/blob/master/src/background/dirac/background/debugging.cljs#L64
so it also fails
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
<chrome-extension://kbkdngfljkchidcjpnfcgcokkbhlkogi/devtools/front_end/inspector.html?devtools_id=1&dirac_flags=111111111&ws=localhost%3A9222%2Fdevtools%2Fpage%2Ffe0a4e3e-78dd-462b-b140-e2a83a4a24e9&backend_api=1&backend_css=1>
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
see the FAQ
have to go, will be back in 30mins
Okay, thanks again!
I’m back again, did it work?
this url somewhat works for me <chrome-extension://kbkdngfljkchidcjpnfcgcokkbhlkogi/devtools/front_end/inspector.html?devtools_id=1&dirac_flags=111111111&ws=localhost:9222/devtools/page/df847fdd-c60e-4781-9281-0f8038df9835>
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
I see
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?
see this: https://github.com/binaryage/dirac/blob/master/docs/node.md#source-maps
to inline source-maps you would have use my patch CLJS-1902
it is doable
I'll try the separate sourcemap server approach
this was my approach in dirac-sample: https://github.com/binaryage/dirac-sample/blob/master/scripts/run-demo-node-source-maps-server.sh https://github.com/binaryage/dirac-sample/blob/master/project.clj#L94
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
I doubt
https://github.com/clojure/clojurescript/wiki/Compiler-Options#source-map-path
https://github.com/clojure/clojurescript/wiki/Compiler-Options#source-map-asset-path
those are different options
oops
figwheel simply forgot to add the other one: https://github.com/bhauman/lein-figwheel/blob/master/sidecar/src/figwheel_sidecar/schemas/cljs_options.clj#L829
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
cool!
that would roughly match https://github.com/binaryage/dirac/releases/tag/v1.2.0
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
yeah
you will avoid a lot of headaches
yes.
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 😛
that would match https://github.com/binaryage/dirac/releases/tag/v0.8.4 from November
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
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 ^^
ok
https://gist.github.com/piotr-yuxuan/7171a13570951871a3fd138b65febafb
(ha yeah, a link would be helpful ^^)
doesn’t re-frisk support preloads? that would be useful for :advanced builds
btw. interesting approach with https://gist.github.com/piotr-yuxuan/7171a13570951871a3fd138b65febafb#file-this-project-clj
@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