Clojurians
#lumo
<
2017-11-17
>

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

richiardiandrea00:11:16

@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

anmonteiro00:11:46

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

anmonteiro00:11:06

loading resources is pretty self contained

anmonteiro00:11:11

in the load function in lumo.repl

richiardiandrea00:11:27

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

anmonteiro00:11:17

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

richiardiandrea00:11:28

just for quickly executing the tests

richiardiandrea00:11:42

will put everything back when I will find the fix :wink:

richiardiandrea00:11:19

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

hlolli00:11:16

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.

anmonteiro00:11:50

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

anmonteiro00:11:54

or whatever it’s called

anmonteiro00:11:04

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

hlolli00:11:37

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

hlolli00:11:26

yup bingo, I was exacly looking there

hlolli00:11:54

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

richiardiandrea01:11:46

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
That I have never seen before

richiardiandrea01:11:06

(apart from the first line that I have added)

richiardiandrea01:11:29

thanks for the hint! digging...

richiardiandrea01:11:36

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

richiardiandrea01:11:29

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

cgrand09:11:35

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)

richiardiandrea15:11:37

Uhm I will try to check that

cgrand16:11:37

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

cgrand16:11:27

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

cgrand16:11:47

(and timestamps are ok)

hlolli16:11:04

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

hlolli16:11:55

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?

cgrand16:11:39

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

hlolli16:11:40

does it ignore it with lowercase or capital k?

cgrand16:11:51

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

cgrand16:11:16

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

cgrand16:11:26

Is my expectation wrong?

hlolli16:11:44

no that's correct expectation

hlolli16:11:47

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.

hlolli16:11:34

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

cgrand16:11:58

I’m running lumo master

hlolli16:11:50

how this could work would be

cd ~/myLumoProject/
lumo -m cljs.core -c src -k node_modules/xforms/.lumo_cache
something like this should prevent cacheing between starts.

richiardiandrea16:11:58

It is a brand new feature something might be off

richiardiandrea16:11:40

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

richiardiandrea16:11:58

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

cgrand16:11:01

@richiardiandrea thanks to you for getting me set up

anmonteiro16:11:54

We dont read cache from Npm packages yet

anmonteiro16:11:07

It’s just not implemented

anmonteiro16:11:18

Which is why the issue is still open

richiardiandrea16:11:58

Oh cool that explains it

cgrand16:11:45

Well now you know that you canuse xforms to test :slightly_smiling_face:

cgrand17:11:03

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?

anmonteiro17:11:45

I havent given it any thought

anmonteiro17:11:53

Might eequire some refactoring

anmonteiro17:11:30

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

cgrand17:11:03

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

cgrand17:11:34

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

anmonteiro17:11:40

Right that may become a problem

anmonteiro17:11:15

Maybe we shouldnt support caches at all

anmonteiro17:11:28

And have that be an app-thing only

cgrand17:11:02

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

richiardiandrea18:11:10

@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)
I would have expected to see cljs.spec.test.alpha$macros? Am I on the right track? EDIT: test was wrong

richiardiandrea18:11:52

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

hlolli18:11:43

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

richiardiandrea18:11:35

uhm lemme have a look

richiardiandrea18:11:57

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

hlolli18:11:25

that's not what I get

richiardiandrea18:11:59

oh, what do you get?

hlolli18:11:33

(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")

hlolli18:11:37

note the slash

richiardiandrea18:11:40

ah well the test is wrong :smile:

richiardiandrea18:11:35

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

hlolli18:11:00

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.

hlolli18:11:18

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

richiardiandrea18:11:00

ok will look into that as well

anmonteiro18:11:02

the warnings are fine

anmonteiro18:11:08

there’s no eval in clojurescript

anmonteiro18:11:02

and the files are there

richiardiandrea18:11:00

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

anmonteiro18:11:22

the callback is fine

anmonteiro18:11:24

I just don’t have time to look into this

anmonteiro18:11:54

@richiardiandrea I don’t see any warnings

anmonteiro18:11:58

on current master

anmonteiro18:11:05

are you sure you have a current build?

anmonteiro18:11:49

oh you mean compiling, not executing

richiardiandrea18:11:30

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

richiardiandrea18:11:22

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

anmonteiro18:11:57

I don’t see any warnings

anmonteiro18:11:02

with latest master

richiardiandrea18:11:42

not even on my branch?

anmonteiro18:11:13

I didn’t check out your branch yet

anmonteiro18:11:53

@richiardiandrea I don’t see your warning on CI

richiardiandrea18:11:05

oh it failed earlier just a sec

anmonteiro18:11:21

what do I have to run

anmonteiro18:11:22

in your branch?

anmonteiro18:11:35

oh it’s in the PR sorry

richiardiandrea18:11:26

yep that, just force pushed

anmonteiro19:11:49

cool I see the warning now

anmonteiro19:11:00

I’ll see if I have time to investigate later

richiardiandrea19:11:17

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

richiardiandrea19:11:24

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

hlolli19:11:36

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