Clojurians Log v2

maybe its because https://github.com/anmonteiro/lumo/blob/0ffdd66dac0b27e9894fe8370e17d3e5f12c932c/src/js/cljs.js#L317-L346 doesnt try to look at the embedded resources?

@hlolli you might be onto something but I am going to wait for Antonio to speak here as I have not dug enough on that myself

I don’t think that code should have anything to do with embedded resources

loading resources is pretty self contained

in the load function in lumo.repl

in the meantime I created a branch for the stest/instrument WARNING: https://github.com/anmonteiro/lumo/pull/312

why did you comment out all the build-api-tests

just for quickly executing the tests

will put everything back when I will find the fix 😉

just wanted to make sure that I am not doing silly things in the ns declaration (which is usually what happens) 😄

yes I agree, but what I'm trying to achieve is bundling cljs code into the nexe. I've spent much time trying to add this feature, I hope we could allow searching for mainScript in bundled resources on certain conditions? Just need to find out where the path gets resolved at least to test it.

I’m saying the path is resolved in lumo.repl/load

or whatever it’s called

and that executePath shouldn’t be where you need to look

ah ok, I think I get you, I will take a look there! thanks

yup bingo, I was exacly looking there

this confirms it Object.lumo.repl.load_other (NO_SOURCE_FILE <embedded>:6470:378)

So it looks like the first time I do boot dev, I get a bunch of:

--- m {:name cljs.spec.test.alpha, :macros true, :path cljs/spec/test/alpha}
WARNING: Use of undeclared Var cljs.spec.test.alpha$macros/eval at line 112 cljs/spec/test/alpha.cljc
WARNING: Use of undeclared Var cljs.spec.test.alpha$macros/eval at line 135 cljs/spec/test/alpha.cljc
WARNING: Use of undeclared Var cljs.spec.test.alpha$macros/eval at line 245 cljs/spec/test/alpha.cljc

(apart from the first line that I have added)

this just passed my eyes, no smallest idea if these are related cc @richiardiandrea https://github.com/anmonteiro/lumo/blob/7c34d011dd8232828a337f361737de0bd3cfd1b4/src/cljs/snapshot/lumo/repl.cljs#L230-L232

thanks for the hint! digging...

or better, it passes by there it seems, but calls back with it, emitting the warnings without injecting eval

Compiling out/cljs/spec/test/alpha.cljs
--- load {:name cljs.spec.test.alpha, :macros true, :path cljs/spec/test/alpha}
--- load-and-cb cljs.spec.test.alpha cljs/spec/test/alpha cljs/spec/test/alpha.clj true
--- load-and-cb bundled-source false js-lib? false
--- load-and-cb cljs.spec.test.alpha cljs/spec/test/alpha cljs/spec/test/alpha.cljc true
--- load-and-cb bundled-source false js-lib? false
WARNING: Use of undeclared Var cljs.spec.test.alpha$macros/eval at line 112 cljs/spec/test/alpha.cljc
WARNING: Use of undeclared Var cljs.spec.test.alpha$macros/eval at line 135 cljs/spec/test/alpha.cljc
WARNING: Use of undeclared Var cljs.spec.test.alpha$macros/eval at line 245 cljs/spec/test/alpha.cljc

Hi I’ve published xforms 0.15.1 to npm which has an up-to-date .lumo_cache but I believe it’s not picked by lumo (that’s what I infer from`lumo -v` output)

Uhm I will try to check that

I mean: if run xforms locally with -K it gets cached and the second time I don’t see any javascript being compiled when I require it

However when I use it as a dep the cache seems to be ignored (despite being present under node_modules/xforms

(and timestamps are ok)

I guess -k lowercase with path works fine? Btw it should only get cached once and read the cache if they exist?

I haven't tried xforms, but if there's no change in the source code, it should be safe to just give a path to the cache to speed up startup time?

xforms is deployed as a npm package and there’s an up to date cache in the package but lumo ignores it

does it ignore it with lowercase or capital k?

with -k or -K, the first time it’s compiled and put in the cache directory.

My expectation was that it would never compile it since a cache is present in the package

Is my expectation wrong?

no that's correct expectation

ok so you're using lumo to call xforms as node module. I think this is not yet implemented. I think lumo will try to chache everything into one directory when in your case it should merge. But I say only as user.

What I personally would like to see, is "lumo" key in package json, this would be a good place for lumo to look at.

I’m running lumo master

how this could work would be

cd ~/myLumoProject/
lumo -m cljs.core -c src -k node_modules/xforms/.lumo_cache

It is a brand new feature something might be off

The cache should be read from directories.cache in package.json and added directly to the pool of cache files

I haven't tried that here yet, but will soon (thanks Christophe for publishing on npm and trying things out!)

@richiardiandrea thanks to you for getting me set up

We dont read cache from Npm packages yet

It’s just not implemented

Which is why the issue is still open

Oh cool that explains it

Thanks!

Well now you know that you canuse xforms to test 🙂

Isn’t the issue tricky when you require A and B and that A depends on B too? Then you have two caches for B code, no?

I havent given it any thought

Might eequire some refactoring

That particular case may not be a problem at all, I’m more concerned about caches for different versions of ClojureScript

what if the B “embedded” in A cache is a different version than the one your required?

That’s was going to me by next question (cljs version)

Right that may become a problem

Maybe we shouldnt support caches at all

And have that be an app-thing only

Not library

Can’t you have a mode for not generating a cache for deps?

@anmonteiro so I have been digging:

cljs.user=> (def cache (ana/read-analysis-cache (ana/cache-file "out/cljs/spec/test/alpha.cljs" "out") "out/cljs/spec/test/alpha.cljs"))
...
cljs.user=> (filter #(clojure.string/includes? (str %) "cljs.spec") (keys (get-in cache [:cljs.analyzer/namespaces])))
(cljs.spec.alpha$macros
 cljs.spec.gen.alpha$macros
 cljs.spec.test.alpha
 cljs.spec.alpha
 cljs.spec.gen.alpha)

looks like the $macros for cljs.spec.test.alpha are not in the cache?

@richiardiandrea its at least bundled (lumo.internal.embedded.keys)

uhm lemme have a look

@hlolli it seems it is not:

cljs.user=> (filter #(clojure.string/includes? (str %) "cljs.spec") (lumo.internal.embedded.keys))
("cljs/core$macros.cljc.cache._COLON_cljs.spec_SLASH_registry_ref.json"
 "cljs/core$macros.cljc.cache._COLON_cljs.spec_SLASH_speced_vars.json"
 "target/cljs/core$macros.cljc.cache._COLON_cljs.spec_SLASH_registry_ref.json"
 "target/cljs/core$macros.cljc.cache._COLON_cljs.spec_SLASH_speced_vars.json")

that's not what I get

oh, what do you get?

(filter #(clojure.string/includes? (str %) "cljs/spec") (lumo.internal.embedded.keys))
("cljs/spec/alpha$macros.cache.json"
 "cljs/spec/alpha$macros.js"
 "cljs/spec/alpha.cljc"
 "cljs/spec/alpha.cljs"
 "cljs/spec/alpha.cljs.cache.json"
 "cljs/spec/alpha.js"
 "cljs/spec/gen/alpha$macros.cache.json"
 "cljs/spec/gen/alpha$macros.js"
 "cljs/spec/gen/alpha.cljc"
 "cljs/spec/gen/alpha.cljs"
 "cljs/spec/gen/alpha.cljs.cache.json"
 "cljs/spec/gen/alpha.js"
 "cljs/spec/test/alpha$macros.cache.json"
 "cljs/spec/test/alpha$macros.js"
 "cljs/spec/test/alpha.cache.json"
 "cljs/spec/test/alpha.cljc"
 "cljs/spec/test/alpha.cljs"
 "cljs/spec/test/alpha.js")

note the slash

ah well the test is wrong 😄

yep saw that

so @hlolli have you dug in that? at which stage those are loaded instead ?

yes, I've looked a bit into that, and I will be spending my friday night now doing more of that. But it's not dynamic, there's a hash-map in the snapshot/cljs section, maybe that entry is missing.

I'm leaving work and heading home. Will be here later on.

ok will look into that as well

the warnings are fine

there’s no eval in clojurescript

and the files are there

yep, I tried to invert the two lines here https://github.com/anmonteiro/lumo/blob/7c34d011dd8232828a337f361737de0bd3cfd1b4/src/cljs/snapshot/lumo/repl.cljs#L227 so that the cb is called after the inject-... but it seems still there...in any case...the WARNING I am interested in is the instrument one, because I always error out on WARNINGs so it stops my compilation

the callback is fine

I just don’t have time to look into this

@richiardiandrea I don’t see any warnings

on current master

are you sure you have a current build?

oh you mean compiling, not executing

yep compiling @anmonteiro the branch I have PR-ed contains the WARNING

don't worry I will try my best to see what is going on 😄

I don’t see any warnings

with latest master

not even on my branch?

I didn’t check out your branch yet

but

@richiardiandrea I don’t see your warning on CI

oh it failed earlier just a sec

what do I have to run

in your branch?

oh it’s in the PR sorry

yep that, just force pushed

cool I see the warning now

I’ll see if I have time to investigate later

ok thanks Antonio, I did a bit of debugging and I posted it in the issue

hlolli was talking about embedded resources, haven't explored there yet

@richiardiandrea yes I'm working on that feature on this fork https://github.com/hlolli/lumo, still in progress

checking 😉

Documentation PR: https://github.com/anmonteiro/lumo/pull/313/files