Clojurians Log v2
clr
I feel such a sense of release.
New releases of some ClojureCLR libraries.
• io.github.clojure/clr.tools.reader {:git/tag "v1.5.0" :git/sha "46ce896"}
• io.github.clojure/clr.tools.namespace {:git/tag "v1.5.4" :git/sha "46d81cb"}
• io.github.clojure/clr.test.generative {:git/tag "v1.1.2" :git/sha "97cd08c"}
• io.github.clojure/clr.data.json {:git/tag "v2.5.1" :git/sha "f84cb88"}
• io.github.dmiller/test-runner {:git/tag "v0.5.3clr" :git/sha "ae91dd2"}
Support libraries for cljr , in case you are using them directly.
• io.github.clojure*/clr.tools.deps* {:git/tag "v0.1.6" :git/sha "a3273a2"}
• io.github.clojure/clr.tools.deps.cli {:git/tag "v0.1.5" :git/sha "a7d281a" }
• io.github.clojure*/clr.tools.gitlibs* {:git/tag "v2.5.198" sha "3d561c2"}
Support libraries for ClojureCLR, in case you are using them directly:
• io.github.clojure/clr.spec.alpha {:git/tag "v0.5.238" :git/sha "1cfe4af"}
• io.github.clojure/clr.core.specs.alpha {:git/tag "v0.4.74" :git/sha "e53b34f"}
Mostly minor updates.
And, finally the biggies:
ClojureCLR : version 1.12.0-alpha11
This release pulls in the last few commits for version 1.12.0 in Clojure(JVM).
It fixes a few issues listed on JIRA.
It adds support for .NET 9.0.
Caveat for .NET 9.0: Moving the Clojure library from netstandard2.1 to net6.0, net8.0, and net9.0 has a consequence.
Some classes that were packaged in netstandard21.dll are now not loaded automatically.
This might mess up some Clojure source file loads in terms of :import directives that fail because the appropriate assembly has not been loaded.
For example, I had to convert
(ns clojure.tools.deps
(:require ... lots of things ... )
(:import ... other things ...
[System.Diagnostics ProcessStartInfo Process]))System.Diagnostics import and inserting the following code below the ns form:
(try
(assembly-load-from (str clojure.lang.RT/SystemRuntimeDirectory "System.Diagnostics.Process.dll"))
(catch Exception e))
(import '[System.Diagnostics Process ProcessStartInfo])try wrapper. I have it here because this code runs under Framework 4.x where that DLL is not present.
Note in this case the need to specify the .NET system runtime directory; this DLL is part of the .NET load itself.
As was true previously, a regular assembly-load without the directory likely will work for things like NuGet pulldowns.
Clojure.Cljr, version 0.1.0-alpha6
Updated also to run on .NET 9 and to update library dependencies.
dotnet tool install --global Clojure.Cljr --version 0.1.0-alpha6
(~)-(!2011)-> cljr
Syntax error (InvalidOperationException) compiling at (clojure/tools/deps.cljc:34:24).
Unable to find static field: SystemRuntimeDirectory in clojure.lang.RT
Full report at:
/tmp/clojure-0bd7ee6e-e940-4027-a61b-8bbc0f3e6828.edn
Tue Dec 10 11:11:32
(~)-(!2012)-> cljr -version
ClojureCLR CLI Version: 0.1.0-alpha6OK, I installed .NET 9 (SDK and runtime). Ran sudo dotnet workload update. Tried to reinstall cljr. And now I still get the same error.
Do I need some additional install @dmiller?
OK, it's the same problem I had before:
(~)-(!2021)-> dotnet tool install --global Clojure.Main --version 1.12.0-alpha11
Tool 'clojure.main' is already installed.
Tue Dec 10 11:18:17
(~)-(!2022)-> dotnet tool uninstall --global Clojure.Main
Tool 'clojure.main' (version '1.12.0-alpha9') was successfully uninstalled.
Tue Dec 10 11:18:34
(~)-(!2023)-> dotnet tool install --global Clojure.Main --version 1.12.0-alpha11
You can invoke the tool using the following command: Clojure.Main
Tool 'clojure.main' (version '1.12.0-alpha11') was successfully installed.
Tue Dec 10 11:18:38
(~)-(!2024)-> cljr
Clojure 1.12.0-alpha11
user=>dotnet tool install with a specific version does not overwrite the existing install 😞You don't have to be running on .NET 9 for cljr.
You do have to update to the latest to the latest Clojure.Main to run the latest cljr.
(That supplies the missing static field you are getting the error on.)
I'll amend the instructions to include an uninstall operation.
(Noting that dotnet tool update appears to work only on stable releases. Sigh.)
Ah, so I could have just updated Clojure.Main and stayed on .NET 8? Well, cljr is the only thing I use that depends on .NET so that's fine 🙂
I updated my local test project's test-runner and confirmed that works too. At some point, maybe I'll dig into what you had to do in that fork -- since I have a JVM fork of test-runner that runs LazyTest, but I've no idea whether that would run on cljr...
The changes to test-runner are pretty trivial. There are three commits with a handful of conditionalizations.
With ClojureCLR now up on .NET 9, some might be wondering about the possibility of the return of AOT compilation of Clojure source code. Among other benefits, likely this would improve the start-up time of ClojureCLR itself.
AOT compilation has been available when running under Framework 4.x. However, when .NET Core was created, the ability to save dynamically generated assemblies was lost. Per a recent document (https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-reflection-emit-persistedassemblybuilder):
> The AssemblyBuilder.Save API wasn't originally ported to .NET (Core) because the implementation depended heavily on Windows-specific native code that also wasn't ported.
.NET 9 introduces a new PersistedAssemblyBuilder class that allows, well, persistence, i.e., saving the dynamically generated assembly to a file.
However:
There is a bifurcation of behavior herein that is going to cause problems. Under Framework 4.x, the AssemblyBuilder could be used to generate types and use them (instantiate the type, invoke a method, etc.) as well as write the finished assembly to file. Under .NET 9, there are two assembly builders. One allows dynamic evaluation but not saving the file. The other allows saving to file but not dynamic evaluation.
When just eval-ing things in Clojure, only dynamic evaluation is needed and we can use what we've been using. If we are compiling, however, we need a PersistedAssemblyBuilder so we can save to a file AND we need to evaluate forms as we go. Even when compiling, we need to evaluate all the forms we encounter as we proceed. Each form in the file, such as a def or defn
modifies the environment seen by subsequent forms.
I'm not yet sure how to solve the problem. Mostly likely I will need to double generate all code -- once to the dynamic assembly to do evaluations to update the current environment, and once to the persistable assembly for saving. There are some nuances that are going to have to be dealt with that I don't even want to go into at this time.
The code that manages assembly builder contexts is messy. I haven't touched it in a dozen years; it works and I'm scared of it. I had planned to do a full analysis as part of the ClojureCLR.Next project -- that may come sooner in order to work on AOT in the current generation.
At any rate, for anyone thinking, "Oh, .NET 9 is here, let's just start calling AssemblyBuilder.Save() again", um, no.
They couldn't give a moment's thought to restoring a lost working API feature as developers were used to using it - they just had to reinvent a completely different approach, breaking everything, didn't they?
I mentioned in a recent thread that I had run into a heisenbug when including support in ClojureCLR for running under .NET 9. It wasn't .NET 9 alone -- it was switching from netstandard2.1 to directly mentioning .NET 6/8/9.
If you like details, I wrote it up for posterity. https://dmiller.github.io/clojure-clr-next/general/2024/12/10/say-my-name.html
I really enjoy your wit, especially when writing about your more adventurous tantric tangos with obscure platform errors and the dark, lonely alley-ways of compiler implementation!