This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (306)
- # boot (191)
- # bristol-clojurians (4)
- # business (3)
- # cbus (4)
- # cider (6)
- # cljsrn (51)
- # clojure (147)
- # clojure-canada (1)
- # clojure-conj (6)
- # clojure-japan (2)
- # clojure-poland (8)
- # clojure-russia (57)
- # clojure-sg (1)
- # clojurecup (1)
- # clojurescript (229)
- # core-async (4)
- # cursive (47)
- # data-science (2)
- # datomic (3)
- # emacs (6)
- # events (1)
- # hoplon (16)
- # immutant (33)
- # jobs (1)
- # ldnclj (7)
- # off-topic (25)
- # om (69)
- # onyx (7)
- # re-frame (35)
- # reagent (3)
- # yada (4)
@pandeiro: sure. all castra calls work normally, but when i make a syntax error, the next castra call fails because the response doesnt have anything else but the exception stack trace, not even a http header
I would recommend u to try the most minimal boot-test scenario to see how it can run with sub-second speeds and u will see what happens when u add datomic.api to the mix
@domkm: try to comment out this line and see what happens before and after on subsequently saving test.clj: https://gist.github.com/onetom/2e39f464df438b5e69b0#file-test-clj-L3
@onetom: Ouch, that's a bummer. I still don't think it's solely to blame though because the test suites runs in <10 secs in a fresh repl so a fresh pod shouldn't (I hope) take 60 secs.
@onetom: In terms of datomic, maybe there is a way to have a fixture run once for the whole test suite instead of once per namespace.
seems like you already have a good workflow with cider for rapid development and boot-test for CI
@domkm: just try to do a
(require 'datomic.api) from a
boot -BP -d com.datomic/datomic-free:0.9.5327 repl
it does take ~3s
@micha: i vaguely remember something like u can "fork" an existing clojure env and make a new pod based on it am i mixing it up with something else? like would it be possible to specify to preload certain stuff into the test pod which we trust not to change between test runs?
you can mitigate all of this with the
pod-pool, which maintains of pool of warmed up pods ready to go
how would that help? between test runs there is enough time to create 10 other which already have the dependencies loaded into them?
im not very confident in this area yet still... havent used
(resolve) yet in any real scenario..
the problem w the 3 seconds is not that we want to run tests that frequently, but we want to continue thinking after we made a change in the tests, so we want to know whether that change was successful or not
@micha: seems the boot-clj docker images fails to build a heroku-valid slug via
@codefinger: does the cedar:14 stack have wget or do i need to install everything as per usual?
Its exactly what you get when you run
heroku run bash, so you could test things out that way
Yeah! I found those guys here: https://github.com/boot-clj/boot/wiki/Boot-for-Leiningen-Users
And, I presume, the process of copying the output of
boot show -u to my build file is up to me?
but it's not really feasible to write to the user's build.boot file because it's a program
Micha, are you one of the boot devs on the off chance? Or just a plucky adventurer like myself?
Well, major kudos to you for the effort. I'm tremendously fond of boot so far, and am really excited to learn all about it.
here is the place, btw: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L197
@codefinger: is there something else I need to do to get the
docker:release to work? it fails to find the slug.tgz
@micha here's the repo for heroku docker image it seems if there is an entry point in the docker file it will fail to build the slug
hey everybody I'm starting to migrate a lein project to boot. no questions, just wanted to say that I'm very impressed by the docs, both quality and quantity. awesome work
@isaac: is that a question or a statement? I know people building react-native apps with boot/boot-cljs
@isaac: can you more specifically say where the document write call is done? also make sure your lein-cljsbuild + boot-cljs compiler options are equivalent
I see that in
:output-to is ignored. What is the usual way of getting the files to
resources/public/... where I want them?
@bensu in boot-cljs you generally specify output location by putting the appropriate .cljs.edn file where you want it
the (README) documentation for this sucks, putting this kind of stuff in a file however has huge advantages (other tasks can look at/modify it)
@isaac: cool, glad you got it working. Would be curious to see a nice/minimal boot + react native setup if you have it
I'm sold on having a
cljs.edn but I'm not sure about placing a config file on the same directory than generated files.
I would want to ignore/delete the generated files but track/keep the
cljs.edn, which is awkward if they are next to each other
I'm serving files out of
resources/public/... and I would like the js files to end in
@bensu: at the end of running the task pipeline boot dumps the fileset contents in
:target-dir (defaults to
many people also just serve stuff straight from the classpath (fileset is on classpath)
@bensu: the initial fileset is computed from the files you have in
@martinklepsch: is there a way to name the final file
app.js both form my dev and production builds and be placed on the same place (to keep the same script tag on the html)?
@bensu: there’s a table in the readme what can be passed to task and what must be .cljs.edn — think most stuff can be done at task level
@martinklepsch: thanks! I can, the options I'm interested are all compiler options. In tenzing, the file is called
app.cljs.edn but the generated file is
@bensu: given you can set all things as task options you can use a single .cljs.edn file yes?
one thing that I don't like is that as long as
boot-cljs doesn't follow the compiler
out convention you will always need an
I guess that
:asset-path requirement depends on where you serve your files from. I assume the reasoning was that multiple builds need multiple output dirs(?)
yeah, it's not such a biggie either since these things are usually sorted out by the fine people that make templates
@flyboarder: still having trouble with the docker stuff? have you tried putting the boot step in an ONBUILD RUN?
using the heroku base image was much simpler than i thought getting all the env setup would be
i had to remove the entry point from the docker file so you will need to run boot <task>
an ONBUILD step would probably work. that's what i do with the lein image https://github.com/heroku/docker-clojure/blob/master/Dockerfile#L16