This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-17
Channels
- # beginners (52)
- # boot (116)
- # cider (21)
- # cljs-dev (44)
- # clojure (104)
- # clojure-dev (82)
- # clojure-greece (5)
- # clojure-japan (4)
- # clojure-nl (14)
- # clojure-russia (65)
- # clojure-serbia (3)
- # clojure-spec (38)
- # clojure-uk (9)
- # clojure-ukraine (1)
- # clojurescript (65)
- # clojurewest (1)
- # community-development (1)
- # core-logic (3)
- # cursive (5)
- # data-science (9)
- # datomic (13)
- # emacs (45)
- # euroclojure (1)
- # hoplon (2)
- # instaparse (23)
- # javascript (1)
- # jobs (2)
- # klipse (43)
- # leiningen (8)
- # lumo (25)
- # off-topic (7)
- # om (13)
- # om-next (3)
- # onyx (11)
- # pedestal (12)
- # planck (19)
- # proton (1)
- # re-frame (26)
- # reagent (26)
- # remote-jobs (13)
- # ring-swagger (23)
- # spacemacs (1)
- # untangled (3)
@stbgz yeah. If I pass it as a classpath entry, would it override the one bundled with lumo?
@moxaj nop you can put a jar in the lumo classpath(as in the classpath that lumo will use to start the repl) and you should be able to access it with a require
@moxaj not possible to override the ClojureScript version in Lumo
not sure it’ll ever be
@anmonteiro I see. Another question, if I may: if I enter (ns a.b #?(:cljs (:require-macros [a.b])))
into the lumo repl, it throws an error (`No such macros namespace ...`). However, loaded from a file, it works. Is this expected?
@moxaj did you define the a.b
namespace?
or rather, the a.b$macros
namespace
that’s what require-macros
really does behind the covers
right. so at the REPL you need to define the a.b$macros
NS before requiring it
see http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html
hmm, so when loading it from a file, with *load-fn*
, does the compiler handle this automatically?
the problem is when defining namespaces at the REPL
not particularly a “problem"
but a gotcha to be aware of
this is still the klipse issue i've fought before, you may remember, and I believe this might be key
it seems klipse evaluates each expression, one after the another, as if entered into a repl, thus triggering this error
I’m not familiar with how Klipse does it