Hey, I'm getting an error on Windows 10 when trying to run the template. Any ideas? I saw some bug referenced before about length of classpath and the limitation of the command line... I don't think it is related (my classpath is "only" around 8K chars)

It is confusing because it seems to complain about missing clojure.spec, but when I run lein classpath the spec jar is listed right there

something like: C:\Users\emman\.m2\repository\org\clojure\spec.alpha\0.1.143\spec.alpha-0.1.143.jar; (which does exist)

found it... lein run -m figwheel.main -- -b dev -r works, so probably a problem with lein trampoline

oooooh

two days later, with teary eyes... I have a figwheel.main running on WIndows 10

truly, I started trying to run it with clojure's jar on windows... lots of errors about missing dependencies and stuff. Then I switched to lein.

feels like the whole windows platform is a bit neglected in the clojure world

(starting by clojurelang itself not providing any easy path to install but lein)

A windows binary for the clojure cli is in the works but not finished

Is it possible to access a background-build's repl from the foreground build repl? Is there a way to switch between the two repls?

Or is it necessary to have two figwheel instances open to manage the client and the server?

ex. I have a browser build, and a node server build, and the node server build is in the background -bb dev-server

i'm trying to mimic a reloaded lifecycle design for both, so I (start) each one individually

alternatively, I could change :main to automatically start and restart on-jsload I suppose

only problem is, the server-side stuff can take several minutes to get to steady-state, so I would like to pick and choose what I restart if i'm only making minor changes to the server

I finished reading the background builds doc, I think I now understand its uses and i'm using it incorrectly

The server and ui builds need to be separate, which makes sense

@benzap accessing a background-build’s repl from a foreground build is not possible right now

but if you use the scripting api you can switch between them quite readily

@benzap is your server a node server?

Yeah, it's entirely clojurescript server+ui

well that will work for a background build

and you can use the scripting api to switch between them

interesting, how do I go about doing that?

https://figwheel.org/docs/scripting_api.html#repl-switching-example

awesome! i'll take a look

nice, it works really well!

Is there a way to send things to be evaluated to each repl from rebel-readline?

I can see some issues with that idea, since the browser repl requires a window to be open, so it would likely hang the main repl

you want things to be evaluated in every connected window?

@benzap ^

@bhauman so a bit of follow-up on my piggieback/figwheel/vim desert wanderings (cf https://clojurians.slack.com/archives/CALJ3BFLP/p1537311445000100) … what I think is happening is that figwheel is defaulting to putting and serving build products in target/public/cljs-out/dev, but any cljs eval within vim (through :Piggieback) has the impression that it should compile buffer evals into out/, and that’s where it’s going looking for react etc, and not finding it.

so now I’m a bit stuck on the last 10 ft… I guess if I set up a ring handler to serve cljs out of out/ instead of target/public/, then all should be hunky-dory

(probably my inexperience, but adding out/ to the classpath isn’t quite enough… the js would have to be in out/resources to be served by Figwheel’s static file server)

(or I just bail out and add another piece to handle sending out index.html and all the js).

@rgm thats sounds like your VIM is using the default cljs.repl not the figwheel repl

yeah the weird part is that I’m doing :Piggieback (figwheel.main.api/repl-env "dev") and does seem to connect OK … it just doesn’t seem to have access to figwheel’s build products. So in-editor, I can eval self-contained stuff that only relies on base clojurescript since (I guess?) the base clojurescript compile is providing it ¯\(ツ)/¯

guess I’ll rig up a static file server to use /out and see what happens.

it sounds like :Piggieback isn’t doing anything

yeah, maybe not

that sounds like a bad path to take

i’d look at how you installed vim.fireplace

when I tried it the first time it was all borked and doing crazy things

then I installed vim.fireplace only

yeah, maybe so. Don’t wanna waste any more of your time; just hoped you’d find it somewhat intriguing or know the problem within 2 sec.

Hey again. I was wondering if these instructions are up to date to run a figwheel.main REPL in cursive: https://github.com/bhauman/lein-figwheel/wiki/Running-figwheel-in-a-Cursive-Clojure-REPL

You need to use the Scripting API instead of the figwheel api

https://figwheel.org/docs/scripting_api.html

you don’t need to use cljsbuild, you just need to make sure that cursive is picking up your dependencies

oh, so I can start a repl from cursive and then run (figwheel.main.api/start "dev") inside?

that’s possible

but you can also create a script that starts figwheel-main as well

I was wondering if it was possible to connect using the "remote repl" feature in cursive

that is possible but more complicated

but since you are using lein it should be easier

you need to start a lein repl

and then connect to that nREPL port

right, but I don't know how to get the port 😛

its displayed when you start lein repl

but you have to make sure all your dependencies are available in lein repl

ah I think is because I ran lein run -m ...

a good way to test that is to start figwheel-main from the lein repl prompt using the scripting api

exactly

ok

@emmanueloga if you add a remote REPL and select Use Leiningen REPL port it will connect up to the repl you started from the scripting api, then (figwheel.main.api/start "dev") will get you a cljs repl alongside your clojure repl

@shaun-mahood I really really need a Cursive Guide 🙂 I’m getting this question all the time

of course, this is easy for lein

but to document all the ways is much harder

Yeah - I'm not sure how well Cursive works without lein these days - I know it's much improved but not sure it's close to parity yet.

Once I get things working nicely I'll write something up - I'm not sure if there's a nice way to have 2 repls going at the same time in Cursive without a lot of switching back and forth.

@bhauman @shaun-mahood I’m changing how REPLs work currently for deps support, which should hopefully make some of this easier. My eternal plan to make CLJS REPLs easier and have a proper CLJ/CLJS double REPL should be coming to fruit soon too, hopefully in the next EAP round.

I refactored a bunch of stuff internally for the EAP that went out today, to allow running any REPL type with any execution method (straight IntelliJ classpath, via lein or via deps).

That was a surprisingly large change but should be good in the future for more options.

@cfleming That's awesome 🙂

sounds good

Actually, opinions welcome - as a default option, are people likely to want separate processes for the CLJ and CLJS parts? Or are they usually run in the same process?

same process

IIRC they used to be usually in the same process… ok, cool.

@cfleming I'm super new to clojure and cursive, but fwiw, I was expecting to be able to run the equivalent of "lein run -m figwheel.main" in cursive, somehow. Could not find a way.

yeah that might be expecting too much 🙂

its hard to document all the ways it won’t work

Hmm, interesting - in today’s EAP you can start a REPL with the moral equivalent of lein run -m clojure.main, but not figwheel.main.

I should allow that to be configured.

@cfleming how would that be possible?

are you just sending expressions to the stdin of the process?

of course you are

For the clojure.main REPL option, yes.

yeah that makes sense

so dang that would work

I have two REPL types, nREPL and clojure.main. I’m planning to extend the clojure.main one for general streaming REPLs so I’ll support socket REPL too.

and you aren’t parsing the results so your good for the clojure.main repl

or the figwheel.main repl

It’s tricky because there are a lot of different ways to start things now, and it will get exponentially worse for CLJS.

I’m planning to have an option for prepl-style structured output for the streaming REPLs too, but haven’t tested that yet.

Basically prepl but without all the tap stuff and not reliant on Clojure 1.10.

Not sure if/how that would work with figwheel.main, or even CLJS in general yet though.

I need some UI work for the clojure.main option too which is also pending.

@bhauman do you have a feeling for what the uptake of figwheel.main has been? Are most people still on old-school figwheel?

So, the script API seems to run all right, but then I go to localhost:9500 and nothing happens

at least I could connect form cursive, no problems

From cursive: (figwheel.main/status) ------- Figwheel Main Status ------- Currently available: dev Currently building: dev => nil

@emmanueloga You need to add a couple dependencies to your dev profile - should look something like this (as well as whatever you already have)

:dev   {:dependencies   [[cider/piggieback "0.3.9"]]
              :repl-options   {:nrepl-middleware [cider.piggieback/wrap-cljs-repl]}]}

https://github.com/nrepl/piggieback#installation is the link to the instructions in case you want more details

@cfleming its been slow, but I think a lot of folks have it on their todo lists now

I’d guess the adoption is in the hundreds though??

its a significant improvement

so... adding the dependency shaun said worked

I have a running repl and localhost:9500 works

but! if I do (js/alert "OK") from the cmd line, it works

but if I run the same from cursive it doesn

't

"no such namespace js"

@bhauman Ok, thanks. I think I’ll probably only support figwheel.main as an integrated solution then, and lein-figwheel users can continue as they are now, which isn’t terrible. Hopefully that will help drive migration too.

@emmanueloga have you run (cljs-repl "dev") from your cursive repl yet?

nop

"unable to resolve symbol cljs-repl"

@emmanueloga you need to require (require 'figwheel.main.api)

and run (figwheel.main.api/cljs-repl "dev")

ohhhhh

it worked!

only took me 3 days hehe. Sorry guys, I'm just venting a bit since I guess it could be helpful to you tool authors to know what it is like when you are a noob

ok, to recap, in order to use figwheel.main in Win10 with cursive I needed to: 1) Install lein (using lein.bat). Put it in a directory somewhere and add it to the %PATH%. 2) lein new figwheel.main 3) Edit the code to fix the paths (the template inserts file paths references like: "edit /myapp\somefile.clj", but then the compiler fails since it tries to insert a escaped char "\s" 4) Add the cider/piggiebak reference and nrepl option 5) run "lein repl", annotate the port 6) add a remote repl in cider and require figwheel main, and run the dev mode 7) profit

I don't think I've seen all the pieces of this "flow" together anywhere

I know there's a lot of docs but sometimes the forest hides the trees...

also, a bit of an inconvenience: if I restart the repl, the port changes, so I need to edit the cursive configuration

@emmanueloga please show me where to change the template and I will

ah, one sec

@emmanueloga When you configure your remote REPL, use the “Use Leiningen REPL port” option and Cursive will pick up the port from where lein writes it out.

sorry I'm switching between computers 😛

https://github.com/bhauman/figwheel-main-template/blob/master/src/leiningen/new/figwheel_main/core.cljs#L15

https://github.com/bhauman/figwheel-main-template/blob/master/src/leiningen/new/figwheel_main/core.cljs#L44

apparently nested-dirs returns a windows path, e.g. "hola\mundo" instead of "hola\\mundo" or "hola/mundo"

but that is just text that won’t prevent things from running

perhaps its being used in a place that will cause an error?

right, so if you introduce an error when figwheel was already running it will show that error HUD right,

but if you try to run figwheel with an error from the start, it will just fail to start

and in my machine that happened because the compiler choke on an invalid scape character

oh you are saying that this will fail to compile as javascript on windows

I gotcha

right

Is there a way to set an :advanced build from figwheel config or using lein run?

-O advanced

for figwheel-main

-m figwheel.main -O advanced -bo dev

Looks good, thanks! Should there still be a folder named after the build in the output folder after the build has completed?

it will build in the same spot as the dev build

Sorry, bad question - in that folder, for my "prod" build, I have a "prod-main.js" file and a "prod" folder. Just wondering if that's the normal behaviour (I have this recollection that it cleaned out that "prod" folder but my memory might be lying to me again)

yes that’s normal

the output directory default goes there

but yes something to think about

Ok thanks - think I've pretty much got things working like I want now, amazing how much of an improvement figwheel-main is over lein-figwheel. Pretty amazing work!

@cfleming your REPL work sounds great! I'm working on a client project right now to replace lein-cljsbuild with figwheel-main... and I've got all the basic bits going (static tests, creating an uberjar). I can launch a figwheel-main CLJS REPL from CIDER and add a "sibling" REPL to do CLJ. Right at the moment I'm trying to see how to emulate this in Cursive. On the CLJS side I can start a REPL in a terminal window with the approach ["trampoline" "run" "-m" "figwheel.main" "-b" "dev" "-r"], but that's not smartly connected to Cursive 😞 I've been thinking about starting a competely separate rebel readline REPL for CLJ and have Cursive connect that port, but @bhauman suggests it would be good to connect to the same REPL process??? Not sure how to do that

@tmarble Hi Tom! Yes, that sounds a bit tricky. For the next build I’ll make the clojure.main REPL config more flexible so you can do the run -m figwheel.main <args> from within Cursive - currently that’s hard-coded to run clojure.main.

... when done that way Cursive would know how to do things like "eval a form (or buffer)" and update the REPL?

That’s right.

And you’d run it from within the IDE without having to drop to the terminal.

nice!

Way back when I did the https://github.com/tmarble/tenzing3 technical study I ended up starting separate processes for the CLJ and CLJS REPL's and then had Cursive connect to each on different ports... I'm wondering if there's a way to "share one backend" (i.e. connect to the the figwheel.main REPL) but not automatically pivot in to CLJS (in order to create a CLJ REPL)?

My long term pipe dream is to have a single REPL run config that will start both CLJ and CLJS simultaneously and have them in tabs.

yes, that's what I'm talkin' about!

... where editing a *.cljc file will update BOTH!

Right - I actually think CIDER does that right now.

Currently CIDER does dual REPLs better than Cursive, and we can’t have that 🙂

hahaha... can't we all just get along 🙂

Hehe, yes, actually I was just with @bozhidar in ClojuTRE, it’s all friendly 🙂

sorry to have missed it! will you be at the Conj?

No, sadly.

😞

That’s just too much travel.

i totally get that

Anyway, we’re somewhat hijacking #figwheel-main, this should all really be over in #cursive

@tmarble Reading above, are you trying to have your figwheel server start up but remain in Clojure?

no... I really want to do what I can with CIDER.. that is keep all the CLJS REPL goodness ... AND, separately, have a CLJ REPL (Ideally connected to the same backend)

You can do that in Cursive as long as you are happy switching between 2 REPL windows when you need to - I've got it set up and it seems to work pretty well

I'm running figwheel in my main repl (using :mode :serve), then connecting to it with a remote repl. I then run (cljs/repl) in the remote repl and can send forms to either one as needed

nice! do you have an example with the various *.cljs.edn files (possibly project.clj) ?

I'll try and throw the specific parts into a thread here

thx!

using fig script api I get error

(fig/start {:id "dev" :config {:mode  :serve :watch-dirs ["src"] :open-url "/dev.html"}})
AssertionError Assert failed: Figwheel Start: build argument required
(build-option-arg? build)  figwheel.main/start* (main.cljc:1906)