Fork me on GitHub
#dirac
<
2017-05-04
>
ksmithbaylor14:05:58

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

darwin15:05:21

sorry, not right now, maybe in 2hrs

darwin15:05:33

did you follow dirac-sample project?

darwin15:05:37

does it work for you?

ksmithbaylor15:05:43

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.

ksmithbaylor15:05:28

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

darwin15:05:27

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

ksmithbaylor15:05:33

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

ksmithbaylor15:05:51

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

ksmithbaylor15:05:07

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

darwin15:05:34

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

ksmithbaylor15:05:00

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

darwin15:05:35

but I’m not sure about figwheel in electron context

ksmithbaylor15:05:35

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

ksmithbaylor15:05:44

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

ksmithbaylor15:05:14

after doing lein deps and yarn install at the project root

darwin15:05:20

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

ksmithbaylor15:05:51

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

darwin15:05:08

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

ksmithbaylor15:05:22

thanks for taking the time, by the way!

ksmithbaylor15:05:38

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

ksmithbaylor15:05:29

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.

darwin15:05:27

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

darwin15:05:41

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

ksmithbaylor15:05:30

I'll add the remote debugging flag

darwin15:05:59

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

ksmithbaylor15:05:38

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

ksmithbaylor15:05:12

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

darwin15:05:54

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

ksmithbaylor15:05:24

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": ""
} ]

darwin15:05:38

ok, good, so I did, something wrong

ksmithbaylor15:05:03

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

darwin15:05:03

push your changes pls

ksmithbaylor15:05:15

Okay, I'll push it up

darwin15:05:22

you want dirac to connect to electron’s V8

ksmithbaylor15:05:51

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

darwin15:05:09

aha, so it was your canary

darwin15:05:12

not electron

ksmithbaylor15:05:16

Oh, I did the switch wrong

darwin15:05:36

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

darwin15:05:41

will be back in 1,5 hrs

ksmithbaylor15:05:56

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

darwin15:05:58

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

ksmithbaylor15:05:05

That's working now 🙂

darwin15:05:06

and then dirac will attempt to connect to it

darwin15:05:31

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

darwin15:05:00

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

ksmithbaylor15:05:15

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.

ksmithbaylor15:05:40

This is so cool 😄

richiardiandrea16:05:35

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

ksmithbaylor16:05:57

@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

ksmithbaylor17:05:36

@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:

ksmithbaylor17:05:41

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.

ksmithbaylor17:05:23

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

darwin17:05:34

I’m back

ksmithbaylor17:05:16

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"
} ]

ksmithbaylor17:05:28

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

darwin17:05:23

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

darwin17:05:51

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

darwin17:05:25

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

ksmithbaylor17:05:16

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

darwin17:05:57

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

darwin17:05:24

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

darwin17:05:33

and with electron it is I guess something similar

darwin17:05:44

it does not match perfectly according to dirac rules

ksmithbaylor17:05:23

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

ksmithbaylor17:05:49

Strange, it does match that URL exactly

darwin17:05:50

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

darwin17:05:22

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

darwin17:05:08

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

darwin17:05:13

so it also fails

darwin17:05:30

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

darwin17:05:02

but I can give you a work around for now

darwin17:05:16

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

darwin17:05:42

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

darwin17:05:26

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

darwin17:05:47

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

darwin17:05:53

see the FAQ

darwin17:05:01

have to go, will be back in 30mins

ksmithbaylor17:05:17

Okay, thanks again!

darwin18:05:43

I’m back again, did it work?

darwin18:05:39

this url somewhat works for me

ksmithbaylor18:05:01

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

darwin18:05:07

it still spits some compatibility errors

ksmithbaylor18:05:12

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

darwin18:05:23

important point is to close Electron’s app devtools

darwin18:05:38

only one debugger protocol client can be connected

ksmithbaylor18:05:32

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

darwin18:05:01

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

darwin18:05:36

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

ksmithbaylor18:05:53

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

darwin18:05:11

I see: Request Overlay.enable failed

darwin18:05:19

and: Request Overlay.setShowViewportSizeOnResize failed

ksmithbaylor18:05:20

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

ksmithbaylor18:05:25

yep, I'm seeing those two as well

darwin18:05:48

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

darwin18:05:01

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

darwin18:05:35

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

darwin18:05:54

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

darwin18:05:34

wait, I will run it on the side

ksmithbaylor18:05:37

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

ksmithbaylor18:05:59

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

darwin18:05:49

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

darwin18:05:11

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

darwin18:05:11

it has some problem with source maps as well….

ksmithbaylor18:05:23

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)

darwin18:05:23

I got tons of errors

ksmithbaylor18:05:27

Yeah, same here 😕

ksmithbaylor18:05:38

I may not have source maps configured in my project

darwin18:05:51

there should be no difference

darwin18:05:19

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

darwin18:05:13

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

darwin18:05:44

or maybe cljs compier

ksmithbaylor18:05:54

Would it work to make them inline source maps?

darwin18:05:21

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

darwin18:05:15

it is doable

ksmithbaylor18:05:31

I'll try the separate sourcemap server approach

darwin18:05:22

node.js had the same issue

ksmithbaylor18:05:46

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

darwin18:05:22

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

ksmithbaylor18:05:50

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

darwin18:05:40

those are different options

darwin18:05:27

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

darwin18:05:12

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

darwin18:05:22

which would be 58.0.3029.96

darwin18:05:24

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

ksmithbaylor18:05:00

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!

darwin18:05:53

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

ksmithbaylor18:05:09

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

darwin18:05:37

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

darwin18:05:14

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

darwin18:05:49

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

ksmithbaylor18:05:27

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

ksmithbaylor18:05:04

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

darwin18:05:06

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

darwin18:05:14

and use embedded electron’s devtools

darwin18:05:24

you will avoid a lot of headaches

darwin18:05:03

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”

darwin18:05:14

Chrome/56.0.2924.87 is damn old

ksmithbaylor18:05:24

in internet years at least 😛

darwin18:05:53

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

ksmithbaylor19:05:04

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

piotr-yuxuan20:05:05

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 ^^

piotr-yuxuan20:05:51

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

darwin21:05:30

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

darwin21:05:10

@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

piotr-yuxuan21:05:44

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

piotr-yuxuan21:05:32

thanks for your review 🙂

darwin21:05:06

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