Fork me on GitHub
#cljs-dev
<
2022-05-10
>
dnolen16:05:38

@alexmiller hrm I'm realizing I looked at the AOT issue probably 4 years ago but gave up - in the assembly I tried to elide the namespaces, but I had commented it out

dnolen16:05:07

after fiddling w/ clojure-maven-plugin - I figured out how to elide AOTed classes for the deps

dnolen16:05:22

however it will not elide the deftype'd classes

dnolen16:05:38

I shrugged and changed the assembly, checked they are no longer in the jar

dnolen16:05:55

but when I try to use the AOTed ClojureScript I see this:

dnolen16:05:23

{:clojure.main/message
 "Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:382).\nclojure.tools.reader.reader_types.IndexingReader\n",
 :clojure.main/triage
 {:clojure.error/class java.lang.ClassNotFoundException,
  :clojure.error/line 382,
  :clojure.error/cause
  "clojure.tools.reader.reader_types.IndexingReader",
  :clojure.error/symbol java.net.URLClassLoader/findClass,
  :clojure.error/source "URLClassLoader.java",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type clojure.lang.ExceptionInfo,
    :message "Unexpected error during REPL initialization",
    :data {:cljs.repl/error :init-failed},
    :at [cljs.repl$repl_STAR_ invokeStatic "repl.cljc" 1218]}
   {:type java.lang.NoClassDefFoundError,
    :message "clojure/tools/reader/reader_types/IndexingReader",
    :at [cljs.repl$repl_STAR_$fn__8140 invoke "repl.cljc" 1038]}
   {:type java.lang.ClassNotFoundException,
    :message "clojure.tools.reader.reader_types.IndexingReader",
    :at
    [java.net.URLClassLoader findClass "URLClassLoader.java" 382]}],
  :trace
  [[java.net.URLClassLoader findClass "URLClassLoader.java" 382]
   [java.lang.ClassLoader loadClass "ClassLoader.java" 424]
   [sun.misc.Launcher$AppClassLoader loadClass "Launcher.java" 349]
   [java.lang.ClassLoader loadClass "ClassLoader.java" 357]
   [cljs.repl$repl_STAR_$fn__8140 invoke "repl.cljc" 1038]
   [cljs.repl$repl_STAR_$fn__8172 invoke "repl.cljc" 1212]
   [cljs.compiler$with_core_cljs invokeStatic "compiler.cljc" 1477]
   [cljs.compiler$with_core_cljs invoke "compiler.cljc" 1466]
   [cljs.repl$repl_STAR_ invokeStatic "repl.cljc" 1166]
   [cljs.repl$repl_STAR_ invoke "repl.cljc" 1033]
   [cljs.cli$repl_opt invokeStatic "cli.clj" 325]
   [cljs.cli$repl_opt invoke "cli.clj" 312]

dnolen16:05:12

this defies my expectation a bit, because line 1038 in repl.cljc is just a function call

dnolen16:05:52

in anycase this hurdle would seem to block any approach (i.e. tools.build etc.) ?

Alex Miller (Clojure team)17:05:36

so the deftype classes are or are not in the output jar?

dnolen17:05:41

I altered the assembly to exclude them, if I include the deftypes it works

Alex Miller (Clojure team)17:05:01

so what's in the jar - just clojurescript, but compiled?

dnolen17:05:58

AOTed ClojureScript, changing the clojure-maven-plugin settings elides all AOTed fns from data.json, tools.reader, and transit-clj

dnolen17:05:19

however, it does not elide the backing interface to protocol, nor the deftypes

Alex Miller (Clojure team)17:05:20

yeah, this is kind of a rocky area wrt protocols

dnolen17:05:50

so it seems like AOTed ClojureScript just cannot get rid of the potential conflict w/o vendorizing tools.reader and causing a different kind of breakage

Alex Miller (Clojure team)17:05:05

this is the problem described (and closed) in https://clojure.atlassian.net/browse/CLJ-1544

😢 1
dnolen17:05:58

ok so unless you think different I don't think anything can be done about this problem same as 4 years ago

dnolen17:05:09

either you manage the deps carefully, or you use the slim JAR

Alex Miller (Clojure team)17:05:52

and what were the difficulties in vendorizing? knobs were exposed up through CLJS with the original names?

dnolen17:05:11

ClojureScript works as library / tooling foundation

dnolen17:05:20

if we vendorize tools.reader everybody has to know abou tthat

Alex Miller (Clojure team)17:05:45

they use those foundations directly in some cases?

dnolen17:05:54

because you can alter reading

Alex Miller (Clojure team)17:05:16

I'm trying to be specific enough to push on this, I just don't know this area enough

dnolen17:05:27

we don't really hide anything because we don't know how it's going to be used

dnolen17:05:35

you can bind the dyn vars for tools.reader

dnolen17:05:38

so anyone who doing custom analysis, or custom reading stuff and these other entrypoints - they would break

Alex Miller (Clojure team)17:05:18

so how big is that surface area? like bindings could be copied if we're talking just a few things like reader/*alias-map*

Alex Miller (Clojure team)17:05:22

there are like 4 dynamic vars in tools.reader

Alex Miller (Clojure team)17:05:31

(I understand this is all a big pain in the ass)

Alex Miller (Clojure team)17:05:52

just trying to understand the scope of the effort

dnolen17:05:48

I think the impact where you can bind outside is only cljs.analyzer and cljs.compiler

dnolen17:05:19

and it appears yes it's really only *alias-map* that can be configured

Alex Miller (Clojure team)17:05:51

data.json and transit-clj are both single namespace libs so should be relatively easy to vendor

dnolen17:05:34

yeah I'm not concerned about those at all

dnolen17:05:46

they are too deep / specific to be of interest / problem

dnolen17:05:53

only the reader knob is real issue

Alex Miller (Clojure team)17:05:49

I mean, seems like it would be pretty easy to bind cljs.tools.reader/alias-map to tools.reader/alias-map if it exists

dnolen17:05:39

like a pure dynamic look up since we don't want to pull that into AOT - ns-resolve

dnolen20:05:37

ok looks like vendorzing data.json, transit-clj worked - tools.reader going to be way more annoying

borkdude21:05:45

What's the annoying bit? (I have vendorized tools reader in clj-kondo for years now. )

Alex Miller (Clojure team)21:05:21

you're holding out on us man!

😆 2
borkdude21:05:25

What was the argument against AOT-ing at all?

Alex Miller (Clojure team)21:05:54

I don't think there is a reason not to AOT once you vendor

Alex Miller (Clojure team)21:05:52

I think the "don't want to pull that into AOT" above is re referencing tools.reader/alias-map

borkdude21:05:17

for tools reader I used https://github.com/benedekfazekas/mranderson to inline that dependency, it worked reasonably well, perhaps I had to change one or two things manually

borkdude21:05:01

I don't fully understand the problem around the dynamic var though, that is probably the real "pain"?

borkdude21:05:48

ah right, if you vendor tools reader, the dynamic var API surface changes

Alex Miller (Clojure team)22:05:02

and it's ok to look it up and re-bind, IF it exists (but not if it doesn't)