This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-17
Channels
- # 100-days-of-code (5)
- # announcements (13)
- # beginners (98)
- # boot (19)
- # cider (10)
- # cljdoc (32)
- # clojure (142)
- # clojure-dev (37)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-spec (30)
- # clojure-uk (18)
- # clojurescript (28)
- # cursive (8)
- # datomic (25)
- # duct (18)
- # editors (5)
- # emacs (39)
- # events (4)
- # figwheel (7)
- # figwheel-main (5)
- # fulcro (38)
- # graphql (19)
- # jobs-discuss (1)
- # jobs-rus (7)
- # keechma (1)
- # lumo (47)
- # off-topic (28)
- # om-next (3)
- # parinfer (3)
- # re-frame (18)
- # reagent (37)
- # reitit (8)
- # shadow-cljs (101)
- # specter (7)
- # tools-deps (8)
- # vim (1)
I remembered why he did that: it was to prevent a bad actor from posting malicious patched versions of Clojure there, since tooling generally pulls from clojars ahead of Maven.
the author hasn't signed a CA but the patch looks trivial, a direct commit should be fine, would be good to get a release out
It looks like there are follow on issues the node?
the patch is literally just fixing a couple of (throw "foo" {})
into (throw (ex-info "foo" {}))
@bendlas usually does all the xml fixing and releases so I’d rather he take care of 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?
(Thread. ^Runnable (bound-fn []))
reflects because bound-fn
loses the metadata; simple ticket+patch?
that's... weird?
I'm not even sure where that would be useful
and actually (Thread. (fn []))
doesn't reflect either, the problem is bound-fn* doesn't have a type hint of returning a clojure.lang.IFn (or Fn)
bound-fn is a macro. The Clojure compiler loses all type hints on macro invocations, IIRC
Here is what I wrote about it when my mind was steeped in the details: https://github.com/jonase/eastwood#unused-meta-on-macro
It mentions ticket https://dev.clojure.org/jira/browse/CLJ-865, which may not be so simple / non-breaking
There are also more details on other type hint cases that the Clojure compiler ignores/uses in the section of the docs on the :wrong-tag
linter
but bound-fn always expands to a call to bound-fn*, and bound-fn* always returns a fn, so if bound-fn* was hinted to return a fn, it would at least eliminate the places where (fn []) doesn't cause reflection and (bound-fn []) does
Oh, if you guys are suggesting adding a type hint to the defn of bound-fn*
, that does sound way tighter in scope and simpler than CLJ-865