#hoplon

chpill, hey, welcome!

alandipert: hi :)

has tmppath been deprecated in favor tmp-path?

danielszmulewicz, in master and soon in rc, but we'll never actually remove tmppath

just update docs and show a warning

cf. https://github.com/boot-clj/boot/issues/128

alandipert: OK, thanks. I like syntactic refactorings. The dash is an improvement. Seriously.

:-)

Smiling because I recognize myself in that attention for detail.

hehe glad you like :-)

yeah considering our emphasis on programmability the public API is something we can't afford to skimp on

Absolutely.

oh btw re: `boot run`

for 2.0 i think we may just reserve the task name so we can get 2.0 but have more time to see what exactly we want it to mean

*get 2.0 out

we were considering reserving a few juicy names that seem like boot should support but we're not sure exactly how they'd work

with the idea that by reserving them we'd save people from upgrading and then their own tasks not working anymore

alandipert: Sure. Sounds good;

Btw, does task name conflicts in Boot follow Clojure's semantics when vars clash?

not exactly because we don't control 'refer'

If I define a task called run, when I require it, it will say that I'm overwriting a built-in task?

but the idea is to dehave similarly

so if you do like (deftask jar []) in a REPL it will explode

i guess because by the time you can add tasks we've already referred the builtins

So tasks never get "overwritten"

?

well, if you write (deftask foo []) (deftask foo []) in your build.boot you'll see the "foo overridden" warning that we made

so you can overwrite your own stuff, this seemed helpful when working with profile.boot

alandipert: Ah, OK, now I see. Makes sense.

but yeah if we reserve 'run' nobody will be able to make their own run task

at least, they won't be able to define it in a build.boot - they might be able to refer it from another ns, i haven't tested

minimally in that 2nd case they'd see the clojure warning about a refer clash

the idea is that they'd get all this feedback before running boot -u some day and afterward their build.boot not running at al

alandipert: Right. Should I rename my (your) run task in system already to be on the safe side?

alandipert: https://github.com/danielsz/system/blob/master/...

danielszmulewicz, at your discretion, the way you have it in a .clj file i think means that worst-case is a warning for the user who refers it into build.boot

michaniskin: there may be something like irony in me asking this, but how do you debug issues when running code in a pod?

I have code that works out of a pod, but inside, I get: java.lang.ClassNotFoundException: org.clojure

full stack: https://gist.github.com/c2e2144b2e7189ef7a4d

and have no idea what would be trying to load a class called "org.clojure"

have you seen that before?

Good news! system-0.1.8-SNAPSHOT adds file-based granularity for hot-reloading a system. This means that if you works on a web app, for example, you can configure the build pipeline to automatically restart the system when certain files are being edited. Isn't that cool?

For example, handler.clj

tcrawley, that's an intense stack trace

tcrawley, i can imagine some things, are you splicing code from the parent environment into the pod?

tcrawley, because it looks like maybe a case where you're expecting a var sym when it's actually a class or something

err "class symbol"