This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (93)
- # boot (34)
- # capetown (1)
- # cider (15)
- # cljs-dev (30)
- # cljsjs (9)
- # clojars (8)
- # clojure (199)
- # clojure-austin (3)
- # clojure-france (3)
- # clojure-greece (2)
- # clojure-italy (46)
- # clojure-quebec (7)
- # clojure-russia (2)
- # clojure-spec (76)
- # clojure-uk (16)
- # clojurescript (43)
- # core-async (7)
- # cursive (14)
- # data-science (1)
- # datascript (4)
- # datomic (3)
- # devcards (60)
- # editors (5)
- # funcool (5)
- # garden (3)
- # hoplon (32)
- # immutant (22)
- # jobs (1)
- # lein-figwheel (21)
- # leiningen (1)
- # mental-health (11)
- # mount (2)
- # off-topic (6)
- # om (16)
- # onyx (15)
- # re-frame (43)
- # reagent (20)
- # rum (18)
- # specter (37)
- # sql (2)
- # testing (8)
- # untangled (7)
- # yada (19)
Has the boot community done anything along the lines of lein voom, where a project can depend on specific git commits or branches of other projects?
I was thinking of the built-in
—checkouts option… but I haven’t actually looked at that.
—checkouts seems to be about JAR files and watching/refreshing dependencies on change? EwenG’s task looks more like Leiningen’s checkouts support perhaps?
boot voom would be awesome... i have a bunch of lein voom projects and one boot project which currently gets its deps updated by hand
When running tests with
boot test, the executing namespace (`*ns*`) of my tests appears to be
pod. However, when I run them manually from the REPL via
(clojure.test/run-tests <my ns>), the namespace is
boot.user. This means if the code I'm testing generates symbols based on
*ns* they will be different between the two scenarios. Is there a way to have the same executing namespace in both situations?
I'm learning boot. I've updated https://github.com/daslu/tenzing-re-frame-todomvc to use current versions of boot, and current library versions. I'm having a problem with .cljs.edn tenzing-re-frame-todomvc has the file resources/js/app.cljs.edn If I remove the .cljs.edn file and adjust index.html to use main.js rather than js/app.js, the application works. If use resources/js/app.cljs.edn, I get the ClojureScript could not load :main, did you forget to specify :asset-path? error. I think that the app.js shim is trying to load the goog dependencies from the server root directory rather than from the js subdirectory. Any ideas for debugging and fixing this problem?
@jannis: The trick we use is to have this in each namespace where we’d want to reference
(def my-ns *ns*)
my-nsinstead. Since this is bound to a value at load time, you’re guaranteed that
my-nsrefers to the actual namespace and not the dynamic value of the calling namespace. Does that help?
@uwo: What kind of problems? With a quick glance ajchemist/boot-figwheel looks like it is not compatible with boot watch and doesn't integrate with Boot filesets, so it can't access files created by other tasks
right. I’ve avoided using it with watch. I think i probably asked for help too soon. my main problem is actually just getting my assets served properly. But, secondarily I run into this error
java (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)
@uwo: have you tried boot-cljs yet? it offers a similar workflow, is better integrated into boot
yes. we just switched to boot-cljs (and boot), however compile times were much slower than with figwheel, so I was experimenting with using figwheel at dev time
Not sure what is the status on OS X or Windows but on Linux the compile times should be similar
But I believe compile times should be similar on OS X also, all my co-workers are using OS X and I haven't noticed that their builds would be any slower than mine
for me, a fresh compile with figwheel was around
14 seconds, and restarting thereafter about 2-4. With boot-cljs I’m around a half minute, though incremental compiles are fine
Boot starts with new temp dirs each time and I haven't found slow starts too annonying yet to store Cljs cache in persistent location
Plus, Cljs cache can still cause random problems, after changing deps etc, that require cleaning it
okay. cool. this wasn’t intended to be a complaint about the speed of boot-cljs, just an inquiry into boot-figwheel. Thanks for your time!
@bsima: I’m not Alan (and I don’t work there) and I’m not sure of the context of your question but… at World Singles we use Component with Boot.
I blogged a bit about that last month… http://seancorfield.github.io/blog/2016/06/17/more-boot/
I was thinking it might be possible to do something fun with different systems in different pods, for example a
client task and a
server task, each running in a separate pod so I can run them completely isolated from each other in development
We run our Expectations test suite in a pod and it does the whole component start / stop inside the pod there.