Fork me on GitHub
#boot
<
2015-11-06
>
alandipert00:11:42

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

alandipert00:11:38

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

domkm05:11:57

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

alandipert09:11:14

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

dm309:11:18

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

dm309:11:34

worth exploring that

alandipert09:11:07

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

alandipert09:11:17

then scripting with it

alandipert09:11:24

excellent point though, thank you

dm310:11:52

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

dm310:11:15

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

dm310:11:37

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

dm311:11:16

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?

dm311:11:05

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

dm311:11:25

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

dm311:11:03

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

jaen11:11:05

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

martinklepsch11:11:34

not a lein template in that sense though

martinklepsch11:11:00

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

jaen11:11:39

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

jaen11:11:40

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

martinklepsch11:11:03

yep, that makes sense simple_smile

jaen11:11:36

Nothing against tenzing though and thanks for the name

jaen11:11:23

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

jaen11:11:29

Going for the wow factor

martinklepsch11:11:55

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

jaen12:11:12

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?

jaen12:11:01

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

jaen12:11:03

Thanks a lot.

micha15:11:12

@dm3: hello

martinklepsch15:11:57

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

juhoteperi15:11:13

@martinklepsch: No

micha15:11:45

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

dm315:11:03

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

martinklepsch15:11:22

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

micha15:11:25

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

micha15:11:38

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

micha15:11:03

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

micha15:11:08

like boot itself for example

micha15:11:58

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

micha15:11:12

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

dm315:11:54

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

micha15:11:25

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

micha15:11:46

boot.core contains all the environment state

micha15:11:01

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

micha15:11:12

because they need to be isolated from it

micha15:11:21

the core state needs to progress linearly

micha15:11:39

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

dm315:11:41

understood

micha15:11:58

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

micha15:11:14

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

dm315:11:50

I forgot boot managed its state too simple_smile

micha15:11:26

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

micha15:11:40

and that's basically global mutable state

micha15:11:48

so it needs to be carefully managed

micha15:11:21

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

micha15:11:51

you pass a java object to runBoot() now

micha15:11:00

which can be a ConcurrentHashMap, for example

micha15:11:12

in which you can store and retrieve state

micha15:11:46

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

micha15:11:12

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

micha15:11:30

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

micha15:11:39

but you can build better abstractions on top of that

dm315:11:37

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

micha15:11:55

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

dm315:11:12

like an actor?

micha15:11:16

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

dm315:11:14

so you want to build a graph of tasks declaratively

dm315:11:21

based on conditions

micha15:11:41

a graph of runBoot() instances

micha15:11:04

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

micha15:11:29

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

micha15:11:45

the semaphore is almost there

micha15:11:06

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

dm315:11:26

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

micha15:11:34

maybe this java.util.concurrent.Phaser

dm315:11:53

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

micha15:11:35

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

dm315:11:36

yes, kind of

dm315:11:26

barrier runs the completion task for you

dm315:11:26

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

micha15:11:13

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

micha15:11:20

without any fancy runboot stuff

micha15:11:46

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

micha15:11:05

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

micha15:11:18

and ideally it would all run smoothly in watcher mode

micha15:11:24

for incremental compiles

micha16:11:35

this is actually pretty much all i need for now

micha16:11:43

can you think of other use cases?

dm316:11:48

mostly release management

dm316:11:10

when module versions are different

dm316:11:24

but I try not to do that

taylor.sando16:11:06

Is there an archive of old boot.sh releases?

micha16:11:24

they're all in github releases

micha16:11:22

yeah those are the older releases

micha16:11:35

we recently split boot.sh into a separate project

micha16:11:59

that's from 2.4.2 and on

micha16:11:14

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

micha16:11:35

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

nha16:11:50

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

micha16:11:27

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

micha16:11:39

that's what i usually do in that situation

nha16:11:49

ah thanks I'll do that simple_smile

micha16:11:01

good luck with your script!

nha16:11:39

Thanks, my first real migration ^^

nha16:11:46

(I mean professionnal one)

taylor.sando16:11:51

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/

nha16:11:41

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

micha17:11:54

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

micha17:11:59

which it seems to need

micha17:11:19

oh nm, tere it is

taylor.sando17:11:38

I seemed to be able to build it with :whitespace

micha17:11:44

do you have externs for momentjs etc?

micha17:11:26

yeah that should have all the externs

micha17:11:06

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

flyboarder20:11:41

has anyone used boot with travis-ci?

alandipert21:11:54

@flyboarder: i do

micha21:11:14

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

micha21:11:44

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

alandipert21:11:22

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

micha21:11:44

no, you just set BOOT_VERSION

micha21:11:53

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

micha21:11:03

you should have a boot.properties file in the repo

alandipert21:11:07

or have boot.properties in project

micha21:11:16

yeah that's the best way i believe