Fork me on GitHub
#clojure-dev
<
2018-10-17
>
seancorfield05:10:46

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.

bronsa09:10:50

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

alexmiller11:10:27

It looks like there are follow on issues the node?

bronsa12:10:59

it seems to be an entirely different issue

bronsa12:10:27

the patch is literally just fixing a couple of (throw "foo" {}) into (throw (ex-info "foo" {}))

alexmiller12:10:44

@bendlas usually does all the xml fixing and releases so I’d rather he take care of it

bendlas10:10:26

I'll have a look

bronsa12:10:05

:thumbsup:

seancorfield21:10:23

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.

seancorfield21:10:50

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!

seancorfield21:10:33

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!

seancorfield21:10:21

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?

seancorfield21:10:52

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?

gfredericks21:10:02

(Thread. ^Runnable (bound-fn [])) reflects because bound-fn loses the metadata; simple ticket+patch?

hiredman21:10:41

it is not simple

hiredman21:10:30

iirc the compiler takes type hints on fns as the return type of the fn

gfredericks21:10:00

that's... weird?

hiredman21:10:42

I may be misremembering, or confusing it with something else

gfredericks22:10:22

I'm not even sure where that would be useful

hiredman22:10:25

I think I must be confusing that with something vars do

hiredman22:10:11

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)

andy.fingerhut22:10:15

bound-fn is a macro. The Clojure compiler loses all type hints on macro invocations, IIRC

favila22:10:23

you can't do tricks with &form?

andy.fingerhut22:10:16

Here is what I wrote about it when my mind was steeped in the details: https://github.com/jonase/eastwood#unused-meta-on-macro

favila22:10:45

(with-meta `(bound-fn* (fn [email protected])) (meta &form)))
?

andy.fingerhut22:10:13

It mentions ticket https://dev.clojure.org/jira/browse/CLJ-865, which may not be so simple / non-breaking

andy.fingerhut22:10:02

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

hiredman22:10:04

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

andy.fingerhut22:10:28

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

favila22:10:15

would that work though? what type hint would you add?

favila22:10:59

I don't actually know how (Thread. (fn [])) doesn't reflect. clojure.lang.Fn doesn't imply Runnable

hiredman23:10:15

ah, good point, the actual type for (fn []) is AFunction which does imply Runnable

hiredman23:10:32

but isn't as nice

bronsa23:10:13

@hiredman the return type hint thing only applies to vars

bronsa23:10:57

type hinting on forms always means on the form itself, the problem is just with macros