Fork me on GitHub
#figwheel-main
<
2018-08-26
>
thiru013015:08:58

I noticed that https://figwheel.org/docs/scripting_api.html says to start rebel readline with clj ( clj -m rebel-readline.main) rather than clojure. Is this a typo or does rebel-readline now work well with clj now?

bhauman15:08:22

@thiru0130 you’re right that should be clojure

bhauman15:08:01

clj works on my system, but I’m not going to bet that it works on every system

bhauman15:08:20

I’m really excited about the new stuff I’m working on right now

bhauman15:08:23

it will let folks run async tasks (like async tests) in a main script: clj -m figwheel.main -m exampl.test-runner

bhauman15:08:01

and will let them asynchronously return a value to be printed or error exit status

bhauman15:08:41

which will in turn allow for command line test runs that integrate well with dev ops

bhauman15:08:55

and other tasks

bhauman15:08:19

main scripts are tough to use because they will normally exit too early to allow anything useful to happen

thiru013015:08:25

Good stuff! I've been away for a few weeks and I'm seeing so many changes

thiru013015:08:21

Yup regarding clj I've had strange behaviours in the past when using it with rebel accidentally (arch linux)

thiru013015:08:38

I'll send a pull request with the fix to that typo.. also seeing some other copy errors with the new docs

thiru013016:08:54

"We’ve successfully switched between ClojureScript REPLs for our builds all the while staying in a Rebel Readline environment." <-- wohoo!

thiru013016:08:25

Is the "o" in this name a typo or naming convention I'm not aware of: figwheel-config-o-build

bhauman16:08:24

I’ve seen the -o- around

thiru013016:08:28

Similarly figwheel-options-o-build

bhauman16:08:42

yeah I’ve seen it and I kinda like it

bhauman16:08:03

not attached to it

bhauman16:08:22

I think it’s used in clojure.core

thiru013016:08:31

Confusing for noobs (like myself) probably.. but no big deal to get over

bhauman16:08:30

willing to change it

thiru013016:08:48

Nice thanks.. I'll include in PR

onetom17:08:46

that -o- is an americanism, i think. it came from some cartoons, i suspect, when they repurposed the word automatic to different *-o-matics or something like that.

onetom17:08:17

btw, for async build processes we are using https://github.com/DarthSim/overmind (or hivemind), but the biggest problem with them is how to combine them into a pipeline. many steps depend on or triggered by filesystem changes, which we monitor with http://www.entrproject.org (which is similar to http://wkf.github.io/hawk/ but without the jvm dependency), but it's cumbersome to notify another step in the build process to rerun at the right time.

onetom17:08:33

what would be really good if existed is something like make, but instead of simply executing commands when a make rule is matched, it should notify an already warmed up background process...

bhauman17:08:04

@onetom very cool

bhauman17:08:12

overmind looks interesting

bhauman17:08:45

I’m talking more about the --main option not being able to handle any sort of async process

bhauman17:08:26

it will return before running async process to completion

bhauman17:08:52

which makes it less than optimal for js

bhauman17:08:16

and very useless for testing where you want something that will run the tests and system-exit with 1

bhauman17:08:23

on failure

bhauman17:08:46

@onetom also I fixed up all the cljs repl api problems that you mentioned

bhauman17:08:06

had to patch up piggieback a bit to get it all working

bhauman17:08:36

so figwheel.main/reset and friends will work properly now

onetom17:08:19

wow, that's awesome. i will try it right away

bhauman17:08:36

its not pushed yet 🙂

bhauman17:08:56

the REPL stuff is pushed

bhauman17:08:12

you have to use figwheel.main 0.1.8 and piggieback 0.3.9

bhauman17:08:36

the async stuff isn’t there yet

onetom18:08:05

i just did a quick experiment to clarify that i can't have multiple -m on the clj command-line, because subsequent -m options would be just passed as params to the first -main function.

bhauman18:08:41

it should work

bhauman18:08:25

clj -m figwheel.main -m exampl.test-runner this works for me

onetom18:08:32

$ rg .
deps.edn
1:{:deps {org.clojure/clojure {:mvn/version "1.9.0"}}}

src/m2.clj
1:(ns m2)
2:(defn -main [& args] (prn "m2"))

src/m1.clj
1:(ns m1)
2:(defn -main [& args] (prn "m1, args:" args))
then
$ clojure -m m1 -m m2
"m1, args:" ("-m" "m2")
instead of printing
m1
m2

bhauman18:08:06

that is correct behavior

bhauman18:08:24

oh it prints both!!!

bhauman18:08:53

it shouldn’t

onetom18:08:07

im just saying i haven't realized until now that some of those -m options are interpreted by the first -main function

bhauman18:08:31

yes that is correct

onetom18:08:26

im not talking about figwheel now, just regular clojure.main in fact, that's already a bit confusing that the clj / clojure commands are running the clojure.main/-main which in turn accepts a -m/`--main` option to run another -main function in some namespace, for example figwheel.main/-main which then also interprets the next -m option to run yet another -main function...

onetom18:08:41

or am i wrong about this chain somewhere?

bhauman18:08:36

you have that right clojure.main/-main is implicit and its’ what actually handles the CLI

bhauman18:08:55

and initializes the environment

bhauman18:08:39

it is the entry point for the java process

bhauman18:08:26

its kind of a turtles all the way down thing

onetom18:08:49

but then i can make an uberjar, in which case my own app.main/-main (with :gen-class) will be the entry point to the java process

onetom18:08:30

which i've just realized, i don't know how to make an uberjar with these new clojure cli... 😕

bhauman18:08:01

me either there are libs though

bhauman18:08:54

the resources are not easy to find though

onetom18:08:40

i've seen dnolen's Embracing Simpler Tools talk, regarding this "just make libraries" approach. very enlightening as usual! 🙂 thanks for the juxt/pack.alpha pointer!

bhauman18:08:32

theres another one called mahyven or something like that. its impossible to search for

thiru013018:08:18

(Haven't tried any of them though)

risinglight21:08:27

At this point I want to start serving index.html from a different dev webserver than the figwheel one, such that relative AJAX calls go to the backend API dev server (written in a different language) as opposed to the figwheel dev server. As a first go, I served up an index.html from the python api dev server which pulled the css and js files from the figwheel server, and that works but subsequent js files (deps.js, cljs_deps.js, etc) fail as the browser tries to get these from python instead of figwheel. Is there an easier way to go about this?

bhauman21:08:58

@risinglight you need to serve the compiled static assets

bhauman21:08:23

from python

bhauman21:08:23

remember that you can configure the output-to and output-dir to place them where ever you need them to go

bhauman21:08:18

when you use a different server you are using a different server for everything except figwheel/repl communication which has CORS support for effortless cross origin communication

risinglight22:08:07

it took some finagling but that did the trick, thanks