Fork me on GitHub

Yesterday I released CIDER 1.7 (, but I forgot to announce it. facepalm Enjoy!

🙌 34
👍 10
🎉 20
cider 16

Announcing version 5.0.0-SNAPSHOT of, a generic, glitch-free, property-to-property reactive engine that works especially well for wrapping GUIs, but can be applied usefully to streams of data as well. New this release: • "async" formulaic cells (object properties); • a single tiltontec.matrix.api NS to reduce require clutter; • a useful :debug true option for formulaic cells; • "observers" are now "watches", to avoid conventional misunderstanding of the word "observer". Unchanged: • mutable input cells; • formulaic cells; • global reach for dependencies or mutations; • eager or lazy formulaic cells; • anonymous cells, or "synapses"; • instance-specific cells; • cell or object type specific "watch" functions for side-effects; and • as always, the While all that ^^^ is true, this release exists mostly to support an upcoming (Monday?) release. Not much doc yet, but DM at will for help getting started, or see you over at #matrix.

🎉 31

Announcing release of cljr as open source under Apache 2.0 license:

🎉 36
👍 8

@U2M7EC8KU Congrats. Windows only?


No it works on .NET core too. Basically targeting .NET Framework (Window) and .NET Core (cross platform). Problem for it on .NET Core is that MS took away saving binaries to hard disk via Reflection.Emit()... a problem that is rumored to be fixed with .NET Core 8.


ah cool, I was confused by cljr.exe, so there is a cljr binary for macOS too?


yeah on Mac you'd run it with dotnet cljr.dll <params>


it builds both cljr.exe and cljr.dll on windows and you use the exe version there.


ah cool, so you could make a bash wrapper that does that for you basically


i have been focused on Windows/.NET framework as I'm also integrating with Office (think: legacy app modernization). But one of the main use cases is microservices so you'd want those to run on Core to deploy cross platform.


.NET is relative hot mess because of the runtime fragmentation over the years (.NET, silverlight, core, standard, winRT, etc). They are trying to tie it all back together again into Core, but because of the Reflection.Emit() restriction the perf on Core is slightly less on startup as the runtime has to compile the entire core clojure library on the fly. Once it's running it's fast; but the startup can take a few seconds. It's much quicker on .NET framework with precompiled libraries.


i need to add detail about deps.edn for CLR purposes. Will add that to the readme over the weekend.


@U2M7EC8KU Have you considered that some libraries may target both JVM and CLR, and how does a deps.edn for such a library look like if it has JVM + CLR dependencies?


there are toplevel CLR-specific keys: :clr-deps and :clr-aliases. These are ignored by JVM tooling. cljr ignores :deps and :aliases.


There, it's mostly documented already. LOL.


{:paths ["src/main/" :another-project-dir]

 {Some.Local.Library {:local/root :some-local-dir}

 {:some-local-dir "C:\\libs\\"
  :another-project-dir "C:\\projects\\another-project\\"}

 :nuget/repos []



Keeping in mind there could also be :deps and :aliases keys in the same file, that's the current functionality. adding git and nuget are the next two big priorities besides expanding aliases for tool execution.


Some.Local.Library => this needs to be a qualified symbol


It will be Some.Local.Library.dll on the hard drive, located at :some-local-dir.


Qualified names will relate more to nuget dependencies and git repos


I'd say that should be:

{:clj-deps {org/lib {:local/root "Some.Local.Library.dll"}}}
cf how deps.edn deals with .jar files. But better discuss this with @U064X3EF3


OK, that's good feedback. Can make it a feature or enhancement request on the Issues tab.


:local/root requires a path on the local drive, which in this case is provided by an alias


.NET formal names can be used in the first part of the k/v pair, but when referring to a specific folder, the short name of the assembly is enough.


another thing worth point out is that assemblies and jar files aren't quite the same thing. If the DLL is compiled by ClojureCLR, each namespace gits its own DLL, so the "correct" thing to do here will be somewhat dictated by a) .NET exigencies and assembly loading logic, and b) the design decisions that went into ClojureCLR up to this point. Java conventions will only be "somewhat" useful.


But yes - everything is on the table for discussion at this point.


Once the functionality is such that we're past the chicken-egg connundrum of needing cljr to build cljr, the implementation will move to Clojure - porting the tools related projects that currently are JVM specific.


But dependency management will require different logic on .NET than it does on the JVM, so I'm waiting to see how far NuGet integration handles that for us.