Fork me on GitHub
#boot
<
2016-03-27
>
micha00:03:52

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

micha00:03:09

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

richiardiandrea00:03:33

I created boot.test

micha00:03:41

maybe make like boot.self-test for now?

micha00:03:57

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

micha00:03:10

just to avoid confusion

richiardiandrea00:03:54

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

micha00:03:23

and runboot, test-report, etc

micha00:03:36

and what's currently in boot.test

richiardiandrea00:03:57

so everything in boot.self-test

micha00:03:58

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

richiardiandrea00:03:40

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

richiardiandrea00:03:57

but yes for me it's ok

micha00:03:18

i like the way the deftesttask macro works

micha00:03:30

very interesting

micha00:03:43

it's very easy to follow

richiardiandrea00:03:30

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

richiardiandrea00:03:11

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

richiardiandrea00:03:45

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

micha00:03:06

perhaps instead of using a future directly you could use delay

micha00:03:15

put the delays into a vector in an atom

micha00:03:48

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

micha00:03:19

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

richiardiandrea00:03:20

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

micha00:03:30

you could still do that

micha00:03:41

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

micha00:03:18

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

micha00:03:23

instead of the future

micha00:03:05

in runboot task i mean

micha00:03:01

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

richiardiandrea00:03:23

Yeah that sounds like a good option

micha00:03:48

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

micha00:03:26

and you can force it inside a future later

micha00:03:51

(future (force the-delay))

micha00:03:08

that way you could force a batch of delays in parallel

micha00:03:56

i wonder about transducers, maybe

micha00:03:06

if we only care about clojure 1.7.0 and later

richiardiandrea00:03:12

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

micha00:03:02

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

micha00:03:16

like it starts the boot in a future

micha00:03:35

or is that not correct?

richiardiandrea00:03:43

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

micha00:03:11

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

micha00:03:26

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

richiardiandrea00:03:59

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

richiardiandrea00:03:37

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

richiardiandrea00:03:03

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

micha00:03:22

perhaps the await-done task does what we want?

micha00:03:45

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

micha00:03:27

so i could do things like:

richiardiandrea00:03:31

Yes that"s a syncing point

micha00:03:09

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

micha00:03:25

i forgot the :data arg

micha00:03:43

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

richiardiandrea00:03:03

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

richiardiandrea00:03:30

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

richiardiandrea00:03:11

All the primitives are in place for that

richiardiandrea00:03:16

I can even move that to something like boot.parallel

micha00:03:41

that is a good idea

richiardiandrea01:03:30

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 ;)

richiardiandrea01:03:45

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