@juhoteperi: running into the old clj 1.7 instaparse StringReader arity bug with boot-livereload, is this something youve run into?

looks like instaparse is coming in through clj-livereload -> compojure -> clout. i was able to fix by excluding instparse and explicitly dep on instaparse 1.4.1, wondering if i'm missing something

@alandipert: I'd talk about the immutable fileset. Applying an FP concept to something inherently mutable (project building) makes things like task composition easy.

@domkm: thanks, i'll definitely talk about that

maybe that it's not just a build tool, but you can run stuff with it

worth exploring that

yeah, i think i'm gonna start with that - show off boot -d .. repl and bring up incanter, other flashy libs

then scripting with it

excellent point though, thank you

btw, have you looked at capsule (http://capsule.io) and the synergies between boot and capsule?

I meant run in the sense of using it as a launcher for deployment, running pods in production

worth mentioning as not everyone will make a connection between running tasks locally and that

what's a good way to communicate between pods, e.g. one pods needs to trigger a restart of the other pod with updated dependencies. Can they somehow communicate via boot.core?

my goal is to get an autoupdating app that pulls itself from nexus

guess I can share an object between pods if its class is loaded in boot's parent classloader

in the same vein: when is it appropriate to create new boot cores, like in https://github.com/micha/multi-module-build/blob/master/build.boot

Quick q - what was the other boot template that was not tenzing?

deraen/saapas

not a lein template in that sense though

@jaen: any reason tenzing doesn’t fit your needs?

Not that it doesn't fit my needs, I just wanted to compare them out of curiosity

Though now that I compared them both I think saapas is a bit closer to what I want at the moment, since it has a sample backend as well and I would have to add it to a tenzing generated app by hand

yep, that makes sense

Nothing against tenzing though and thanks for the name

I'm basically playing around with to see how workable would be having a presentation that's also a working application with backend that you can hot reload with system on the backend and boot-reload on the frontend

Going for the wow factor

I wouldn’t take any offence I was just curious if there’s something that’s bugging you/could be improved

Gotcha

Also, I think there was a boot task that created a synchronised project.clj out of the dependencies in build.boot, sort of a reverse of from-lein (https://github.com/boot-clj/boot/wiki/Using-Boot-in-a-Leiningen-Project). Am I making things up or is this a real thing?

https://github.com/boot-clj/boot/wiki/For-Cursive-Users — this might be what you’re looking for?

Yes, that's it. And in such an obvious place '

Thanks a lot.

@dm3: hello

hi

@juhoteperi: any reason you’re starting with -1 instead of -0?

@martinklepsch: No

@dm3: did you figure out the answer to your question before?

the first one - yes, regarding the boot cores - no

made this thing today: https://github.com/martinklepsch/custom-comparator-set — would be curious about feedback

ok, the boot cores use case is for when you need to run boot inside boot

that is, you want to run multiple instances of boot in the same JVM

you might want to do this when you have multiple modules that depend on each other and aren't really suitable to develop separately

like boot itself for example

the boot clojure code is factored into like 4 or 5 separate jars so that different pods can be started with different permutations of those loaded

so you can see that some of them depend on others etc

and why can't you run just in separate pods?

because you need the core stuff, and the whole bootstrapping to be separate

boot.core contains all the environment state

pods that you make with make-pod don't have access to this state

because they need to be isolated from it

the core state needs to progress linearly

ok

i.e. you add or remove things from the classpath in a sequence of atomic operations

understood

the runBoot() thing allows you to have completely separate boot state

it's like running in separate jvms, but in a single jvm

I forgot boot managed its state too

yeah it's managing the filesystem directories that are in the classpath

and that's basically global mutable state

so it needs to be carefully managed

i just updated the multi-module-build repo to reflect the most recent changes btw

hehe

you pass a java object to runBoot() now

which can be a ConcurrentHashMap, for example

in which you can store and retrieve state

so like if you have builds that need to start in a certain order, like in the multi-module example, you can do it by storing a Semaphore or something in there

and tasks in the different boot instances can all see it and use it to synchronize themselves

it's pretty low-level interface at the moment of course

but you can build better abstractions on top of that

I see

we do need a user friendly solution for multi-module builds in Clojure

do you know of a java concurrency construct that can impose ordering on the execution of async tasks?

like an actor?

or like an atom that you can do (.blockUntilEquals myAtom 2)

so you want to build a graph of tasks declaratively

based on conditions

a graph of runBoot() instances

like i don't want to build a module until its dependencies are satisfied

i want to be able to ensure that async process 2 doesn't start until async process 1 has done its work

the semaphore is almost there

but it requires the sort of hacky acquiring of locks in the main process

countdownlatch where each dependent registers one with a count of his dependencies

maybe this java.util.concurrent.Phaser

hm

but it seems like this kins of thing could be controlled by an actor which gets events of completion

you're sort of describing the cyclicbarrier above, no?

http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Phaser.html#awaitAdvance(int)

yes, kind of

barrier runs the completion task for you

what should a multi-module build system support for your use cases?

most of the issues with multi-module builds are solved pretty well by the checkout task

without any fancy runboot stuff

but like to build boot itself, which has unusual structure because of the classloader setup

it's nice to have a single process that can orchestrate all the sub-builds

and ideally it would all run smoothly in watcher mode

for incremental compiles

https://github.com/micha/multi-module-build/blob/master/build.boot

this is actually pretty much all i need for now

can you think of other use cases?

mostly release management

when module versions are different

but I try not to do that

Is there an archive of old boot.sh releases?

they're all in github releases

by tag

Ok, I see it https://github.com/boot-clj/boot/releases

yeah those are the older releases

we recently split boot.sh into a separate project

https://github.com/boot-clj/boot-bin/releases

that's from 2.4.2 and on

you shouldn't need any of the older boot.sh though

the latest one (2.4.2) will work with any version of boot, 2.0.0 and later

Hello, I have a use case for using boot scripts at work (yay 😛 ) : migrating data from a database to another (mongo -> rethink). I was just wondering, how can I have a REPL to my boot script (ex. migrate.clj) ?

@nha: you can do boot repl and then (load-file "migrate.clj")

that's what i usually do in that situation

ah thanks I'll do that

good luck with your script!

Thanks, my first real migration ^^

(I mean professionnal one)

I'm getting a weird error from either simple or advanced compilation: (intermediate value)(intermediate value)(intermediate value)(...) is not a function. You can see it on a running webserver here: https://client.app.takemyspot.ca/

@micha works perfectly, thanks. I used boot repl wait to connect with Emacs cider.

@taylor.sando: i don't see momentjs in there

which it seems to need

oh nm, tere it is

I seemed to be able to build it with :whitespace

do you have externs for momentjs etc?

yeah that should have all the externs

@martinklepsch: you were asking yesterday to see some use case for the boot.pod/data thing

https://github.com/micha/multi-module-build/blob/master/build.boot

has anyone used boot with travis-ci?

@flyboarder: i do

@flyboarder: it just got easier, since there is now a single download url for boot.sh that will never change (or you could even put boot.sh in your git repo, it's only 5k or so)

all you need in travis other than boot.sh is java 7

@micha: although with the new boot.sh, you have to run boot twice right?

no, you just set BOOT_VERSION

which you need to do anyway if you're doing automatic builds

gotcha

you should have a boot.properties file in the repo

or have boot.properties in project

yeah that's the best way i believe