@richiardiandrea: how do you feel about moving the test tasks from boot.task.built-in to its own namespace?

so we don't need to have it as part of the public api yet

sounds ok

I created boot.test

maybe make like boot.self-test for now?

and combine the stuff in boot.test with the test tasks in there?

just to avoid confusion

so one more namespace boot.self-test with runtests in it right?

and runboot, test-report, etc

yes

and what's currently in boot.test

so everything in boot.self-test

the name boot.test might cause confusion, do you think?

well, maybe, it can be used for testing arbitrary things, not just boot

but yes for me it's ok

i like the way the deftesttask macro works

very interesting

it's very easy to follow

oh that's the best compliment, and it is a compliment that I send right at you, because tasks are key for that 😄

i need to think how to partition middlewares now so that i can batch execution

probably I will need a higher order task, partition, that does that

perhaps instead of using a future directly you could use delay

put the delays into a vector in an atom

and after they're all in the atom you could force them in batches

(delay (boot.App/runBoot ...)) or something like that

yes that would work too, I liked that I was returning comps of tasks 😄

you could still do that

the future is in the body of with-pass-thru

so what you do in there could be (swap! runboot-queue conj (delay (boot.App/runBoot ...)))

instead of the future

in runboot task i mean

then you could force the delays in parallel in the parallel-start part maybe

Yeah that sounds like a good option

delay seems like it's perfect for this kind of thing, somehow

and you can force it inside a future later

(future (force the-delay))

that way you could force a batch of delays in parallel

i wonder about transducers, maybe

if we only care about clojure 1.7.0 and later

Yes I didn't want to touch runboot because it can be still used as it is for something else, that is why I added it to built-in, but it is something that not many people would use I gueas

the only thing about runboot that gives me reservations is that the coordination part isn't really figured out in a general way yet

like it starts the boot in a future

or is that not correct?

Yes I totally agree, for testing is good but for "real" stuff it maybe deceptive (for instance that warning is difficult to understand)

No agree 100%

like if i wanted the runboot instances to run in sequence, not in parallel

is it possible to do that with the runboot task as it currently is?

No each call to runboot spawns and executes on a different thread

It is actually a hack for executing tasks in parallel IMHO :)

Prolly runboot should be stripped of the future, and parallelism handled by the caller (task)

perhaps the await-done task does what we want?

like if i want runboot to be synchronous i can put await-done right after it?

so i could do things like:

Yes that"s a syncing point

(deftask complicated-build
  []
  (comp (runboot :commands ["build-foo"])
        (runboot :commands ["build-bar"])
        (await-done)
        (runboot :commands ["build-baz"])
        (await-done)))

i forgot the :data arg

but that would build the first two things in parallel and then the third thing

Yea you can, you need to just set the data and init it with initial-sync-map

That I have already made a bit better, accepting the number of tasks to wait for

All the primitives are in place for that

sweet!

I can even move that to something like boot.parallel

Or better name

that is a good idea

K will do

Ok you triggered a lot of very cool parallel thoughts and I think I will create boot.parallel in another PR, for instance therebcan be a task called parallelize which runs a task in a future setting up the sync-map data for you ;)

To close this one I need to batch the tests ones, I hope I will have time tomorrow