Clojure Q&A - Recent questions in Contrib libs

Is the recent change to flow's futurize safe?

Tue, 17 Mar 2026 15:54:00 +0000

Previously flow's futurize would rethrow any exceptions thrown by the function when deref'ed. With the recent changes to return a CompletableFuture it no longer does that and instead if the function throws deref'ing will just hang forever.

tools.cli: capture unrecognized options as unparsed arguments

Fri, 06 Mar 2026 00:35:16 +0000

I frequently write a command that accepts options and in turn execute a shell command passing arguments through; I want to be able to specify additional arguments to that shell command.

In tools.cli, the :in-order key almost does what i want:

`
(require '[clojure.tools.cli :as cli])
=> nil
(def opts [["-d" "--debug"]])
=> #'net.lewisship.cli-tools-test/opts
(cli/parse-opts

["--foo"]
[]
:in-order true)

=> {:options {}, :arguments [], :summary "", :errors ["Unknown option: \"--foo\""]}
(cli/parse-opts

["xxx" "--foo"]
[]
:in-order true)

=> {:options {}, :arguments ["xxx" "--foo"], :summary "", :errors nil}
`

However, it will assume an undefined option is an error until the first non-option argument is consumed.

I would like a further option that is like :in-order but accepting of these unrecognized options. Maybe, :passthru-options would be a good name?

I can work on a patch if we have some consensus on direction.

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.

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!

`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.

Core Cache and Count

Wed, 28 Jan 2026 16:54:22 +0000

Hi,

I notice that in the wrapped namespace of core.cache, there is a has? function that checks the wrapped cache if it has an element or not. It does this by delegating to the underlying cache c/has? function of the wrapped cache.

For reporting purposes, I need to get the current size of the cache (with the caveat of course that the size could be approximate, given the particular nature of a particular cache - but approximation is fine).

Unfortuantely, a size or count function doesn't exist in the wrapped namespace, it only exists on the wrapped cache itself - thus doing:

(count @wrapped-cache)

does return the value.

It would be good, however, if there was also a similar function in the wrapped namespace, something like this (using size as the function name, but could be something else):

(defn size
   [cache-atom]
   (c/count @cache-atom)

The rationale being that having this function exposed in the wrapped namespace keeps the code consistent - i.e., whilst I can continue to do:

(count @wrapped-cache)

It would more preferrable to keep using the wrapped namespace (as I do with other operations, such as evict), i.e., something along the lines of:

(wrapped/size wrapped-cache)

Do you think this suggestion might be something that could be included in the wrapped namespace?

Thank you.

-=david=-

clojure.java.doc.api/javadoc-data-fn does not include return types for methods

Tue, 20 Jan 2026 22:26:31 +0000

Calling clojure.java.doc.api/javadoc-data-fn returns data about methods of a java class in the :methods and :selected-method entries. It does not include any directly accessible description of the return types for methods. The return type for a method can be found indirectly in the :method-description-html and :method-description-md entries of the :selected-methods (but not the :methods entries).

Example:

(def jdoc-data
  (clojure.java.doc.api/javadoc-data-fn "CharSequence/.charAt"
                                        nil))
  
(def my-method (-> jdoc-data :selected-method first))

> my-method
{:signature "charAt(int index)",
 :description "Returns the char value at the specified index.",
 :static? false,
 :clojure-call "^[int] CharSequence/.charAt",
 :method-description-html "<section class ...",
 :method-description-md "### charAt {#charAt(int)}\n\nchar charAt (int index)..."}

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

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".

`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

Can doc and jdoc be refactored to a common protocol while it's still early?

Tue, 28 Oct 2025 11:41:48 +0000

A fresh clojure library clojure.java.doc introduces some nice functions for querying javadoc.
It all seems nice and useful, I really can't complain (nor this is high priority to me since Javadoc is usually so verbose that I would probably continue to read it in the Web browser unless I discover use cases where REPL access is more practical to me).

However, one thing that struck my mind, and I had to ask is this: why introduce new functions, such as jdoc? Wouldn't it be more convenient to introduce a protocol (say, doc) which could then be extended to support
1. original Clojure doc
2. Javadoc
3. some sort of javascript doc, if that exists
4. C# doc
5. Native libraries doc, etc.

I understand that doc is a part of Clojure core, which you avoid changing at any costs, but this protocol wouldn't have to touch it.

It could simply be a "replacement" from the new namespace, which would have one implementation that invokes doc, but also be open to other implementations, such as jdoc.

And I understand that for Clojure core it's an absolute priority to not even change a formatting of the source code unless it's absolutely necessary, to keep very detailed compilation behavior or whatnot. It's a choice you made, it has its traidoffs, you chose those, and that's it. But, are those tradeoffs the same for namespaces such as clojure.repl and functions such as doc?

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.

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.

Allocation churn on generators

Tue, 07 Oct 2025 21:16:10 +0000

When generating moderately large values there is some LazySeq churn that could be avoided. For example, the following snippet allocates over 15GB (measured with async-profiler):

(core/let [g (vector (not-empty string-alphanumeric) 1000 5000)]
  (time
   (dotimes [seed 50]
     (dorun (generate g 100 seed)))))

The pattern of generating multiple (increasingly larger) values is common with quick-check (via deftest et al).

Many generators are built on top of choose, and there is an opportunity to reduce churn by special casing shrink-int for longs (which should be the common case compared to big ints).

I have a patch that decreases total allocations of the repro above by ~15% and speed up the run time by ~25% (measured on jdk 25, with -Xmx512m -XX:+UseSerialGC to decrease variance). Happy to share it.

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!

Typos in Flow guide

Mon, 18 Aug 2025 08:19:35 +0000

As reported by a Hacker News user, there are typos in the Flow Guide :

"excepiton" should be "exception"
"provded" should be "provided"

and also, it seems that in the transition section, "The description arity takes the current state ..." should be "The transition arity takes the current state ..."

tools.build compile-clj capture out/err

Mon, 28 Jul 2025 19:41:29 +0000

When calling compile-clj, a user can pass in :out and :err to capture the output of the compilation call. However, if for some reason the sub-process exits with a non-0, compile-clj throws without returning that output, making it hard to know what went wrong. (see here: https://github.com/clojure/tools.build/blob/2d2f1b05fd84c3cc756221c17fcfb98034b4d65c/src/main/clojure/clojure/tools/build/tasks/compile_clj.clj#L120)

I would find it helpful if the ex-data of the thrown exception included the :out (variable ps-out and :err (variable ps-err) from the process/process call. Then I could have further insight into what went wrong.

Is core.async.flow available in ClojureScript?

Thu, 17 Jul 2025 08:31:10 +0000

Hi,

I know it's early days for core.async.flow but I thought I would give it a try in one of my ClojureScript projects.

I've got {:mvn/version "1.9.808-alpha1"} in my deps.edn but I'm getting the following error when I try to access the namespace:

No such namespace: clojure.core.async.flow, could not locate clojure/core/async/flow.cljs

Thanks for your help.

tools.build fails with http_proxy/https_proxy set

Wed, 02 Jul 2025 11:56:53 +0000

The autopkgtest of the tools.build package fails with:

Running tests in #{"src/test/clojure"}

Testing clojure.tools.build.tasks.test-basis
Warning: failed to load the S3TransporterFactory class
Jul 01, 2025 8:15:38 AM org.apache.http.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo1.maven.org:443: Network is unreachable
[...]

The autopkgtest script debian/tests/source:

#!/bin/bash

set -ueo pipefail

cp=($(< debian/libtools-build-clojure.classpath))
test "${cp[0]}" = usr/share/java/tools.build.jar
unset cp[0] # drop it

test_cp=(src/main/clojure
         src/test/clojure
         /usr/share/java/test-runner.jar
         /usr/share/java/maven-resolver-named-locks.jar
         /usr/share/java/maven-repository-metadata-3.x.jar
         "${cp[@]}")

test_cp="$(IFS=:; echo "${test_cp[*]}")"

# Derived from ./deps.edn, and avoids a circular dep on clojure-cli
java -XX:-OmitStackTraceInFastThrow -cp "$test_cp" clojure.main \
     -m cognitect.test-runner cognitect.test-runner.api/test \
     --dir src/test/clojure --namespace-regex '.*'

The Ubuntu autopkgtest infrastructure restrict the Internet access and sets http_proxy/https_proxy.

Please support those proxy settings.

Bug-Ubuntu: https://launchpad.net/bugs/2115740

`create-basis` silently accepts missing aliases

Tue, 10 Jun 2025 00:57:37 +0000

In this scenario, the alias for create-basis was incorrect, preventing security deps overrides from being applied. For 2 years clojars was deployed with these vulnerable deps.

In this case, I proposed to inline the alias into :deps. However there may be other scenarios where a tools.deps change might be helpful to catch these mistakes earlier, for example a warning or error.

Dependency between options in Clojure/tools.cli ?

Tue, 27 May 2025 11:24:35 +0000

Hello, newbie user of tools.cli here.

I'm having a use case where I'd like to describe dependencies between options.
For example : if option -a is used, then options -f and -d are required too.

Looking at the documentation, it seems that the function option :in-order may allow that, but I haven't been able to figure how to use it. And haven't found any tutorial on that topic.

Anyone who could provide some pointers and/or example on how to express such dependencies (if that's possible).

Thank you!

what kind of systems could be made with clojure.async.flow?

Tue, 29 Apr 2025 15:48:35 +0000

Trying to capture mechanical essence of clojure.async.flow with basic terms instead of flow own terms i guess that clojure.async.flow allows to structure a system as a set of stateful functions running concurrently in the same jvm process and interacting with each other explicitly via channels.

what kind of systems could be made with clojure.async.flow?

it's definitely not naive service which handles API http requests, transforms it somehow and puts it into database.

tools.cli: Support default value for arg with value

Mon, 28 Apr 2025 17:21:53 +0000

I would like to have a --diff flag which defaults to origin/HEAD but allow pass a different rev in the arg, like --diff origin/bar.

Context: https://clojurians.slack.com/archives/C03S1KBA2/p1745859358672599

clojure.tools.reader.edn/read can cause incorrect column number for token at end of input

Sat, 01 Mar 2025 16:58:43 +0000

Context
A user reported that rewrite-clj column number metadata can be incorrect for a token at the end of input.

Rewrite-clj uses clojure.tools/reader to read clojure source.
It uses clojure.tools.reader.reader-types/get-column-number to discover the current column offset.

Affected
clojure.tools/reader v1.3.4 through v1.5.0
Clojure only (not ClojureScript)

Env
On Linux using Clojure CLI 1.12.0.1517 with JDK 23.0.2 (temurin)

Symptom
When the element at end of input is a token, after it is read, the column number is one less than it should be.

Setup
Let's setup a playground in foo.clj

(ns foo
  (:require [clojure.pprint :refer [pprint]]
            [clojure.tools.reader.edn :as edn]
            [clojure.tools.reader.reader-types :as rt]))

(defn reader [s]
  (-> s
      rt/string-push-back-reader
      rt/indexing-push-back-reader))

(defn dump-with-cols [s]
  (println "input string:" s)
  (println "colnums:     " (apply str (take (inc (count s)) (cycle [1 2 3 4 5 6 7 8 9 0])))))

(defn read-by-obj [s]
  (with-open [r (reader s)]
    (loop [acc [{:at :bof :col-number (rt/get-column-number r)}]
           obj (edn/read r false ::eof {})]
      (if (not= ::eof obj)
        (recur (conj acc {:after obj :col-number (rt/get-column-number r)})
               (edn/read r false ::eof {}))
        (conj acc {:at :eof :col-number (rt/get-column-number r)})))))

(let [s (first *command-line-args*)]
  (dump-with-cols s)
  (println "parse result:")
  (pprint (read-by-obj s)))

Reproduction
Using clojure.tools/reader v1.5.0:

$ clojure -Sdeps '{:deps {org.clojure/tools.reader {:mvn/version "1.5.0"}}}' \
        -M foo.clj ':bip :bop'
input string: :bip :bop
colnums:      1234567890
parse result:
[{:at :bof, :col-number 1}
 {:after :bip, :col-number 5}
 {:after :bop, :col-number 9}
 {:at :eof, :col-number 9}]

Notice after :bip we see the correct :col-number 5, but after :bop we see the incorrect :col-number 9; it should be :col-number 10.

An incorrect column number occurs for any unwrapped last token, a number:

$ clojure -Sdeps '{:deps {org.clojure/tools.reader {:mvn/version "1.5.0"}}}' \
        -M foo.clj 123
input string: 123
colnums:      1234
parse result:
[{:at :bof, :col-number 1}
 {:after 123, :col-number 3}
 {:at :eof, :col-number 3}]

a symbol:

$ clojure -Sdeps '{:deps {org.clojure/tools.reader {:mvn/version "1.5.0"}}}' \
        -M foo.clj x
input string: x
colnums:      12
parse result:
[{:at :bof, :col-number 1}
 {:after x, :col-number 1}
 {:at :eof, :col-number 1}]

But we get a correct result for syntax wrapped elements:

$ clojure -Sdeps '{:deps {org.clojure/tools.reader {:mvn/version "1.5.0"}}}' \
        -M foo.clj '(x)'
input string: (x)
colnums:      1234
parse result:
[{:at :bof, :col-number 1}
 {:after (x), :col-number 4}
 {:at :eof, :col-number 4}]

Diagnosis
If I dial clojure.tools/reader back to v1.3.3, I don't see the issue:

$ clojure -Sdeps '{:deps {org.clojure/tools.reader {:mvn/version "1.3.3"}}}' \
        -M foo.clj ':bip :bop'
input string: :bip :bop
colnums:      1234567890
parse result:
[{:at :bof, :col-number 1}
 {:after :bip, :col-number 5}
 {:after :bop, :col-number 10}
 {:at :eof, :col-number 10}]

And then bump one version to v1.3.4, I see the issue:

$ clojure -Sdeps '{:deps {org.clojure/tools.reader {:mvn/version "1.3.4"}}}' \
        -M foo.clj ':bip :bop'
input string: :bip :bop
colnums:      1234567890
parse result:
[{:at :bof, :col-number 1}
 {:after :bip, :col-number 5}
 {:after :bop, :col-number 9}
 {:at :eof, :col-number 9}]

There was only one significant change between v1.3.3 and v1.3.4.

Unreading the character at eof is causing the off-by-one issue.

If I change the existing:

  (loop [sb (StringBuilder.)
         ch initch]
    (if (or (whitespace? ch)
            (macro-terminating? ch)
            (nil? ch))
      (do (unread rdr ch)
          (str sb))
      (if (not-constituent? ch)
        (err/throw-bad-char rdr kind ch)
        (recur (doto sb (.append ch)) (read-char rdr))))))))

To:

  (loop [sb (StringBuilder.)
         ch initch]
    (cond
      (or (whitespace? ch)
          (macro-terminating? ch))
      (do (unread rdr ch)
          (str sb))

      (nil? ch)
      (str sb)

      (not-constituent? ch)
      (err/throw-bad-char rdr kind ch)

      :else
      (recur (doto sb (.append ch)) (read-char rdr)))))))

The problem is resolved for me.

Next Steps
Happy to contribute a patch if the above makes sense to you and you think it is worthwhile to fix.

core.async go block error with clojure 1.12 method values

Tue, 25 Feb 2025 19:17:23 +0000

I haven't seen this reported.

(Long/.toString 123) ;;works
(a/<!! (a/thread (Long/.toString 123))) ;;works
(a/go (Long/.toString 123)) ;;error

Note: The following stack trace applies to the reader or compiler, your code was not executed.

CompilerException Syntax error macroexpanding a/go at (1:1). {:clojure.error/phase :macro-syntax-check, :clojure.error/line 1, :clojure.error/column 1, :clojure.error/source "NO_SOURCE_PATH", :clojure.error/symbol a/go}
ExceptionInfo No matching method: .toString for class: class java.lang.Long and arity: 1 {:method .toString, :class java.lang.Long, :argc 1, :file "NO_SOURCE_PATH", :column 7, :line 1}
	clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:127)
	clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:87)
	clojure.tools.analyzer.passes.jvm.validate/eval4802/fn--4803 (validate.clj:137)
	clojure.lang.MultiFn.invoke (MultiFn.java:229)
	clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:265)
	clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:240)
	clojure.lang.Var.invoke (Var.java:386)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3429 (passes.clj:167)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.core/partial/fn--5929 (core.clj:2648)

Please consider making tools.build pom.properties reproducible (e.g. the "Generated by" date)

Sun, 16 Feb 2025 18:43:21 +0000

At the moment (in 1.2.24) the pom.properties includes the current date in a comment, making the resulting jars differ. For now, in Debian we're deferring to SOURCE_DATE_EPOCH whenever it's set: https://salsa.debian.org/clojure-team/tools-build-clojure/-/blob/5739183ec76c39453ff267c6ba19c0605eb406b7/debian/patches/0002-write-pom-make-pom.properties-generated-date-reproducible.patch

Auto-descending in clojure.data.zip doesn't seem to make a difference

Mon, 10 Feb 2025 11:05:44 +0000

Learning about zippers, I am trying to make sense of the difference between children and children-auto, as documented in the auto-generated docs, however, by reviewing the code and inspecting its history with git-log, it looks like the last reading of this meta property (possibly through the auto? function) was removed by this commit in 2016.

I think I will give up my trying to understand what "auto-descending by tag=" meant when it no longer matters. I would find it good to remove mentions of it from the documentation to save time to future learners like me, or at least clarify that the behaviour of tag= doesn't change with the choice of children v. children-auto.

What could change, anyway, if there is no code sensitive to this metadatum in the library? Is there another library that uses it, or is it targeted only at user code (remembered in a comment to the auto function), or is it just not useful anymore and should the metadatum (the :zip-filter/no-auto? key) be dropped and associated functions (including children-auto) with it?

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

clojure.java.data.builder fails with overloaded setter

Wed, 22 Jan 2025 20:27:39 +0000

Trying to run make-chat-model

(ns problem.problem
  (:require [clojure.java.data.builder :as builder])
  (:import (dev.langchain4j.model.openai OpenAiChatModel)
           (dev.langchain4j.model.openai OpenAiChatModel$OpenAiChatModelBuilder)))

(defn make-chat-model []
  (builder/to-java
    OpenAiChatModel 
    OpenAiChatModel$OpenAiChatModelBuilder
    (OpenAiChatModel/builder)
    {:baseUrl  "localhost"
     :apiKey (System/getenv "OPENAI_API_KEY")} {}))

fails with the following error

:#error {}
 :cause Duplicate setter found for :modelName in dev.langchain4j.model.openai.OpenAiChatModel$OpenAiChatModelBuilder class
 :via
 [{:type java.lang.IllegalArgumentException
   :message Duplicate setter found for :modelName in dev.langchain4j.model.openai.OpenAiChatModel$OpenAiChatModelBuilder class
   :at [clojure.java.data.builder$find_setters$fn__9041 invoke builder.clj 66]}]

The code is in the following repo: https://github.com/gavlooth/problem

tools.namespace remove-node does not remove outgoing dependencies from :dependents

Mon, 20 Jan 2025 02:32:44 +0000

Problem

I noticed that when a dependency, example.one, was removed from another namespace, example.two, example.one still showed up under [::track/deps :dependents 'example.two] in the tracker after an invocation of repl/scan.

After digging into this for some time, I saw that the implementation of remove-node in MapDependencyGraph didn't make any changes to the :dependents attribute.

This seems like a mistake to me, as the remove-node docstring reads:

Removes the node from the dependency graph without removing it as a
dependency of other nodes. That is, removes all outgoing edges from
node.

The implementation of remove-node follows:

(remove-node [graph node]
  (MapDependencyGraph.
    (dissoc dependencies node)
    dependents))

This removes outgoing edges from dependencies, but if dependents is effectively an inverse of dependencies, then I'd expect to see some sort of removal from dependents as well. Instead, dependents remains unmodified.

Proposed Fix

If this is indeed a bug, and not a misunderstanding on my part, I have a fix here along with a couple tests on my behavioral-tests branch that removes node from values in the dependents map.

Does this align with the expected behavior of remove-node, or am I misunderstanding the intended behavior of this function?

unable to use add-lib on io.github.borkdude/grasp

Fri, 17 Jan 2025 14:15:15 +0000

repro:

user=> (add-lib 'io.github.borkdude/grasp {:mvn/version "0.1.4"})
Execution error (ExceptionInfo) at clojure.tools.deps.interop/invoke-tool (interop.clj:81).
Could not find artifact org.clojure:clojure:jar:1.11.0-rc1

This seems strange to me. The deps edn of grasp: https://github.com/borkdude/grasp/blob/master/deps.edn

{:deps {org.babashka/sci {:mvn/version "0.3.2"}}
 :aliases {:native {:jvm-opts ["-Dclojure.compiler.direct-linking=true"]
                    :extra-deps {org.clojure/clojure {:mvn/version "1.10.2-alpha3"}
                                 org.clojure/tools.cli {:mvn/version "1.0.194"}}}
           :test {:extra-paths ["test"]
                  :extra-deps {org.clojure/clojure {:mvn/version "1.11.0-rc1"}
                               cognitect-labs/test-runner
                               {:git/url "https://github.com/cognitect-labs/test-runner"
                                :sha "cb96e80f6f3d3b307c59cbeb49bb0dcb3a2a780b"}}
                  :main-opts ["-m" "cognitect.test-runner"]}}}

It's surprising to me that deps in the :test alias would cause issues.

EDIT: seems to work now. Here's the stacktrace from a socket repl where i first encountered it

user=> (add-lib 'io.github.borkdude/grasp {:mvn/version "0.1.4"})
Execution error (ExceptionInfo) at clojure.tools.deps.interop/invoke-tool (interop.clj:81).
Could not find artifact org.clojure:clojure:jar:1.11.0-rc1
user=> nil
user=> (pst)
ExceptionInfo Could not find artifact org.clojure:clojure:jar:1.11.0-rc1 {:via [{:type clojure.lang.ExceptionInfo, :message "Could not find artifact org.clojure:clojure:jar:1.11.0-rc1", :data {:lib org.clojure/clojure, :coord {:mvn/version "1.11.0-rc1", :deps/manifest :mvn, :dependents [io.github.borkdude/grasp], :parents #{[io.github.borkdude/grasp]}}}, :at [clojure.tools.deps.extensions.maven$get_artifact invokeStatic "maven.clj" 167]}], :trace [[clojure.tools.deps.extensions.maven$get_artifact invokeStatic "maven.clj" 167] [clojure.tools.deps.extensions.maven$get_artifact invoke "maven.clj" 155] [clojure.tools.deps.extensions.maven$eval1225$fn__1228 invoke "maven.clj" 178] [clojure.lang.MultiFn invoke "MultiFn.java" 244] [clojure.tools.deps$download_libs$fn__802$fn__803 invoke "deps.clj" 466] [clojure.lang.AFn applyToHelper "AFn.java" 152] [clojure.lang.AFn applyTo "AFn.java" 144] [clojure.core$apply invokeStatic "core.clj" 667] [clojure.core$with_bindings_STAR_ invokeStatic "core.clj" 1990] [clojure.core$with_bindings_STAR_ doInvoke "core.clj" 1990] [clojure.lang.RestFn invoke "RestFn.java" 428] [clojure.lang.AFn applyToHelper "AFn.java" 156] [clojure.lang.RestFn applyTo "RestFn.java" 135] [clojure.core$apply invokeStatic "core.clj" 671] [clojure.core$bound_fn_STAR_$fn__5837 doInvoke "core.clj" 2020] [clojure.lang.RestFn invoke "RestFn.java" 400] [clojure.lang.AFn call "AFn.java" 18] [java.util.concurrent.FutureTask run "FutureTask.java" 317] [java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1144] [java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 642] [java.lang.Thread run "Thread.java" 1583]], :cause "Could not find artifact org.clojure:clojure:jar:1.11.0-rc1", :data {:lib org.clojure/clojure, :coord {:mvn/version "1.11.0-rc1", :deps/manifest :mvn, :dependents [io.github.borkdude/grasp], :parents #{[io.github.borkdude/grasp]}}}}
	clojure.tools.deps.interop/invoke-tool (interop.clj:81)
	clojure.tools.deps.interop/invoke-tool (interop.clj:41)
	clojure.repl.deps/add-libs (deps.clj:48)
	clojure.repl.deps/add-lib (deps.clj:59)
	clojure.repl.deps/add-lib (deps.clj:59)
	user/eval310956 (NO_SOURCE_FILE:320)
	user/eval310956 (NO_SOURCE_FILE:320)
	clojure.lang.Compiler.eval (Compiler.java:7700)
	clojure.lang.Compiler.eval (Compiler.java:7655)
	clojure.core/eval (core.clj:3232)
	clojure.core/eval (core.clj:3228)
	user/eval257807/fn--257810 (NO_SOURCE_FILE:8)

Incorrect docstring for parse-opts

Tue, 03 Dec 2024 16:02:27 +0000

In the docstring for clojure.tools.cli/parse-opts (seen here), it says,

:id           The key for this option in the resulting option map. This
              is normally set to the keywordized name of the long option
              without the leading dashes.

              Multiple option entries can share the same :id in order to
              transform a value in different ways, but only one of these
              option entries may contain a :default(-fn) entry.

              This option is mandatory.

The final line says "This option is mandatory." which is technically true for parse-opts' internals, but it's not true for users because (as the first paragraph says) :id is also generated by keywordizing the long option.

May I recommend changing it to be more explicit? Something like "If a long option is not provided, this option is mandatory."

Providing nil for long option in tools.cli does not seem to work per readme

Tue, 19 Nov 2024 22:03:50 +0000

Hi,

A very simplified tools.cli call:

(let [cli-opts [["-m" "--mode MODE" "Application mode"]]]
  (cli/parse-opts ["-m" "hub"] cli-opts))

Evaluates as expected to:

{:options {:mode "hub"} ... }

However, when I try to replace the long option with nil per the docs:

(let [cli-opts [["-m" nil "Application mode" :id :mode]]]
  (cli/parse-opts ["-m" "hub"] cli-opts))

I get:

{:options {:mode true} :arguments ["hub"] ... }

I get the same behaviour with long option = "", "--mode", and "MODE"; the only way it seems to work is with the full "--mode MODE". Setting the short option to nil works as I'd expect.

Tested in Clojure 1.12.0, tools.cli 1.1.230, Java 23; same behaviour on Windows 11 and MacOS 15.

Am I doing something wrong, or is tools.cli? :)

How can I ensure that a private Maven coordinate cannot be shadowed in a public repository?

Wed, 16 Oct 2024 11:08:07 +0000

Given a deps.edn file with a :mvn/repos entry for a private Maven repository and a dependency on a Maven coordinate that lives in that repository, how can I mitigate the risk of that coordinate getting shadowed / hijacked in one of the default public repositories?

Possible solutions:

Allow pinning a Maven dependency to a particular repository
Allow declaring priority order of Maven repositories (in the example scenario, the private repository would then get the highest priority and always be checked before the other ones)
Allow pinning a Maven dependency to a particular signing key and require it be signed (but looks like tools.deps currently doesn't support verifying signed artifacts?)

clojure.data.xml.event: EndElementEvent should provide tag and location-info

Thu, 10 Oct 2024 14:34:39 +0000

Additional information on the EndElementEvent would be very helpful, especially for processing large data in a streaming way.

I would be happy to propose a patch – I've already signed the Contributor Agreement

clojure.data.priority-map's IKVReduce implementation doesn’t support `reduced`

Sat, 28 Sep 2024 23:52:55 +0000

Hi folks!

Just a heads-up that clojure.data.priority-map’s IKVReduce implementation doesn’t support reduced.

The current implementation (v1.2.0, 2024-02-19):

clojure.core.protocols/IKVReduce
(kv-reduce [this f init]
  (if keyfn            
    (reduce-kv (fn [a k v] (reduce (fn [a v] (f a v (item->priority v))) a v))
      init priority->set-of-items)
    (reduce-kv (fn [a k v] (reduce (fn [a v] (f a v k)) a v))
      init priority->set-of-items)))

But the nested reduce means that something like this’d be needed:

(defn- convey-reduced [x] (if (reduced? x) (reduced x) x))

clojure.core.protocols/IKVReduce
(kv-reduce [this f init]
  (if keyfn            
    (reduce-kv (fn [a k v] (reduce (fn [a v] (convey-reduced (f a v (item->priority v))) a v)))
      init priority->set-of-items)
    (reduce-kv (fn [a k v] (reduce (fn [a v] (convey-reduced (f a v k)) a v)))
      init priority->set-of-items)))

Note that the issue affects only (reduce-kv a-priority-map …), not (reduce a-priority-map …).

Thanks, cheers! :-)

core.unify doesn't handle maps correctly

Sat, 28 Sep 2024 19:55:39 +0000

core.unify does a classic approach to unification: in garner-unifiers, it has a branch for sequential things, whereby it unifies the first elements of each sequence and then uses those bindings to unify the remaining bits:

https://github.com/clojure/core.unify/blob/master/src/main/clojure/clojure/core/unify.clj#L120

(every? composite? [x y]) (garner-unifiers uv-fn
                                           variable?
                                           (rest x) 
                                           (rest y)
                                           (garner-unifiers uv-fn
                                                            variable?
                                                            (first x)
                                                            (first y) 
                                                            binds))

Maps also take this path.

unify=> (composite? {})
true

The code then expects first and rest to get the sequence of the same keys (and unifiable values) from both maps. This is not necessarily true. It's broken when keys have the same hash in a hashmap and it's broken when keys are in a different order when in an arraymap

unify=> (let [kws #{:a :b :c :d :e :f :g :h :i :dCv :wxW}]
          (assert (= (hash :dCv) (hash :wxW)))
          [(garner-unifiers (zipmap kws (repeat '?a))
                            (zipmap kws (repeat 1)))
           (garner-unifiers (zipmap kws (repeat '?a))
                            (zipmap (reverse kws) (repeat 1)))])
[{?a 1} nil]
unify=> [(garner-unifiers {:a '?a :b '?b} {:a 1 :b 2})
         (garner-unifiers {:a '?a :b '?b} {:b 2 :a 1})]
[{?a 1, ?b 2} nil]

Fun thread in #clojure : https://clojurians.slack.com/archives/C03S1KBA2/p1727544444884499
And hat tip to p-himik who identified the minimal reproduction here.

core.unify run-tests.sh file has an error

Sat, 28 Sep 2024 14:20:35 +0000

Two issues:
- there is no artifact called 1.11.0-master-SNAPSHOT
- it uses -A to invoke with main-opts

❯ ./run-tests.sh

[valid output]
...
Error building classpath. Could not find artifact org.clojure:clojure:jar:1.11.0-master-SNAPSHOT in central (https://repo1.maven.org/maven2/)

real	0m1.932s
user	0m2.018s
sys	0m0.132s

and

WARNING: Use of :main-opts with -A is deprecated. Use -M instead.

Running tests in #{"src/test/clojure"}

Testing with Clojure 1.10.1

Testing clojure.core.unify-test

Ran 12 tests containing 51 assertions.
0 failures, 0 errors.

The following patch quickly fixes both

diff --git a/deps.edn b/deps.edn
index d87033c..4d96956 100644
--- a/deps.edn
+++ b/deps.edn
@@ -7,7 +7,8 @@
            :1.8 {:override-deps {org.clojure/clojure {:mvn/version "1.8.0"}}}
            :1.9 {:override-deps {org.clojure/clojure {:mvn/version "1.9.0"}}}
            :1.10 {:override-deps {org.clojure/clojure {:mvn/version "1.10.1"}}}
-           :master {:override-deps {org.clojure/clojure {:mvn/version "1.11.0-master-SNAPSHOT"}}}
+           :1.11 {:override-deps {org.clojure/clojure {:mvn/version "1.11.1"}}}
+           :1.12 {:override-deps {org.clojure/clojure {:mvn/version "1.12.0"}}}
            :runner
            {:extra-deps {com.cognitect/test-runner
                          {:git/url "https://github.com/cognitect-labs/test-runner"
diff --git a/run-tests.sh b/run-tests.sh
index d0674d4..198907a 100755
--- a/run-tests.sh
+++ b/run-tests.sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 
-versions="1.6 1.7 1.8 1.9 1.10 master"
+versions="1.6 1.7 1.8 1.9 1.10 1.11 1.12"
 for v in $versions
 do
-  time clj -A:test:runner:$v
+  time clj -M:test:runner:$v
 done

Accidental breaking change in data.json 2.5.0: previously, read succeeded, now it isn't

Wed, 25 Sep 2024 15:46:20 +0000

Here is a snippet of code that fails on data.json 2.5.0:

clj -Sdeps '{:deps {org.clojure/data.json {:mvn/version "2.5.0"}}}' -M -e '((requiring-resolve (quote clojure.data.json/read)) (clojure.lang.LineNumberingPushbackReader. (java.io.StringReader. "[\n  {\n    \"name\": \"position\",\n    \"type\": \"float32\",\n    \"count\": 3,\n    \"data\": [0,0,0]\n  },\n  {\n    \"name\": \"normal\",\n    \"type\": \"float32\",\n    \"count\": 3,\n    \"data\": [0,0,0]\n  },\n  {\n    \"name\": \"texcoord0\",\n    \"type\": \"float32\",\n    \"count\": 2,\n    \"data\": [0,0]\n  }\n]")))'

Execution error (IOException) at java.io.PushbackReader/unread (PushbackReader.java:166).
Pushback buffer overflow

The same code succeeds on 2.4.0:

clj -Sdeps '{:deps {org.clojure/data.json {:mvn/version "2.4.0"}}}' -M -e '((requiring-resolve (quote clojure.data.json/read)) (clojure.lang.LineNumberingPushbackReader. (java.io.StringReader. "[\n  {\n    \"name\": \"position\",\n    \"type\": \"float32\",\n    \"count\": 3,\n    \"data\": [0,0,0]\n  },\n  {\n    \"name\": \"normal\",\n    \"type\": \"float32\",\n    \"count\": 3,\n    \"data\": [0,0,0]\n  },\n  {\n    \"name\": \"texcoord0\",\n    \"type\": \"float32\",\n    \"count\": 2,\n    \"data\": [0,0]\n  }\n]")))'
[{"name" "position", "type" "float32", "count" 3, "data" [0 0 0]} {"name" "normal", "type" "float32", "count" 3, "data" [0 0 0]} {"name" "texcoord0", "type" "float32", "count" 2, "data" [0 0]}]

The gist of the problem: previously, Clojure's line numbering pushback reader could be used as an input to read. Now it can't: it throws an exception.

For reference, this is a json repro (a valid json!):

[
  {
    "name": "position",
    "type": "float32",
    "count": 3,
    "data": [0,0,0]
  },
  {
    "name": "normal",
    "type": "float32",
    "count": 3,
    "data": [0,0,0]
  },
  {
    "name": "texcoord0",
    "type": "float32",
    "count": 2,
    "data": [0,0]
  }
]

And, the formatted code: that uses the json:

(clojure.data.json/read 
  (clojure.lang.LineNumberingPushbackReader.
    (java.io.StringReader. "...")))

It seems the problem is introduced in https://clojure.atlassian.net/browse/DJSON-50

clj -X:deps find-versions prefers git deps if both git and mvn exist

Wed, 11 Sep 2024 20:16:33 +0000

Environment

clj --version
Clojure CLI version 1.12.0.1479

Source

A chat on Slack where we happened to notice the behaviour.

Scenario

When lib x is both a git dep and a maven dep,
clj -X:deps find-versions :lib x shows only versions from git deps.

Specific example: io.github.clojure/tools.build

As a git dep:

io.github.clojure/tools.build {:git/tag "v0.10.5" :git/sha "2a21b7a"}

As a Maven dep:

io.github.clojure/tools.build {:mvn/version "0.10.5"}

Reproduction

clj -X:deps find-versions :lib io.github.clojure/tools.build

Actual Behavior

Versions from git deps are listed:

{:git/tag "v0.9.4", :git/sha "76b78fe"}
{:git/tag "v0.9.5", :git/sha "24f2894"}
{:git/tag "v0.9.6", :git/sha "8e78bcc"}
{:git/tag "v0.10.0", :git/sha "3a2c484"}
{:git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:git/tag "v0.10.3", :git/sha "15ead66"}
{:git/tag "v0.10.4", :git/sha "31388ff"}
{:git/tag "v0.10.5", :git/sha "2a21b7a"}

Expected Behavior

TBD by Alex, but note that although maven deps exist, they are not listed.

A few ideas to poke at:

Idea One: populate this list with all available versions:

{:mvn/version "0.9.4" :git/tag "v0.9.4", :git/sha "76b78fe"}
{:mvn/version "0.9.5" :git/tag "v0.9.5", :git/sha "24f2894"}
{:mvn/version "0.9.6" :git/tag "v0.9.6", :git/sha "8e78bcc"}
{:mvn/version "0.10.0" :git/tag "v0.10.0", :git/sha "3a2c484"}
{:mvn/version "0.10.1" :git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:mvn/version "0.10.3" git/tag "v0.10.3", :git/sha "15ead66"}
{:mvn/version "0.10.4" :git/tag "v0.10.4", :git/sha "31388ff"}
{:mvn/version "0.10.5" :git/tag "v0.10.5", :git/sha "2a21b7a"}

But maybe that's a bit confusing for users copy/paste-wise.

Idea Two: list all available versions side by side:

{:mvn/version "0.9.4"} {:git/tag "v0.9.4", :git/sha "76b78fe"}
{:mvn/version "0.9.5"} {:git/tag "v0.9.5", :git/sha "24f2894"}
{:mvn/version "0.9.6"} {git/tag "v0.9.6", :git/sha "8e78bcc"}
{:mvn/version "0.10.0"} {:git/tag "v0.10.0", :git/sha "3a2c484"}
{:mvn/version "0.10.1"} {:git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:mvn/version "0.10.3"} {git/tag "v0.10.3", :git/sha "15ead66"}
{:mvn/version "0.10.4"} {:git/tag "v0.10.4", :git/sha "31388ff"}
{:mvn/version "0.10.5"} {:git/tag "v0.10.5", :git/sha "2a21b7a"}

Idea Three: list all available versions sequentially

{:mvn/version "0.9.4"} 
{:mvn/version "0.9.5"} 
{:mvn/version "0.9.6"} 
{:mvn/version "0.10.0"}
{:mvn/version "0.10.1"}
{:mvn/version "0.10.3"}
{:mvn/version "0.10.4"} 
{:mvn/version "0.10.5"} 
{:mvn/version "0.9.4" :git/tag "v0.9.4", :git/sha "76b78fe"}
{:mvn/version "0.9.5" :git/tag "v0.9.5", :git/sha "24f2894"}
{:mvn/version "0.9.6" :git/tag "v0.9.6", :git/sha "8e78bcc"}
{:mvn/version "0.10.0" :git/tag "v0.10.0", :git/sha "3a2c484"}
{:mvn/version "0.10.1" :git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:mvn/version "0.10.3" git/tag "v0.10.3", :git/sha "15ead66"}
{:mvn/version "0.10.4" :git/tag "v0.10.4", :git/sha "31388ff"}
{:mvn/version "0.10.5" :git/tag "v0.10.5", :git/sha "2a21b7a"}

The cljs docstring of `clojure.core.async/promise-chan` does not mention that it returns the value repeatedly

Tue, 27 Aug 2024 16:28:38 +0000

Question in slack about why a promise chan "returns the result of the promise every time you call".

The docstring in clj includes the phrase

Consumers will block until either a value is placed in the channel or the
channel is closed, then return the value (or nil) forever.

This is missing from the clojurescript version of the docstring:

Creates a promise channel with an optional transducer, and an optional
exception-handler. A promise channel can take exactly one value that consumers
will receive. Once full, puts complete but val is dropped (no transfer).
Consumers will block until either a value is placed in the channel or the
channel is closed. See chan for the semantics of xform and ex-handler.

source

tools.reader parse-symbol is too sloppy when reading new n-dimensional class array

Tue, 20 Aug 2024 19:17:17 +0000

Tools.reader accepts this symbol: MyClazz:/3 while it does not accept the symbol MyClass:. This seems inconsistent. That's the main subject of this "ask".

Incidentally I noticed that this commit https://github.com/clojure/tools.reader/commit/31adc06cd56753ed5a3cd443cea32158ba68c45c#diff-11ba7fe0994caede16eeb1c6ed52fc3aba112849ce1fd23dff0b9fb72441a09fR111 uses a regex + re-matches to check if the string sym is a 1-sized numeric string. I noticed that this causes a slight performance regression compared to version 1.4.2. I think the check can be implemented using a somewhat more elaborate but more performant check:

check if the string is of size 1
only then check if that string represents a number between 1 and 9

E.g. this version seems to be roughly 6x faster than the re-matches approach:

user=> (defn array-dim? [^String s] (and (= 1 (.length s)) (some-> (try (Integer/parseInt s) (catch Exception e nil)) pos?)))
#'user/array-dim?
user=> (time (dotimes [i 10000000] (array-dim? "1")))
"Elapsed time: 45.287416 msecs"

user=> (defn array-dim2? [^String s] (re-matches #"[1-9]" s))
#'user/array-dim2?
user=> (time (dotimes [i 10000000] (array-dim2? "1")))
"Elapsed time: 304.30275 msecs"
nil

Note how clojure's own reader implemented it:

https://github.com/clojure/clojure/commit/1fa5b038a434da34f787e3aec56f9cb48ed4dd99#diff-9216bc4fd055e0567fa034ec14a8ba470d36ba5be16418c8f2e2ebe1939bbb21R259

data.json :date-formatter does not support all the formats Cheshire :date-format does due to using Instant internally

Fri, 09 Aug 2024 20:42:44 +0000

See Slack discussion here for the full background: https://clojurians.slack.com/archives/C03S1KBA2/p1723222018579489

Problem statement:

I have a :date-format of "MMMM, dd yyyy HH:mm:ss Z" that I use with Cheshire to turn various types of date/time values into JSON. In particular, java.sql.Timestamp but also others. This works.

I wanted to switch to data.json so I provided :date-formatter with (DateTimeFormatter/ofPattern "MMMM, dd yyyy HH:mm:ss Z") but it threw an exception because data.json internally coerces date/time values to java.time.Instant which doesn't support that pattern.

Several possible solutions I considered:

force users to manually convert those types themselves (avoiding that was the whole point of DJSON-41) -- this is essentially "do nothing"
provide an option to pre-transform Instant to some other type prior to formatting (which gives the user control over zones/offsets etc)
make existing :date-formatter option "smarter" so it can accept a DateTimeFormatter or a user-supplied Instant formatting function
change from Instant to some other date/time type internally in a way that is compatible with any formatting that Instant already supports to allow for more variety of DateTimeFormatter patterns
...

I worked around it by using :value-fn but this means a runtime test on every value and manual conversion of date/time values to strings in user code...

1 goes against the whole point of adding date/time formatting support
2 and 3 both add a small runtime overhead (3 would probably be my preference tho')
4 might be tricky to completely support all existing formatting (I don't know) but might be the most seamless "Cheshire compatibility" path

How to suppress/capture the output of defspec for use in clojure.test?

Tue, 06 Aug 2024 20:41:33 +0000

I've been a fan of test.check since the beginning. However, I've never found a convenient way to capture the output when using defspec. When used with clojure.test, one gets output that looks like:

Testing tst.tupelo.y64 {:result true, :num-tests 999, :seed 1722976402694, :time-elapsed-ms 53, :test-var "dospec-line-53"} {:result true, :num-tests 999, :seed 1722976402747, :time-elapsed-ms 36, :test-var "dospec-line-44"}

somewhat polluting the unit test output. How can one capture and/or suppress this output?

Is the clojure.cache behavior for lookup-or-miss value-fn re-entrancy broken or am I misunderstanding the docstring?

Mon, 05 Aug 2024 17:56:40 +0000

I’m trying to reconcile clojure.cache behavior between what the docstring/code both suggest, and what I observe actually happening. I am referring to this line:

https://github.com/clojure/core.cache/blob/99fbd669a429bc800ff32b64b21cf82b6b486f06/src/main/clojure/clojure/core/cache/wrapped.clj#L43

value-fn (and wrap-fn) will only be called (at most) once even in the
case of retries, so there is no risk of cache stampede.

It seems quite trivial to get the value-fn to be called more than once when the cache is under contention. I’ve emulated this behavior in the repl, as follows:

(require '[clojure.core.cache.wrapped :as cache])
=> nil
(def c (cache/fifo-cache-factory {}))
=> #'user/c
(pmap (fn [_] (cache/lookup-or-miss c :foo (fn [k] (println "miss") k))) (range 10))
miss
miss
miss
miss
miss
miss
miss
miss
=> (:foo :foo :foo :foo :foo :foo :foo :foo :foo :foo)

In this case, the miss function was invoked 8 out of 10 times when threads were competing. I see this same behavior in the real world, too.

What I don't fully understand is why when the swap! protects the call to c/through-cache. I'm guessing it has to do with how swap resolves conflicts. But if so, doesn't that mean the docstring is wrong?

This is reproducible for me in both fifo and ttl caches. I haven't tried the others.

Fressian API Documentation

Fri, 12 Jul 2024 10:25:32 +0000

Hi,

I wanted to link to the API documentation of https://github.com/clojure/data.fressian, but it seems to be down. The README links to the following Github Page: https://clojure.github.com/data.fressian which returns a 404.

Can this be fixed?

Thanks, Roman.

Support Clojure 1.12-alpha12 Array class notation

Thu, 23 May 2024 19:02:29 +0000

Currently, the function clojure.tools.reader.impl.commons/parse-symbol is fairly lax with what it allows, both in general and with regard to the forthcoming Clojure 1.12 Array class notation.

user=> (mapv trc/parse-symbol ["String/1" "String/-1" "String/11" "String/1a"])
[nil ["String" "-1"] nil nil]

This is different than the current implementation, which only accepts the first. Is there any interest in updating it to be stricter for the new notation?

Can someone `refer-clojure :exlude [abs]` in algo.generic

Mon, 06 May 2024 23:04:37 +0000

Simple request. https://github.com/clojure/algo.generic/blob/master/src/main/clojure/clojure/algo/generic/math_functions.clj#L23 provides for an abs function and so any usage of this library has a warning:

WARNING: abs already refers to: #'clojure.core/abs in namespace: clojure.algo.generic.math-functions, being replaced by: #'clojure.algo.generic.math-functions/abs

Happy to make a jira issue, or patch, or whatever is easiest to help this along.

Repro:

❯ clj -Sdeps '{:deps {org.clojure/algo.generic {:mvn/version "LATEST"}}}'
Clojure 1.11.2
user=> (require 'clojure.algo.generic.math-functions)
WARNING: abs already refers to: #'clojure.core/abs in namespace: clojure.algo.generic.math-functions, being replaced by: #'clojure.algo.generic.math-functions/abs
nil
user=>

How to ignore :src-pom default for clojure.tools.build.api/write-pom if ./pom.xml exists?

Sun, 31 Mar 2024 20:50:22 +0000

I have a project that generates more than one jar artifact. For project A, I have ./pom.xml that is used as a template and everything works fine.

For project B, I want to generate a pom.xml that's completely separate from project A which does not use ./pom.xml as a template. I generate the pom as follows:

(require '[clojure.tools.build.api :as b])
(b/write-pom {:class-dir class-dir
                  :pom-data pom-data
                  :lib coord
                  :version version
                  :basis basis})

However, since ./pom.xml exists, it is used as a template. Explicitly passing nil for :src-pom doesn't help. The only workaround I could find was to pass in a bogus path for :src-pom.