This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-18
Channels
- # 100-days-of-code (6)
- # announcements (4)
- # beginners (126)
- # cider (49)
- # cljdoc (28)
- # cljsrn (3)
- # clojure (89)
- # clojure-dev (19)
- # clojure-greece (2)
- # clojure-italy (13)
- # clojure-mexico (1)
- # clojure-nl (13)
- # clojure-spec (108)
- # clojure-sweden (1)
- # clojure-uk (48)
- # clojurescript (31)
- # cloverage (3)
- # core-async (16)
- # cursive (28)
- # data-science (3)
- # datascript (1)
- # datomic (60)
- # defnpodcast (1)
- # docker (17)
- # editors (18)
- # emacs (16)
- # events (1)
- # figwheel (22)
- # figwheel-main (4)
- # graphql (26)
- # jobs (2)
- # off-topic (9)
- # om-next (2)
- # overtone (4)
- # perun (1)
- # re-frame (2)
- # reagent (18)
- # reitit (1)
- # ring-swagger (2)
- # shadow-cljs (2)
- # tools-deps (49)
- # uncomplicate (1)
- # unrepl (1)
- # vim (2)
clojure.tools.namespace.find/find-sources-in-dir
returns dupes when the directory has .clj
and .cljc
files — it's somewhat conflicting with how require
works as far as I understand. Would this be worth a ticket?
I posted this yesterday but didn't get any responses -- anyone care to take a run at it?
Just run into something odd... I have a project that uses :gen-class
, built with Clojure 1.8 ages ago. I just tried to use it in a Clojure 1.10 (RC1) project and it failed trying to initialize the generated class. This only seemed to happen when I built the JAR via clj
and depstar
-- when I was building the JAR with boot
, it seemed to work.
When I dug deeper into it, it seems that in the ns
spec, :gen-class
now requires :state
to be a simple-symbol?
-- where it was in fact a string in my old project!
I corrected that (re-built the old project with Clojure 1.10 and pushed a new version), then rebuilt my new project's JAR and it seems to work. Yay!
So... first question, if I'm using code with :gen-class
which requires AOT, what is the right way to handle that in the clj
/ deps.edn
world now?
Second question, does my line of reasoning sound right, that attempting to load a class generated from an ns
with a bad :gen-class
clause would fail at runtime, even tho' the namespace (and the generated .class
file) were previously compiled and both available on the classpath?
re gen-class - you need a build step
OK, so as simple as running (compile 'some.ns)
as long as you have a classes
folder on your classpath I guess...
on the 2nd question, don’t know without doing a lot of work
NP. I'm going to assume my logic is right -- it was just very hard to track down why it was failing to "initialize" the class because the actual cause was masked. I may try to create a simple repro case an open a ticket -- it would be nice if the exception was more informative!
FYI I never quite understood the rationale for gen-class requiring AOT, ther doesn't seem to be a technical reason why it couldn't JIT
I'm wondering if the reason is not historical due to how the classloader worked pre CLJ-979, as it was for e.g. gen-interface
@bronsa I was thinking that it was due to the primary use-case for gen-class was to have a more “static” classfile on the classpath for a lang like Java to compile against with something like javac
I guess I'm ok with it being not that useful, if it means I won't see many usages of it in the wild :)
yeah, subclassing things too, I guess there are cases for that that would be fine JIT
proxy
can subclass things can't it?