planck

Planck ClojureScript REPL
borkdude 2019-12-10T09:28:05.044400Z

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.

mfikes 2019-12-10T13:15:48.045800Z

@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

mfikes 2019-12-10T13:20:36.046900Z

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

borkdude 2019-12-10T13:22:57.048200Z

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.

borkdude 2019-12-10T13:23:59.048400Z

CWD I mean

mfikes 2019-12-10T13:24:09.048600Z

maybe that's true

borkdude 2019-12-10T13:24:26.048900Z

For babashka the same would make sense I think

borkdude 2019-12-10T13:24:36.049200Z

(also putting the cwd on the classpath)

mfikes 2019-12-10T13:25:40.049900Z

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

borkdude 2019-12-10T13:26:02.050300Z

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

borkdude 2019-12-10T14:36:00.051300Z

@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