This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # beginners (42)
- # boot (34)
- # cider (157)
- # cljs-dev (12)
- # cljsrn (3)
- # clojure (165)
- # clojure-conj (1)
- # clojure-india (1)
- # clojure-italy (6)
- # clojure-russia (20)
- # clojure-spec (27)
- # clojure-uk (173)
- # clojurescript (116)
- # cursive (30)
- # datomic (87)
- # devcards (1)
- # docs (9)
- # emacs (2)
- # ethereum (2)
- # events (2)
- # fulcro (60)
- # graphql (10)
- # hoplon (2)
- # jobs-rus (6)
- # keechma (1)
- # lein-figwheel (9)
- # leiningen (36)
- # luminus (2)
- # mount (3)
- # off-topic (16)
- # om (14)
- # onyx (12)
- # pedestal (19)
- # portkey (107)
- # re-frame (9)
- # reagent (5)
- # ring (26)
- # shadow-cljs (149)
- # spacemacs (3)
- # sql (6)
Do we still need to first require a namespace from a namespace declaration in order to be able to require it in the bREPL?
I'm following modern-cljs and I believe it is a tad dated. It mentions an existing (at the time) limitation of boot, one that forces us to first require a namespace in a namespace declaration of a clojurescript file in our project in order to be able to require that namespace in the bREPL to get to know it..
Sorry, modern-cljs is a tutorial, I don't know how well known it is. https://github.com/magomimmo/modern-cljs
@anantpaatra I'm still not sure what you're asking -- it doesn't sound like a limitation of Boot so I'm wondering if something you're reading is confusing you? Can you link to the exact page that talks about the "limitation" you're asking about? The way you've phrased it doesn't make any sense to me, I'm afraid...
It states that you first need to use the
(:require [namespace]) in a file in order to
(require '[namespace]) from the bREPL.
I think it's just saying that you can't
(require '[arbitrary.namespace]) in the bREPL -- it either has to be a namespace in your cljs source files or else a library namespace that your own cljs source specifically
(:require ...)s (and that you need to
(require ...) the namespace matching that source file first). No idea whether that's still a limitation. I don't do anything with cljs these days, only clj.
But I think the author of
boot-cljs-repl is here in this channel and might be able to give you a better answer? Or at least, the author of the
FWIW, that limitation isn't really a big deal. It just means you (probably) need to
require one of your own project's namespaces first (and that will make the library namespaces available) -- which would be your most common workflow anyway I think.
Your explanation helped me grasp the implications. I believe you are right and I've given too much attention to this. Also, I'll keep in mind that I can contact the authors through this medium as well, I'm not used to that possibility. Thanks again!
Hello, how to add a dependency at runtime in the repl ? I tried
(boot.core/merge-env! :dependencies '[org.clojure/core.match "0.3.0-alpha5"]) but it tells me
java.lang.UnsupportedOperationException: nth not supported on this type: Symbol
Hii all, I’m trying to use boot-test and it seems as a default it exercises all loaded namespace is this intended behaviour? (e.g. not artefacts in my project) As an example this is the output I get:
boot test -n prequote.test-suite RC: 0 - (git)-[master] Testing clojure.spec.gen.alpha Testing clojure.set Testing prequote.test-suite Testing boot.from.io.aviso.exception Testing clojure.stacktrace Testing clojure.string Testing boot.from.io.aviso.writer
@nfisher I don't think it's supposed to test other namespaces, according to a quick skim of the source
It looks like core/cache-dir! can be used as a persistent alternative to core/tmp-dir! .
@dominicm Yes it requires a namespace qualified key but that is easy enough to get. It is still not preserving enough. I really need all of the temporary directories participating in the filesets to be preserved.
wait task does what I want, obviously.
Best thing I can think of is to hash all of the files in those directories together, to use as your key
What is a good way to capture the messages emitted to stdout and stderr ? [from within a task]
@dominicm of course, thanks, but it does not capture err. I made a copy and called it
with-err-str any idea why such a function does not already exist?
If a task needs to bail out on what it is doing what should it return? Clearly the
next-handler should not be called.
throwing an exception will stop the pipeline also, if it needs to bail because of an error