lumo

:lumo: Standalone ClojureScript environment. Currently at version 1.9.0
metametadata 2017-11-13T07:08:04.000159Z

What's the current best way to reload code in REPL? I use :reload/`:reload-all` (e.g. (require '[foo.bar :as bar] :reload-all)). But I was wondering if there's some tool which can reload only changed files similarly to clojure.tools.namespace.repl. :reload-all does the job but is quite slow in my project.

2017-11-13T14:57:19.000510Z

So I'm experimenting with the code packaging with lumo, for the entry point I feed this json map as option to startClojurescriptEngine()

{"scripts":[],"classpath":[],"dependencies":[],"unrecognized":false,"help":false,"version":false,"legal":false,"repl":true,"verbose":false,"dumb-terminal":false,"static-fns":false,"fn-invoke-direct":false,"elide-asserts":false,"quiet":false,"args":[],"mainScript":"/home/hlolli/forks/lumo/demo.cljs"}
I compile development bundle go into target dir and do node bundle.js, where I'm greeted with
WARNING: demo is a single segment namespace at line 1 

	 Object.<anonymous> (/home/hlolli/forks/lumo/demo.cljs:1:63)
	 Module._compile (module.cljs:624:30)
	 (Object.lumoEval)
	 (Object.lumo.repl.caching_node_eval)
	 (evalmachine.<anonymous>:5837:273)
	 E (evalmachine.<anonymous>:5838:269)
	 (evalmachine.<anonymous>:5831:207)
	 (evalmachine.<anonymous>:5729:190)
	 Object.cljs.js.load_macros (evalmachine.<anonymous>:5702:199)
	 (evalmachine.<anonymous>:5723:433)
the contents of the file demo.cljs is
(ns demo)

(println "Something works!")
maybe from this given information anyone could see why this error is coming, I tried adding target to classpath and call it as node target/bundle.js but then I had strange macro cache error messages.

mfikes 2017-11-13T15:15:26.000433Z

@hlolli The warning is related to the fact that the demo namespace has only one segment, i.e. it does not contain any dots in it. This can lead to subtle things breaking, so a warning is emitted discouraging its use.

2017-11-13T15:19:51.000603Z

@mfikes, the warning is not what is distracting me here, as I often encounter it due to lazyness at times to create new directory but compare these two

$ lumo ~/forks/lumo/demo.cljs
WARNING: demo is a single segment namespace at line 1 
Something works!
the print statement is called. But of course the huge difference is that I'm calling lumo binary directly, not this potential dev bundle mess I've created here (willingly).

mfikes 2017-11-13T15:22:32.000594Z

So perhaps your problem has nothing to do with the single-segment namespace, but, as you are saying, is the fact that the println fails to produce output. (And presumably it would also do so if it were in a multi-segment namespace.)

2017-11-13T15:25:00.000175Z

that's what I think, I'm now researching how the lumo cli parser creates the option map when given a mainScript argument, could be some option that is needed but I'm not providing. Not sure if you know the source code but I'm trying to bypass src/js/cli.js completly to enable compilation of binary of lumo with static options with a user provided main function etc (which would be bundled, but I'm not there yet)

2017-11-13T15:31:14.000141Z

ok the exact same things happens with the bundle generated from the boot dev task (with added console log of the options).

$ node target/bundle.js -c target ~/forks/lumo/demo.cljs 
opts: {"scripts":[],"classpath":["target"],"dependencies":[],"unrecognized":false,"help":false,"version":false,"legal":false,"repl":false,"verbose":false,"dumb-terminal":false,"static-fns":false,"fn-invoke-direct":false,"elide-asserts":false,"quiet":false,"args":[],"mainScript":"/home/hlolli/forks/lumo/demo.cljs"}
WARNING: demo is a single segment namespace at line 1 

	 Object.<anonymous> (/home/hlolli/forks/lumo/demo.cljs:1:63)
	 Module._compile (module.cljs:624:30)
	 (Object.lumoEval)
	 (Object.lumo.repl.caching_node_eval)
	 (evalmachine.<anonymous>:5837:273)
	 E (evalmachine.<anonymous>:5838:269)
	 (evalmachine.<anonymous>:5831:207)
	 (evalmachine.<anonymous>:5729:190)
	 Object.cljs.js.load_macros (evalmachine.<anonymous>:5702:199)
	 (evalmachine.<anonymous>:5723:433)

anmonteiro 2017-11-13T17:22:51.000726Z

@hlolli ooops that might not be your problem

anmonteiro 2017-11-13T17:24:37.000676Z

Try changing this line

anmonteiro 2017-11-13T17:25:14.000034Z

To if (execPath != null && !__DEV__) {

2017-11-13T18:51:01.000805Z

@anmonteiro that fixed it!

2017-11-13T19:35:02.000615Z

hmmm an aot compilation is a tricky problem, I can imagine two solutions, the user provides a .cljs file that states all the requires and require-macros needed to run the application, or the user runs the app him/herself and provides the path to the cache directory as argument and it will get bundled.

2017-11-13T19:40:51.000775Z

cat $USER-PROJECT-ROOT/aot.cljs | $(pwd)/build/lumo --quiet -c target -sfdk aot-tmp - if this is not provided, then the user would only suffer from much slower startup time I'd assume.

fabrao 2017-11-13T21:33:25.000562Z

hello all, sorry my dumb questio, but what is the main use of lumo?

fabrao 2017-11-13T21:33:55.000250Z

NodeJS as Clojurescript?

2017-11-13T21:40:18.000464Z

@fabrao yes, along with fast startup time and great portability due to no dependency on java.

fabrao 2017-11-13T21:41:42.000143Z

@hlolli Have you ever used with Electron?

2017-11-13T21:42:35.000242Z

I have made electron app in js that communicates with lumo, but not made the electron app trough lumo, but I've seen that in the wild.