Fork me on GitHub

would there be any way to add to Planck’s classpath at runtime?


@mhuebert I don't think that's possible in Planck. FWIW we have an open ticket for that in Lumo


I think that's one of the places where we can move away from the current (JVM) ClojureScript behavior


@mhuebert Right, adding to the classpath at runtime is not currently possible. Are you thinking of the use case where you are at a REPL and you forgot to include a JAR on the classpath, but you want to require a namespace in it?


@anmonteiro thanks for the head’s up, I’ll keep my eye on that. @mfikes my use-case is pretty specialized, I’m working on packaging deps for self-hosted clojurescript, where you might want to include things that aren’t on your project classpath, or maybe want to respond dynamically to requests. For me this is not so important that this is changed in Planck - I have a multi-step process anyway where i start by calculating deps in Clojure (using stuff in cljs.closure etc), and then I move to Planck to package things together and make use of Planck’s compiled js and analysis caches.


i’m using Alembic in Clojure so that i can specify/load dependencies there. Alembic keeps track of modifications to the classpath, so I can pass the expanded classpath to Planck for the next step.


@mhuebert Ahh cool. So part of what is going on there is also downloading dependencies, as well as the transitive closure of its dependencies, which is a big unsolved problem in the self-hosted world. (At its core, that involves imitating part of what Maven does.)


@mhuebert I’m curious: When you package stuff, are you packaging AOT-compiled artifacts? (Meaning, are you packaging compiled JavaScript?)


@mfikes Yeah. I tried packaging clj* files, and that worked too, but really, really slow to compile everything in the browser


@mhuebert Ahh, interesting. Sounds like you are pushing the boundaries on stuff, exploring new things that have not yet been done previously 🙂


@mfikes 🙂 with a ton of help from what you’ve done with Planck!


@mhuebert This may be unrelated, but given that ClojureScript benefits so much from AOT in some cases, I was pondering whether AOT artifacts could be included in library JARS. A problem that presents is that the ClojureScript compiler version is embedded in the artifacts—in short, AOT compiled artifacts are really only usable from a specific version of ClojureScript (at least today, that the way ClojureScript works).


@mfikes +1. I guess because of the different compiler versions it might look more like some kind of cache/cdn service. (unless something would change w/ cljs)


@mfikes oh, another question - do you know if it is possible to get the ordinary ClojureScript compiler to output compiled macros? or is the macro-loading in self-hosted cljs too different


@mhuebert You can think of a macro as just a special kind of function that is called by the compiler. So, in self-hosted ClojureScript, those “functions” are compiled just like any others (to JavaScript) and thus you can cache the result of that compilation. In regular ClojureScript, since macros are in Clojure, you essentially have the Clojure compiler compiling the macros for use at runtime (to byte code).


(I think that essentially means the answer is “no”)


@mfikes ok, that makes sense.


One way I think of it in my mind: The browser target use case has (rightfully) informed the way ClojureScript works, with the goal being to heavily minimize the output, giving up on some dynamic aspects of Lisp (like eval). But, self-hosted ClojureScript can live on the other end of this spectrum, and be a lot more like Clojure.


I agree entirely. I like being able to play (online evaluation etc.) but for most production cases it doesn’t make sense


the dep-loading lib I’m working on is here:


re: macros - I was just wondering if there was a more straightforward way to do all of this packaging. For now it seems necessary to use artefacts from both sources: to get analysis caches of namespaces that aren’t loadable in self-hosted environment, so we need the artefacts of an ordinary cljs build, but then have to use a self-host env. to compile macros.


there is an old demo of cljs-live here: (must be updated w/ new updates.)