This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-31
Channels
- # aleph (3)
- # aws (5)
- # beginners (65)
- # boot (17)
- # cljs-dev (112)
- # cljsrn (5)
- # clojure (146)
- # clojure-austin (3)
- # clojure-dusseldorf (3)
- # clojure-italy (18)
- # clojure-norway (13)
- # clojure-russia (84)
- # clojure-serbia (5)
- # clojure-spec (24)
- # clojure-uk (84)
- # clojurescript (204)
- # css (1)
- # cursive (21)
- # data-science (3)
- # datascript (21)
- # datomic (26)
- # emacs (5)
- # euroclojure (1)
- # hoplon (8)
- # jobs (7)
- # jobs-discuss (2)
- # keechma (35)
- # lumo (92)
- # mount (1)
- # nrepl (2)
- # numerical-computing (16)
- # off-topic (10)
- # om (58)
- # re-frame (13)
- # reagent (90)
- # remote-jobs (2)
- # ring-swagger (1)
- # spacemacs (9)
- # specter (6)
- # unrepl (17)
- # untangled (56)
- # yada (2)
hey everybody
I'm getting this error when I try to run a script
klipse $ lumo scripts/generate-clojure-spec-cache.cljs
Cannot find module 'nexeres'
Function.Module._resolveFilename (module.cljs:470:15)
Function.Module._load (module.cljs:418:25)
Module.require (module.cljs:498:17)
require (internal/module.cljs:20:19)
(evalmachine.<anonymous>:2:18)
ContextifyScript.Script.runInThisContext (vm.cljs:23:33)
Object.runInThisContext (vm.cljs:95:38)
(Object.lumoEval)
lumo.repl.caching_node_eval (NO_SOURCE_FILE <embedded>:6133:194)
(NO_SOURCE_FILE <embedded>:5373:29)
I'm using lumo 1.5.0
waaaat
I am told that an older version of lumo worked with the same script
nexeres
is gone
does the script rely on internal Lumo things?
oh yes it does
@ericnormand nexeres
was never public API so you should expect breakage
it’s gone because I optimized a few things
I’ll PR KLIPSE
yes, please
thanks
I'll test it out
It works fine
what works fine?
that worked
The scripts from your PR
yeah, I tested it locally, glad it works for you too
Merged into master
Thanks for your contribution @anmonteiro
note that this now makes KLIPSE depend on Lumo 1.4+ I think
I don’t recall exactly when I moved away from nexeres
@viebel however, note these are still internal APIs and if I find a faster alternative I’m not going to be concerned as to what breaks downstream
That’s fine
I don’t expect them to be consumed and they’re very Lumo specific
e.g. tied to Lumo’s ClojureScript version too
It will not break Klipse
great
It will break only the script that generates the analysis cache that Klipse uses
I guess that the cached files are still the same. right?
yes, but dependent on the ClojureScript version they were compiled with
so for Lumo 1.5, CLJS 1.9.542
Makes senses
I’m trying to require ‘om.core inside lumo
And it fails because it cannot require cljsjs.react
I remember that it used to work
@anmonteiro any idea about ⬆️ ?
@viebel I think I broke foreign libs in 1.5. Can you try brew install --HEAD lumo
?
I can also link you a built binary if you'd prefer
I’m trying with brew
Is there a way to skip the requiring of a lib
I mean to mark the lib as already loaded
Something like goog.provide()
@anmonteiro installed lumo from HEAD
issue still there
are you adding react to the classpath
what do u mean @anmonteiro ?
lumo -c /path/to/cljsjs/react.jar
?
you need to specify the full transitive classpath
react is in the classpath
@anmonteiro By the way, it works fine with Lumo 1.1.0
it should also work with Lumo from master, unless you uncovered another bug
@viebel can you paste the output of starting lumo?
here you go
lumo -k . -c $cp
Lumo 1.5.0
ClojureScript 1.9.542
Node.js v7.10.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 'cljsjs.react)
Could not require cljsjs.react
(new)
Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:1937:200)
Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2484:92)
(NO_SOURCE_FILE <embedded>:5237:40)
Object.cljs.js.run_async_BANG_ (NO_SOURCE_FILE <embedded>:5217:173)
Object.cljs.js.process_deps (NO_SOURCE_FILE <embedded>:5217:244)
Object.cljs.js.process_libs_deps (NO_SOURCE_FILE <embedded>:5219:60)
(NO_SOURCE_FILE <embedded>:5235:358)
Object.cljs.js.run_async_BANG_ (NO_SOURCE_FILE <embedded>:5217:173)
Object.cljs.js.process_deps (NO_SOURCE_FILE <embedded>:5217:244)
Unexpected identifier
createScript (vm.cljs:53:10)
Object.runInThisContext (vm.cljs:95:10)
(Object.lumoEval)
lumo.repl.caching_node_eval (NO_SOURCE_FILE <embedded>:6133:194)
(NO_SOURCE_FILE <embedded>:5236:153)
Object.cljs.js.run_async_BANG_ (NO_SOURCE_FILE <embedded>:5217:173)
Object.cljs.js.process_deps (NO_SOURCE_FILE <embedded>:5217:244)
Object.cljs.js.process_libs_deps (NO_SOURCE_FILE <embedded>:5219:60)
(NO_SOURCE_FILE <embedded>:5235:358)
Object.cljs.js.run_async_BANG_ (NO_SOURCE_FILE <embedded>:5217:173)
right
@viebel you’re not using lumo from HEAD
brew uninstall lumo && brew install --HEAD lumo
or, hey, are you on a mac?
Actually I did brew unlink lumo && brew install --HEAD lumo
@viebel https://590-69415002-gh.circle-artifacts.com/0/Users/distiller/lumo/build/lumo.zip
downloading it…
By the way @anmonteiro : Is there a way to skip the requiring of a lib inside lumo?
I mean to mark it as already resolved
For Klipse, I just need to generate the analysis cache with lumo
with lumo from HEAD => (require 'cljsjs.react)
works fine 🙂
@viebel what do you mean by skip requiring it
rehashing an old question: is there something akin to *clojure-version*
in lumo
?
for understanding if I am in a lumo
repl
cljs.user=> (require '[lumo.core :refer [*lumo-version*]])
nil
cljs.user=> *lumo-version*
"1.5.0"
uhm that is great, two instructions though are a bit tough to handle for inf-clojure
and I was wondering whether there is a one instruction check I can do
well this works:
cljs.user=> (require '[lumo.core :refer [*lumo-version*]]) *lumo-version*
nil
"1.5.0"
maybe we could move the *lumo-version*
to an already required namespace? what do you think Antonio?
cljs.user=> (do (require '[lumo.core :refer [*lumo-version*]]) *lumo-version*)
"1.5.0"
@richiardiandrea what about this? ^
1 form
it is good, however the point of moving is still valid because it kind of make sense to have it always visible...
@richiardiandrea please open an issue so we can discuss the cost of auto-referring lumo.core
will do
tnx a lot!