Fork me on GitHub
#boot
<
2016-06-06
>
richiardiandrea01:06:50

hey guys, would you be possible to run boot using https://github.com/ninjudd/drip ?

richiardiandrea01:06:10

I know that boot.sh has some crazy way to include the jar file

richiardiandrea01:06:52

but can i use just boot.jar

richiardiandrea01:06:14

I guess the answer is yes, I will try to investigate

richiardiandrea01:06:03

first time:

time drip -cp ~/bin/clj/boot.jar boot.App

real	0m7.177s
user	0m15.919s
sys	0m0.485s
second time:
real	0m2.800s
user	0m0.055s
sys	0m0.039s

richiardiandrea01:06:11

so it is faster!

richiardiandrea01:06:46

I guess there is a way to use the executable with drip automatically, maybe BOOT_JAVA_COMMAND ?

micha01:06:50

that's a new one

micha01:06:09

drip never improved anything for me, because it just saves the jvm startup time

micha01:06:23

but the jvm starts in like 20ms

micha01:06:02

all of the time is spent compiling and running clojure code that doesn't exist when the jvm starts

micha01:06:37

i'd be interested to see what it is about your setup that can make boot faster with drip

micha01:06:06

are you actually loading a build.boot file and stuff?

richiardiandrea03:06:40

in that case no I wasn't, I am trying now, but if you say that, probably it is not going to make a difference ...

richiardiandrea04:06:49

so is it a script with drip -cp .... enough for bootstrapping boot or I need the same preamble as in the boot of the README?

micha04:06:24

@richiardiandrea: that seems like it should work

micha04:06:52

you will need to pass arguments like boot.sh does

micha04:06:09

but you can use head.sh in the boot-bin repo as a guide there

richiardiandrea04:06:41

Ok starting my tests with:

#!/bin/bash
declare -a "options=($BOOT_JVM_OPTIONS)"
self="${BASH_SOURCE[0]}"
selfdir="$(cd "$(dirname "${self}")" ; pwd)"
selfpath="$selfdir/$(basename "$self")"
drip -cp bin/clj/boot.jar "${options[@]}" -Dboot.app.path="$selfpath" boot.App "[email protected]"

micha04:06:12

i wonder what happens with environment variables

micha04:06:20

i guess it can't really support that

micha04:06:32

so it probably just has the ones it starts the first jvm with

micha04:06:46

and also the CWD

micha04:06:00

those would be the main things to check

richiardiandrea04:06:24

yes there is something in their README

richiardiandrea04:06:14

> Drip passes all environment variables exported at runtime to the JVM and merges them into the map returned by System.getenv. Keep in mind that the environment isn't modified until we connect to the JVM; during initialization, the environment will be derived from the previous process that launched the spare JVM.

micha04:06:33

huh, i wonder how they modify env vars after the jvm is already running

richiardiandrea04:06:10

it feels a little bit more responsive on start but I cannot measure, the "execution" time still dominates

richiardiandrea04:06:00

after a rm -Rf .drip it slows down a bit, but my "ad-random" count is in the order of 500ms so...not very noticeable

micha04:06:09

yeah that's what i saw too

micha04:06:32

that's the price we pay for dynamic languages i guess

micha04:06:49

the compiler can't run your program for you in advance 🙂

nha18:06:11

when doing a boot script defclifn, is there a way to get the last argument ? like so: ./myscript --named-arg "ok" last-catchall-arg ? It is not bound into *opts*

micha18:06:07

@nha:

boot.user=> (cli/defclifn x [] (prn :args *args*))
#'boot.user/x
boot.user=> (x "1" "2" "3")
:args ["1" "2" "3"]

nha18:06:16

Thanks !

micha18:06:25

they have to be strings, of course

micha18:06:33

which they will be when you call from the command line

nha18:06:49

Right - that's my use case 🙂

micha18:06:07

yeah that's the only use case that makes sense for the *args*

micha18:06:34

we can't support that for boot tasks because how would boot distinguish between catchall arguments and task names for the next task?

micha18:06:45

boot.user=> (cli/defclifn x [d doop bool "the doop"] (prn :opts *opts* :args *args*))
#'boot.user/x
boot.user=> (x "1" "2" "3")
:opts {} :args ["1" "2" "3"]
nil
boot.user=> (x "-d" "1" "2" "3")
:opts {:doop true} :args ("1" "2" "3")
nil

nha18:06:41

Ah right. Should I make a small edit to the wiki to mention *args* ?

micha18:06:56

sure that would be awesome

nha18:06:46

Additional question: are out-of-order args meant to be supported ? Like: ./my-script.clj --bool "lastarg" gives an *opts of {:all true} ./my-script.clj "lastarg" --bool gives an *opts of {}

micha19:06:44

no, that's not really something that can be supported if defclifn is used as the basis for deftask

micha19:06:57

because "lastarg" there would be interpreted as the next task name

nha19:06:36

Ah I had that feeling. I should re-read your answers more 🙂

micha19:06:01

it's a tricky balance

nha19:06:29

CLI is always more tricky than it seems at first

micha19:06:49

by limiting what's supported you can eliminate a lot of boilerplate

nha19:06:01

Right. I'm happy with defclifn as it is by the way.

nha19:06:05

(After trying tools.cli, parsing args in bash and C, and using various node.js libs to do the same)

micha19:06:25

yeah i always forget how to do getopts correctly

kenbier23:06:51

if i wanted to bump a version of a cljsjs package how would i generate the checksum?