Clojurians
#lumo
<
2017-11-13
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

metametadata07:11:04

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.

hlolli14:11:19

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.

mfikes15:11:26

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

hlolli15:11:51

@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).

mfikes15:11:32

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.)

hlolli15:11:00

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)

hlolli15:11:14

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)

anmonteiro17:11:51

@hlolli ooops that might not be your problem

anmonteiro17:11:37

Try changing this line

anmonteiro17:11:14

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

hlolli18:11:01

@anmonteiro that fixed it!

hlolli19:11:02

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.

hlolli19:11:51

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.

fabrao21:11:25

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

fabrao21:11:55

NodeJS as Clojurescript?

hlolli21:11:18

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

fabrao21:11:42

@hlolli Have you ever used with Electron?

hlolli21:11:35

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.