Fork me on GitHub
#boot
<
2015-11-18
>
onetom00:11:22

@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

onetom00:11:28

@domkm: loading the datomic api takes quite a while

onetom00:11:56

We experience 4-7second runtimes w in-mem datomic db

onetom00:11:09

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

onetom00:11:53

@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

onetom00:11:19

on my i5 rMBP it takes 0.1s without datomic and takes 3s with datomic

onetom00:11:06

so much about the promise of having an in-memory db making tests fast simple_smile

domkm00:11:05

@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.

domkm00:11:48

@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.

onetom01:11:33

it's not the fresh pod which takes long to create but to load the datomic.api into it

micha01:11:25

seems like you already have a good workflow with cider for rapid development and boot-test for CI

micha01:11:48

that seems like a pretty good way to do it

micha01:11:09

that's pretty much what i've been doing, too

onetom01:11:09

@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

onetom01:11:48

@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?

micha01:11:56

it doesn't copy the stuff in memory, only the dependencies and jvm configuration

micha01:11:09

there is no way to share clojure objects between pods

micha01:11:20

because of the way protocols work it's impossible

onetom01:11:23

u r reloading clojure itself too, right?

micha01:11:55

you can mitigate all of this with the pod-pool, which maintains of pool of warmed up pods ready to go

micha01:11:02

the boot-test task uses one

onetom01:11:04

how would that help? between test runs there is enough time to create 10 other which already have the dependencies loaded into them?

micha01:11:25

i would hope so

onetom01:11:44

any example on how to do this?

micha01:11:49

if you need to test your thing every < 3 seconds i would say there is something wrong

micha01:11:13

and you can bump up the size of the pool to handle spikes

micha01:11:21

boot-test does this

micha01:11:30

it preloads clojure in the pod

micha01:11:48

but you could preload more, like datomic

micha01:11:04

the only issue is if the stuff you preload needs to change when you work

micha01:11:13

then of course it won't work the way you want

onetom01:11:39

where can i specify what to preload?

micha01:11:54

there is an :init option to pod-pool where you can make a constructor

micha01:11:55

pod-pool takes a :size option as well, i believe

micha01:11:04

which you can use to increase the number of pods in the pool

onetom01:11:24

how can i override that :init ?

onetom01:11:35

using something like with-redefs?

micha01:11:53

we should add the option to the boot-test task

onetom01:11:57

or should i just fork boot-test and...

micha01:11:06

👍 totes

micha01:11:17

it could take a symbol

micha01:11:30

and resolve that to get the init fn you want to use

micha01:11:35

or something

onetom01:11:16

im not very confident in this area yet still... havent used (resolve) yet in any real scenario..

onetom01:11:44

but anyway, no worries, i can hack something specific up for ourselves 1st

onetom01:11:28

it will be really usable if we can shave off that 3 seconds!

onetom01:11:36

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

micha01:11:18

have you tried running the tests in the repl, like with cider?

onetom01:11:24

but kenneth says maybe we should not be drinking (cider) while trying to run tests.

onetom01:11:36

he is the irish person on the team 😉

micha01:11:04

drinking seems to help when i run tests

onetom01:11:57

kenneth will come over and test that hypothesis w u simple_smile

onetom01:11:17

and we shall formally include it into our development practices then

flyboarder02:11:42

@micha: seems the boot-clj docker images fails to build a heroku-valid slug via heroku docker:release

micha02:11:24

do you know what the issue might be?

flyboarder02:11:52

working on it

flyboarder02:11:20

the log was fairly useless

flyboarder02:11:06

im going to rebuild the boot-clj from the heroku/jvm image

micha02:11:34

it would be a shame if you needed to use a special image to deploy to heroku

micha02:11:54

seems like it would kind of defeat the purpose of using docker

codefinger02:11:21

You need to inherit from heroku/jvm

codefinger02:11:04

Or at least heroku/cedar:14

flyboarder02:11:30

yeah that what i figured

codefinger02:11:56

I would argue that its a drawback of docker though :)

flyboarder02:11:36

what is the problem that you are not able to use other images?

codefinger02:11:20

Because it ultimate is executed on our LXC runtime and not a docker runtime

codefinger02:11:00

We will probably get to a true docker runtime. No promises though :)

micha02:11:52

does the heroku/jvm image work normally with docker?

flyboarder02:11:44

@codefinger: does the cedar:14 stack have wget or do i need to install everything as per usual?

codefinger02:11:43

No wget i think. But does have curl

codefinger02:11:38

Its exactly what you get when you run heroku run bash, so you could test things out that way

flyboarder03:11:01

initial commit is looking promising, its building now

spiralganglion03:11:55

Is there anything like lein-ancient for boot?

micha03:11:23

boot show -u

spiralganglion03:11:50

Thanks! That seems to work pretty darn well 😉

spiralganglion03:11:59

Beginner question: where is that documented?

micha03:11:02

:thumbsup:

micha03:11:20

boot show --help or (doc show) in the repl

micha03:11:35

to see all the tasks that are available at any time you can do boot --help

micha03:11:55

or (boot) in the repl

micha04:11:38

you might also want boot show -d and boot show -p

micha04:11:54

like lein deps :tree sort of

spiralganglion04:11:21

But the boot show -u is new to me.

micha04:11:44

show is where the project diagnostic tools are

spiralganglion04:11:46

And, I presume, the process of copying the output of boot show -u to my build file is up to me?

spiralganglion04:11:30

nod easy enough!

micha04:11:30

you can make a deps.edn file

micha04:11:34

if you want

micha04:11:41

and slurp that in in your build.boot

micha04:11:45

or something

spiralganglion04:11:07

Right, and then just write a task to update that..?

micha04:11:17

but it's not really feasible to write to the user's build.boot file because it's a program

spiralganglion04:11:20

Micha, are you one of the boot devs on the off chance? Or just a plucky adventurer like myself?

micha04:11:40

yeah i've been working on it for a while now

spiralganglion04:11:02

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.

micha04:11:24

if you wanted to get the update dep info as clj data

micha04:11:31

you can call that function from the repl

micha04:11:49

and make a task that updates your deps.edn file or whatever you want to do

micha04:11:31

thanks! i'm glad you are enjoying it simple_smile

flyboarder04:11:18

@codefinger: is there something else I need to do to get the docker:release to work? it fails to find the slug.tgz

flyboarder15:11:12

@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

bensu16:11:51

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

martinklepsch16:11:53

👍 that’s great to hear

isaac17:11:11

boot-cljs do not support react-native

martinklepsch17:11:57

@isaac: is that a question or a statement? I know people building react-native apps with boot/boot-cljs

isaac17:11:46

boot-cljs compiler js can’t running on iOS

isaac17:11:27

It’s contains document.write …

isaac17:11:38

the output file content difference with lein-cljsbuild outputed

martinklepsch17:11:24

@isaac: I see what you mean

martinklepsch17:11:02

@isaac: how should a loading shim for React Native look?

martinklepsch17:11:17

@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

bensu17:11:43

I see that in boot-cljs :output-to is ignored. What is the usual way of getting the files to resources/public/... where I want them?

isaac17:11:09

Oh! I’m sorry, my :asset-path set wrong

isaac17:11:20

@martinklepsch: thanks

martinklepsch17:11:15

@bensu in boot-cljs you generally specify output location by putting the appropriate .cljs.edn file where you want it

martinklepsch17:11:05

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)

martinklepsch17:11:57

@isaac: cool, glad you got it working. Would be curious to see a nice/minimal boot + react native setup if you have it simple_smile

bensu17:11:09

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.

bensu17:11:50

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

isaac17:11:54

@martinklepsch: OK, simple_smile

martinklepsch17:11:56

(this is just the “same directory” in target/ — just to be clear)

martinklepsch17:11:15

@bensu: generated files will never pollute your source tree

martinklepsch17:11:26

everything happens in fileset and is eventually dumped to target/

bensu17:11:07

I'm serving files out of resources/public/... and I would like the js files to end in resources/public/js/generated.js

bensu17:11:37

do I have to grab the files and move them there with a task?

bensu17:11:59

I think I'm going to play with tenzing before migrating a project

bensu17:11:14

seeing how it should work will probably help

martinklepsch17:11:08

@bensu: why not serving from target/public/?

bensu17:11:40

because I hadn't realize that is how (serve) works

bensu17:11:02

I'm now trying tenzing (AWESOME) and I see how it is supposed to work

martinklepsch17:11:06

@bensu: at the end of running the task pipeline boot dumps the fileset contents in :target-dir (defaults to ./target/)

bensu17:11:41

yeah, but does it also dump all your files in resources there and "merges" the dirs?

martinklepsch17:11:49

many people also just serve stuff straight from the classpath (fileset is on classpath)

martinklepsch17:11:21

@bensu: the initial fileset is computed from the files you have in resource-paths, source-paths &c.

bensu17:11:33

haha genius

martinklepsch17:11:40

these you need to set like (set-env! :resource-paths #{“resources”}) of course

bensu18:11:06

@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)?

martinklepsch18:11:27

@bensu: is something preventing you from using the same .cljs.edn file?

bensu18:11:51

they are completely different

bensu18:11:16

(as in every field)

martinklepsch18:11:46

you can use the sift task to move a file… boot sift -h

martinklepsch18:11:57

how are they so different though? simple_smile

bensu18:11:24

can I just leave it empty and pass all the options from the task?

martinklepsch18:11:35

@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

bensu18:11:17

@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 app.js

bensu18:11:28

in my project the generated file is app.cljs.edn.js

bensu18:11:45

is that related to the :ids?

martinklepsch18:11:01

how do you specify :ids?

martinklepsch18:11:38

@bensu: given you can set all things as task options you can use a single .cljs.edn file yes?

bensu18:11:45

yes, it was a bad :ids.

bensu18:11:14

I'm guessing boot-cljs magically finds the .cljs.edn file

martinklepsch18:11:46

it scans the fileset for .cljs.edn files yes.

bensu18:11:55

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 :asset-path for :none

martinklepsch18:11:04

That said value of :ids should always have .cljs.edn trimmed

bensu18:11:56

ahh, good to know

martinklepsch18:11:08

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(?)

bensu18:11:17

yeah, it's not such a biggie either since these things are usually sorted out by the fine people that make templates

martinklepsch19:11:53

not all things are greenfield simple_smile

codefinger23:11:04

@flyboarder: still having trouble with the docker stuff? have you tried putting the boot step in an ONBUILD RUN?

flyboarder23:11:42

@codefinger: I got it deploying finally

flyboarder23:11:10

if you have suggestions PR’s welcome simple_smile

flyboarder23:11:33

using the heroku base image was much simpler than i thought getting all the env setup would be

flyboarder23:11:51

just updating circleci for running tests in docker

codefinger23:11:10

i'll pull it down and give it a try

flyboarder23:11:17

i had to remove the entry point from the docker file so you will need to run boot <task>

codefinger23:11:15

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

flyboarder23:11:13

i also had to remove VOLUME

flyboarder23:11:31

moving these things to docker-compose file resolves the issue

flyboarder23:11:58

i didnt need VOLUME for my web service so having it only in shell instead of the dockfile is cleaner IMHO