Fork me on GitHub
#lumo
<
2017-09-27
>
hlolli11:09:35

that didn't do anything, I guess this needs to be set here https://github.com/nexe/nexe#flags-string in package.js on line 111. I give that a try then...

metametadata13:09:06

Hi! What is the proper way to instrument spec-ed functions in Lumo? I could get it to work in REPL but not when loading the script file. Specifically:

; foo.cljs
(ns foo.core
  (:require [clojure.spec.test.alpha :as st :include-macros true]))

(defn bar
  []
  (st/instrument))
Then in REPL (with org.clojure/test.check present in the classpath passed to lumo):
cljs.user=> (require 'foo)
              ⬆
Cannot read property 'cljs$core$IFn$_invoke$arity$1' of undefined at line 6 foo.cljs

hlolli13:09:49

it's foo.core right, and a file called core in a directory called foo in a folder that's on classpath?

metametadata13:09:58

well, I've put foo.cljs in the current folder. Lumo doesn't really care that namespace name doesn't match the filename

hlolli13:09:33

try removeing .core from the foo and use single name namespace (you get warning you can ignore)

metametadata13:09:33

I had the same problem with correct file structure. it's just the minimal example

metametadata13:09:49

ok, I'll try just to make sure

hlolli13:09:57

the symbols are always stored in the analyzer under the namespace name.

metametadata13:09:03

Tried removing .core - no luck. Also no luck with foo/core.cljs, ns foo.core and (require 'foo.core). So it seems to be some problem related specifically to how I require clojure.spec.test.

hlolli13:09:23

I got

cljs.user=> (require 'foo)	
(require 'foo)	
            ⬆
WARNING: foo is a single segment namespace at line 1 foo.cljs
No such namespace: clojure.test.check, could not locate clojure/test/check.cljs, clojure/test/check.cljc, or JavaScript source providing "clojure.test.check" in file foo.cljs
	 (new)
	 Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:1928:72)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2560:92)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (NO_SOURCE_FILE <embedded>:2559:92)
	 (NO_SOURCE_FILE <embedded>:5560:162)
	 Object.lumo.repl.load_other (NO_SOURCE_FILE <embedded>:6367:378)
	 lumo.repl.load (NO_SOURCE_FILE <embedded>:6371:96)
	 Function.cljs.js.require.cljs$core$IFn$_invoke$arity$5 (NO_SOURCE_FILE <embedded>:5562:77)
	 (NO_SOURCE_FILE <embedded>:5535:284)
	 (Object.lumo.repl.run_sync_BANG_)

metametadata13:09:35

yeah, it's because [org.clojure/test.check "0.9.0"] is needed to be on classpath

metametadata13:09:17

I have it in project.clj deps and and then invoke REPL with

lumo -c `lein cp`

metametadata13:09:49

and then this works without problems:

cljs.user=> (require '[clojure.spec.test.alpha :as st])
nil
cljs.user=> (st/instrument)
[]

hlolli13:09:57

e $ lumo -c src:~/.m2/repository/org/clojure/test.check/0.9.0/test.check-0.9.0.jar
Lumo 1.8.0-beta
ClojureScript 1.9.931
Node.js v8.5.0
 Docs: (doc function-name-here)
       (find-doc "part-of-name-here")
 Source: (source function-name-here)
 Exit: Control+D or :cljs/quit or exit

cljs.user=> (require 'foo)
(require 'foo)
            ⬆
WARNING: foo is a single segment namespace at line 1 foo.cljs
nil
cljs.user=> 

metametadata13:09:47

ok, that's reassuring 🙂

metametadata13:09:20

ᐅ lumo -c src:~/.m2/repository/org/clojure/test.check/0.9.0/test.check-0.9.0.jar
Lumo 1.8.0-beta
ClojureScript 1.9.927
Node.js v8.5.0
 Docs: (doc function-name-here)
       (find-doc "part-of-name-here")
 Source: (source function-name-here)
 Exit: Control+D or :cljs/quit or exit

cljs.user=> (require 'foo)
            ⬆
WARNING: foo is a single segment namespace at line 1 foo.cljs
              ⬆
Cannot read property 'cljs$core$IFn$_invoke$arity$1' of undefined at line 6 foo.cljs
	 (new)
	 Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:1928:72)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2539:92)
	 Object.cljs.analyzer.macroexpand_1 (NO_SOURCE_FILE <embedded>:3118:329)
	 Function.cljs.analyzer.analyze_seq.cljs$core$IFn$_invoke$arity$4 (NO_SOURCE_FILE <embedded>:3125:35)
	 Object.cljs.analyzer.analyze_form (NO_SOURCE_FILE <embedded>:3162:213)
	 Object.cljs.analyzer.analyze_STAR_ (NO_SOURCE_FILE <embedded>:3165:337)
	 Function.cljs.analyzer.analyze.cljs$core$IFn$_invoke$arity$4 (NO_SOURCE_FILE <embedded>:3170:52)
	 Function.cljs.analyzer.analyze_seq.cljs$core$IFn$_invoke$arity$4 (NO_SOURCE_FILE <embedded>:3125:189)
	 Object.cljs.analyzer.analyze_form (NO_SOURCE_FILE <embedded>:3162:213)

Cannot read property 'cljs$core$IFn$_invoke$arity$1' of undefined
	 Function.cljs.spec.test.alpha$macros.instrument.cljs$core$IFn$_invoke$arity$4 (evalmachine.<anonymous>:266:94)
	 Function.cljs.core.apply_to_simple.cljs$core$IFn$_invoke$arity$6 (NO_SOURCE_FILE <embedded>:774:131)
	 Function.cljs.core.apply_to_simple.cljs$core$IFn$_invoke$arity$5 (NO_SOURCE_FILE <embedded>:773:205)
	 Function.cljs.core.apply_to_simple.cljs$core$IFn$_invoke$arity$4 (NO_SOURCE_FILE <embedded>:772:199)
	 Function.cljs.core.apply.cljs$core$IFn$_invoke$arity$4 (NO_SOURCE_FILE <embedded>:785:297)
	 Object.cljs.analyzer.macroexpand_1_STAR_ (NO_SOURCE_FILE <embedded>:3115:105)
	 Object.cljs.analyzer.macroexpand_1 (NO_SOURCE_FILE <embedded>:3118:211)
	 Function.cljs.analyzer.analyze_seq.cljs$core$IFn$_invoke$arity$4 (NO_SOURCE_FILE <embedded>:3125:35)
	 Object.cljs.analyzer.analyze_form (NO_SOURCE_FILE <embedded>:3162:213)
	 Object.cljs.analyzer.analyze_STAR_ (NO_SOURCE_FILE <embedded>:3165:337)

cljs.user=> 

metametadata13:09:36

the only difference is the reported ClojureScript version

metametadata13:09:10

you have 1.9.931 vs. 1.9.927 on my machine somehow

hlolli13:09:17

pff ok, I actually compiled lumo just few minutes ago for another reason. Did you try deleteing .lumo_cache?

metametadata13:09:10

yes, the problem is still there

hlolli13:09:21

well, then compile newest lumo and take a run few times around the block in the meantime 🙂

metametadata13:09:15

alright, thanks for the help! maybe indeed it's the bug in current Lumo versions

hlolli14:09:07

neither modifying flags in scripts/package.js flags: ['--max-old-space-size=8192'] or adding v8.setFlagsFromString('--max_old_space_size=8192'); in src/js/cli.js (next to strict mode flag), changes the value from

(.-heap_size_limit (.getHeapStatistics (js/require "v8")))
=> 1501560832
just as short term solution, I'd like to change the limit, so I welcome all hints.

richiardiandrea14:09:19

@metametadata from what understood version 0.9.0 is not self-host compatible

metametadata14:09:22

@richiardiandrea huh, good point. I don't really use anything from test.check, but I'll try 0.10.0-alpha just to make sure

metametadata14:09:36

also I've built Lumo from master and it fixed my bug

metametadata14:09:08

I guess I need test.check on classpath only because of this issue https://dev.clojure.org/jira/browse/CLJS-1792

richiardiandrea15:09:53

Yes there was a bug in there as well and Antonio fixed it @metametadata ...did not know about that jira though, I added a test.check test in lumo and it seems to be green :)) all good

richiardiandrea15:09:06

Yep saw that, btw -D allows you to specify the dep directly without the whole .m2 path, it does the folder scan in there for you

metametadata17:09:24

@anmonteiro are there any plans for releasing beta2 (with test.check bug fixed)? I didn't want to bother you, but it looks like building Lumo under Linux is more cumbersome than under MacOS 🙂 Somehow (in "node:8.5.0-stretch" docker container) compilation is killed at some point with message "Killed" and no additional information.

anmonteiro17:09:45

probably running out of memory

anmonteiro17:09:03

can you run that?

metametadata17:09:53

okay, didn't think about that. ok, let me try

anmonteiro17:09:53

I’m planning on releasing 1.8.0-rc or 1.8.0 proper eventually, but I have 1 more thing I wanna get done

metametadata17:09:18

@anmonteiro yes, zipped executable seems to work in Debian, thank you

metametadata18:09:49

@anmonteiro did something change in the way require works since 1.7.0? I'm now hitting a very strange problem of not being able to require local file anymore. It only happens when I run Lumo > 1.7.0 inside the docker container which is created by Jenkins pipeline 😕 Cleaning .lumo-cache doesn't help. I can't reproduce it on MacOS or even when I manually run the same docker image and perform all the operations manually. It seems as if Jenkins machinery somehow has effect on how Lumo behaves inside the container. I've checked that the required file exists at the respective path, pwd, etc.

metametadata19:09:44

This is a log from my container (I'm using 1.8.0-beta from npm):

+ cat foo.cljs
(ns foo)

+ lumo --version
1.8.0-beta

+ lumo -e (require 'foo)
No such namespace: foo, could not locate foo.cljs, foo.cljc, or JavaScript source providing "foo"
	 (new)
	 Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:1928:72)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2539:92)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (NO_SOURCE_FILE <embedded>:2538:92)
	 (NO_SOURCE_FILE <embedded>:5847:162)
	 Object.lumo.repl.load_other (NO_SOURCE_FILE <embedded>:6363:378)
	 lumo.repl.load (NO_SOURCE_FILE <embedded>:6367:96)
	 Function.cljs.js.require.cljs$core$IFn$_invoke$arity$5 (NO_SOURCE_FILE <embedded>:5849:77)
	 Function.cljs.js.load_deps.cljs$core$IFn$_invoke$arity$7 (NO_SOURCE_FILE <embedded>:5859:507)
	 Function.cljs.js.ns_side_effects.cljs$core$IFn$_invoke$arity$6 (NO_SOURCE_FILE <embedded>:5917:287)

anmonteiro20:09:40

@metametadata sure you’re not just messing quoting?

anmonteiro20:09:53

i.e. lumo -e "(require 'foo)"

metametadata20:09:43

yep, it's the logging of Jenkins messes stuff up. the only thing I change is the version of Lumo: 1.7.0 <-> 1.8.0-beta

metametadata20:09:28

I suspect there can be something different in the way Lumo started scanning for files and Jenkins executing Lumo process somehow triggers the issue

metametadata20:09:27

For some context, in my a Jenkinsfile there's this line calling the "built-in" pipeline DSL function which runs stuff in shell:

sh """ lumo -e "(require 'foo)" """

metametadata20:09:40

I also managed to docker exec -it ... bash into the same container instance while Jenkins pipeline was running and couldn't reproduce the issue from there

metametadata20:09:08

I also suspect that in these cases Lumo could receive different env vars. But I have to debug it and am not sure if it can really affect require-ing files

richiardiandrea20:09:03

A question: if I have source-map-support in my node_modules, should I see some difference in lumo script stack traces currently