Clojure Q&A - Search results for goedkope fc points besuche die website buyfc26coins.com. einfach und unkompliziert, super..zypn

Literals for Unicode code points (and perhaps also sequences thereof)

Mon, 12 Jan 2026 20:02:41 +0000

Context
For historical reasons the JVM type system's support for Unicode code points is poor, and while this is usually invisible to the developer it becomes a hassle when String literals containing non-Latin1 code points are used in code. It also becomes particularly problematic when cross-platform (cljc) code is attempting to do this, since other platforms may not share this historical oddity so solutions that "work" in ClojureJVM may break in other dialects.

For example, the transgender flag emoji (a single grapheme cluster that happens to be defined by 5 Unicode code points) cannot easily be constructed at the REPL or in a source file without detailed knowledge of the JVM's history (and associated knowledge of UTF-16, an increasingly obsolete character encoding).

Using the documented code points for this grapheme cluster with the JVM's Unicode escaping mechanism does not give the expected outcome:

The correct, but unintuitive solution is to remember that the JVM does not directly support Unicode code points in the supplemental planes, and then to translate the supplemental code point U+1F3F3 into its UTF-16 code unit / surrogate pair representation:

Note: I had to use screenshots for this, since ask.clojure doesn't appear to support Unicode supplemental code points properly either...

Question/request/proposal
Clojure can sidestep this issue in a purely accretive manner, providing better consistency across the JVM and other runtimes, by adding direct support for Unicode literals.

This would involve adding a new literal syntax that represents a single Unicode code point, and perhaps also a new literal syntax that represents a sequence of Unicode code points (perhaps supporting not only the novel Unicode code point literal, but also the existing Character and String literals). Both of these new literals would produce a standard JVM (or JavaScript, or ...) String object, in whatever native encoding those objects employ on their respective platforms - after such literals are read, it's all just the extant String data type - there is no runtime impact.

An example literal syntax

While I am not proposing a specific syntax for these new literals here (though such a task is a necessary step), for illustrative purposes here is an example of what these literals might approximately look like:

Single Unicode code point literals:

#U+0061: produces a String containing the Latin letter a: "a"
#U+1F921: produces a String containing the clown emoji (which ask.clojure cannot display)

Sequences of Unicode code point literals:

#U+[U+0061 U+0020 U+1F921]: produces the 3 grapheme cluster String: "a <clown emoji>"
#U+["a " U+1F921]: produces the same String, but demonstrates why it may be useful to support a mix of literals within the sequence (for readability)
#U+[\a \space U+1F921]: ditto
#U+[U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F]: produces a String containing a single grapheme cluster (the transgender flag emoji)

This final example is an ideal test case, since the transgender flag emoji is a single Unicode grapheme cluster, defined by 5 Unicode code points, but on the JVM (for the historical reason listed originally) is made up of 6 Characters.

Note that the sequence literal may not be necessary, since str could be used with the single code point literal syntax; e.g. (str #U+1F3F3 #U+FE0F #U+200D #U+26A7 #U+FE0F). Whether shifting the cost of string concatenation from read-time to runtime matters or not is another topic worthy of deeper consideration.

Other notes
Orthogonal to this proposal (at least from a Clojure core perspective; from a user perspective they're closely related), it would also be useful if Clojure core (perhaps in the clojure.string namespace) had functions to turn Strings into sequences of code points (as integers) and vice versa. Both the JVM and JavaScript provide native APIs for doing this (and presumably other platforms do too), but providing these as standard functions in Clojure core (similar to what was done with parse-long, parse-double, and parse-boolean in Clojure v1.11) has value and is also purely accretive.

proxy-super is not threadsafe, it should be made safe or documented to be unsafe

Wed, 05 Jul 2017 17:43:53 +0000

Coming from java you might expect proxy-super to be pretty innocuous, but proxy-super operates by mutating the proxy object then restoring it after the call to proxy-super is invoked. This can lead to very weird behavior. If you have a proxy with method M, which invokes proxy-super, then while that proxy-super is running all calls to M on that proxy object will immediately invoke the super M not the proxied M.

Actually making proxy-super safe (not just threadsafe, but also safe when invoked later on in the same callstack) seems like it might be really hard, but it would be nice. Alternatively some blinking hazard lights in the docstring might be a good idea.

clojure.java.data/from-java throws stack overflow

Mon, 10 Feb 2025 10:39:57 +0000

I use the following function to get scrollpoints from a client io.qdrant.client.QdrantClient

(def client ...) => io.qdrant.client.QdrantClient

(defn make-scroll-points [collection-name k v]
  (builder/to-java Points$ScrollPoints
                   Points$ScrollPoints$Builder
                   (Points$ScrollPoints/newBuilder)
                   {:collectionName collection-name
                    :filter (builder/to-java Points$Filter
                                             Points$Filter$Builder
                                             (Points$Filter/newBuilder)
                                             {:addMust (ConditionFactory/matchKeyword (name k) (str v))}
                                             {})
                    :limit 1
                    :withPayload (WithPayloadSelectorFactory/enable true)}
                   {}))

(def scroll-points (qdrant/make-scroll-points  <collection-name> :user "user-1"))

(def scrolled (.get (.scrollAsync client scroll-points)))

(bean scrolled)

works, but when i do

(clojure.java.data/from-java scrolled)

I get a stackoverflow error

Does Clojure have an anti LLM code contributions policy? Would it make sense for Clojure to adopt one?

Sun, 29 Mar 2026 13:14:25 +0000

LLM use appears to have a bunch of ethical and practical problems, the most pressing one seems to be the plagiarism that seems to be pretty excessive even for code and even when not baited:

Video clip of apparently a lawyer live demoing what seems to be Co-Pilot plagiasm

I don't know anything about law, but the lawyer at one point says: "This is a copyright infringement." I've also found this: https://www.twobirds.com/en/insights/2025/landmark-ruling-of-the-munich-regional-court-(gema-v-openai)-on-copyright-and-ai-training It seems to talk about "fair use" of AI model training.

Also see this high-profile incident: https://www.pcgamer.com/software/ai/microsoft-uses-plagiarized-ai-slop-flowchart-to-explain-how-github-works-removes-it-after-original-creator-calls-it-out-careless-blatantly-amateuristic-and-lacking-any-ambition-to-put-it-gently/

Also this field study that appears to be putting the plagiarism rate at seemingly at least 2-5%: https://dl.acm.org/doi/10.1145/3543507.3583199

This article mentions a study that apparently puts the plagiarism rate at 8–15% as a minimum for the easily detectable kind: https://www.theatlantic.com/technology/2026/01/ai-memorization-research/685552/

I don't know what this means legally, but at least morally and ethically this seems sad.

Apparently, some people in the Clojure space already spoke out against LLMs, but I wasn't able to find any anti LLM policy. If there was such a policy, I would expect it to be mentioned in the following places:

I simply wanted to suggest that perhaps the project may want to adopt such a policy.

Here are some other projects that have already done so: Asahi Linux, elementaryOS, Forgejo, Gedit, Gentoo, GIMP, GoToSocial, Löve2D, Loupe, NetBSD, postmarketOS, Qemu, RedoxOS, Servo, stb libraries, Zig.

My deepest apologies if there already is such a policy, or if I'm asking in the wrong space.

Create a vector with a non-`get` IFn

Thu, 02 Jan 2025 07:25:05 +0000

Goal: Create a new flavor of vector that is identical to the built-in vector, except when invoked, uses a different function (a variadic function defined by me, but concat is a good stand-in for demonstration purposes) instead of get.

Invoking a built-in vector implies get.

(def A (vector :a :b :c))
(get A 1) ;; => :b
(A 1) ;; => :b

No matter what we create to accomplish this task, the standard vector should behave exactly as before.

The new flavor of vector would behave ever-so-slightly differently. First, some example definitions using a new function, foo-vector.

(def B (foo-vector :a :b :c)) ;; => [:a :b :c]
(def C (foo-vector 'foo 'bar 'baz)) ;; => ['foo 'bar 'baz]
(def D (foo-vector 42 99)) ;; => [42 99]

All the usual functions work as before, because, for the most part, they are Clojure vectors.

(first B) ;; => :a
(get C 1) ;; => 'bar
(count D) ;; => 2

The only difference would appear when a "foo-vector" is invoked: Instead of an implied get, it's an implied concat (or some other variadic function, but concat works well for discussion).

(B C D) ;; => [:a :b :c 'foo 'bar 'baz 42 99]

Bonus points: Regular vectors and "foo-vectors" containing the same values would satisfy 'equals'.

(= (vector 1 2 3) (foo-vector 1 2 3)) ;; => true

In all respects, "foo-vectors" B, C, and D are vectors, with the exception that when appearing as the first element of a list (i.e., in the function position), an alternative function is called (in our example, concat) instead of get.

Question: What does foo-vector look like to create this new flavor of vector?

I do not know where to begin researching this problem other than regurgitating terms like IFn, deftype, extends, etc. I greatly appreciate any help.

How to persist Clojure data structures to disk?

Tue, 22 Oct 2024 08:45:52 +0000

Hello,
I'm building a web crawler in Clojure that records its results in a map of maps. The data structure basically looks like this:

{"https://example.org" {:base-url "https://example.org"
                        :crawled {"/blog" {:relevant true :status 200}
                                  "/contact" {:relevant false :status 200}}
 "https://foo.com" {:base-url "https://foo.com"
                    :crawled {"/home" {:relevant true :status 200}}}

The web crawler is feed with a list of websites. However, for the sake of efficiency I want to avoid crawling already crawled websites. Therefore, I was looking for a way to persist the above data structure so that it can be consulted in subsequent runs to check if a given website was already crawled. (Of course, I have other reasons to store the results too, e.g. to do various analysis on the captured data)

First, I thought EDN would be a perfect solution. To my surprise, clojure.edn does not have write functions. A lot of advice online says to use pr-str. However, using pr-str has caveats as pointed out in https://nitor.com/en/articles/pitfalls-and-bumps-clojures-extensible-data-notation-edn (e.g. possbile truncations when print-length is set). And it's totally possible to generate invalid edn as pointed out in this comment by @alexmiller: https://ask.clojure.org/index.php/10278/should-pr-str-on-a-function-produce-valid-edn-syntax?show=10282#c10282.

Despite https://clojuredocs.org/clojure.edn claiming that it is "designed to be used in a similar way to JSON or XML" I have the impression it is more geared towards writing edn files by hand (i.e. configuration files).

Looking for alternatives, I stumbled upon Transit. However, its mainly intended "as a wire protocol for transferring data between applications". And the README further says

If storing Transit data durably, readers and writers are expected to use the same version of Transit and you are responsible for migrating/transforming/re-storing that data when and if the transit format changes.

Because in Clojure, data is code and code is data and because of the existence of EDN, I really thought persisting simple data structures like the above would be a breeze in Clojure.

Instead I see these sub-optimal options with my current knowledge:

Hope that pr-str produces valid EDN without loss in my particular case
Build a custom XML serialization
Use Transit
Use JSON?! (what about keywords etc.?!)

Is there a more idiomatic way to store and read back in simple Clojure data structures?

fn? and multimethods

Mon, 07 Oct 2024 21:25:33 +0000

The docstring for clojure.core/fn? says "Returns true if x implements Fn, i.e. is an object created via fn.", defined in this commit from 2008.

Multimethods semantically act as functions. They're not collections (maps), they're not pieces of data that work like functions for ease (keywords), they're procedures with behavior and input and output. Protocol methods semantically act like functions as well. However, multimethods don't respond to fn? because they don't implement clojure.lang.Fn, they implement clojure.lang.AFn, whereas protocol methods do respond to fn? because they are created with fn* in the defprotocol macro.

This has led to confusion in my code where I have a sequence of function-like objects and in certain cases I want to select only the "semantically function" objects. It has forced me to write fn+? which is implemented as (or (fn? x) (instance? clojure.lang.MultiFn x)). Now, having written it, it works fine and my immediate problem is solved. However, I think this points to an underlying semantic mismatch between multimethods and their implementation.

It would benefit me and others to have this mismatch cleaned up.

Namespace starting with `com` broken in graaljs replenv

Wed, 15 May 2019 14:15:41 +0000

With graal installed:

$ java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-20190420112649.buildslave.jdk8u-src-tar--b03)
OpenJDK GraalVM CE 19.0.0 (build 25.212-b03-jvmci-19-b01, mixed mode)

$ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.520"}}}' -m cljs.main -re graaljs
ClojureScript 1.10.520
cljs.user=> (ns com.foo)

com.foo=> (defn bar [])
#'com.foo/bar
com.foo=> (bar)
Execution error (Error) at (<cljs repl>:1).
(intermediate value).foo.bar.call is not a function

How to access non-jar artifacts (aar, zip) downloaded via tools.deps in build.clj?

Wed, 24 Dec 2025 08:55:46 +0000

I want to access an aar/zip artifact in build.clj that's already downloaded via deps.edn:

{:deps
 {com.newrelic.agent.android/android-agent {:local/root "build/jars/android-agent.jar"
                                            :doc        "extracted from aar"}
  com.newrelic.agent.java/newrelic-api     {:local/root "build/jars/newrelic-api.jar"
                                            :doc        "extracted from newrelic-java.zip"}}
 :aliases
 {:build {:deps       {io.github.clojure/tools.build            {:mvn/version "0.10.11"}
                       com.newrelic.agent.java/newrelic-java    {:mvn/version "8.25.1"
                                                                 :extension   "zip"}
                       com.newrelic.agent.android/android-agent {:mvn/version "7.6.14"
                                                                 :extension   "aar"}}
          :ns-default build}}}

In build.clj I need to unpack this zip and extract a jar from it.
And I don't have to hardcode .m2 paths or duplicate the version.

How can it be done?

See https://github.com/clojure/tools.deps/blob/46661e929ab702d0ee532188edb58d06b39cef6c/src/main/clojure/clojure/tools/deps/extensions/maven.clj#L172

Is taggedliteral's equality check inefficient?

Fri, 27 Mar 2026 13:43:44 +0000

Following on from a very interesting article about tagged literals: https://buttondown.com/tensegritics-curiosities/archive/when-you-run-out-of-types/ I noticed that the implementing class checks for value equality before checking for tag equality.

if (form != null ? !form.equals(that.form) : that.form != null) return false;
if (tag != null ? !tag.equals(that.tag) : that.tag != null) return false;

This leads to the following type of comparison that could be answered immediately but instead takes over a second:

impl=> (time (= (tagged-literal 'foo (seq (range 1e7))) (tagged-literal 'bar (butlast (seq (range 1e7))))))
"Elapsed time: 1911.677375 msecs"
false

it checks if these huge seqs are equal and then compares the associated symbols. Swapping this seems identical semantically but with less computation.

Support for automatic promotion to BigDecimal in +', *', etc.

Mon, 10 Nov 2025 04:15:47 +0000

Is there support for BigDecimal promotion in the +', *', etc. clojure.core functions?

When I run the following code in the REPL:

(* 2 Double/MAX_VALUE)     ;; ##Inf, Doesn't auto-promote as was expected.
(*' 2 Double/MAX_VALUE)    ;; ##Inf, Expected that it would auto promote.

Following cases also didn't work:

(*' Double/MAX_VALUE 2)        ;; ##Inf, Moving around the arguments.
(*' 2.0 Double/MAX_VALUE)      ;; ##Inf, Using a Double literal instead.
(*' Double/MAX_VALUE 2.0)      ;; ##Inf
(*' Double/MAX_VALUE 2.0M)     ;; ##Inf, Using a BigDecimal literal instead.
(*' 2.0M Double/MAX_VALUE)     ;; ##Inf

I decided to check the Clojure compiler source for promotion, and based on my limited understanding of the code I see that DoubleOps is using the implementation of addP of OpsP abstract class (which just calls the normal add function) while there is one present for LongOps which can be found here.

Is this a bug? And if yes, I would like to work on the fix and I'll check the Development page of Clojure to do the needfull.

`find` docstring enhancement proposal

Thu, 11 Dec 2025 12:41:48 +0000

The docstring for clojure.core/find states

Returns the map entry for key, or nil if key not present.

Formatted lower-cased with a space, it is not immediately apparent that 'map entry' is a term of art referring to a specific thing. 'map entry' might be mis-interpreted as a casual synonym for 'the entry of a map associated to a key', i.e., the value.

Proposal #1
Reword the find docstring to be more precise about what is returned.

Returns a clojure.lang.MapEntry containing key and the associated value, or nil if key not present.

Proposal #2
If you don't want to make a commitment to returning a MapEntry, reword to

Returns a sequential collection containing key and the associated value, or nil if key not present.

[clojure.edn] Leading zeros in numbers

Thu, 04 Dec 2025 13:31:23 +0000

clojure.edn allow leading zeros ending up reading such number as octal representation. The problem is that it is also allowed to have indefinite amount of leading zeros for octals:

000000000000042  ;; => 34

and when there is a suffix "M" that forces floating point representation the same string become float 42 stripping all leading zeros.

000000000000042M ;; => 42M

At the same time EDN specification forbids integers with leading zeros at all even for floats.
I found a ticket about leading zeros in data.json but I think it should be expanded to cover clojure as well.

In the same scope but origin is in the EDN spec:
float specification allows leading zeroes in exponent and only zeros in fractional parts:

0.00000000...00
0.0e0001

probably because of that clojure.edn read such numbers without error too.

a) how: programmatically set REPL ‘context’ ‘prj-1 aware’? b) how: programmatically switch REPL ‘context’ ‘prj-n aware’?

Sun, 23 Feb 2025 16:56:50 +0000

Ok, regardless of editor, running clj in a directory will start a repl that has "project context" to project deps.edn in that directory, and that is the way that most Clojure developers create a connected repl.

The implication seems to be to work on a different project one must (System/exit 0) VM and start another VM using clj command to ‘create a connected repl’ to project deps.edn in a different directory? This appears to be idiomatically (colloquially) referred to as ‘restarting the REPL’ I believe?

Seems rather draconian for a dev env, let alone a lisp dev env? I thought the highly dynamic heritage of lisp replete with multiple REPLs was universally sought after? 10 years later and no multiple REPLs for clojure? Personally, I’m somewhat surprised, but maybe nobody really wants, needs or requires multiple clojure REPLs? I think multiple REPLs could be transformational in many use cases IMHO, or maybe I’m really ‘out of the loop’ no pun intended?

03-10-2015 Clojure stream socket repl discussion (https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/mgwvmEnjnBoJ) several notable sub-quotes:

“I think it is important, with tooling, to have the broadest, open notion of the types of 'use cases' for Clojure, and for workflows of people using Clojure, lest you actually limit them. I hope people are able to write their languages and DSLs, test embedded control/debug consoles, design next-generation REPLs and debuggers, grab data dumps etc, all from their REPL. That's the heritage of Lisp. Many people are doing data science, languages, genetics, rule-systems etc type things with Clojure, not just web apps

But it is quite common in rich Common Lisp IDEs like Lispworks for people to have multiple listener (REPL) sessions open at the same time (against the same runtime). You can launch long running processes that produce streaming output, switch to another listener and continue interaction and development, have separate listeners for separate contexts/state/command-history etc. There's a lot to Lisp development that's not RPC.

Note multiple listeners, data inspectors and more. Maybe not the latest GUIs, but the capabilities should be a source of inspiration for any Clojure IDE.”

Previously hinted personal end goal: exploit ‘critical mass’ for a (truly) ‘dynamic’ clojure dev env, including dynamic java recompilation, namespace reloading, etc. and include at a minimum:

clojure.repl.deps
clojure.tools.build.api (clojure.tools.build)
clojure.tools.deps
clojure.tools.deps.cli.api (clojure.deps.cli)
clojure.tools.namespace
clojure.tools.tools.api (clojure.tools.tools)
GitHub - clj-commons/virgil: Recompile Java code without restarting
the REPL (https://github.com/clj-commons/virgil)
other polyglot ‘evaluation/compilation’ TBD

I also included a few tools to help come back up to speed quicker:

GitHub - nubank/morse: A graphical, interactive tool for browsing
Clojure data (https://github.com/nubank/morse)
[clj-ns-browser/clj-ns-browser "2.0.0-SNAPSHOT"] – Clojars
(https://clojars.org/clj-ns-browser/versions/2.0.0-SNAPSHOT)

Eventually will look at many ‘current projects’ including: GitHub - HumbleUI/HumbleUI: Clojure Desktop UI framework (https://github.com/HumbleUI/HumbleUI) as stated to build better apps than possible with web, AND access full power of your computer (multithreaded), wouldn’t that be convenient?

Another quote from 03-10-2015 Clojure stream socket repl discussion (https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/IHoVWiJz5UIJ):

“REPL stands for something - Read, Eval, Print, Loop. It does not stand for - Eval RPC Server/Window.”

Anyway, that would be ERSW, seriously, I couldn’t agree more, a required lisp feature, for me anyway: multiple simultaneous-concurrent (multi-threaded) REPLs, I refer to as ‘Clojure Listeners’ (‘in-process’ or ‘against the same runtime’) non-socket non-nREPL non-LSP non-network non-middleware non-multi-VM based REPL approaches that support multiple simultaneous dev management ‘native VM’ approaches for polyglot projects ala GraalVM.

[SEE Multiple Clojure Listeners] (https://github.com/mgrisius/clj-mode/blob/0.9/Clojure_Listener_2025-02-23_09-02-41.jpg)

Note JavaScript Listener “JS-1” pictured. Could have python, R, ruby, or whatever language(s) available in GraalVM. ‘Clojure Listeners’ used with or without emacs, ‘regardless of editor’, in any Java VM for that matter. Could easily have multi-threaded socket-based listeners . . .

Clojure Listeners: multi-threaded, full history, type ahead, line editing, completion, pop-up menus, colorized output, colorized-balanced-brackets-([{, etc. Also working on other listener features: multi-line editing, enhanced source lookup, doc lookup, repo-artifact search, embeddable .e.g. in morse, etc. all leveraging the ‘purest clojure value chain possible’!

As previously mentioned, my basic ‘old style’ simple.bat with (~60mb) über jar simple compatibility with emacs lisp-inferior-mode works good with ‘legacy’ approach and new ‘CLI deps.edn approach’ basic use so far, both with ~1 second startup time. Zero optimization has been done thus far, e.g. GraalVM native image, etc.

My forward-looking goal & reason for asking initial question: compatibility with future clojure tool direction(s), NOT invent the next ‘technical debt’ ad hoc one-off hack. My Holy Graal: I want a fully dynamic long running VM under full clojure programmatic control.

So, the question remains: a) how to programmatically set REPL with ‘context’ for ‘project-1 aware’? b) how to programmatically switch REPL ‘context’ to ‘project-n aware’?

Optimize `eduction`

Fri, 03 Apr 2026 14:25:17 +0000

Problem statement

Eduction is useful part of the transducer ecosystem, which has a benefit/aim of improved performance. However, the function eduction only has a single varargs arity, which adds multiple function calls and and seq traversal allocations.

As seen in this PR to clj-kondo, manually passing in an xform directly can improve both overall performance and lower allocations.

Proposal

Adding arities to eduction can sidestep those allocations and seq traversals, improving baseline performance of all eduction invocations.

(defn eduction2
  {:arglists '([xform* coll])
   :added "1.7"}
  ([coll] (->Eduction identity coll))
  ([f1 coll] (->Eduction f1 coll))
  ([f1 f2 coll] (->Eduction (comp f1 f2) coll))
  ([f1 f2 f3 coll] (->Eduction (comp f1 f2 f3) coll))
  ([f1 f2 f3 f4 & args]
   (->Eduction (apply comp f1 f2 f3 f4 (butlast args)) (last args))))

requiring an empty .clj without an alias should fail as with an alias

Thu, 02 Apr 2026 18:48:37 +0000

if file a/b/c.clj is "empty"

it creates an empty ns: (and does not fail) when doing

(require '[a.b.c])

while when using ":as" it fails correctly with error:

(require '[a.b.c] :as c)

Syntax error compiling at ... ; namespace 'a.b.c' not
found after loading '/a/b/c'

see here for initial discussion:
https://clojurians.slack.com/archives/C03S1KBA2/p1775155101843229?thread_ts=1775153939.803389&cid=C03S1KBA2

Using https://developers.google.com/web/tools/puppeteer/ from Clojure ?

Fri, 18 Sep 2020 04:15:31 +0000

Is there a way to use https://developers.google.com/web/tools/puppeteer/ from Clojure?

Googling, there are lots of "puppet" related Clojure libraries, but none appear to be for web scraping with Chrome.

Is there a way to use https://developers.google.com/web/tools/puppeteer/ from Clojure?

How to use core.async from cljr command line tool?

Mon, 24 Nov 2025 06:05:40 +0000

At some point it would be good to facilitate use of core.async from cljr command line tool (clr.core.cli).

I think what's required is:

add a deps-clr.edn to clojure/tools.analyzer
add a deps-clr.edn to clojure/tools.analyzer.clr (depends on tools.analyzer, clr.tools.reader, clr.core.memoize -> clr.core.cache -> clr.data.priority-map)
add a deps-clr.edn to clojure/clr.core.async
also, archive clojure/clr.tools.analyzer

This is not urgent because it's possible to procure core.async from NuGet but it would be convenient if it could also be procured via git.

TDEPS-269: checksums should use sha256sum instead of shasum

Tue, 27 Jan 2026 11:17:20 +0000

This commit broke our Docker build: https://github.com/clojure/brew-install/commit/d6d540756cb0a6342374db529d07f1de35d5bc71

because shasum is a perl executable provided on Fedora by perl-Digest-SHA-1 rpm, but it's not available on the UBI platform. The standard way to validate checksums is through sha256sum provided by coreutils on most (if not all) linux distributions.

The jira ticket even talks about sha256sum, but then the commit doesn't use it: https://clojure.atlassian.net/jira/software/c/projects/TDEPS/issues?jql=project = TDEPS ORDER BY created DESC&selectedIssue=TDEPS-269

bug bigdec

Fri, 05 Dec 2025 05:09:44 +0000

clojure.edn and clojure allows keywords with empty ("") namespaces

Fri, 05 Dec 2025 09:56:54 +0000

Following links and snippets are about clojure.edn but because this logic is the same in clojure it also affects clojure reader as well.

Here is how symbol pattern is defined:

[:]?([\D&&[^/]].*/)?(/|[\D&&[^/]][^/]*)

It is eagerly matching prefix until the last slash character, after that it matches symbol name.

Then there is a wrong analysis of matched groups happen: ns is incorrectly set to everything until the last slash with validation that it is not ends with :/

Then in Symbol.intern call there is an another lookup for the first slash to split symbol into namespace and name.

The result is that keywords like this: ":/-/-", end up with namespace set to empty string "".

Looks like the least intrusive way to fix it is to use the same logic to find namespace borders in both places:

during symbol reading, lookup the first / to set ns instead of using the first matching group
in symbol interning the logic is correct

Another option is to use different regular expression:

[:]?([\D&&[^/]][^/]*/)?(/|[\D&&[^/]].*[^/])

This matches symbol prefix til the first slash keeping restriction "name can't end with slash".

shasum not found error when using ./posix-install on linux

Wed, 11 Mar 2026 21:49:11 +0000

I was redeploying an AWS beanstalk application. I was installing clojure using the commands from the clojure install guide for posix

commands:
  01_install_clojure:
    command: |
      curl -L -O https://github.com/clojure/brew-install/releases/latest/download/posix-install.sh
      chmod +x posix-install.sh
      sudo ./posix-install.sh

I believe this used to work, but it now fails with

./posix-install.sh: line 30: shasum: command not found

Using the linux instructions worked just fine. I can provide more info about the linux envorionment, but it was using aws' "Corretto 17 running on 64bit Amazon Linux 2023/4.10.0" platform which is one of the builtin java platforms for beanstalk.

Persistent collections can implement equiv() more efficiently

Thu, 30 Sep 2021 16:57:25 +0000

I found that structural equality between persistent collections makes very few assumptions which lead to inefficient implementations, especially for vectors and maps.

The thrust of the implementation is dispatching via methods which directly iterate over the underlying arrays.

These implementations aren't the prettiest or most idiomatic but they're efficient. If this gets implemented it would look different in Java anyway.

I tried these alternative implementations and found dramatic speed ups:

Vector

(let [die (clojure.lang.Reduced. false)]
  (defn vec-eq
    [^PersistentVector v ^Iterable y]
    (let [iy (.iterator y)]
      (.reduce v (fn [_ x] (if (= x (.next iy)) true die)) true))))

This works well when comparing vectors and for vector x list
Current implementation goes through a loop from 0 to count and calls nth for every element. nth calls arrayFor() every time, while both reduce and an iterator get the backing array once per array.

Map

(let [o (Object.)
      die (clojure.lang.Reduced. false)
      eq (fn [m2] (fn [b k v]
                   (let [v' (.valAt ^IPersistentMap m2 k o)]
                     (if (.equals o v')
                       die
                       (if (= v v') true die)))))]
  (defn map-eq
    [m1 m2]
    (.kvreduce ^IKVReduce m1 (eq m2) true)))

Here, too, the implementation iterates directly over the underlying array structure.
Current implementation casts the array to seq then iterates over it while getting entries from the other map via the Map interface.
This implementation avoids casting the map to a sequence and does not allocate entries.

Sequences

When the receiver is a list the object compared against it and the receiver will be cast to a seq.

It could be more efficient to compare it with other collections via an iterator

(defn iter-eq
  [^Iterable x ^Iterable y]
  (let [ix (.iterator x)
        iy (.iterator y)]
    (loop []
      (if (.hasNext ix)
        (if (= (.next ix) (.next iy))
          (recur)
          false)
        true))))

Benchmarking

With criterium, vec-eq wins both cases. There are diminishing returns with size increase but still at n=64 vec-eq is twice as fast as =.
map-eq is also 2-3x faster for bigger maps and up to 10x faster for smaller maps

(doseq [n [1 2 4 8 16 32 64]
        :let [v1 (vec (range n))
              v2 (vec (range n))]]
  (println 'iter-eq n (iter-eq v1 v2))
  (cc/quick-bench (iter-eq v1 v2))
  (println 'vec-eq n (vec-eq v1 v2))
  (cc/quick-bench (vec-eq v1 v2))
  (println '= n (= v1 v2))
  (cc/quick-bench (= v1 v2)))


(doseq [n [1 2 4 8 16 32 64]
        :let [v1 (vec (range n))
              v2 (list* (range n))]]
  (println 'iter-eq n (iter-eq v1 v2))
  (cc/quick-bench (iter-eq v1 v2))
  (println 'vec-eq n (vec-eq v1 v2))
  (cc/quick-bench (vec-eq v1 v2))
  (println '= n (= v1 v2))
  (cc/quick-bench (= v1 v2)))

(doseq [n [1 2 4 8 16 32 64]
        :let [m1 (zipmap (range n) (range n))
              m2 (zipmap (range n) (range n))]]
  (cc/quick-bench (map-eq m1 m2))
  (cc/quick-bench (= m1 m2)))

Addendum:
Also checked the following cases:

(doseq [n [10000 100000]
        :let [v1 (vec (range n))
              v2 (assoc v1 (dec (count v1)) 7)]]
  (cc/quick-bench (vec-eq v1 v2))
  (cc/quick-bench (iter-eq v1 v2))
  (cc/quick-bench (= v1 v2)))

(doseq [n [100000]
        :let [m1 (zipmap (range n) (range n))
              m2 (assoc m1 (key (last m1)) 7)]]
  (cc/quick-bench (map-eq m1 m2))
  (cc/quick-bench (= m1 m2)))

Optimized implementations still win by huge margins

clojure.core.cache caches delays that hold exceptions as of version 1.2.254

Mon, 23 Feb 2026 19:43:34 +0000

As of version 1.2.254 of org.clojure/core.cache, using a value-fn that throws will cause an entry to be added to the cache associated with a Delay with :status :failed and the exception as a value.

The code below can be used to compare the behavior between versions 1.1.234 and 1.2.254.

(require '[clojure.core.cache.wrapped :as cw])

(def counter (atom 0))

(defn value-fn [v]
  (prn :value-fn-called)
  (swap! counter inc)
  (if (= @counter 1)
    (throw (ex-info "thrown" {}))
    v))

(def test-cache (cw/lu-cache-factory {} :threshold 10))

(reset! counter 0)
; this will throw
(cw/lookup-or-miss test-cache "throw" value-fn)
; in 1.1.234 this will call value-fn again and not throw; in 1.2.254, it won't call and return
; the cached delay result, which is an exception
(cw/lookup-or-miss test-cache "throw" value-fn)

; evict to force call to value-fn
(cw/evict test-cache "throw")

This is related to work done in CCACHE-65 to avoid cache stampede in multi-threaded applications, and could be related to what has been reported in CMEMOIZE-31.

This was initially reported in Clojurians Slack.

Is it legal for a namespace to start with a number?

Mon, 23 Feb 2026 18:53:53 +0000

There are rules (informally in the spec, formally in the reader) about disallowing symbols to start with numbers: (def 1asdf 5) However, there aren't rules about namespaces (either middle segments or as the final segment) starting with numbers, leading to their usage in the wild. (For example: https://github.com/marick/Midje/tree/bee206983db22c6dc92044fd7b5b0365bbd44fc6/test/implementation/parsing/0_to_fact_form)

Is this intentional? Should such namespaces be considered legal or not?

`(max "x" "y")` used to return "y", now it returns "x"

Mon, 22 Dec 2025 13:45:04 +0000

Hello!

With cljs 1.12.42:

cljs.user=> (max "x" "y")
"y"
cljs.user=>

With cljs 1.12.134:

cljs.user=> (max "x" "y")
"x"
cljs.user=>

Probably related to CLJS-3425 and this commit which added NaN checks:

(defn ^number max
  "Returns the greatest of the nums."
  ([x] x)
  ([x y]
   (cond
     (NaN? x) x
     (NaN? y) y
     (> x y) x
     :else y))
  ([x y & more]
   (reduce max (cljs.core/max x y) more)))

But:

cljs.user=> (NaN? "x")
true
cljs.user=>

Hence the result.

Not sure what the expected result should be since min/max are only supposed to work with numbers but current behavior is surprising.

flow monitoring tool serves resources from unqualified path

Tue, 04 Nov 2025 20:57:47 +0000

For flow monitoring, HTML, CSS, and javascript assets are served from the resource path "public/". If there is another library on the classpath that also has a resource at "public/index.html", then flow monitoring's assets will get clobbered and serve the wrong web page instead. Alternatively, flow monitoring may clobber someone else's resources.

https://github.com/clojure/core.async.flow-monitor/blob/6248a5d8e4228ab5974289559e3cb11ff3152263/src/clojure/core/async/flow_monitor.clj#L104

This can be addressed by moving resources to a qualified path like "clojure/core/async/flow_monitor/public/index.html".

Is it valid for metadata to have metadata?

Thu, 12 Feb 2026 15:45:20 +0000

Hello,

I am implementing a pretty printer and while adding/testing support for *print-meta* I noticed that pr prints an object whose metadata has metadata in the following way:

user> (binding [*print-meta* true]
        (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork}))))
"^^{:frob :zork} {:bar :baz} foo"

When reading such a form, only the "outermost" metadata is preserved:

user> (binding [*print-meta* true]
        (let [s (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork})))
              o (clojure.edn/read-string s)]
          {:o o
           :meta (meta o)
           :metameta (meta (meta o))}))
{:o foo, :meta {:bar :baz}, :metameta nil}

The behaviour is the same for clojure.core/read-string and also the tools.reader readers.

Can anyone clarify for me if this is either:

simply GIGO
a bug in the printer
a bug in the readers
a state that should be somehow disallowed
something else?

Neither the metadata reference nor the reader reference explicitly allow or disallow such a thing, as far as I can tell. Should they?

N.B. this is not an issue in any kind of production context and I'm not aware of any library or program that constructs such a thing. It's simply something I tested to see if/how it would break the pretty printer I'm building.

EDIT:

I dug into this some more with Nicola. Here's a perhaps much clearer case that demonstrates the reader isn't propagating nested metadata:

user> (let [o ^^:foo {1 2} {3 4}]
        {:o o :meta (meta o) :metameta (meta (meta o))})
{:o {3 4}, :meta {1 2}, :metameta nil}

:metameta should be {:foo true}.

In this section of MetaReader.invoke we are iterating over the entries of the meta map and manually associng them into the existing meta of the object; any metadata on the meta map itself is not preserved. I have a patch that adds a failing test case and correctly propagates the the meta map's metadata. If this is worth a ticket then I'm more than happy to attach it to that or send it to you directly.

Choosing between core.async pipelines

Sun, 26 Oct 2025 22:19:12 +0000

It's no longer clear what kind of pipeline is suitable for what kind of task in core.async.

Previously, my understanding was that anything I/O-bound should go into pipeline-blocking, while CPU-bound tasks went into regular (i.e. :compute) pipeline. But a while back :compute pipelines were changed to use threads instead of go-blocks. And now, with the introduction of virtual threads, pipeline-async seems like the right choice for I/O-bound tasks.

It seems that workloads are being classified into one of three types: :compute, :io, and :mixed. Is :async meant to be the equivalent of :io, and :blocking the equivalent of :mixed? I don't think that's original semantics, but it seems to be the mapping now.

Why is `list` defined with a RestFn instead of `create` method?

Tue, 09 Dec 2025 15:18:48 +0000

Stemming from a conversation on slack, I learned that list is not a function created with fn* but an instance of the class clojure.lang.PersistentList$Primordial. This leads to inconsistencies, such as (vary-meta list assoc :hello :world) throwing an error instead of returning an AFunction with metadata. Reading through the git history, it looks like this approach was chosen very early (commit "made list return a PersistentList, not a seq").

Is there a reason why this approach was taken versus a create(ISeq args) overload like vector and hash-map?

Optimized str function

Mon, 16 Mar 2026 11:12:53 +0000

Opimized version of str function:

(defn my-str
  (^String [] "")
  (^String [^Object x]
   (if (nil? x) "" (. x (toString))))
  (^String [^Object x & ys]
   (let [sb (StringBuilder. (if (nil? x) "" (. x (toString))))]
     (loop [ys (seq ys)]
       (if-not (nil? ys)
         (let [x (.first ys)]
           (if-not (nil? x)
             (.append sb (.toString ^Object x)))
           (recur (.next ys)))))
     (.toString sb))))

Benchmarks:

(let [xs (vec (range 1000))]
    (criterium/bench
      (apply my-str xs)))

Evaluation count : 2577840 in 60 samples of 42964 calls.

         Execution time mean : 23.611394 µs

(let [xs (vec (range 1000))]
    (criterium/bench
      (apply str xs)))

Evaluation count : 1375200 in 60 samples of 22920 calls.

         Execution time mean : 42.015320 µs

`flow/ping-proc` can be slow or fail to respond, even when process isn't busy

Wed, 28 Jan 2026 18:01:40 +0000

I've run into a few cases where flow/ping and flow/ping-proc are slow and timeout.

I was able to track the issue down to this line https://github.com/clojure/core.async/blob/b871f3519de6843a9f5ce66cf8d5c6cbe44d3222/src/main/clojure/clojure/core/async/flow/impl.clj#L273

(async/>!! c
            (walk/postwalk datafy
                           #::flow{:pid pid, :status status
                                   :state state,
                                   :count count
                                   :ins pins :outs pouts}))

This causes the state of the flow process to be traversed and datafied.

In one case, I had some process state that threw an exception when datafied due to an incomplete datafy extension. This caused flow/ping-proc to silently fail. No errors were reported.

In some other cases, the flow processes were working with large values. Walking the process state was slow and caused pings to respond slowly.

Hide Warnings from Com.Google.Cloud.Translate

Tue, 26 Jan 2021 02:38:21 +0000

Howdy. I am using this excellent wrapper over google translate. https://github.com/billwinkler/google-translate

However, whenever I invoke
(gt/translate! ... :from "" :to "")
I get warnings printed to the console / REPL.
I would really like to not see these warnings:

WARNING: Ignoring Application Default Credentials GOOGLE_APPLICATION_CREDENTIALS: using explicit setting for API key instead.

I am relatively new to logging and understand the java side of things is a mess, is there any way I can prevent seeing these warnings in the REPL ?

Improving curl options for CLI install scripts (brew-install)

Mon, 26 Jan 2026 12:39:44 +0000

Hi!

I'm the maintainer for Heroku's Clojure buildpack. It uses the install scripts from clojure/brew-install to install the CLI. I noticed intermittent install failures related to the download of the Clojure tools. I believe most of them could be avoided with a slightly changed curl command line options.

I opened a PR before realizing that PRs will not be accepted, so I'm starting this thread to properly get the discussion going. For reference, the closed PR can be found here: https://github.com/clojure/brew-install/pull/10

I believe these options would improve the download behaviour for all users, but especially when used in automations:

--connect-timeout 3 (https://curl.se/docs/manpage.html#--connect-timeout)
Prevents hanging when server is unreachable.

--fail (https://curl.se/docs/manpage.html#-f)
Exit with error code 22 for HTTP responses with status codes >= 400.

--max-time 60 (https://curl.se/docs/manpage.html#-m)
Maximum time in seconds for the entire transfer operation. Prevents hanging indefinitely with slow connections.

--no-progress-meter (https://curl.se/docs/manpage.html#--no-progress-meter)
Introduced in curl 7.67.0 (Nov 2019). Disables the progress bar for cleaner output. But less drastic than --silent and will still output diagnostic information (i.e. retries).

--retry-max-time 60 (https://curl.se/docs/manpage.html#--retry-max-time)
Retry only within this time period (60 seconds). After this time expires, no more retries will be attempted.

--retry 5 (https://curl.se/docs/manpage.html#--retry)
Introduced in curl 7.12.3 (Dec 2004). Retry up to 5 times on transient errors (timeouts, HTTP 408, 429, 500, 502, 503, 504, 522, 524).

--retry-connrefused (https://curl.se/docs/manpage.html#--retry-connrefused)
Introduced in curl 7.52.0 (Dec 2016). Consider connection refused as a transient error for --retry.

These are obviously opinionated and my ask is not for these options specifically. Happy to get anything that will improve the situation. :)

Manuel

Does clojure-clr work on Android?

Sat, 19 Apr 2025 19:59:28 +0000

EDIT: Answer is YES. Below is my long-winded exploration.

I see one of the reasons for clojure-clr-next is it will work on more platforms, is Android one of those?

I'm using Termux to operate dotnet on Android.

Both the clojure-clr global dotnet tool and locally compiled clojure-clr fail with exit code 1, no exceptions or anything. I tried dotnet-trace and it gets a partial trace, but no minidump. Puzzling as with the partial trace, the documentation indicates an expectation of a minidump, maybe there is some unmet condition to emit the minidump I'm not aware of yet (env variables for it didn't work).

In the trace here is an early line followed by some of the last lines:
`
"system.linq!System.Linq.Enumerable.SelectManyS\ingleSelectorIterator\u003cSystem.Reflection.As\sembly,System.Type\u003e.MoveNext()"

[...]
"system.collections!System.Collections.Generic.\
SortedSet\u003cSystem.Collections.Generic.KeyVa\luePair\u003cSystem.Int32,clojure.lang.CljCompi\ler.Ast.FnMethod\u003e\u003e.AddIfNotPresent(Sy\stem.Collections.Generic.KeyValuePair`2\u003cin\t,

[...last line...]
"ManagedModule!System.Buffers.SharedArrayPool\u\003cSystem.Byte\u003e.Trim()"
`

So maybe something to do with reflection, or that SharedArrayPool?

I tried inserting some logging to Clojure.Main, but nothing logged as it appears to fail before CljMain.Main() is called. Possibly fails during setting up attributes on one of the classes, in one of the Symbol.intern() or RT.var() calls or somewhere else?

Couldn't run the dotnet msbuild build.proj -t:Test -p:TestTargetFramework=net8.0, fails with:
Clojure.Main -> /data/data/com.termux/files/home/dev/clojure-clr/Clojure/Clojure.Main/bin/Debug/net8.0/Clojure.Main.dll ClojureCompileAssets = '' ClojureMainAssets = '' ClojureTestsAssets = '' /data/data/com.termux/files/home/dev/clojure-clr/Clojure/build.proj(177,5): error MSB3073: The command "dotnet run --project /data/data/com.termux/files/home/dev/clojure-clr/Clojure/Clojure.Main --framework net8.0 -c Debug -p:TargetOS=linux-bionic -p:TargetPlatform=arm64 -p:TargetFramework=net8.0 -p:TargetFrameworks='net8.0' -- run_test.clj" exited with code 1.
I had to edit build.proj a bit to get custom -p:TargetFrameworks and such to pass through, but still fails with exit code 1.

Well I'll continue poking around in this uncharted territory.

clojure.core/subs should use type hints of ^CharSequence, NOT ^String

Tue, 13 Jan 2026 18:10:48 +0000

This is related to this ancient ask, but it would be ideal if clojure.core/subs was type hinted with ^CharSequence rather than ^String, and used the subSequence() method instead of substring() (since the latter doesn't exist in CharSequence).

The single parameter version of subs would need to call s.length() as the second argument in the call to subSequence() (there is no single-arg version of that method, unlike substring()).

More generally, there are substantial benefits in using CharSequence instead of String throughout Clojure core, not only in the context of Java interop, but also when using custom String-like data structures (e.g. ropes).

[edit] @alexmiller mentioned this in another forum (and I'm capturing it here for posterity), but this might also require that the result be stred, to ensure the return type remains unchanged (subSequence() returns a CharSequence, unlike substring, which might break callers). There may be performance implications of adding that call for types other than String (but existing callers should be unaffected, since String.toString() is identity).

Confusing error message on deps.edn wrong git/url dependency

Thu, 05 Dec 2024 10:17:00 +0000

When you misspell the :git/url of a git dependency (or the dep name used to infer a url) the error says :

Cloning: https://github.com/MISSPELLED-ORG-OR-REPO-PATH
Error building classpath. Unable to clone /home/user/.gitlibs/_repos/https/github.com/MISSPELLED-ORG-OR-REPO-PATH
fatal: could not read Username for 'https://github.com': terminal prompts disabled

I find the the 3 sentences confusing since they mention classpath, a local folder, username, and terminal prompts disabled.

It would be great if it more clearly can express that no repo could be found with the provided URL, or at least remove the last sentence fatal: could not read Username for 'https://github.com': terminal prompts disabled which I find misleading.

Maybe the Unable to clone could be followed by the url instead of the local folder also?

qualified versus simple classnames when using `gen-class` compiled classes

Fri, 28 Feb 2025 11:55:45 +0000

Using the qualified name of a subclass compiled by gen-class to access the superclass' members throws an exception. Using the simple name proceeds as expected.

Here's an example that I've tried to cut down as much as possible, but it's still lengthy. All files are relative to the project root directory, indicated as <project root>.

Define a class in file <project root>/src/com/example/SomeClass.java with two members, a static field and a static method.

package com.example;

public class SomeClass {

    public static int aField = 99;

    public static String aStaticMethod(int i) {
	    return "aStaticMethod received " + i;
    }
}

Define a subclass in file <project root>/src/com/example/SomeSubClass.java that extends the previous class.

package com.example;

public class SomeSubClass extends SomeClass {
}

Compile with

$ javac -d target/classes/ src/com/example/SomeClass.java
$ javac -d target/classes/ -cp target/classes/ src/com/example/SomeSubClass.java

Now we have files

<project root>/target/classes/com/example/SomeClass.class
<project root>/target/classes/com/example/SomeSubClass.class

Let's see how Clojure handles those two classes. In file <project root>/src/com/example2/demo.clj

(ns demo)

;; javac-compiled SuperClass
(import com.example.SomeClass)

(com.example.SomeClass/aField) ;; 99
(com.example.SomeClass/aStaticMethod 123) ;; "aStaticMethod received 123"

;; javac-compiled SubClass
(import com.example.SomeSubClass)

(com.example.SomeSubClass/aField) ;; 99
(com.example.SomeSubClass/aStaticMethod 456) ;; "aStaticMethod received 456"

All fine and good: Clojure can resolve the superclass members aField and aStaticMethod by using the qualified name com.example.SomeSubClass.

Now, in file <project root>/src/com/example/ExtendSomeClass.clj, define another subclass --- ExtendSomeClass --- this time using Clojure's gen-class.

(ns com.example.ExtendSomeClass)

(gen-class
 :name com.example.ExtendSomeClass
 :extends com.example.SomeClass)

Back in file <project root>/src/com/example2/demo.clj, compile ExtendSomeClass by evaluating

(compile 'com.example.ExtendSomeClass)

which produces in directory <project root>/target/classes/com/example/ the following four files

ExtendSomeClass.class
ExtendSomeClass.class$fn__NNNN.class
ExtendSomeClass.class$loading__NNNN__auto__NNNN.class
ExtendSomeClass__init.class

I would expect the behavior of the gen-class-compiled ExtendSomeClass to be substantially the same as the javac-compiled SomeSubClass. However, I obtain an exception when I attempt to access the static members inherited from the superclass with the qualified classname.

Returning to file <project root>/src/com/example2/demo.clj

(import com.example.ExtendSomeClass)

(com.example.ExtendSomeClass/aField)
;; java.lang.RuntimeException
;; No such var: com.example.ExtendSomeClass/aField

(com.example.ExtendSomeClass/aStaticMethod 789)
;; java.lang.RuntimeException
;; No such var: com.example.ExtendSomeClass/aStaticMethod

Interestingly, using the unqualified classname works as expected.

(ExtendSomeClass/aField) ;; 99
(ExtendSomeClass/aStaticMethod 789) ;; "aStaticMethod received 789"

Q: How can I understand the difference in the behavior of a gen-class-compiled subclass and the javac-compiled subclass. Should I double-check how the classpaths align to the directory structure?

Appendix:
I disassembled the class files and observed the following:

Compiled from "SomeClass.java"
public class com.example.SomeClass ...

Compiled from "SomeSubClass.java"
public class com.example.SomeSubClass extends com.example.SomeClass ...

public class com.example.ExtendSomeClass extends com.example.SomeClass ...

(This last result is missing the "Compiled from ___.java" first line.)

And when I make a demonstration to see how the gen-class-compiled class works from java-land:

package com.example;

import com.example.ExtendSomeClass;

public class TestExtendSomeClass {

    public static void main(String[] args) {
	    System.out.println(com.example.ExtendSomeClass.aStaticMethod(123));
    }
}

I am able to access the superclass fields with the qualified class name.

$ java -cp target/classes/ com.example.TestExtendSomeClass 
aStaticMethod received 123

Replace core.async’s internal LinkedList queue with ArrayDeque?

Tue, 02 Sep 2025 08:02:18 +0000

Hi! While reading the channel implementation I noticed the internal queue is a java.util.LinkedList:
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj

The common JVM guidance these days is to prefer java.util.ArrayDeque for FIFO/LIFO queues due to better locality and lower GC overhead. For example, the JDK docs state: “This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.”
https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html
Related SO discussion: https://stackoverflow.com/questions/6163166/why-is-arraydeque-better-than-linkedlist

A few questions for the maintainers:

Was LinkedList originally chosen for a specific reason (e.g., very old JDK compatibility)?
Are there behaviors in channels that specifically rely on LinkedList (e.g., allowing null, I believe channels disallow nil anyway, or particular iterator characteristics), or would ArrayDeque be a drop-in replacement for the add/remove-from-ends operations used?
If we provide a small PR and benchmark showing an improvement (lower allocations / better throughput under contention), would such a change be considered?
Since ArrayDeque is available on Java 8+, and current Clojure/core.async baselines target that or newer, is there any remaining compatibility concern?

Context: there was an older conversation in Clojurians (#clojure) that suggested ArrayDeque could reduce GC pressure under load and that the original choice may have been influenced by older JDKs:
https://clojurians.slack.com/archives/C03S1KBA2/p1526551888000376

If this sounds reasonable, I’m happy to run the core.async test suite, add JMH-style benchmarks focused on channel put/take hot paths, and submit a PR.

Thanks!

CVE-warning in org.fressian/fressian <- org.clojure/data.fressian

Fri, 09 Jan 2026 12:45:21 +0000

Dependency Information
When running clj-watson in a project with

org.clojure/data.fressian {:mvn/version "1.1.1"}

I get the following warning, refering to CVE-2018-10054 (relates to a vulnerability in H2 and its usage in older versions of datomic). I assume this is a false positive.

NAME: org.fressian/fressian
VERSION: 0.6.8

DEPENDENCY FOUND IN:

[org.clojure/data.fressian]

FIX SUGGESTION:

Vulnerabilities

SEVERITY: HIGH
IDENTIFIERS: CVE-2018-10054
CVSS: 8.8 (version 3.1)
PATCHED VERSION: Information not available.

Improve javadoc especially for tool usage

Tue, 16 Sep 2025 17:54:13 +0000

In order to provide a hot key in VS Code to show the JavaDocs associated with a selected form (class name or the type of an expression), I wrote the following Joyride script:

https://github.com/seancorfield/vscode-calva-setup/blob/develop/joyride/scripts/javadoc.cljs#L15

This highlights three issues that could be addressed/improved:

On JDKs later than 15, the javadoc machinery falls back to JDK 8, unless you explicitly call add-remote-javadoc for at least java. and javax.. This is a known issue that should be addressed in Clojure 1.13 per https://clojure.atlassian.net/browse/CLJ-2920 -- hopefully it will assume the URL structure for JDKs going forward so we don't run into this problem again, unless Oracle changes their URL structure again (hopefully, unlikely).
javadoc-url is private so tools have to use #' to access it, which makes it feel like this is just an implementation detail and subject to change. It would be nice for tools if this was part of the public, documented API for clojure.java.javadoc.
Inner classes are not handled well. If you ask for the javadoc-url for java.util.Map$Entry, you get a URL with Map$Entry.html which doesn't exist. Since inner classes are documented in their outer class, removing $[a-zA-Z0-9_]+ from the class name or from the URL would really help here.

Here's an example REPL session for Clojure 1.12.2 on JDK 24, showing these issues:

user=> (clojure-version) "1.12.2" user=> (require 'clojure.java.javadoc) nil user=> (#'clojure.java.javadoc/javadoc-url "java.util.concurrent.ExecutionException") "http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutionException.html" user=> (#'clojure.java.javadoc/javadoc-url "java.util.Map$Entry") "http://docs.oracle.com/javase/8/docs/api/java/util/Map$Entry.html" user=>

Why do core.async timeouts rely on non-monotonic system clock?

Wed, 01 Nov 2023 16:26:33 +0000

clojure.core.async/timeout uses System/currentTimeMillis to calculate its deadline (see here and here). While the docstring for System/currentTimeMillis doesn't mention it explicitly, it's quite clearly unsuitable for this purpose because it returns the current time as reported by the OS. Since that time can change arbitrarily (e.g. by correction via NTP), the deadline calculations may end up inconsistent. This behavior is very much intended, see e.g. this ticket where it was suggested to switch System/currentTimeMillis over to a monotonic clock where possible. It was refused with the following comment:

System.currentTimeMillis() is required to return milliseconds since the epoch and should reflect external changes to the system/wall-clock time. CLOCK_MONOTONIC_COARSE does not provide that and so can not be used for this purpose.

Also, the docstring for java.util.concurrent.ScheduledExecutorService states this quite plainly:

All schedule methods accept relative delays and periods as arguments, not absolute times or dates. It is a simple matter to transform an absolute time represented as a Date to the required form. For example, to schedule at a certain future date, you can use: schedule(task, date.getTime() - System.currentTimeMillis(), TimeUnit.MILLISECONDS). Beware however that expiration of a relative delay need not coincide with the current Date at which the task is enabled due to network time synchronization protocols, clock drift, or other factors.

Since all we care about here is deltas, it seems advisable to switch to System/nanoTime instead. Unfortunately, its docstring also doesn't make its properties very obvious. It doesn't mention that it's a monotonic clock but only hints at it by stating:

Returns the current value of the running Java Virtual Machine's high-resolution time source, in nanoseconds. This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. [...] The values returned by this method become meaningful only when the difference between two such values, obtained within the same instance of a Java virtual machine, is computed.

A case in point for using it is OpenJDK's implementation of java.util.concurrent.ScheduledThreadPoolExecutor whose deadline calculation method does so, as well as its getDelay implementation.

Furthermore--if it's anything to go by--various StackOverflow posts also discuss this and arrive at the same conclusion, e.g. this one:

Nonetheless, nanoTime() should still be preferred for implementing timed blocking, interval waiting, timeouts, etc. to currentTimeMillis() because the latter is a subject to the "time going backward" phenomenon (e. g. due to server time correction), i. e. currentTimeMillis() is not suitable for measuring time intervals at all. See this answer for more information.

Porting clojure libraries w/ java interop to clojure-clr

Fri, 15 Aug 2025 01:31:53 +0000

I've been browsing around to understand the ecosystem.

I see some libraries are ported to use CLR interop, like core.logic, some are part way finished, like core.async.

Here is one maintainer's concerns, they would much like to point CLR users at a fork with CLR interop maintained by someone else:
https://github.com/weavejester/medley/pull/96
https://github.com/weavejester/medley/pull/65

For fun I examined how to use formal logic to do the code translation. Using Spec, and core.logic for code generation perhaps. I think it would require a lot of knowledge representation.

It might be easier, for these non-core/crucial libraries to use LLMs to do the code translation, and direct the outputs into a set of forks. Perhaps the core libraries used as training data on what to do. This author has some great insights and details on a plausible workflow(s) including with the utility of editor integration. He has done interop translation and work with clojure:
https://m.youtube.com/watch?v=oNhqqiKuUmw

As it is only the interop which requires translation (subsets of clojure files), with a skilled hand there might be better results than some of what he illustrates.

I looked around for a spec for the dotnet core API. I saw one they used to maintain but couldn't find a recent one. Though, all this LLM stuff is beyond me at this time. I thought to share some of my exploration.

EDIT: Found the dotnet API spec/reference for netstandard 2.1.0, I think someone wrote they since moved it into dotnet/runtime but I couldn't find it there, dunno if this helps: https://github.com/dotnet/standard/blob/v2.1.0/src/netstandard/ref/System.IO.cs

Support characters beyond basic multilingual plane

Tue, 02 Dec 2025 15:10:36 +0000

For now characters are defined as \uXXXX so it is not possible to encode character beyond BMP. Surrogate pairs is a common way to encode such characters but LispReader explicitly throws when it sees it - https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L1217-L1218

Double colon ("::") in the middle or at the end of identifier.

Thu, 27 Nov 2025 12:15:33 +0000

Right now double colon is allowed only when used as a start of not empty identifier prefix. I wonder is there some explanation why it is forbidden anywhere else?

I found original commit, where this was introduced.
https://github.com/clojure/clojure/commit/005ea1b5f96c5bb762e155032a865e29ad71bcf3

But commit message has no explanation why it allows only non-repeating colon

Skip stacktrace creation in ExceptionInfo

Thu, 17 Jul 2025 14:46:52 +0000

Many libraries and applications use exceptions as control flow or data collection, which allows for handling complex situations with more consistent and legible code. Some libraries use custom throwables (IGJoshua/farolero, NoahTheDuke/lazytest) and some use ExceptionInfos (scgilardi/slingshot, fmnoise/flow, pangloss/pure-conditioning, exoscale/ex).

One of the reasons that libraries reach for custom throwables is because they want to skip creation of a stack trace (which isn't used and would be thrown away immediately). Stack traces in Java are already fairly expensive to create, and then the filtering work done in ExceptionInfo greatly increases that expense, making them much slower than needed. (There's an Ask about this but I can't find it.) This performance cost pressures developers to use custom throwables if their code will ever be used in a "hot path", which harms portability and ease of development. (I want to write Clojure, not Java, and I want it to be usable in Clojurescript and Babashka and whatever other dialects might arise.)

I know that there's a rejected Jira ticket (CLJ-2423) for supporting the "enableSuppression" flag, but in light of these use-cases, I'd like to bring it up again.

javadoc-data-fn does not find selected method for inherited methods

Sat, 07 Feb 2026 19:55:52 +0000

Even though java.util.jar.JarEntry/.getName is a valid qualified method, the selected method docs aren't found.

> java.util.jar.JarEntry/.getName
 #function[...]

> (clojure.java.doc.api/javadoc-data-fn
   "java.util.jar.JarEntry/.getName"
   nil)
{:classname "java.util.jar.JarEntry",
 :class-description-html "<section ...",
 :class-description-md "All Implemented...",
 :methods
 [{:signature "getAttributes()",
   :description
   "Returns the Manifest Attributes for this entry, or null if none.",
   :static? false,
   :return-type "Attributes",
   :clojure-call "java.util.jar.JarEntry/.getAttributes"}
  ...],
 :selected-method []}

clojure.java.doc.api/javadoc-data-fn does not include constructor info

Fri, 06 Feb 2026 05:58:34 +0000

It would be helpful to include the constructor summary info from the javadoc. I tried querying the class as well as the /new method value.

(clojure.java.doc.api/javadoc-data-fn 
 "java.io.PushbackReader/new" nil)
(clojure.java.doc.api/javadoc-data-fn 
 "java.io.PushbackReader" nil)

I've integrated java.doc into my IDE and it's been very helpful. Thanks!

`pipeline-blocking` uses `thread` internally instead of `io-thread`

Wed, 29 Oct 2025 15:54:00 +0000

pipeline-blocking is explicitly meant for blocking operations (implying I/O). However, internally it uses thread rather than io-thread for processing: https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L637-L640.

Since 1.9.829-alpha2 this has practical implications, as only io-thread will utilize virtual threads, when available.

Can this be fixed / changed?
If not, can an explicit pipeline-io (or similar) function be added to support this use case?

Thanks

An undocumented breaking change in data.json

Thu, 23 Oct 2025 17:18:23 +0000

between the versions 1.1.0 and 2.0.0, data.json introduced a breaking change: The JSONWriter#-write signature changed from [object out] to [object out options]
On this commit:
https://github.com/clojure/data.json/commit/8f070ba94dc7c469f303259ce5f5bfa0b53d50bd
In release notes Release 2.0.0 on 2021-Mar-19 , there is no mention to JSONWriter or -write protocol changes.

I know it's a very old problem, but I think this documentation could be present.