Fork me on GitHub
#figwheel-main
<
2018-09-13
>
tmarble16:09:38

Anyone else using figwheel-main with CIDER?

eval202019:09:29

@tmarble couple of days back there was some discussion about CIDER in this channel. Still visible in the/my history

tmarble19:09:22

cool, I'll check that out... for the moment the CIDER stuff seems to be working fine (including auto tests), but I am having some trouble with testing

tmarble19:09:11

I've had success running fig:test from the https://rigsomelight.com/figwheel-main-template/ and, in particular, the compiler options in test.cljs.edn are respected as demonstrated by running "run" "-m" "figwheel.main" "-co" "test.cljs.edn" "-pc" However, if I specify either :output-to or :output-dir then it hangs after printing "Environment output being logged to:"

tmarble19:09:39

What's also strange is that.. in another (actual) project where I want to use figwheel-main for testing (a la "fig:test") the :output-to is set to "/var/folders/....." even though I didn't specify :output-dir nor :output-to in test.cljs.edn???

tmarble19:09:26

And, perhaps because of the non-default :output-* behavior I mentioned above the test also hangs??

eval202019:09:09

no experience with the template myself, but that last conclusion sounds plausible

tmarble19:09:46

Indeed I've taken a lot of inspiration from that page... including writing a shell script for :launch-js which will pick the correct chrome executable path based on platform (e.g. Mac, Linux)... And I have a followup lein do shell script that will check if the headless chrome is still running after the test (and kill it if necessary)

bhauman20:09:46

@tmarble I’d love to help you with this

tmarble20:09:12

it would be very appreciated!

bhauman20:09:28

I only have about 5 minutes before I do an interview for the REPL

bhauman20:09:35

what are you trying to do?

bhauman20:09:44

@tmarble you are trying to REPL into your tests with CIDER?

tmarble20:09:47

I am trying to see what's in the new project that might be changing :ouput-* AND why the hang occurs

bhauman20:09:52

But you are trying to get a REPL into your tests?

tmarble20:09:08

well i do want to do both... the live update auto-test seems to be working..

tmarble20:09:25

the problem is with the fig:test functionality

bhauman20:09:03

you are trying to change the output-to

tmarble20:09:10

so instead of -b dev -r it's -co test.cljs.edn RUNNER

tmarble20:09:00

in the new project, with the problem, I am NOT changing output-to... BUT -pc shows that it HAS changed... I wonder if it might be some legacy figwheel sidecar stuff (which I have tried to remove)

bhauman20:09:38

without the specifics this is tough

tmarble20:09:36

i am trying to come up with a minimal test case

bhauman20:09:18

@tmarble if you skip the -m in -m RUNNER

bhauman20:09:26

that will screw things up

bhauman20:09:50

OK my time is up for now but I’ll be happy to look at this later

tmarble20:09:23

however I do have a minimal test case using the figwheel-template.... SETTING :output-to and/or :output-dir causes the fig:test to hang... The symptom is that the environment log seems to be in an infinite loop printing >>> {"result":{"type":"undefined"}}

tmarble20:09:35

great, thx!!!!

tmarble20:09:50

oh i didn't skip the -m

bhauman20:09:15

if you use -pc without the -m it will change the output-to

bhauman20:09:38

you need to use -pc with the whole command

bhauman20:09:47

anyway talk with ya later

tmarble20:09:53

oh... should the -pc be at the end?

tmarble20:09:57

ok... ttyl!

bhauman20:09:13

roght after figwheel.main

tmarble20:09:27

ok.. i'll double check that

bhauman20:09:40

but no REPL is going to start when you use -m RUNNER

tmarble20:09:27

in doing the (non interactive development) "fig:test" we need -m RUNNER I will note, FWIW, that the meta data in test.cljs.end tells chrome to add the --repl arg (to create a JavaScript REPL), but I know this is different

bhauman12:09:15

@tmarble I’m 90% sure its your :launch-js config

bhauman12:09:06

hit me up when you are available, I’d like to work this out

tmarble17:09:14

I will! Sorry I'm in an all day workshop today, but I'll ping you when I get back online

tmarble15:09:25

Sorry it's taken so long to get back to you. I found that I wanted to to use a shell script in :launch-js so that I could avoid hard coding the path to Chrome (most developers use Macs, but the CI/CD pipeline uses Linux). I also found that using the shell script allowed me to keep the PID of Chrome so that I could ensure it was properly stopped after the test.

tmarble15:09:27

FWIW I did think about the possibility of keeping a reference to a Process created by ProcessBuilder so that figwheel-main could later call .destroy per. https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html#destroy-- BUT it would involve a significant change to the this function is wrapped in a Lamba (hence the desire to discuss this with you): https://github.com/bhauman/figwheel-repl/blob/master/src/figwheel/repl.cljc#L1151

tmarble15:09:00

To test your theory.. I reverted my :launch-js to use the hard-coded path the Chrome on the Mac (again using the template application) and if the :output-dir :output-to options are set the tests still hang. 😞

tmarble15:09:59

When Chrome is run with --repl is the idea that figwheel is communicating with it over STDIN/STDOUT? (i.e. if true I'm wondering if somehow the streams are not getting connected in certain cases).

tmarble16:09:54

Just did a little technical study with Chrome to see that, yes, it is an interactive REPL on STDIN/STDOUT.