Fork me on GitHub
#planck
<
2019-12-10
>
borkdude09:12:05

Two questions about planck: - It adds the current working dir + the src folder on the default classpath, is that correct? - If you are adding a bunch of jars to the classpath and you do a require, does it walk through the list and searches for entries in each jar file until it found the correct entry, every time you do a require for a previously unloaded namespace? Or does it have some sort of caching about what file belongs to which jar file? I briefly skimmed through the C code: it seems the former. I'm asking because I'm considering similar --classpath option for for babashka and want to have some information about best practices.

mfikes13:12:48

@borkdude If I recall correctly, Planck itself doesn't actually cache JAR entries, but there is evidence that the underlying library is faster if the archives are left open: https://github.com/planck-repl/planck/issues/566

mfikes13:12:36

For your first question, raw planck doesn't add anything to the classpath, but plk behaves like clj.

borkdude13:12:57

I get:

$ plk -e "(require '[foo]) (require '[bar])"
WARNING: foo is a single segment namespace at line 1
foo
WARNING: bar is a single segment namespace at line 1 /private/tmp/src/bar.cljs
bar
with PWD /tmp and /tmp/foo.cljs, /tmp/src/bar.cljs so it seems that PWD is also added to the classpath, contrary to clj.

mfikes13:12:09

maybe that's true

borkdude13:12:26

For babashka the same would make sense I think

borkdude13:12:36

(also putting the cwd on the classpath)

mfikes13:12:40

I think I had Planck originally doing that, and perhaps just left it as is so as to not break anything.

borkdude13:12:02

for bash-like scripting I think that makes sense, just put everything in one dir

borkdude14:12:00

@mfikes fwiw clj-kondo had a weird issue which was caused by keeping jar files open: https://github.com/borkdude/clj-kondo/issues/542 it hit the OS limit for open files for some people who had a huge list of dependencies on their classpath