Clojure Q&A - Recent questions tagged problem

linux installer fails for non english locale

Thu, 14 May 2026 20:48:19 +0000

"OK" returned by sha256sum may be translated. Better rely on the exit status. Since -p pipefail is used, the pipe to grep could be simply omitted.

Installing Clojure on IPv6-only machine

Fri, 24 Apr 2026 23:21:53 +0000

Since GitHub (still) do not support IPv6 it is not possible to follow the instructions at https://clojure.org/guides/install_clojure (for Linux, say) to install the Clojure CLI on a machine running ONLY IPv6 (in this case Hertzner).

When downloading the .tar.gz-file manally and uploading it directly, installing the CLI tools is possilbe.

The problems seem to continue installing common clojure dependencies, like data.json 2.5.2, which leads to this:

clj -X:server
Error building classpath. Failed to read artifact descriptor for org.clojure:data.json:jar:2.5.2
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.clojure:data.json:jar:2.5.2
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:255)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:263)
	at clojure.tools.deps.extensions.maven$read_descriptor.invokeStatic(maven.clj:115)
	at clojure.tools.deps.extensions.maven$fn__1340.invokeStatic(maven.clj:143)
	at clojure.tools.deps.extensions.maven$fn__1340.invoke(maven.clj:143)
	at clojure.lang.MultiFn.invoke(MultiFn.java:244)
	at clojure.tools.deps$expand_deps$children_task__959$fn__961$fn__962.invoke(deps.clj:299)
    ...
Caused by: java.net.SocketException: Network is unreachable
at java.base/sun.nio.ch.Net.connect0(Native Method)
at java.base/sun.nio.ch.Net.connect(Net.java:546)
at java.base/sun.nio.ch.Net.connect(Net.java:535)
at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:585)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.jar

All this seem a bit bisarre of course. Workarounds would make me happy!

false positive warning: "cljs.core/+, all arguments must be numbers"

Tue, 06 Jan 2026 16:51:22 +0000

The inc function below will never receive a nil, but falsely warns that it might:

clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.12.134"}}}' -M -m cljs.main -re node
ClojureScript 1.12.134

cljs.user=> (some-> 1 (#(when (pos? %) %)) inc)
WARNING: cljs.core/+, all arguments must be numbers, got [#{nil clj-nil} number] instead at line 1 <cljs repl>
2

Why does the REPL incorrectly display my command after I press enter?

Mon, 22 Dec 2025 15:01:06 +0000

Hello,

I'm having a small bug with the Clojure REPL - when I enter a command, after pressing the enter key, the command gets displayed incorrectly - basically the beginning of the text of the command that I entered is displayed for the first few characters, and then everything after that is overwritten with the same text of the command displayed with an indentation.

Not sure if that's very clear, so I've added a pair of screenshots, "before and after", to illustrate.

This issue seems similar to this older question, although in that case the issue was with the rlwrap library, which was patched afterwards.

Is there a way to fix this?

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

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

bug bigdec

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

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

Inconsistent errors in ratio parsing with either `clojure.edn/read` or `clojure.core/read`

Sat, 22 Nov 2025 17:12:47 +0000

user=> (clojure.edn/read-string "777/2") ;; no surprises
777/2
user=> (clojure.edn/read-string "0777/2") ;; wait, 0777 supposed to be 511
777/2
user=> (clojure.edn/read-string "0x777/2") ;; hexadecimal suddenly throws
Execution error (NumberFormatException) at user/eval175 (REPL:1).
Invalid number: 0x777/2
user=> (clojure.edn/read-string "32r777/2") ;; radix throws as well
Execution error (NumberFormatException) at user/eval177 (REPL:1).
Invalid number: 32r777/2
user=> (clojure.edn/read-string "777N/2") ;; same for BigInt
Execution error (NumberFormatException) at user/eval181 (REPL:1).
Invalid number: 777N/2

Inconsistent part here is octal integer numerator form. I would expect it to fail the same way as the rest of this list but not to silently drop leading zero and turn to not octal form at all.

Second part of the question is: Why other forms throws at all?

Docstring clojure.edn/read-string is misleading

Thu, 20 Nov 2025 15:10:38 +0000

user=> (doc clojure.edn/read-string)
-------------------------
clojure.edn/read-string
([s] [opts s])
Reads one object from the string s. Returns nil when s is nil or empty.
Reads data in the edn format (subset of Clojure data):
http://edn-format.org

opts is a map as per clojure.edn/read

Note Returns nil when s is nil or empty.. But when called with opts without explicit :eof it throws EOF error

user=> (clojure.edn/read-string {} "")
Execution error at user/eval222 (REPL:1).
EOF while reading

And without options it returns nil as expected

user=> (clojure.edn/read-string "")
nil

clojure.edn/read invoke user-supplied reader functions when tagged literal is to be discarded by discard macro

Thu, 20 Nov 2025 14:57:19 +0000

According to edn-format/edn specification

A reader should not call user-supplied tag handlers during the processing of the element to be discarded.

But with clojure.edn/read and its derivatives execute provided reader functions under discard tag:

user=> (clojure.edn/read-string {:readers {'foo (fn [val] (prn "!!!") val)}} "#_ #foo [1 2 3]")
"!!!"
Execution error at user/eval216 (REPL:1).
EOF while reading

The same happen with clojure.core/read and its derivatives:

user=> (binding [*data-readers* {'foo (fn [val] (prn "!!!") val)}] (read-string "#_ #foo [1 2 3]"))
"!!!"
Execution error at user/eval146 (REPL:1).
EOF while reading

I understand that Clojure' reader does not provide explicit description of what is executed during reading out form to be discarded except "The form following #_ is completely skipped by the reader." but I think it is worth to mention that here.

After realisation that this post is not qualifies as "ask"

To summarize:
Is this a bug in clojure edn specification implementation?
Is the edn specification no longer accurate?

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

Typo in clojure.zipper/zipper docstring

Mon, 27 Oct 2025 09:30:17 +0000

The docstring for clojure.zipper/zipper currently contains:

branch? is a fn that, given a node, returns true if can have
children, even if it currently doesn't.

which should be:

branch? is a fn that, given a node, returns true if it can have
children, even if it currently doesn't.

Does cljr -Sdeps work for other people?

Mon, 01 Sep 2025 23:26:42 +0000

Putting the dependencies in a deps-clr.edn file works.

But not via cljr -Sdeps. E.g.: try to launch nREPL server:
$ cljr -Sdeps '{:deps {io.github.clojure/clr.tools.nrepl {:git/tag "v0.1.2-alpha2"}}}' -X clojure.tools.nrepl/start-server! Clojure core loaded in 4177 milliseconds. Starting exec/tool Clojure core loaded in 4207 milliseconds. Namespace could not be loaded: clojure.tools.nrepl

I did custom compile some things so wondering if it's just me. The README for clr.core.cli says -Sdeps is supported.

I can malform the string and seems to throw no errors, I don't think it's being processed.

Well I'll poke around and report back what I find meanwhile.

Method with int parameter is called, although the provided parameter is long

Sat, 05 Jul 2025 21:13:00 +0000

AIMesh provides several overloaded create methods. There is one with an int parameter and another one with a long parameter. They have very different semantics.

This code snippet intends to call the one with the long parameter:

(defn read-model
  "read a 3D model from a file"
  [path]
  (let [scene (Assimp/aiImportFile path (bit-or Assimp/aiProcess_Triangulate
                                                Assimp/aiProcess_FlipUVs))]
    (if (= scene nil)
      (println (Assimp/aiGetErrorString))
      (for [index (range (.mNumMeshes scene))]
        (let [pointer (.get (.mMeshes scene) index)]
          (assert (= (type pointer) java.lang.Long))
          (AIMesh/create pointer))))))

The assertion right before the problematic call makes sure that pointer is indeed a long; but nevertheless the int overload of create is called, as can be verified in the stack trace:

{:clojure.main/message
 "Execution error (IllegalArgumentException) at java.nio.Buffer/createCapacityException (Buffer.java:290).\ncapacity < 0: (-689151616 < 0)\n",
 :clojure.main/triage
 {:clojure.error/class java.lang.IllegalArgumentException,
  :clojure.error/line 290,
  :clojure.error/cause "capacity < 0: (-689151616 < 0)",
  :clojure.error/symbol java.nio.Buffer/createCapacityException,
  :clojure.error/source "Buffer.java",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type clojure.lang.Compiler$CompilerException,
    :message
    "Syntax error macroexpanding at (learnopengl/core.clj:12:1).",
    :data
    {:clojure.error/phase :execution,
     :clojure.error/line 12,
     :clojure.error/column 1,
     :clojure.error/source "learnopengl/core.clj"},
    :at [clojure.lang.Compiler load "Compiler.java" 7665]}
   {:type java.lang.IllegalArgumentException,
    :message "capacity < 0: (-689151616 < 0)",
    :at [java.nio.Buffer createCapacityException "Buffer.java" 290]}],
  :trace
  [[java.nio.Buffer createCapacityException "Buffer.java" 290]
   [java.nio.Buffer <init> "Buffer.java" 253]
   [java.nio.ByteBuffer <init> "ByteBuffer.java" 316]
   [java.nio.ByteBuffer <init> "ByteBuffer.java" 324]
   [java.nio.MappedByteBuffer <init> "MappedByteBuffer.java" 113]
   [java.nio.DirectByteBuffer <init> "DirectByteBuffer.java" 107]
   [java.nio.ByteBuffer allocateDirect "ByteBuffer.java" 360]
   [org.lwjgl.system.Struct __create "Struct.java" 118]
   [org.lwjgl.assimp.AIMesh create "AIMesh.java" 487]
   [jdk.internal.reflect.DirectMethodHandleAccessor
    invoke
    "DirectMethodHandleAccessor.java"
    103]
   [java.lang.reflect.Method invoke "Method.java" 580]
   [clojure.lang.Reflector invokeMatchingMethod "Reflector.java" 167]
   [clojure.lang.Reflector invokeStaticMethod "Reflector.java" 332]
   [learnopengl.mesh_model$read_model$iter__332__336$fn__337$fn__338
    invoke
    "mesh_model.clj"
    66]
   [learnopengl.mesh_model$read_model$iter__332__336$fn__337
    invoke
    "mesh_model.clj"
    63]
   [clojure.lang.LazySeq sval "LazySeq.java" 42]
   [clojure.lang.LazySeq seq "LazySeq.java" 51]
   [clojure.lang.RT seq "RT.java" 535]
   [clojure.lang.RT countFrom "RT.java" 650]
   [clojure.lang.RT count "RT.java" 643]
   [learnopengl.core$eval351 invokeStatic "core.clj" 12]
   [learnopengl.core$eval351 invoke "core.clj" 12]
   [clojure.lang.Compiler eval "Compiler.java" 7194]
   [clojure.lang.Compiler load "Compiler.java" 7653]
   [clojure.lang.RT loadResourceScript "RT.java" 381]
   [clojure.lang.RT loadResourceScript "RT.java" 372]
   [clojure.lang.RT load "RT.java" 459]
   [clojure.lang.RT load "RT.java" 424]
   [clojure.core$load$fn__6908 invoke "core.clj" 6161]
   [clojure.core$load invokeStatic "core.clj" 6160]
   [clojure.core$load doInvoke "core.clj" 6144]
   [clojure.lang.RestFn invoke "RestFn.java" 408]
   [clojure.core$load_one invokeStatic "core.clj" 5933]
   [clojure.core$load_one invoke "core.clj" 5928]
   [clojure.core$load_lib$fn__6850 invoke "core.clj" 5975]
   [clojure.core$load_lib invokeStatic "core.clj" 5974]
   [clojure.core$load_lib doInvoke "core.clj" 5953]
   [clojure.lang.RestFn applyTo "RestFn.java" 142]
   [clojure.core$apply invokeStatic "core.clj" 669]
   [clojure.core$load_libs invokeStatic "core.clj" 6016]
   [clojure.core$load_libs doInvoke "core.clj" 6000]
   [clojure.lang.RestFn applyTo "RestFn.java" 137]
   [clojure.core$apply invokeStatic "core.clj" 669]
   [clojure.core$require invokeStatic "core.clj" 6038]
   [clojure.core$require doInvoke "core.clj" 6038]
   [clojure.lang.RestFn invoke "RestFn.java" 408]
   [user$eval140$fn__144 invoke "form-init15974239925031016013.clj" 1]
   [user$eval140 invokeStatic "form-init15974239925031016013.clj" 1]
   [user$eval140 invoke "form-init15974239925031016013.clj" 1]
   [clojure.lang.Compiler eval "Compiler.java" 7194]
   [clojure.lang.Compiler eval "Compiler.java" 7184]
   [clojure.lang.Compiler load "Compiler.java" 7653]
   [clojure.lang.Compiler loadFile "Compiler.java" 7591]
   [clojure.main$load_script invokeStatic "main.clj" 475]
   [clojure.main$init_opt invokeStatic "main.clj" 477]
   [clojure.main$init_opt invoke "main.clj" 477]
   [clojure.main$initialize invokeStatic "main.clj" 508]
   [clojure.main$null_opt invokeStatic "main.clj" 542]
   [clojure.main$null_opt invoke "main.clj" 539]
   [clojure.main$main invokeStatic "main.clj" 664]
   [clojure.main$main doInvoke "main.clj" 616]
   [clojure.lang.RestFn applyTo "RestFn.java" 137]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.main main "main.java" 40]],
  :cause "capacity < 0: (-689151616 < 0)",
  :phase :execution}}

This repository contains the full code to reproduce the error. read-model is defined in mesh-model.clj.

I ran this with Clojure version 1.11.1 and Java version:

openjdk 21.0.7 2025-04-15
OpenJDK Runtime Environment (Red_Hat-21.0.7.0.6-2) (build 21.0.7+6)
OpenJDK 64-Bit Server VM (Red_Hat-21.0.7.0.6-2) (build 21.0.7+6, mixed mode, sharing)

There was a previous question on stackoverflow leading to this question.

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

Why does a qualified instance method call fails at compile time with NullPointerException if missing target

Mon, 30 Jun 2025 13:33:36 +0000

Has anyone else noticed a lot of Syntax error (NullPointerException) when using the new Class/.instanceMethod syntax? Specifically whenever I forget the first argument like

(fn [] (String/.length))

gets

#error{:cause "Cannot invoke \"clojure.lang.Compiler$Expr.emit(clojure.lang.Compiler$C, clojure.lang.Compiler$ObjExpr, clojure.asm.commons.GeneratorAdapter)\" because \"this.target\" is null",
       :via [{:type clojure.lang.Compiler$CompilerException,
              :message "Syntax error compiling fn* at (/private/var/folders/cr/wpw7hgnx0jj9m33g28rtbpzc0000gn/T/form-init4871175438924650637.clj:1:1).",
              :data #:clojure.error{:phase :compile-syntax-check,
                                    :line 1,
                                    :column 1,
                                    :source "/private/var/folders/cr/wpw7hgnx0jj9m33g28rtbpzc0000gn/T/form-init4871175438924650637.clj",
                                    :symbol fn*},
              :at [clojure.lang.Compiler analyzeSeq "Compiler.java" 7677]}
             {:type java.lang.NullPointerException,
              :message "Cannot invoke \"clojure.lang.Compiler$Expr.emit(clojure.lang.Compiler$C, clojure.lang.Compiler$ObjExpr, clojure.asm.commons.GeneratorAdapter)\" because \"this.target\" is null",
              :at [clojure.lang.Compiler$InstanceMethodExpr emit "Compiler.java" 2060]}],
       :trace [[clojure.lang.Compiler$InstanceMethodExpr emit "Compiler.java" 2060]
               [clojure.lang.Compiler$BodyExpr emit "Compiler.java" 6723]
               [clojure.lang.Compiler$FnMethod doEmit "Compiler.java" 6243]
               [clojure.lang.Compiler$FnMethod emit "Compiler.java" 6045]
               [clojure.lang.Compiler$FnExpr emitMethods "Compiler.java" 4500]
               [clojure.lang.Compiler$ObjExpr compile "Compiler.java" 5136]
               [clojure.lang.Compiler$FnExpr parse "Compiler.java" 4662]
               [clojure.lang.Compiler analyzeSeq "Compiler.java" 7667]
               [clojure.lang.Compiler analyze "Compiler.java" 7360]
               [clojure.lang.Compiler analyze "Compiler.java" 7316]
               [clojure.lang.Compiler$BodyExpr$Parser parse "Compiler.java" 6683]
               [clojure.lang.Compiler$FnMethod parse "Compiler.java" 6022]
               [clojure.lang.Compiler$FnExpr parse "Compiler.java" 4585]
               [clojure.lang.Compiler analyzeSeq "Compiler.java" 7667]
               [clojure.lang.Compiler analyze "Compiler.java" 7360]
               [clojure.lang.Compiler eval "Compiler.java" 7736]
               [clojure.lang.Compiler eval "Compiler.java" 7694]
               [clojure.core$eval invokeStatic "core.clj" 3232]
               [clojure.core$eval invoke "core.clj" 3228]
               [nrepl.middleware.interruptible_eval$evaluate$fn__966$fn__967 invoke "interruptible_eval.clj" 87]
               [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]
               [nrepl.middleware.interruptible_eval$evaluate$fn__966 invoke "interruptible_eval.clj" 87]
               [clojure.main$repl$read_eval_print__9248$fn__9251 invoke "main.clj" 437]
               [clojure.main$repl$read_eval_print__9248 invoke "main.clj" 437]
               [clojure.main$repl$fn__9257 invoke "main.clj" 459]
               [clojure.main$repl invokeStatic "main.clj" 459]
               [clojure.main$repl doInvoke "main.clj" 368]
               [clojure.lang.RestFn invoke "RestFn.java" 1526]
               [nrepl.middleware.interruptible_eval$evaluate invokeStatic "interruptible_eval.clj" 84]
               [nrepl.middleware.interruptible_eval$evaluate invoke "interruptible_eval.clj" 56]
               [nrepl.middleware.interruptible_eval$interruptible_eval$fn__997$fn__1001
                invoke
                "interruptible_eval.clj"
                152]
               [clojure.lang.AFn run "AFn.java" 22]
               [nrepl.middleware.session$session_exec$main_loop__1065$fn__1069 invoke "session.clj" 202]
               [nrepl.middleware.session$session_exec$main_loop__1065 invoke "session.clj" 201]
               [clojure.lang.AFn run "AFn.java" 22]
               [java.lang.Thread run "Thread.java" 1447]]}

Bug in Clojurescript string/split with limit?

Wed, 23 Apr 2025 12:03:38 +0000

This seems like a bug to me? Using limit in clojure.string/split (in Clojurescript) gives the wrong result on a simple split.

;; NB Clojurescript
(clojure.string/split "a|b" #"|")
;=> ["a" "|" "b"]
(clojure.string/split "a|b" #"|" 3)
;=> ["" "" "a|b"]

Results should be the same?

Corresponding code in Javascript

"a|b".split(/|/)
;=> ['a', '|', 'b']
"a|b".split(/|/, 3)
;=> ['a', '|', 'b']

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.

":added" metadata missing from some new public functions in namespace clojure.java.process

Fri, 11 Apr 2025 16:29:23 +0000

These functions in the namespace clojure.java.process are mentioned in the doc string for the namespace, and have doc strings, but do not have metadata {:added "1.12"} as do other new public docstring'ed functions in that namespace:

stdin
stdout
stderr
exit-ref

I did not find any other such functions anywhere else that are new in Clojure 1.12.0 vs. Clojure 1.11.1.

Why is shuffle not nil-safe?

Wed, 26 Mar 2025 14:04:15 +0000

Shuffling an empty collection is fine:

user> (shuffle [])
[]

But shuffling nil results in NPE:

user> (shuffle nil)
Execution error (NullPointerException) at java.util.ArrayList/<init> (ArrayList.java:181).
Cannot invoke "java.util.Collection.toArray()" because "c" is null

Why is it not nil-safe like other seq ops?

Docstring typos in clojure.core/bytes, chars, shorts

Thu, 06 Mar 2025 06:54:53 +0000

The docstring of clojure.core/bytes has a minor typo:

"Casts to bytes[]"

which should read byte[]; similarly for the docstrings of chars and shorts.

Given the new array class syntax in Clojure 1.12 perhaps these should be updated to read byte/1, float/1 etc. instead of using Java style syntax?

Source maps show the wrong row in ClojureScript

Wed, 05 Mar 2025 02:52:12 +0000

When some error occurs in ClojureScript, the source map usually shows the line above the actual error, but sometimes it's even worse. An example is on my own plug-in Lazuli, where using Reagent with the newer React causes a very weird source map, as following GIF:

The stracktrace shows:

lazuli$connections$conn_view            @ connections.cljs:64
(anonymous)	                            @ connections.cljs:199
lazuli$connections$connect_nrepl_BANG_  @	connections.cljs:195

But the correct lines are 63, and 197, with 195 being probably the only correct line in this

Is there any way to configure this to be correct?

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.

Breaking change in 1.12.0 - a static field is always preferred to a static function with the same name

Fri, 28 Feb 2025 20:06:59 +0000

In 1.11.4, if a class has a static field and a static method with the same name, attempting to use the method as a function works as expected.

In 1.12.0, the static field is always returned instead.

A CLI reproduction case:

Clojure 1.12.0
user=> (add-lib 'com.badlogicgames.gdx/gdx)
[com.badlogicgames.gdx/gdx com.badlogicgames.gdx/gdx-jnigen-loader]
user=> (import '(com.badlogic.gdx.math MathUtils))
com.badlogic.gdx.math.MathUtils
user=> MathUtils/random
#object[com.badlogic.gdx.math.RandomXS128 0x3df978b9 "com.badlogic.gdx.math.RandomXS128@3df978b9"]
user=> (MathUtils/random)
#object[com.badlogic.gdx.math.RandomXS128 0x3df978b9 "com.badlogic.gdx.math.RandomXS128@3df978b9"]
user=> (MathUtils/random 0 10)
#object[com.badlogic.gdx.math.RandomXS128 0x3df978b9 "com.badlogic.gdx.math.RandomXS128@3df978b9"]


Clojure 1.11.4
user=> (import '(com.badlogic.gdx.math MathUtils))
com.badlogic.gdx.math.MathUtils
user=> MathUtils/random
#object[com.badlogic.gdx.math.RandomXS128 0x71c905a3 "com.badlogic.gdx.math.RandomXS128@71c905a3"]
user=> (MathUtils/random)
0.37632704
user=> (MathUtils/random 0 10)
0

A potential test case:

diff --git a/test/clojure/test_clojure/java_interop.clj b/test/clojure/test_clojure/java_interop.clj
index 4a503884..c99370a3 100644
--- a/test/clojure/test_clojure/java_interop.clj
+++ b/test/clojure/test_clojure/java_interop.clj
@@ -20,7 +20,7 @@
             [clojure.test-helper :refer [should-not-reflect]])
   (:import java.util.Base64
            (java.io File FileFilter FilenameFilter)
-           (java.util UUID)
+           (java.util ArrayList Collections$UnmodifiableCollection UUID)
            (java.util.concurrent.atomic AtomicLong AtomicInteger)
            (clojure.test FIConstructor FIStatic FunctionalTester AdapterExerciser)))
 
@@ -783,6 +783,16 @@
   (def fi-static (FIStatic/numbers (fn [i] (< i 0))))
   (is (= [-2 -1] fi-static)))
 
+(deftest static-field-and-method
+  (let [fv FIStatic/numbers
+        mv0 (FIStatic/numbers)
+        mv1 (FIStatic/numbers neg?)]
+    (is (= [-2 -1 0 1 2] fv))
+    (is (instance? Collections$UnmodifiableCollection fv))
+    (is (= [-2 -1 0 1 2] mv0))
+    (is (instance? ArrayList mv0))
+    (is (= [-2 -1] mv1))))
+
 ;; newDirectoryStream is overloaded, takes ^[Path String] or ^[Path DirectoryStream$Filter]
 ;; so this method will reflect
 (defn get-dir-stream [^java.nio.file.Path dir-path glob-pattern]
diff --git a/test/java/clojure/test/FIStatic.java b/test/java/clojure/test/FIStatic.java
index 8273c357..4a8198ae 100644
--- a/test/java/clojure/test/FIStatic.java
+++ b/test/java/clojure/test/FIStatic.java
@@ -1,13 +1,20 @@
 package clojure.test;
 
+import java.util.ArrayList;
 import java.util.Arrays;
+import java.util.Collections;
 import java.util.List;
 import java.util.function.Predicate;
 
 public class FIStatic {
 
+    public static List<Integer> numbers = Collections.unmodifiableList(Arrays.asList(-2, -1, 0, 1, 2));
+
+    public static List<Object> numbers () {
+        return new ArrayList<>(numbers);
+    }
+
     public static List<Object> numbers(Predicate<Integer> pred) {
-        List<Integer> numbers = Arrays.asList(-2, -1, 0, 1, 2);
         Object[] filteredNumbers =  numbers.stream().filter(pred).toArray();
         return Arrays.asList(filteredNumbers);
     }

`doseq` and `for` expands body twice

Wed, 26 Feb 2025 23:15:06 +0000

The bodies of doseq and for seem to be duplicated in their expansions.

$ clojure
user=> (defmacro a [] (prn :expand))
#'user/a
user=> (doseq [_ nil] (a))
:expand
:expand
nil
user=> (for [_ nil] (a))
:expand
:expand
()

I found the same problem in ClojureScript. I could not find an existing discussion about this so I'm not sure if this is by design, apologies if so. I'm aware that these macros have a large code footprint and that doseq cannot use closures (the usual way to prevent exponential expansion), but I missed this detail.

This leads to exponential code blowup if these forms are nested. Artificial demonstration:

$ clojure
Clojure 1.12.0
user=> (def counter (atom -1))
#'user/counter
user=> (defmacro a [] (prn :expand (swap! counter inc)))
#'user/a
user=> #(doseq [_ 1] (doseq [_ 2] (doseq [_ 3] (doseq [_ 4] (a)))))
:expand 0
:expand 1
:expand 2
:expand 3
:expand 4
:expand 5
:expand 6
:expand 7
:expand 8
:expand 9
:expand 10
:expand 11
:expand 12
:expand 13
:expand 14
:expand 15
#object[user$eval926$fn__927 0x76563d26 "user$eval926$fn__927@76563d26"]

This might be especially relevant to core.async, where placing go under doseq is idiomatic, since go is expensive in both expansion time and code size.

user=> (time (eval '(doseq [_ nil] (a/go (doseq [_ nil] (a/go (doseq [_ nil] (a/go))))))))
"Elapsed time: 837.230917 msecs"
nil

It also leads to duplicated reflection warnings from the fully expanded forms, which is how I found this problem.

user=> (doseq [_ nil] (Thread/sleep (identity 1)))
Reflection warning, NO_SOURCE_PATH:1:16 - call to static method sleep on java.lang.Thread can't be resolved (argument types: unknown).
Reflection warning, NO_SOURCE_PATH:1:16 - call to static method sleep on java.lang.Thread can't be resolved (argument types: unknown).
nil

I believe the exponential expansion for doseq was introduced in Clojure 1.1.0 with support for chunked seqs with this commit.

$ clojure -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.0.0"}}}' 
Downloading: org/clojure/clojure/1.0.0/clojure-1.0.0.pom from central
Downloading: org/clojure/clojure/1.0.0/clojure-1.0.0.jar from central
Clojure 1.0.0-
user=> (defmacro a [] (prn :expand))
#'user/a
user=> (doseq [_ nil] (a))
:expand
nil
user=> ^D
$ clojure -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.1.0"}}}'
Downloading: org/clojure/clojure/1.1.0/clojure-1.1.0.pom from central
Downloading: org/clojure/clojure/1.1.0/clojure-1.1.0.jar from central
Clojure 1.1.0
user=> (defmacro a [] (prn :expand))
#'user/a
user=> (doseq [_ nil] (a))
:expand
:expand
nil
user=>

At first I wasn't sure if this was hopeless, but I think doseq is fixable fusing the chunked and non-chunked cases like so:

(defmacro doseq
  "Repeatedly executes body (presumably for side-effects) with
  bindings and filtering as provided by \"for\".  Does not retain
  the head of the sequence. Returns nil.
  
  Unlike clojure.core/doseq, does not cause exponential macro expansion
  of expressions in bindings or body."
  [seq-exprs & body]
  (#'clojure.core/assert-args
     (vector? seq-exprs) "a vector for its binding"
     (even? (count seq-exprs)) "an even number of forms in binding vector")
  (let [step (fn step [recform exprs]
               (if-not exprs
                 [true `(do ~@body)]
                 (let [k (first exprs)
                       v (second exprs)]
                   (if (keyword? k)
                     (let [steppair (step recform (nnext exprs))
                           needrec (steppair 0)
                           subform (steppair 1)]
                       (cond
                         (= k :let) [needrec `(let ~v ~subform)]
                         (= k :while) [false `(when ~v
                                                ~subform
                                                ~@(when needrec [recform]))]
                         (= k :when) [false `(if ~v
                                               (do
                                                 ~subform
                                                 ~@(when needrec [recform]))
                                               ~recform)]))
                     (let [seq- (gensym "seq_")
                           chunk- (with-meta (gensym "chunk_")
                                             {:tag 'clojure.lang.IChunk})
                           count- (gensym "count_")
                           i- (gensym "i_")
                           in-chunk- (gensym "in-chunk_")
                           recform `(if ~in-chunk-
                                      (recur ~seq- ~chunk- ~count- (unchecked-inc ~i-))
                                      (recur (next ~seq-) nil 0 0))
                           steppair (step recform (nnext exprs))
                           needrec (steppair 0)
                           subform (steppair 1)]
                       [true
                        `(loop [~seq- (seq ~v), ~chunk- nil,
                                ~count- 0, ~i- 0]
                           (let [~in-chunk- (< ~i- ~count-)
                                 ~seq- (if ~in-chunk- ~seq- (seq ~seq-))]
                             (when (if ~in-chunk- true ~seq-)
                               (let [chunked?# (if ~in-chunk- false (chunked-seq? ~seq-))
                                     ~k (if ~in-chunk-
                                          (.nth ~chunk- ~i-)
                                          (if chunked?# nil (first ~seq-)))]
                                 (if (if ~in-chunk- false chunked?#)
                                   (let [c# (chunk-first ~seq-)]
                                     (recur (chunk-rest ~seq-) c#
                                            (int (count c#)) (int 0)))
                                   (do ~subform
                                       ~@(when needrec [recform])))))))])))))]
    (nth (step nil (seq seq-exprs)) 1)))

Clojure 1.12 breaks Serialization for records implementing IFn

Fri, 21 Feb 2025 20:51:39 +0000

If you have a class/record that implements a functional interface AND IFn, serializing it will throw the same error as CLJ-2880. Here's a repro

(let [^java.util.function.Function my-f
      (reify
        Serializable
        java.util.function.Function
        clojure.lang.IFn
        )]
  (with-open [os (java.io.ObjectOutputStream. (java.io.ByteArrayOutputStream.))]
    (.writeObject os my-f)))

Will throw java.io.NotSerializableException. If you comment out clojure.lang.IFn, this code works.

This is a regression from 1.11.

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

When using remote prepl server, repl is false, preventing use of add-lib and related functions

Thu, 06 Feb 2025 13:54:48 +0000

To reproduce:

clojure -J-Dclojure.server.jvm="{:port 5555 :accept clojure.core.server/io-prepl}"

Clojure 1.12.0
user=>

then

nc localhost 5555
*repl*
{:tag :ret, :val "false", :ns "user", :ms 0, :form "*repl*"}

SourceDataLine method not found

Wed, 22 Jan 2025 21:38:08 +0000

Hi, I've found some weird behaviour when attempting to play a sound using a javax.sound.sampled.SourceDataLine. The following code illustrates the problem:

(ns cljtest.core)
(import '[java.util Random]
        '[javax.sound.sampled AudioSystem AudioFormat])

; create an AudioFormat instance:
(def fmt (AudioFormat. 44100. 16 2 true false))

; create some data representing a second of white noise:
(def data (byte-array 176400))
(.nextBytes (Random.) data)

; define a function that creates a SourceDataLine and uses it to play a sound:
(defn play1 []
  (let [l (AudioSystem/getSourceDataLine fmt)]
    (.open l) (.start l) (.write l data 0 (count data))))

; define a function that creates a SourceDataLine and returns it:
(defn getline []
  (AudioSystem/getSourceDataLine fmt))

; define a function that uses the output of getline to play a sound:
(defn play2 []
  (let [l (getline)]
    (.open l) (.start l) (.write l data 0 (count data))))

Compiling this with Clojure 1.12.0 using Leiningen, play1 does what it's supposed to, but play2 gives me the following error:

Execution error (IllegalArgumentException) at cljtest.core/play2 (core.clj:24).
No matching method write found taking 3 args for class com.sun.media.sound.DirectAudioDevice$DirectSDL

I get this error using both OpenJDK 21.0.5.11-hotspot and Oracle's JDK 23. Also with Clojure 1.11.0 and 1.10.0, but 1.9.0 works fine. Anyone know why this is happening?

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

Incorrect result when evaluating `not=` on `##NaNs`

Sun, 08 Dec 2024 21:14:02 +0000

Alex Miller asked me to write this up here. I found a bug in clojure.core yesterday that involves not= when used to compare NaNs. This was reported on Slack and the discussion is here:
https://clojurians.slack.com/archives/C03S1KBA2/p1733612992809069

Here is a more highly summarized version of the discussion from Slack (at least from my perspective). If we fire up the Clojure CLI, we can evaluate the following.

 Clojure 1.12.0
 user=> (= ##NaN ##NaN)
 false
 user=> (not= ##NaN ##NaN)
 false
 user=> (not (= ##NaN ##NaN))
 true

The problem here is that =, not, and not= have a relationship between them. Specifically, for any x and y, if (= x y) returns a boolean, then (not (= x y)) should return the opposite boolean, and since not= is defined as (not (= x y)), it should return the same value as (not (= x y)) for all x and y. This doesn't happen if x and y are both ##NaN.

Note that there were a lot of calories burned on Slack with suggestions that doubles should never be compared for equality, that NaNs are shifty, not-quite-value objects and should be avoided, that anybody who wants to test for the presence of a NaN should use NaN? which is already in clojure.core, and that the documentation around equality should be updated to say some of those things. Many of those statements are true or good practice. But all of them miss the broader point.

This bug has nothing to do specifically to do with NaNs. It just seems that NaNs expose the bug. The real issue is with the contractual relationship between =, not, and not= which appears to be violated in the presence of NaNs. Specifically, not= is no longer referentially transparent with respect to (not (= ...)).

On Slack, @potetm decompiled the code generated for these cases and found the following.

For (not= ##NaN ##NaN) :

(clj-java-decompiler.core/decompile
  (not= ##NaN ##NaN))

// Decompiling class: cjd__init
import clojure.lang.*;

public class cjd__init
{
    public static final Var __not_EQ_;
    public static final Object const__1;
    
    public static void load() {
        ((IFn)cjd__init.__not_EQ_.getRawRoot()).invoke(cjd__init.const__1, cjd__init.const__1);
    }
    
    public static void __init0() {
        __not_EQ_ = RT.var("clojure.core", "not=");
        const__1 = Double.NaN;
    }
    
    static {
        __init0();
        Compiler.pushNSandLoader(RT.classForName("cjd__init").getClassLoader());
        try {
            load();
            Var.popThreadBindings();
        }
        finally {
            Var.popThreadBindings();
        }
    }
}

And then for (not (= ##NaN ##NaN)):

(clj-java-decompiler.core/decompile
  (not (= ##NaN ##NaN)))

// Decompiling class: cjd__init
import clojure.lang.*;

public class cjd__init
{
    public static final Var __not;
    
    public static void load() {
        ((IFn)cjd__init.__not.getRawRoot()).invoke(Util.equiv(Double.NaN, Double.NaN) ? Boolean.TRUE : Boolean.FALSE);
    }
    
    public static void __init0() {
        __not = RT.var("clojure.core", "not");
    }
    
    static {
        __init0();
        Compiler.pushNSandLoader(RT.classForName("cjd__init").getClassLoader());
        try {
            load();
            Var.popThreadBindings();
        }
        finally {
            Var.popThreadBindings();
        }
    }
}

It appears that the compiler optimizes the call to = and does not box the ##NaN values when compiling (not (= ##NaN ##NaN)), whereas the call to not= receives the ##NaNs boxed as Doubles. This then causes a subsequent call to clojure.lang.Util/equiv (after following the call chain through not= -> = -> clojure.lang.Util/equiv) to return true improperly (since NaNs are never equal to anything, even themselves).

IMO, this is a bug, albeit a low priority one. Most programmers successfully use floating point math without ever having to deal with NaNs. While NaNs seem to trigger the bug, there may be other cases that also trigger it. I can't speak to that.

Incorrect stream reads in clojure.java.io

Mon, 18 Nov 2024 14:34:28 +0000

I've noticed that the clojure.java.io namespace's code includes a very common mistake when reading InputStreams. Your typical do-copy will have some variation of this loop:

`
(let [buffer (make-array Byte/TYPE (buffer-size opts))]

(loop []
  (let [size (.read input buffer)]
    (when (pos? size)
      (do (.write output buffer 0 size)
          (recur))))))

It is incorrect to say when (pos? size) because the InputStream interface has this definition for read method return:

Returns: the total number of bytes read into the buffer, or -1 if there is no more data because the end of the stream has been reached.

Yes, it is perfectly legal for read to return 0 bytes read when the stream is not at the end yet.

I guess they made it like that so that you can return 0 bytes from a socket that is stalled and enable the caller to timeout or abort or do something else.

In any case the correct condition for detecting end of stream is to compare the return to -1.

Java interop issue

Tue, 12 Nov 2024 19:25:31 +0000

Hi everyone,

Failing to make clojure work with our commercial java library. I can run the following Java code on my machine and it works fine:

import com.numerix.pro.Application;
import com.numerix.pro.ApplicationCall;
import com.numerix.pro.ApplicationData;
import com.numerix.pro.ApplicationObjectFactory;
import com.numerix.pro.ApplicationWarning;

public final class FxAmericanOption {

    public static void main(final String argv[]) 
    {
        int rVal = 0;      // exit value
        try {
            System.out.println("Running: " + new Throwable().getStackTrace()[0].getClassName() + "\n");

            final Application app = new Application();
            {
                final ApplicationCall call = new ApplicationCall();
                call.addValue("ID",       "USD_Curve");
                call.addValue("OBJECT",   "Curve");
                call.addValue("TYPE",     "Yield");
                call.addValue("Now Date", ApplicationObjectFactory.parseDate("26-Oct-2003"));
                call.addValue("CURRENCY", "USD");
                call.addValue("RATE",     0.04);

                final String[] outHeaders =
                    new String[] {"Updated", "Timer", "ID"};

                final ApplicationWarning warning = new ApplicationWarning();

                app.call(call, outHeaders, warning);

I tried porting it to clojure 1.12 like this

(ns hello
  (:import (com.numerix.pro Application ApplicationCall
                            ApplicationWarning 
                            ApplicationObjectFactory)))
           
(def myapp (new Application))
(def appcall (new ApplicationCall))
(def warning (new ApplicationWarning))

(.addValue ^ApplicationCall appcall "NAME" "Yield Curve")
(.addValue ^ApplicationCall appcall "ID" "MyCurve")
(.addValue ^ApplicationCall appcall "OBJECT" "Curve")
(.addValue ^ApplicationCall appcall "TYPE" "Yield")
(.addValue ^ApplicationCall appcall "Now Date" (ApplicationObjectFactory/parseDate "26-Oct-2023"))
(.addValue ^ApplicationCall appcall "CURRENCY" "USD")
(.addValue ^ApplicationCall appcall "RATE" 0.04)

(def outHeaders (into-array String ["timer" "id"]))

(^[ApplicationCall String/1 ApplicationWarning] Application/.call ^Application myapp
                                                                  ^ApplicationCall appcall
                                                                  ^String/1 outHeaders
                                                                  ^ApplicationWarning warning)

I can inspect appcall object and it looks totally fine - all the .addValue register correctly with it. But when I evaluate the last form with Application/.call I get an error which I don't understand how to address..

 Execution error (IllegalAccessError) at hello/eval10370 (REPL:25).
; failed to access class com.numerix.pro.ApplicationCommon from class hello$eval10370 (com.numerix.pro.ApplicationCommon is in unnamed module of loader 'app'; hello$eval10370 is in unnamed module of loader clojure.lang.DynamicClassLoader @cc01572)

Any help much appreciated!

seque forces n+2 items ahead of consumer instead of n

Tue, 08 Oct 2024 21:33:17 +0000

seque's documentation says:

The queued seq will produce a concrete seq in the background, and can
get up to n items ahead of the consumer.

It seems to force n+2 items ahead of the consumer.

(let [producer (fn step [i]
                 (lazy-seq
                   (prn "producer" i)
                   (cons i (step (inc i)))))
      s (seque 1 (producer 0))]
  (Thread/sleep 1000)
  nil)
;="producer" 0
;="producer" 1
;="producer" 2
nil

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

The new array class syntax in 1.12 doesn't seem to be supported by definterface meta tags

Sat, 24 Aug 2024 12:30:36 +0000

Noticed by user yuhan in slack https://clojurians.slack.com/archives/C03S1KBA2/p1724499452475139

❯ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.12.0-rc1"}}}'
Clojure 1.12.0-rc1
user=> (definterface Foo (^String/1 bar []))
user.Foo
user=> (reify Foo (bar [this]))
Syntax error (ClassNotFoundException) compiling reify* at (REPL:1:1).
java.lang.String.1
user=>

New add-lib in Clojure 1.12 doesn't load data readers brought by the lib

Tue, 20 Aug 2024 20:42:06 +0000

I see that the new add-lib in Clojure 1.12 doesn't call clojure.core/load-data-readers (like clojure.core does on loading) so if you bring libraries that have data-readers you can't use them.

Calling clojure.core/load-data-readers from the repl doesn't solve the issue since it changes *data-readers* root value which is already being shadowed by clojure.main/repl.

$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.12.0-rc1"} com.github.flow-storm/flow-storm-dbg {:mvn/version "3.17.2"}}}'
Clojure 1.12.0-rc1
user=> *data-readers*
{trace #'flow-storm.api/read-trace-tag, ctrace #'flow-storm.api/read-ctrace-tag, rtrace #'flow-storm.api/read-rtrace-tag, tap #'flow-storm.api/read-tap-tag, tap-stack-trace #'flow-storm.api/read-tap-stack-trace-tag, flow-storm.types/value-ref #'flow-storm.types/make-value-ref, amalloy/ring-buffer #'amalloy.ring-buffer/read-method}

now with add-lib :

$ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.12.0-rc1"}}}'                                                             
Clojure 1.12.0-rc1
user=> (add-lib 'com.github.flow-storm/flow-storm-dbg {:mvn/version "3.17.2"})
[...]
user=> *data-readers*
{}
user=> (#'clojure.core/load-data-readers)
{trace #'flow-storm.api/read-trace-tag, ctrace #'flow-storm.api/read-ctrace-tag, rtrace #'flow-storm.api/read-rtrace-tag, tap #'flow-storm.api/read-tap-tag, tap-stack-trace #'flow-storm.api/read-tap-stack-trace-tag, flow-storm.types/value-ref #'flow-storm.types/make-value-ref, amalloy/ring-buffer #'amalloy.ring-buffer/read-method}
user=> *data-readers*
{}

The only way I see to bring in data-readers with add-lib is by starting a sub-repl :

clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.12.0-rc1"}}}'
Clojure 1.12.0-rc1
user=> (add-lib 'com.github.flow-storm/flow-storm-dbg {:mvn/version "3.17.2"})
[...]
user=> (binding [*data-readers* (#'clojure.core/load-data-readers)] (clojure.main/repl))
user=> *data-readers*
{trace #'flow-storm.api/read-trace-tag, ctrace #'flow-storm.api/read-ctrace-tag, rtrace #'flow-storm.api/read-rtrace-tag, tap #'flow-storm.api/read-tap-tag, tap-stack-trace #'flow-storm.api/read-tap-stack-trace-tag, flow-storm.types/value-ref #'flow-storm.types/make-value-ref, amalloy/ring-buffer #'amalloy.ring-buffer/read-method}

which won't work with nrepl tooling.

ClojureScript compiler does not transpile "es8" closure libraries

Tue, 20 Aug 2024 17:42:31 +0000

The ClojureScript compiler determines the type of the Closure library in the transpile function. However, :es8is not implemented.

I have a fix for this, when a bug number has been assigned.

Thanks,
Hadil

defn rejects arity with args vector [&form]

Mon, 19 Aug 2024 21:05:00 +0000

Here's the smallest case, but it seems to happen no matter how many other arities are provided or whether list or vector syntax is used for the arity.

user=> (clojure-version)
"1.12.0-rc1"
user=> (defn f [&form])
Unexpected error (IndexOutOfBoundsException) macroexpanding defn at (REPL:1:1).
null
user=> *e
#error {
 :cause nil
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message "Unexpected error macroexpanding defn at (1:1)."
   :data #:clojure.error{:phase :macroexpansion, :line 1, :column 1, :source "NO_SOURCE_PATH", :symbol defn}
   :at [clojure.lang.Compiler macroexpand1 "Compiler.java" 7551]}
  {:type java.lang.IndexOutOfBoundsException
   :message nil
   :at [clojure.lang.RT subvec "RT.java" 1634]}]
 :trace
 [[clojure.lang.RT subvec "RT.java" 1634]
  [clojure.core$sigs$asig__5505 invoke "core.clj" 235]
  [clojure.core$sigs invokeStatic "core.clj" 259]
  [clojure.core$defn__5514 invokeStatic "core.clj" 317]
  [clojure.core$defn__5514 doInvoke "core.clj" 294]
  [clojure.lang.RestFn applyTo "RestFn.java" 149]
  [clojure.lang.Var applyTo "Var.java" 707]
  [clojure.lang.Compiler macroexpand1 "Compiler.java" 7525]
  [clojure.lang.Compiler macroexpand "Compiler.java" 7598]
  [clojure.lang.Compiler eval "Compiler.java" 7684]
  [clojure.lang.Compiler eval "Compiler.java" 7655]
  [clojure.core$eval invokeStatic "core.clj" 3232]
  [clojure.core$eval invoke "core.clj" 3228]
  [clojure.main$repl$read_eval_print__9240$fn__9243 invoke "main.clj" 437]
  [clojure.main$repl$read_eval_print__9240 invoke "main.clj" 437]
  [clojure.main$repl$fn__9249 invoke "main.clj" 459]
  [clojure.main$repl invokeStatic "main.clj" 459]
  [clojure.main$repl_opt invokeStatic "main.clj" 523]
  [clojure.main$main invokeStatic "main.clj" 668]
  [clojure.main$main doInvoke "main.clj" 617]
  [clojure.lang.RestFn invoke "RestFn.java" 400]
  [clojure.lang.AFn applyToHelper "AFn.java" 152]
  [clojure.lang.RestFn applyTo "RestFn.java" 135]
  [clojure.lang.Var applyTo "Var.java" 707]
  [clojure.main main "main.java" 40]]}

clojure.pprint/pprint converts unquote+deref to unquote-splicing

Mon, 12 Aug 2024 23:25:23 +0000

This is very unusual syntax but pretty-printing it does not round-trip.

$ clj -Sforce -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.11.4"}}}'
Clojure 1.11.4
user=> (require '[clojure.pprint :as pp])
nil
user=> (-> "~ @a" read-string pp/pprint)
~@a
nil
user=> (-> '~ @a)
(clojure.core/unquote (clojure.core/deref a))
user=> (-> '~ @a pp/pprint with-out-str read-string)
(clojure.core/unquote-splicing a)

Why does clojure.core/newline not respect flush-on-newline?

Wed, 07 Aug 2024 23:09:06 +0000

Calling (newline) appends a newline to the output stream but does not flush it *flush-on-newline* is bound to true (the default).

Instead, only clojure.core/prn mentions *flush-on-newline* in its docstring and the check and (flush) call is explicit there.

Why is this?

Also, println does not mention that it Observes *flush-on-newline* like prn does, and it doesn't hint that it calls prn which does, since it says Same as print followed by (newline) which isn't actually true.

Using integer parameters in deftype annotations

Sun, 30 Jun 2024 18:44:17 +0000

I am trying to use a Java library that uses annotations on Java classes and methods, so I pass to it deftypes with annotated methods. Some of the annotations require using integer parameters and it seems there is no convenient way to do this in Clojure. The code I am trying is something like this:

(deftype SomeType []
  (^{Retention RetentionPolicy/RUNTIME
     SomeAnnotationClass {:order 1} }
   someMethod [_]...))

The :order 1 part causes an exception:

Incorrectly typed data found for annotation element ... (Found data of type java.lang.Long[1])

This happens because the java library expects that :order would have a java.lang.Integer value, but Clojure creates a java.lang.Long. If I try (int 1) instead of 1, I get another exception.

I asked for help on clojurians Slack, and it was suggested that I use #java.lang.Integer[1] instead of simply 1. This works, but it would be nice to have a more intuitive way to do this.

Deadlock with clojure.java.shell/sh

Mon, 17 Jun 2024 15:19:36 +0000

The clojure.java.shell/sh function has this construct at the end:

(with-open [stdout (.getInputStream proc)
            stderr (.getErrorStream proc)]
  (let [out (future (stream-to-enc stdout out-enc))
        err (future (stream-to-string stderr))
        exit-code (.waitFor proc)]
    {:exit exit-code :out @out :err @err}))

So the outputs of a process are read in two futures, while the current thread awaits for process to end (and generate exit code). If an exception happens during an execution of a future, that exception is stored and thrown (wrapped in ExecutionException), when futures are derefed (in this case this is after process ends).

I've had a case where I was calling git with sh and the generated output was large enough to produce OutOfMemoryError. And here's where you get a "deadlock" (it's not one technically).

Git was shoveling data into pipe, while Java process was reading it in the future, main thread was awaiting process end
Future reading out encounters an OutOfMemory exception, it is stored and out reader loop terminates
Pipe buffer between processes becomes full, as git is writing but nobody is reading anymore
Git stalls indefinitely trying to write to pipe
Java process main thread awaits git process end indefinitely
The future is never derefed so no exception stacktrace or message is ever produced

This can happen with any type of exception during one of those 2 future's reads. Another realistic scenario would be if I specify an encoding and underlying process returns some bytes that cannot be parsed in that encoding.

This "bug" was quite frustrating because there is no error message and very little indication of what is wrong. In my case it happened sporadically in production and it was quite hard to track down.

I don't know what the remedy is, but it might be smart to do some sort of mitigation for this.

Locals clearing + forcing a delay recursively results in NPE

Thu, 30 May 2024 21:11:28 +0000

Discovered by Ambrose Bonnaire-Sergeant (@ambrosebs).

Given this convoluted example:

(let [f +
      p (promise)
      d (delay (f) @@p)]
 (deliver p d)
 @d)

When executed, it fails with:

1. Unhandled java.lang.NullPointerException
   Cannot invoke "clojure.lang.IFn.invoke()" because "this.f" is null

The same error happens with lazy seqs:

(let [f +
      p (promise)
      d (lazy-seq (f) (first @p))]
  (deliver p d)
  (first d))

The reason in both cases is that locals clearing assigns this.f = null; right after it is first invoked, so when the recursive call reaches (f) again, the reference is already nil.

(binding [*compiler-options* {:disable-locals-clearing false}]
  (clj-java-decompiler.core/decompile
   (defn repro []
     (let [f +
        p (promise)
        d (delay (f) @@p)]
    (deliver p d)
    @d))))

=>

@Override
public Object invoke() {
    final Object f = this.f;
    this.f = null;
    ((IFn)f).invoke();
    final IFn fn = (IFn)__deref.getRawRoot();
    final IFn fn2 = (IFn)__deref.getRawRoot();
    final Object p = this.p;
    this.p = null;
    final Object invoke = fn2.invoke(p);
    this = null;
    return fn.invoke(invoke);
}

Is this a bug or undefined behavior?

(deftype) blues - private and mutable field access problems

Mon, 20 May 2024 18:15:40 +0000

New to clojure, trying to define an effective class with mutable fields via deftype, definitions below.

My program is single threaded, no one else will ever use my code, promised. I know all the advantages of immutability, but this program makes over 500,000,000 updates, so the GC would be the main actor, not my code. I've tried that.

Two problems I've got at run time.

*1. ; Execution error (IllegalArgumentException) at layout.core.Individual/idivlCopy (core.clj:161).
    ; No matching field found: fitness for class layout.core.Individual

I understand that the fields of a deftype are not public, but the code of idivlCopy is in the deftype itself. It seems to me, that the runtime knows (.fitness this) but not (.fitness that).

What is the rationale of this behaviour and how can I get around it?
How can I access the private protected fields (of that) from the private (i.e. deftype) code area?!

*2. ; Execution error (ClassCastException) at layout.core.Individual/idivlSwap (core.clj:173).
           ; class clojure.core.Vec cannot be cast to class clojure.lang.IEditableCollection
           ;    (clojure.core.Vec and clojure.lang.IEditableCollection are in unnamed module of loader 'app')

The annotations tell that both fields are volatile-mutable. Why is this not known at run time for the chromosome vector? Why can't I (assoc! ) my volatile-mutable chromosome vector-of :char -s?

(definterface IIndividual

  (idivlCopy [that])                      ; Copies that Individual to this
  (idivlSwap [^Integer xP, ^Integer xQ])) ; Swaps two genes in the chromosome
  ; and somme more.
)

(deftype Individual                ; An individual has a fitness value and a chromosome
  [^{:volatile-mutable true}  ^Integer fitness,       ; Integer
   ^{:volatile-mutable true}           chromosome]    ; vector-of :char
 
  IIndividual

	:
	.

  (idivlCopy         ; Copies that Individual to this
    [_, that] 
*1  (set! fitness    (.fitness    that))         ; (set! fitness  999) worked!!
    (set! chromosome (.chromosome that))
    nil)

  (idivlSwap         ; Swaps the genes in the chromosome at alleles P and Q
    [this,
     ^Integer iP,                 ; index of allele P
     ^Integer iQ]                 ; index of allele Q
    (let [gP (chromosome iP),     ; gene  at allele P
          gQ (chromosome iQ)]     ; gene  at allele Q
*2    (assoc! chromosome iP gQ)
      (assoc! chromosome iQ gP)
      nil))

    ; and some more
    :
	.
)

tools.tools install-latest throws sha error with :coord and never upgrades with :tool

Mon, 13 May 2024 10:24:47 +0000

Thanks for https://clojure.atlassian.net/browse/TDEPS-253, however I noticed it doesn't quite work as expected for a fresh install (with :coord); I get an error due to a missing sha, contrary to the doc string "git coords may omit sha".

clj -Ttools install-latest \
:lib org/tool-name \
:coord '{:git/url "git@gitlab.int.org.com:group/subgroup/tool-name.git"}' \
:as tool-name

=>
Execution error (ExceptionInfo) at clojure.tools.deps.extensions.git/eval1656$fn (git.clj:79).
Library org/tool-name has coord with missing sha

I also found upgrading a tool with saved coordinates (clj -Ttools install-latest :tool tool-name) always results in "Skipping, newest installed" (because passing the coord returned by parse-install-latest-args to install-1 means ext/find-all-versions is never evaluated). Looks like this issue would affect tools with auto resolved git urls too.

`(s/gen ratio?)` throws exceptions

Wed, 08 May 2024 07:44:49 +0000

(s/gen ratio?) is implemented as (gen/such-that ratio? gen/ratio)

The problem is that about 10% of the time gen/ratio returns a whole number, which fails the ratio? predicate. If that happens 10 times in a row, gen/such-that throws an exception.

With a large enough sample size, (s/gen ratio?) reliably fails:

(dorun (gen/sample (s/gen ratio?) 10000000))

Execution error (ExceptionInfo) at clojure.test.check.generators/fn (generators.cljc:435).
Couldn't satisfy such-that predicate after 10 tries.

A quick fix is to increase the max-tries param for such-that:

(dorun (gen/sample (gen/such-that ratio? gen/ratio 100) 10000000))

=> nil

I do however also find it odd that (s/gen ratio?) always generates Ratios, but gen/ratio generates a mixture of ratios and integers. So perhaps a better fix would be to update gen/ratio to not generate integers?