Sean Corfield: Clojure alpha tester by day, Clojure beta tester by night. 🙂

Still day here 🙂

And you know how much I just love to get new Clojure builds into production quickly!

I know you do it, for sure. I hope you love it, because otherwise you may be a bit touched in the head 🙂

I ❤️ Clojure and ClojureScript! That is all.

Re: the set discussion

$ clj
Clojure 1.10.0-beta5
user=> (require '[clojure.set :as set])
nil
user=> (alter-var-root #'set/superset? (fn [raw] (fn [set1 set2] (raw (set set1) (set set2)))))
#object[user$eval3$fn__139$fn__140 0x4f2613d1 "user$eval3$fn__139$fn__140@4f2613d1"]
user=> (set/superset? [1 2 3 4] [1 2 3])
true
user=> (set/superset? 1 2)
Execution error (IllegalArgumentException) at user$eval3$fn__139$fn__140/invoke (REPL:1).
Don't know how to create ISeq from: java.lang.Long
user=> (require '[clojure.spec.test.alpha :as stest])
nil
user=> (require '[clojure.spec.alpha :as s])
nil
user=> (s/fdef set/superset? :args (s/cat :set1 set? :set2 set?) :ret set?)
clojure.set/superset?
user=> (stest/instrument)
[clojure.set/superset?]
user=> (set/superset? #{1 2 3 4} [1 2 3])
Execution error - invalid arguments to clojure.set/superset? at (REPL:1).
[1 2 3] - failed: set? at: [:set2]
user=>

And since clojure is compiled using direct linking, such a spec won’t impact clojure itself. I’m not sure if clojure.pprint is also directly linked…

Everything in Clojure is compiled with direct linking enabled, including clojure.data/diff has its calls to clojure.set functions direct linked. Doing instrument, which uses alter-var-root on, clojure.set functions, will not affect the behavior of clojure.data/diff.

FYI in case you are curious, spec'd functions have a fairly high performance penalty, even for simple specs. There are performance comparisons in this README: https://github.com/jafingerhut/funjible

If your goal to use spec vs. something else here is just running tests, then perhaps performance is not your main concern, though.

That benchmark makes me wonder why is Spec so slow.

@andy.fingerhut yes. I ran some advent of code puzzles with instrumentation on clojure.core functions. it becomes creepingly slow

so I think this kind of instrumentation has its place during development and tests, but not in performance critical code

maybe spec-alpha2 does something about performance? I also wonder if spec-alpha2 works with older versions of Clojure, so you don’t have to maintain multiple versions of specs for different Clojure versions

So far the advice has always been that you probably don't want to run with specs enabled in production, because of performance reasons. You can of course go against that recommendation if you want, but the performance you are willing to live with in production is your decision to make.

I'm just surprised that it would be much slower then an equivalent assertion.

I'm trying to switch from lein to deps.edn, and I hit a wall when packaging the app into an uberjar. I have net.mikera/imagez {:mvn/version "0.12.0"} as a dependency, and use pack.alpha, but I get an error: Could not find artifact net.mikera:mikera-pom:jar:0.6.0 in central ().

This error has some google results. someone blamed lein-npm which I don't have/use. Looking up this package on clojars, it tells me that the clojars package (0.0.4) might be shadowing a release on central. Any idea what I can do now? Can I somehow download this dependency locally so it can be found when packaging?

The net.mikera:mikera-pom in version 0.6.0 can be found in my ~/.m2 dir already though.

@didibus added this to the README of speculative as a result of our conversation yesterday: https://github.com/slipset/speculative#speculative-broke-my-project

@andy.fingerhut would adding type hints in this code help after you have done the pre-condition checks? https://github.com/jafingerhut/funjible/blob/master/src/funjible/set.clj Tim Baldridge did a benchmark with type hints that made the code even faster in some benchmarks, not slower. I’m not sure if his code is public (cc @tbaldridge)

maybe that should happen in Java code itself, I’m not sure

maybe wrapping the args in (set ...) (while still having the pre-conditions) will make the JIT faster because it knows it’s always a set

anyway, linked your data here: https://dev.clojure.org/jira/browse/CLJ-2433?focusedCommentId=50544&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-50544

I don't know how type hints might help make that code run faster. Type hints most often make things faster if they help the compiler avoid reflection during Java interop calls, but there are none in that code.

@andy.fingerhut more information to the JIT

@andy.fingerhut I’m not sure how TB found the speedup, but it was something similar. He describes it in the defn podcast.

Are you saying you think they might help the spec'd version run faster? Or only the one with the type checks? The second seems possible, I just don't know exactly how. The first sounds harder to believe.

no, nothing to do with spec

I’ll look up the part where he talks about it, after dinner

Is there any roadmap when the next Clojure version is coming out?

Found it: https://clojure.org/community/devchangelog

I would not want it to be rushed. Maybe Nov.29.

There is something of an air of "thinking out loud" in the latest betas.

I’ve heard that podcast and he did say that it was a JIT thing, and it was the one that either called set or asserted the type. @andy.fingerhut @borkdude

If someone has a way that makes the type checking code even faster, I am all ears. I don't know how likely I am to find a chunk of several hours to devote to random experiments that don't pan out, but certainly open to other people wanting to do performance experiments on variations of that code 🙂

@andy.fingerhut found the section. it’s here at 43:19-44:00 https://soundcloud.com/defn-771544745/41-timothy-baldridge-aka-halgari

I have pinged Tim on Twitter to see if he still has this code and/or data

Is there any way, or any hack for that matter, to exclude a file included in a jar completly. It's a file that has no public member, but has unwanted side effects on require.

so who requires it?

a source file in my project, that retuires a source file (in a jar) that requires it, I don't require this file directly.

I could start by making phantom namespace with same name, and it would then ignore it right?

if I do it before this chain of requires..

found out that my problem was unrelated, there's something mysterious setting the jna.library.path to something else, after I assign to it... going to dig deeper.