Clojurists Together

Call for Proposals. Feb. 2026 Survey

Wed, 04 Mar 2026 08:30:00 +0800

Greetings folks!

Clojurists Together is pleased to announce that we are opening our Q2 2026 funding round for Clojure Open Source Projects. Applications will be accepted through the 19th of March 2026 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.

We will be awarding up to $33,000 USD for a total of 5-7 projects. The $2k funding tier is for experimental projects or smaller proposals, whereas the $9k tier is for those that are more established. Projects generally run 3 months, however, the $9K projects can run between 3 and 12 months as needed. We expect projects to start at the beginning of April 2026.

A BIG THANKS to all our members for your continued support. We also want to encourage you to reach out to your colleagues and companies to join Clojurists Together so that we can fund EVEN MORE great projects throughout the year.

And Now the Survey…

We surveyed the community in February to find out what what issues were top of mind and types of initiatives they would like us to focus on for this round of funding. As always, there were a lot of ideas and we hope they will be useful in informing your project proposals.

A number of themes appeared in the survey results.

The biggest theme, by far, was related to adoption and growth of Clojure. Respondents repeatedly mentioned that Clojure is niche, and although they are happy with Clojure, that makes it harder to justify for projects, to find employment, and to persuade others than it is for more popular languages. Respondents want a larger community and wider adoption. In particular, they want more public advocacy for Clojure, including videos, tutorials, public success stories, starter projects, and outreach in general.

Another major theme was AI. Respondents were concerned about AI coding assistants being perceived as having weak Clojure support, and they expressed frustration that Python is perceived as the safe choice for AI despite how well Clojure works with AI tooling. Nonetheless, respondents would like to see more work on tooling, guides, and resources for using AI with Clojure.

ClojureScript and JavaScript interop received the most specific attention. Respondents want CLJS/Cherry/Skittle to provide frictionless support for modern JavaScript standards (ES6 and ESM) and would like an overall simplification of the build and run process.

Developer experience issues came up a number of times, including: confusing error messages, poor documentation, and under-supported libraries. Improvements to any of those would be welcome.

Difficulty finding Clojure employment was another recurring theme. Respondents were not sure how to solve it, but suggested a community job board might be helpful.

February 2026 Survey

88% of respondents use or refer to projects funded by Clojurists Together

Plans for Conference Attendance in 2026 (number of mentions):

Clojure/Conj: 8
Dutch Clojure Days: 6
babashka conference: 5
Clojure South: 1
Clojure Jam: 1
reClojure: 1

If you were only to name ONE, what is the biggest challenge facing Clojure developers today and how can Clojurists Together support you or your organization in addressing those challenges? If you could wave a magic wand and change anything inside the Clojure community, what would it be? (select responses by category).

Adoption:

Advertising video like that one on Clojure Conj five years ago or so
Language Adoption and popularity, projects that helps to grow the popularity of the language or helps to start programming easily
Lack of widespread adoption is not a problem… until you want to convince others that Clojure is a technology you can count on and is worth developing with. Convincing others that Clojure is a great and solid technology that’s here to stay, regardless of low(er) adoption, is sometimes tough.
The fact that many teams and project would rule out Clojure as an option, being perceived as niche, far from mainstream, and thus risky
I would have more Clojure evangelism. More videos/blog posts/demos around using Clojure, both about whatever is currently at the peak of the broader tech hype cycle – LLMs currently – as well as uses and topics outside of the hype cycle.

AI/LLMs

Keeping relevant in a programming market is the top challenge. With the IA, everyone is moving toward the most popular languages. If nobody uses Clojure, it is more difficult to justify its use, no matter how much better it could be.
The biggest challenge is the spreading expectation that everything will be done in Python because AI will fix whatever problems Python will allegedly cause.
How will Clojure and the Community fare in the light of LLMs and coding assistants?
We are being encouraged to use Agentic AI coding assistants, but their support for Clojure is behind that of other languages.
How can we articulate the value of Clojure as a sustainable, modern solution when discussion about AI is taking all of the air in the room. We can for example fortify our tooling regards this. Projects such as Calva make Clojure easy to approach for newbies and ClojureMCP is a great tool for Agentic developers.
I am unsure about how LLM driven development fits with Clojure. I find myself building some things with JS and Python. For larger projects I am relying on Clojure for it’s correctness properties and lower likelyhood of bugs.
Support AI integration Clojure projects

Employment

Difficulty finding interesting and reliable work, but this isn’t just Clojure-specific, the whole industry is weird right now.
Finding employment writing Clojure code
I would say that the biggest challenge for Clojure developers is in the job search. I’m not certain of a solution to this challenge, but perhaps some kind of Clojurists Together Job Board?

Developer Experience

Developer tooling improvements competitive with modern JavaScript/TypeScript tooling
Missing parts of the data science stack
Better documentation of the tools and projects and more tutorials
Better integration with cljs/scittle/js/typescript - separate cljs compilation too complicated - scittle/squint/cherry with ES6 integration is the way clojurescript support for ESM libraries. It’s crazy the hoops you have to jump through to use ESM with clojurescript, most people probably assume it’s not possible at all because it’s so difficult.
Closer integration with JavaScript/TypeScript tooling -Seamless integration of cljs/cherry/scittle into the js-ecosystem with live repl and load-file support, standard sente/websocket communication included, standard/default solid telemetry/instrumentation API
Quicker resolution of outstanding Clojure (JIRA) issues
Have a official support program to people that focus on promote the language and/or community instead of library maintainers (like GDE from Google, MVP from Microsoft, Github Stars from Github)
I would encourage “cljc” as a default idiom. The linter could say, “This could be a cljc file!” or “Change this to that and suddenly it would be cljc-compatible”.
It remains Error Reporting imho, and anyone working on improving it would get my eternal gratitude.

What areas of the Clojure ecosystem need support? (select responses)

“I think something around marketing/evangelism; I have worked on several teams using Clojure/ClojureScript that have had to defend the use of Clojure/ClojureScript against more mainstream JVM/JS languages, and the core issue we’ve run up against is a confluence of the following three items:
– 1. there are more Kotlin/Scala/TypeScript/Java developers than there are Clojure/ClojureScript developers
– 2. The salary ranges for those languages tends to be lower than that for Clojure/ClojureScript
– 3. The greatest benefits to be gained from using Clojure/ClojureScript – systems which are far easier to understand, maintain, and extend, thus accelerating business goals – are exceptionally difficult to quantify.”
“data.xml – My ticket has been rotting away for 14 months. :) (XML is a core technology at my company.)”
Repl tooling and setup, more official tutorials and guides. Data validation and schemas.
Data science, clojure for frontend
Guides for LLM driven development that don’t invoke huge piles of software just to modify code.
Growth to new domains and use cases, specifically scientific / academic / teaching

Last Call for Q2 2026 Funding Survey

Mon, 16 Feb 2026 14:00:00 +1200

Greetings Clojurists!

We are about to close our Q2 2026 Funding Survey which helps inform our Q2 project awards. It is not a heavy lift - maybe 5 minutes of your time. But your input is invaluable! A link to the survey was sent to your email in the last few weeks - and just in case it made its way to spam, you can look for “We Need Your Input - Q2 2026 Funding”. The survey closes midnight PST on February 21, 2026.

Thanks as always for your support of Clojurists Together and for being a part of this awesome community.

Any questions, please email me at kdavis@clojuriststogether.org

Kathy Davis Program Manager Clojurists Together Foundation

Clojars Maintenance and Support: November/December 2025 Update

Sun, 25 Jan 2026 14:00:00 +1200

Critical Infrastructure: Clojars Maintentance and Support Update by Toby Crawley

November-December, 2025. Published January 24, 2026

This is an update on the work I’ve done maintaining Clojars in November and December of 2025.
Most of my work on Clojars is reactive, based on issues reported through the community or noticed through monitoring.

If you have any issues or questions about Clojars, you can find me in the #clojars channel on the Clojurians Slack, or you can file an issue on the main Clojars GitHub repository.

You can see the CHANGELOG for notable changes, and see all commits in the clojars-web and infrastructure repositories for this period. I also track my work over the years for Clojurists Together (and, before that, the Software Freedom Conservancy.

Below are some highlights for work done in November and December:

I did lots of dependency upgrades, based on an antq task I added to the project.
I fixed a bug where would still try do generate an email for an address in the denylist, which resulted in an NPE and noise in Sentry.

Annually-Funded Developers' Update: November and December 2025

Tue, 20 Jan 2026 14:00:00 +1200

Hello Fellow Clojurists!

This is the sixth and final report from the 5 developers who received Annual Funding in 2025. You can review their reports from throughout the year here:

Jan/Feb 2025
March/April 2025
May/June 2025
July/Aug 2025
Sept/Oct 2025

Thanks everyone for the fantastic work!

Dragan Djuric: Neanderthal, Deep Diamond, Diamond ONNX Runtime
Eric Dallo: ECA, clojure-lsp
Michiel Borkent: clj-kondo, Reagami, Squint, babashka, SCI, and more…
Oleksandr Yakushev: CIDER nREPL, Orchard, clj-async-profiler, Virgil
Peter Taoussanis: Telemere, Tufte, Sente, Tempel, Carmine, Trove

Dragan Djuric

2025 Annual Funding Report 6. Published January 4, 2026.

My goal with this funding in 2025 is to support Apple silicon (M cpus) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

Having achieved a lot of the goals for this project in 2025 in the previous 10 months, in this funding period, my main effort was concentrated on the icing on the cake.

I improved support for various data types in Deep Diamond (including :double)
improved the implementation of the info method in DD
released Deep Diamond 0.41.0
improved cuda handling of :long descriptors
extended Neanderthal Vector with the support for Tensor protocols,
extended Neanderthal Matrix with the support for Tensor protocols,
simplified the code in various places,
wrote new tests,
GE matrices are now also tensors
fixed the transfer support for integer matrices
implementated integer kernels for vectors and GE matrices in CUDA,
updated Apple BNNS tensor to be compatible with the changes in the last 3-4 months,
fixed leftover reflections in the old BNNS-based engine in DD
released Neanderthal 0.60.0,
released Deep Diamond 0.42.0,
Update upstream onnxruntime to 1.23.2, also build it locally with CUDA to update diamond-onnxrt,
released diamond-onnxrt 0.21.0

I released several new versions of Uncomplicate libraries with these user-facing improvements including:

Deep Diamond
Neanderthal
Diamond ONNX Runtime

Hammock time. Did some research on LLMs and the future Clojure implementation of high-level LLMs based on Diamond ONNX Runtime

I also wrote a tutorial on dragan.rocks. I had plans to write more, but couldn’t find time and energy, since December was especially full with lectures at the university, and I did not want to risk burnout :)

Eric Dallo

2025 Annual Funding Report 6. Published January 6, 2026.

What a year! This was probably the year that I most commited and worked in some many things for Clojure community, all of that thanks to ClojuristsTogether, thank you very much! In November I met so many people at ClojureConj that I work for 5 years and never met personally, it was a very good feeling to talk about so many subjects, projects, and hear about the best people in Clojure community. Check it out the picture with the biggest names in developer tooling for Clojure!

(From left to right: Eric Dallo, Rich Hickey, Peter Strömberg, Michiel Borkent, and Arthur Fücher)

I spent some time preparing my talk that I gave there about ECA which should be available soon for anyone interested.

eca

ECA is growing even faster, with more people using, testing, finding bugs, asking for features, and **I’m confident to say that after 6 months, ECA is a tool as good comparing with big players in the market, being free, OSS, written in Clojure and so much extensible, I’m really happy with the result so far and there are so many ideas and improvements I wanna do next year thanks to community sponsor and support!

0.78.2 - 0.87.2

Add workspaces to /doctor
Improve LLM request logs to include headers.
Add openai/gpt-5.1 to default models.
Fix regression exceptions on specific corner cases with log obfuscation.
Fix absolute paths being interpreted as commands. #199
Remove non used sync models code during initialize. #100
Fix system prompt to mention the user workspace roots.
Improve system prompt to add project env context.
Add support to rollback messages via chat/rollback and chat/clear messages. #42
Add new models to GitHub config (Gpt 5.1 and Opus 4.5).
Update anthropic default models to include opus-4.5
Update anthropic default models to use alias names.
Fix binary for macos amd64. #217
Support rollback file changes done by write_file, edit_file and move_file. #218
Improve rollback to keep consistent UI before the rollback, fixing tool names and user messages.
Support nested folder for rules and commands. #220
Fix custom tools output to return stderr when tool error. #219
Support dynamic string parse (${file:/path/to/something} and ${env:MY_ENV}) in all configs with string values. #200
Improve /compact UI in chat after running, cleaning chat and showing the new summary.
Better config values dynamic string parse:
- Support ${classapath:path/to/eca/classpath/file} in dynamic string parse.
- Support ${netrc:api.foo.com} in dynamic string parse to parse keys. #200
- Support default env values in ${env:MY_ENV:default-value}.
- Support for ECA_CONFIG and custom config file.
Deprecate configs:
- systemPromptFile in favor of systemPrompt using ${file:...} or ${classpath:...}
- urlEnv in favor of url using ${env:...}
- keyEnv in favor of key using ${env:...}
- keyRc in favor of key using ${netrc:...}
- compactPromptFile in favor of compactPrompt using ${classpath:...}
Fix ${netrc:...} to consider :netrcFile config.
Fix ${netrc:...} to consider :netrcFile config properly.
Enhanced hooks documentation with new types (sessionStart, sessionEnd, chatStart, chatEnd), JSON input/output schemas, execution options (timeout)
Fix custom tools to support argument numbers.
Improve read_file summary to mention offset being read.
Enhanced hooks documentation with new types (sessionStart, sessionEnd, chatStart, chatEnd), JSON input/output schemas, execution options (timeout)
Support rollback only messages, tool call changes or both in chat/rollback.
Fix backwards compatibility for chat rollback.
Support providers httpClient version config, allowing to use http-1.1 for some providers like lmstudio. #229
Support openai/gpt-5.2 and github-copilot/gpt-5.2 by default.
Improve agent behavior prompt to mention usage of editor_diagnostics tool. #230
Use selmer syntax for prompt templates.
Support Google Gemini thought signatures.
Support gemini-3-pro-preview and gemini-3-flash-preview models in Google and Copilot providers.
Fix deepseek reasoning with openai-chat API #228
Support ~ in dynamic string parser.
Support removing nullable values from LLM request body if the value in extraPayload is null. #232
Improve read-file summary to show final range properly.
Improve model capabilities for providers which model name has slash: my-provider/anthropic/my-model
Fix openai-chat tool call + support for Mistral API #233
Skip missing/unreadable @file references when building context
Fix regression: /compact not working for some models. Related to #240

clojure-lsp

We finally support vertical alignment in clojure-lsp format via cljfmt, one of the most requested features!
I started a sequence of lots of outdated bumps which fixed some issues and intend to finish on the next release as some break tests and some existing features. Also, we had some new features like squint projects support!

2025.11.28-12.47.43

New keywords completion inside namespaced maps. #2113
Pass current namespace aliases to cljfmt when range-formatting. #2129
bump clj-kondo to 2025.10.24-20251120.193408-8 improving performance, fixing false-positives and supporting java inner classes.
Bump cljfmt to 0.15.5 - adding support for vertical alignment.
Support squint projects when having squint.edn. #2158
Support find definition of java inner classes (Foo$Bar). #2157
Bump babashka/fs to 0.5.28.
Bump opentelemetry to 1.51.0.

Michiel Borkent

2025 Annual Funding Report 6. Published January 6, 2026.

In this post I’ll give updates about open source I worked on during November and December 2025.

To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all! So a sincere thank you to everyone who contributes to the sustainability of these projects.

Current top tier sponsors:

Open the details section for more info about sponsoring.

Sponsor info

Thanks..and more

Mon, 29 Dec 2025 14:00:00 +1200

As 2025 comes to a close we want to reach out and thank you for supporting Clojure, open-source, and the Clojurists Together community.

We’ve been able to accomplish a lot this year with your support.

In 2025, we funded a total of $171,000 of projects. 10 developers completed 12 shorter-term projects ($66,000 USD). 6 developers received a monthly stipend for the year ($105,000 USD in long-term funding). Since 2018, Clojurists Together has awarded more than $1.2 million to 87 developers working on more than 154 projects.

Your input on our quarterly surveys is critical to ensuring that we are funding work that is needed, valued, and adopted by the community at large. 22% of members participate every quarter.

30% of members participated in the process for selecting the developers to receive 2026 annual funding. Thank you for reviewing the proposals and voting!

We appreciate your subscription to our regular news and updates dispatches - as we believe it encourages wider use of the tools and resources of the developers we have funded - strengthening and advancing the open-source and Clojure community. For those of you who subscribe but are not yet members, you can always join the voting community for as little as $5 per month.. For those of you who are already members, even a small increase in membership contributions could enable us to fund more projects. Every little bit helps.

We were able to attend the Heart of Clojure/Conj conference in the U.S. in November - and it was great to see and share with so many of you in person!

The developer’s work we fund is highly valued - and used daily.

In addition to requesting specific tools and improvements, we have heard a consistent call for better documentation (content, presentation, and organization) and more support for engaging and supporting new Clojure users. This year, we received and funded several proposals that focused on these needs and will continue to encourage work in these areas. It is great to see that so many of you refer to and rely on the work the developers have undertaken throughout the year.

Short-Term Projects Funded in 2025

Q2 2025: Bling, CALVA, CIDER, Code Combat, Jank, and Scicloj Building Bridges

Q3 2025: Fastmath, Fireworks, Jank, Malli, Uncomplicate Clojure ML, and Uix

2025 developers receiving annual funding: Michiel Borkent, Eric Dallo, Dragan Djuric, Peter Taoussanis, Oleksandr Yakushev, and Toby Crawley (Clojars maintenance and support).

Fun Facts and Thank You’s

We are truly an international group bringing a wide range of experience. From Q1 2022 to Q3 2025, we funded developers working in 22 countries including Austria, Belgium, Brazil, Bulgaria, Canada, Denmark, England, Finland, France, Germany, Israel, Lithuania, Netherlands, Norway, Poland, Serbia, South Korea, Spain, Sweden, Ukraine, UK and the US.

This staggering amount of work has benefited our members and the broader Clojurist community.
A thanks goes out to all the developers for their commitment and contributions to the community over the last 8 years: Adam Helins, Alexander Oloo, Ambrose Bonnaire-Sergeant, Arne Brasseur, Ashima Panjwani, Baptiste Dupuch, Benjamin Kamphaus, Ben Brinckerhoff, Bobbi Tower, Bozhidar Batsov, Brandon Ringe, Bruce Hauman, Chris Badahdah, Chris McCormick, Charles Comstock, Chris Oakman, Christian Johansen, Christophe Grand, Dainius Jocas, Daniel Higginbotham, Daniel Slutsky,Danny Freeman, David Levy, David Nolen, Dragan Duric, Eric Dallo, Ethan Miller, Gert Goet, Grodziski, Henry Widd, Iizuka Masashi, Isaac Johnston, Jack Rusher, Jacob O’Bryant, James Reeves, Janet Carr, Jeaye Wilkerson, Jeremiah Coyle, John Collins, John Stevenson, Joakim Tengstrand, Joel Holdbrooks, José Luis Lafuente, Juho Teperi, Karl Pietrzak, Karol Wójcik, Kira McLean, Konrad Kühne, Kury Harringer, L. Jordan Miller, Lee Hinman, Lukas Domagala, Mark Engelberg, Martin Kavalar, Matthew Davidson, Matthew Huebert, Matthew Ratzke, Michael Sappler, Michiel Borkent, Mike Fikes, Mitesh Shah, Nikita Prokopov, Oleksandr Yakushev, Oleksii Kachaiev, Oliver Caldwell, Othman Azil, Peter Stromberg, Peter Taoussanis, Rafael Krzyważnia, Roman Luitikou, Sam Ritchie, Savo Djuric, Sean Corfield, Sebastian Zartner, Siyoung Byun, Thomas Clark, Thomas Heller, Tim Pope, Toby Crawley, Tommi Jalkanen, Tommi Reiman, VEMV, Vladislav Protsenko, William Acton, Zach Oakes, Žygis Medelis, and the team at Gaiwan.

Finally, a shout-out to the companies and organizations who have supported our work throughout the year and most for many years. They believe in Open Source development and have made a commitment to Clojure as an important tool for their product, service, and organizational projects. If your company might consider becoming a sponsoring member, please contact Daniel Compton at daniel@clojuriststogether.org to explore further.

Thanks to Map, Transduce, and Filter Members:

And a shout out to the Into, Cons and Assoc Members who Contributed in 2025!

… and another thank you to Revenue Share member Jacek Schae (Learn Reagent, Learn re-frame) and all the 2025 Contributing Members. All of you make this work possible!

Let’s join in celebrating this wonderful community - and hoping for peace in the New Year.

lvh, Maria, Daniel C, Heather, Lorelai, Daniel S., Chrisoph (Clojurists Together Board), and Kathy (Program Manager).

December Q3 2025 Project Updates

Mon, 22 Dec 2025 14:00:00 +1200

As 2025 winds down, we have several Q3 project updates and a few more coming in January 2026 as several are on staggered schedules. A brief summary of each project is included to provide overall context. Thanks to everyone for your incredible work on these projects!

Ambrose Bonnaire-Seargent: Malli
Looking back on this project, it started with a proposal for an external analysis pass that could be used to optimize Malli validators. Now at the completion of the funding period, we’re solving the same problem, but instead of an additional tool, we’re applying the analysis directly within Malli’s validation algorithm.

Thomas Clark: Fastmath
Inasmuch as Lewis Carrol may have creatively objected, complex numbers are now an essential part of modern life: from quantum computing upwards and whether we are aware of it or not. Clojure’s support for these numbers however, remains sporadic while it’s biggest competitor, the well-known comedy snake - and scripting language https://www.geeksforgeeks.org/python/history-of-python/ treats complex numbers as first-class citizens.

With this funding, I would like to address the issue somewhat, particularly with regard to the implementation of complex matrices, but concerning a consistent complex API more generally.

Jeremiah Coyle: Fireworks

Publish Fireworks editor plugins/extensions/integrations for Emacs, VS Code, and IntelliJ. These are fairly simple extensions that involve some basic form rewriting for wrapping/unwrapping forms.
Add support for automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to Chalk. #42
Documentation of interactive workflow.
Enhanced documentation for theme creation.
Call-site options for quick formatting changes. For hifi printing, support call-site option to disable all truncation and ellipsis #14

Dragan Djuric: Uncomplicate Clojure ML
My goal with this funding in Q3 2005 is to develop a new Uncomplicate library, ClojureML.

a Clojure developer-friendly API for AI/DL/ML models (in the first iteration based on ONNX Runtime, but later refined to be even more general).
Implement its first backend engine (based on ONNX Runtime).
support relevant operations as Clojure functions.
an extension infrastructure for various future backend implementations.
a clean low-level integration with Uncomplicate, Neanderthal, Deep Diamond and Clojure abstractions.
assorted improvements to Uncomplicate, Neanderthal, Deep Diamond, to support these additions.
develop examples for helping people getting started.
related bugfixes.
TESTS (of course!).

Jeaye Wilkerson: Jank
This quarter, I’ll be building packages for Ubuntu, Arch, Homebrew, and Nix. I’ll be minimizing jank’s dependencies, automating builds, filling in test suites for module loading, AOT building, and the Clojure runtime. I’ll be working to get the final Clang and LLVM changes I have upstreamed into LLVM 22, adding a health check to jank to diagnose installation issues, and filling in some C++ interop functionality I couldn’t get to last quarter. Altogether, this quarter is going to be a hodgepodge of all of the various tasks needed to get jank shipped.

AND NOW FOR THE REPORTS!

Ambrose Bonnaire-Seargent: Malli

Q3 2025 $9K, Report No. 3, Published December 12, 2025

Looking back on this project, it started with a proposal for an external analysis pass that could be used to optimize Malli validators. Now at the completion of the funding period, we’re solving the same problem, but instead of an additional tool, we’re applying the analysis directly within Malli’s validation algorithm. This is an excellent improvement, but the stakes are now much higher as we’re changing some of the oldest, most foundational code in Malli.

The big news is that recursive validators now compile to recursive functions! This is a major optimization, integrated directly into the heart of Malli.

The road to this point started in 2021, where I prototyped and ultimately—a year later—contributed a subtle enhancement to malli.generator to map recursive schemas onto recursive generators. The main insight: recursive schemas can be detected by finding cycles of Malli refs.

Over the last few months, I knew I needed to really nail why this works before exploiting it to optimize Malli’s validation.

This culminated in a simple but clarifying documentation improvement in which we learn something new about Malli itself.

I’ll include it in full here:

Mutable registries are a dev-time abstraction

For performance reasons, Malli heavily caches registry lookups once a schema has been created via m/schema.

Don’t rely on registry mutations to be recognized consistently unless all schemas are reparsed. Here’s a simple example:

(def registry*
  (atom {:int (m/-int-schema)
         :string (m/-string-schema)
         ::node :int}))

(def eagerly-cached
  (m/schema ::node {:registry (mr/mutable-registry registry*)}))

(swap! registry* assoc ::node :string)

(-> eagerly-cached m/deref m/form)
;; => :int

Even atomic transactions mutating multiple schemas simultaneously in a mutable registry is not reliable, as a parsed schema may have cached one eagerly, and another lazily, leading to inconsistent results. See malli.core-test/caching-of-mutable-registries-test for demonstration of this phenomenon.

In practice, this is analogous to Clojure’s treatment of vars. If a var is mutated, the most reliable general strategy to recognize the update is to refresh all namespaces that use that var. Similarly, if a registry is mutated, the best strategy for recognizing the update in all schemas is to recreate all schemas.

Back to ref cycles, this doc is relevant to recursive schemas because the cycle detection algorithm also breaks in the presence of unprincipled mutating registries. If we assume registries are immutable for the duration of cycle detection, then the algorithm seems air-tight to me, and so we went forward with using ref cycles to compile to recursive schemas to recursive validators.

Recursive validators are superior to the previous approach because:

they can be fully compiled ahead of time
they take constant space relative to their inputs, before it was linear in the maximum depth of the validated input
they only need to compile one layer of recursion, before it was equal to the maximum depth of the validated input

While this is a great improvement, there is even more we can do, with even higher impact. Not everyone uses recursive schemas, but it’s much more common to use refs more than once such as [:tuple ::expr ::expr]. Malli’s handling of validators for such schemas could be greatly improved. Here’s how I explained it to Malli’s maintainers:

Plumatic Schema solves this by caching validators for all schemas during compilation. In addition to handling recursive schemas, it also prevents a nasty exponential blowup of compilation size for even non-recursive schemas, that Malli also suffers from.

Malli’s validator compilation is exponential. This registry demonstrates how:

(def registry {::creates-1-validator [:tuple]
               ::creates-2-validators [:tuple ::creates-1-validator ::creates-1-validator ::creates-1-validator ::creates-1-validator]
               ::creates-16-validators [:tuple ::creates-2-validators ::creates-2-validators ::creates-2-validators ::creates-2-validators]
               ::creates-64-validators [:tuple ::creates-16-validators ::creates-16-validators ::creates-16-validators ::creates-16-validators]
               ::creates-256-validators [:tuple ::creates-64-validators ::creates-64-validators ::creates-64-validators ::creates-64-validators]
               ::creates-1024-validators [:tuple ::creates-256-validators ::creates-256-validators ::creates-256-validators ::creates-256-validators]
               ::creates-4096-validators [:tuple ::creates-1024-validators ::creates-1024-validators ::creates-1024-validators ::creates-1024-validators]
               ::creates-16384-validators [:tuple ::creates-4096-validators ::creates-4096-validators ::creates-4096-validators ::creates-4096-validators]
               ::creates-65536-validators [:tuple ::creates-16384-validators ::creates-16384-validators ::creates-16384-validators ::creates-16384-validators]
               ::creates-262144-validators [:tuple ::creates-65536-validators ::creates-65536-validators ::creates-65536-validators ::creates-65536-validators]
               ::creates-1048576-validators [:tuple ::creates-262144-validators ::creates-262144-validators ::creates-262144-validators ::creates-262144-validators]
               ::creates-4194304-validators [:tuple ::creates-1048576-validators ::creates-1048576-validators ::creates-1048576-validators ::creates-1048576-validators]})

With this registry, each level of depth N compiles (m/validator ::creates-1-validator) 4^N times.

e.g., (m/validator ::creates-4194304-validators) compiles (m/validator ::creates-1-validator) 4,194,304 (4^11) times.

Plumatic Schema would only compile it once. It’s not so trivial to achieve with dynamically scoped refs, but it’s the same idea as detecting ref cycles, which we can now do reliably. Here’s a reproduction of the issue https://github.com/frenchy64/malli/pull/36/files which I have been pondering since discussing https://github.com/metosin/malli/pull/1180

I may propose work on this for a future Clojurists Together project, please stay tuned.

Thank you Clojurists Together and the Clojure community for funding this project, it was highly enjoyable and I learnt a lot.
I hope you find the results useful.

Thomas Clark: Fastmath

Q3 2025 $2K, Report No. 1, Published December 8, 2025

Overview
Surveying the scene
Revised goals and towards future-proofed user-experience
Outlook

Overview

Due to various circumstances - life, the universe and everything etc. - this project started significantly later than it should have and I apologise for that. It did however gain momentum quickly. Below, I consider the progress, as measured both chronologically and according to milestone. In a nutshell though, I have considered different possible avenues of implementation, played with various API strategies and made a couple of draft implementations.

Surveying the scene

The first task of the project was to more concretely situate the goals with respect to what already exists: that is, with respect to `fastmath` itself, the wider Clojure ecosystem and the available java libraries.

It was clear from the outset that `fastmath` hadn’t yet implemented complex matrices, but how real matrices and complex numbers themselves were implemented, was still a question. Thanks to a valuable discussion with generateme though, I had my first look at the depths and came to understand the mixture of Apache Commons and hard-coded Clojure that made up the library as it was.

It was concluded that `core.matrix`, rightly or wrongly, was currently dead to the community and not the right avenue for this project. The next big Clojure allies were Neanderthal and dtype-next. Both of these are very powerful and mature, but neanderthal was considered too low-level for fastmath and dtype-next, although potentially promising, would realistically require a lot of original code writing, with most operations and decomposition etc. needing to be implemented manually. The maths section of the `qclojure` library was also considered with interest, but it wasn’t implemented with efficiency as a goal. Instead, it will be used as something of a model consumer for this complex matrix project.

The conclusion therefore, was, at least initially, to wrap a java library. But which one? And how? The natural choice, would have beeen to extend the coverage of Apache Commons, but, as a working physicist, performance is a strong goal for me and it seemed that there were faster options available. Surveying the existing documentation online, `jblas` looked powerful, but has complicated dependencies and so the best all round options (as demonstrated by the Java Matrix Benchmark, and filtered by available ’complex’ API) seemed to be EJML and ojAlgo. I experimented with both of these libraries somewhat and my feeling is that ojAlgo has the greater performance, but that it’s API is much less intuitive. It took me significant time to work out how to do basic constructions and operations - and I also found a bug that required reflection (in the Java sense!) to overcome. Using EJML however, was very straightforward and I could quickly draft a solution. Going forward therefore, in the knowledge that this project has a finite deadline, I decided to continue with EJML, but with a caveat. I wanted to keep the implementation details abstracted, so that we can swap alternative backends in and out more easily in the future.

Revised goals and towards future-proofed user-experience

Realising that I might have to change how complex ’numbers’ are implemented opened up a considerable can of worms, as did the temptation of unifying the complex implementation with the real implementation. In fact, (over)thinking and implementing a separation of user experience from the Java backend took up much of the remaining time so far. And the decision of how much to change of the existing `fastmath` API is an ongoing question, that will have to be finalized with generateme in the second half.

Fundamentally, the tension in this project is to make a library that is easy to use for maths/physics-minded people, is flexible enough to be extended into the future and yet still still fast enough to live up to the library’s name. The current solution therefore is a sophisticated hierarchy of protocols: to represent mathematical identities, and for fast implementation; as well as a new, versioned, multimethod-based API. This second layer features overloaded mathematical operators such that the full linear algebra stack can be used intuitively, with operator ordering and type coercion happening ’under the hood’. If this proves too much of a performance cost though, then you can simply revert to the explicit protocol methods.

As an example, rather than `fastmath.protocols.matrix` beeing one of only two protocols, we now have a full mathematical structure available, with implementations like `fastmath.algebra.object.number.complex.ejml` and `fastmath.algebra.object.matrix.rectangular.complex.ejml`. This provides more obvious places for future specializations or alternative backends.

With mathematical properties, we can use Clojure protocols as they were intended, for flexibility and without reinventing the wheel, when it comes to how to partition functions. For example, a complex number, can now be easily implemented according to its definition: as ’a field on a normed space that has complex and polar coordinates’. What is a field you might ask? Well, it’s an algebraic structure that forms a ring and a multiplicative group. As an example, that last sentence can now be represented programmatically (below). And by structuring the protocols this way, we get polymorphism across different types and domains for free.

(ns fastmath.protocol.algebra.structure.field
  (:require [fastmath.protocol.algebra.structure.ring :as ring]
            [fastmath.protocol.algebra.structure.multiplicative.group :as mgroup]))

(defprotocol  Field)

(def add ring/add)
(def multiply ring/multiply)
(def negate ring/negate)
(def one ring/one)
(def zero ring/zero)

(def inverse mgroup/inverse)

(defn ? [x]
  (and
   (ring/?  x)
   (mgroup/?  x)
   (satisfies? Field x)))

Outlook

Having considered the architecture, API creation and first implementation tests, the project, as a whole, is on a firm footing for development. With the expansion of API goals however, the proposal metrics will have to be reprioritised. In this light, the next steps will be to widen the matrix implementations beyond basic operations and to integrate them with other `fastmath` functions, like decomposition and fourier functions. After this, I will focus on integration with the `clay` system, so that some sort of report and documentation can be published on time. On the current trajectory, it’s not clear that the performance comparisons, for example, will be completed during the official funding period, but, if not, they will surely follow promptly.

Jeremiah Coyle: Fireworks

Q3 2025 $2K, Report No. 2, Published November 30, 2025

I’m happy to report that 5 of the primary goals and 6 of the secondary goals were achieved in Q3. Many thanks to Clojurists Together for supporting this work!

Primary goals

Add support for automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to Chalk.
#42
Completed
Support call-site option to disable all truncation and ellipsis
#14
Completed
Documentation of interactive workflow:
- deps.edn sample project
- Leiningen sample project
VS Code Integration
Completed
Cursive / IntelliJ Integration
Completed
Emacs Integration
In progress. Work on this will commence and once a sufficient amount of data from the use of the Joyride and Cursive implementations is gathered. This will inform any unforeseen details about ergonomics and/or implementation details.

Secondary goals

Allow for call-site changes to the label color.
#53
Completed

(? {:label-color :red} (+ 1 1))

Flag for eliding truncation and ellipsis at callsite
#77
Completed

(? :+ my-coll)
;; as shorthand for:
(? {:truncation? false} my-coll)

Add option to produce bold output.
#70
Completed

(? {:bold? true} (+ 1 1))

Add option to format the label as code.
#82
Completed

(? {:format-label-as-code? true}
   (mapv (fn [i] (str "id-" i))
         (range 20)))

Add function to set options globally for project, at runtime, with a config! macro.
#81
Completed

(fireworks.core/config!
 {:format-label-as-code? true
  :template              [:file-info :form-or-label :result]
  :label-length-limit    100})

Properly display contents and badges of native js data structures, when they are within a native cljs data structure.
#46
Completed

(? [#js {:a 1 :b 2}
    (new js/Set #js["foo" "bar"])
    (into-array [1 2 3])
    (new js/Map #js[#js[3 1] #js[4 2]])
    (new js/Int8Array #js[1 2 3])])

The latest release of Fireworks is v0.16.1, which features the enhancements listed above.

Dragan Djuric: Uncomplicate Clojure ML

Q3 2025 $9K, Report No. 3, Published December 1, 2025

Final progress after the third month:

In the first two months, I have already released more than 10 versions to Clojars as org.uncomplicate/diamond-onnxrt, with the progressively better coverage of the onnxruntime’s C API, established a nicer Clojure API for onnxruntime internals, higher level Deep Diamond and Neanderthal model integrations, and make inroads into GPU support with CUDA.

In the third month, i tried several typical open models, and did the development and refinements to support the necessary features required by these real-world examples.

I refined the low-level and high-level model support incrementally, to support as much automatic wiring of the models with Clojure as possible, and I am quite pleased with the result. One of the goals of all Uncomplicate libraries is to offer access to all abstraction levels to Clojure programmers: from the lowest fine grained just above the C API, to the highest “magic” that configures itself, and we supported this here to the fullest. Everyone can use the internal core namespace to program every single detail by themselves in Clojure - if they wish so - while they also can leverage mid-level abstract functions that build standalone models, OR, let Deep Diamond do everything for themselves. There’s something even handier: even the most abstract level supports detailed configuration of the models, with sane defaults. This is what I spent most of the time in the third month of the project: the overall usability and polishing!

The final result: now we can load a model, and almost everything related to loading and setting that model up with Deep Diamond’s Clojure tensors is automatic. If we want to configure most of the stuff that can be configured, it’s an options map away, with nice Clojure keywords, while we don’t have to worry how that configuration produces its results. At the same time, if the users have more specific requirements, or they don’t like how I implemented it, or they simply just want to learn, they still have a ladder down the rabbit hole, and they can use any of the lower layers as they please, as independent nuts and bolts for their own creations.

I released a few more versions to Clojars (the most recent one is 0.20.0).

An example of what we can do now is that we can now clone a Hugging Face repository of Google’s open model Gemma 3 in ONNX format, we can load it without much hassle as DD blueprint, instantiate it as a standalone layer function, get the access to input and output parameters as nice DD Clojure tensors, easily load them with data, and run the model as a straightforward Clojure function evaluation! Now, a casual onlooker would think: “Great. Now I just load Gemma 3, and I have a home-sized mini Gemini!” Well, no. This model accepts tensor full of numbers, and it can infer tensors full of numbers that indicate next token(s). But, LLM is more than that. It accepts strings (or images, etc) re-computes these strings into appropriate numbers (tensors), runs the inference in a loop, bookkeep various context tensors, makes sense of the output numbers, etc. That’s a whole new level of application of these moving parts, and requires another level of applicative automation. Some models do not need that applicative automation, but LLMs are more complex beasts.

So, looking back at what I proposed to implement, I would declare that I’m quite happy that I achieved everything planned, and even achieved a simpler API than envisioned at the start.
No we can bite even at the LLMs at the next step, which is a focused effort on its own.

Jeaye Wilkerson: Jank

Q3 2025 $9K, Report No. 3, Published November 30, 2025

Howdy folks! Thank you so much for the sponsorship this quarter. This month was Conj 2025 month, so leading up to the Conj I was very focused on preparing for my talk and two different Conj working groups. Outside of that, though, I have been tackling overall jank stability. The number one concern there was GC stability, since our GC usage of BDWGC (Boehm) was leading to either leaks or intermittent crashes. In total, this has involved three weeks of spelunking in both the GC code and jank’s code.

The crashes were nearly always caused by the GC prematurely collecting an object because it could no longer find a usage of it. In some cases, this happened because that object was only accessible from the system heap (i.e. normal new or malloc), rather than the GC heap. These cases could be fixed by correct usage of the GC allocator for C++ collections, which we sometimes missed. In another case, jank was using a thread-local collection to store Clojure bindings. However, on Linux, thread-local memory is stored separately from normal memory, so the GC is unable to find references to the objects within that collection. Finally, I have found that there are some aspects of our LLVM IR generation which lead the GC to prematurely collect. I have solved some of these issues, but more investigation and development remains. Curiously, though, I found that using jank’s C++ code generation, rather than LLVM IR, skirts these issues.

To prioritize stability for the upcoming alpha release in December, I decided to focus on C++ generation as the default. This has required some catching up, since we’ve been running both for a while but we’ve been focusing on LLVM IR. Now, at the end of the month, all tests are passing with C++ code generation and there are no known GC issues on macOS and Linux. I’ll continue developing the LLVM IR generation, to resolve these issues, but I’ll take the time needed to do it right. Until then, C++ generation as a default provides many benefits and no behavioral change.

The biggest remaining task for the alpha release is now documentation, which I will be tackling in the next few weeks. Then it’s alpha time!

Clojurists Together 2026 Annual Funding Announcement

Tue, 16 Dec 2025 14:00:00 +1200

The votes are in!! Clojurists Together members have voted to to fund 5 developers $1.5k/month for 12 months ($90k USD total!). We’re pleased to announce the following developers/teams who will be funded:

Bozhidar Batsov
Michiel Borkent
Clojure Camp
Eric Dallo
Jeaye Wilkerson

We are very excited to see what these developers will do over the next year. They will share updates of what they’ve been working on, and we’ll post and email them as part of our regular updates. You’ll find summaries below of what each of these developers plan to work on (although they are just a starting points and they’re free to change their plans as they see fit). If you want more detail, you can refer back to the proposals submitted on our website.

Thanks to the all of you - the Members - who took the time to review the applications and make the difficult decision to select just 5 from many excellent proposals. Congratulations are in order to Bozhidar, Michiel, Eric, Jeaye, and the Clojure Camp team! For everyone else who submitted their projects, there will be more grant opportunities in 2026 - so keep posted.

Bozhidar Batsov

https://github.com/bbatsov

Continuously improving CIDER, nREPL, clojure-ts-mode and their related projects. Building a formal nREPL specification is one of the bigger challenges I hope to tackle next year. As is fully decoupling clojure-mode from CIDER.
Most of the projects are hosted under the following GitHub orgs:
https://github.com/clojure-emacs https://github.com/nrepl

Michiel Borkent

https://github.com/borkdude

My main projects are clj-kondo, babashka / SCI, and squint/cherry.
Links:
https://github.com/clj-kondo/clj-kondo
https://github.com/babashka/babashka
https://github.com/babashka/sci
https://github.com/squint-cljs/squint

I have identified the following long-term goals that I want to focus on in 2026:

Clj-kondo: run macros directly from source code
Clj-kondo: run exported configs/hooks directly from classpath (instead of having to copy files to a local dir)
Squint/Cherry: browser nREPL support
Squint/Cherry: source maps
Squint: protocolize coll functions so you can extend them to e.g. ImmutableJS or other custom collections
Scittle2 (working name): better/faster/smaller version of Scittle using Cherry (in-browser CLJS compiler)
Babashka: support CIDER middleware from source directly in bb
Babashka: distinguished parallel task output (e.g. colors or prefix)
Clj-kondo: add first-class support for Clojure dialects like ClojureDart and Jank
Clojure CLI: help improve UX via a new tools working group
Clj-kondo: performance improvements for bigger projects

Apart from these long-term goals, there are plenty of maintenance-type issues to work on. Babashka consists of several libraries like SCI, fs, process, deps.clj, http-client and edamame that benefit not only babashka, but also the wider Clojure ecosystem. These libraries all need some love from time to time. There are several ideas to improve clj-kondo with more linter rules as well.

Clojure Camp

(Rafal Dittwald, Jordan Miller, and others)
https://clojure.camp

Continue various existing Clojure Camp projects:

supporting new developers to attend Conj and other Clojure conferences (travel bursaries, and or/ organizing and subsidizing shared accommodation)
continue our peer-to-peer pairing program, with a new goal to also appeal to existing Clojurians
continue offering weekly online vents (mobs, office hours, etc)
improve communication of our offerings (by regularly posting)

Explore new Clojure Camp projects:

develop our “curriculum map” into a learning roadmap and badge system
facilitate a mentorship program, pairing Clojure OSS devs with other devs (junior and senior)
experiment with hosting “micro-conjs” (6-10 person, in-person weekend coding retreats)

Eric Dallo

https://github.com/ericdallo

ECA (Editor Code Assistant)
This project was born 5 months ago (with clj-together’s help!) and it’s growing, there are so many improvements to this project related to features and parity with other big tools like Claude/Cursor, compatibility with more editors, fix and support community issues. This AI tool is written in Clojure but works in any language which is huge for discoverability of Clojure community outside Clojure bubble, it has a lot of potential in my opinion, and projects for each editor to maintain and evolve.

Clojure-lsp
I want to work on custom code actions, support for new clojure.java.javadoc lib, improve java interop support like go to class locations, methods etc, lots of this would require me working in clj-kondo too

metrepl
I want to help with guide and examples of metrics of your repl and how that can help companies understand developers REPL usage

Jeaye Wilkerson

https://github.com/jeaye

I will be working full-time on jank.

jank’s alpha release is going out in December 2025, which will lead us into a hectic start to 2026 as we’ll be collecting/fixing as many bugs as we can. Meanwhile, I will be developing jank’s build system for native system dependencies, improving stability, significantly improving performance, and adding the remaining features to achieve strong Clojure parity (records, protocols, futures, etc). Furthermore, I will be authoring the jank book, which will be a free standalone resource for learning jank (and Clojure), inspired by and very similar to the Rust book.

I will also continue to lead the clojure-test-suite initiative, which provides thorough unit test coverage for all core Clojure functions and is currently serving Clojure JVM, Clojure CLR, ClojureScript, babashka, and jank. I aim to capture ClojureDart and Basilisp in 2026 and I have already started discussions with the creators of both dialects.

I am currently mentoring four different open source contributors, who’re learning to be compiler hackers, and I aim to pick up a fifth during 2026. I’m specifically looking to add a Clojure lady to the gang and I began outreach for this at the Conj.

Additionally, I will continue streaming on Twitch regularly, to raise Clojure awareness. I will generally use that time to either develop jank itself or to use jank to develop Clojure-related tooling.

Overall, my goal for EOY 2026 is production readiness for jank. This is an aggressive goal, but I will work aggressively on it.

Thanks

Thanks again to all of our members for selecting these developers. If it wasn’t for your generous support, this wouldn’t be possible. A special thanks goes to Latacora, Roam Research, Whimsical, Nubank, Cisco, JUXT, Metosin, Solita, Grammarly, Nextjournal, ClojureStream, Shortcut, Flexiana, Toyokumo,doctronic, and 180° Seguros. They have all contributed significant amounts to Clojurists Together which helps us award $90,000 in long-term funding to Clojure developers in the coming year.

Vote on 2026 Annual Funding

Tue, 02 Dec 2025 14:00:00 +1200

Greetings Clojurists Together Members! Last year, based on your feedback, we tried a new process to identify annual funding recipients. It was a vast improvement from years past, so this year we are using it again.

We put out the call - and we received 16 applications for you to consider. The board reviewed and voted to move all 16 to the 2026 Ranked Vote ballot.

Now it is up to you, the members, to select the 5 developers who will each receive $1,500 monthly stipends (for a total of $18K USD). Be on the lookout for an email that contains the link to your Ranked Vote ballot. Deadline for voting is 12 December 2025 midnight Pacific Time.

You can review past long-term project updates on our website to get an idea of what past annual (or long-term) funding recipients have been able to accomplish with your support (pretty amazing!)

Thanks again to all the members for making this happen. We know from our surveys that you and the larger Clojurist Community that receive our project updates refer to this work on a regular basis - 83% daily or several times a week! This is a testament to its importance of these projects.

Deadline for your vote to be counted: December 12, 2025 Midnight Pacific Time

Here we go ..in alphabetical order (by last name)….
Bozhidar Batsov
Adrian Bendel
Michiel Borkent
Clojure Camp (Rafal Dittwald, Jordan Miller, and others)
Thomas Cothran
Alex Coyle
Jeremiah Coyle
Eric Dallo
Dragan Djuric
Siavash Mohammady
Nikita Prokopov
James Reeves
Tomasz Sulej
Peter Taoussanis
Jeaye Wilkerson
Oleksandr Yakushev

Bozhidar Batsov

https://github.com/bbatsov

What do you plan to work on throughout the year?
Continuously improving CIDER, nREPL, clojure-ts-mode and their related projects. Building a formal nREPL specification is one of the bigger challenges I hope to tackle next year. As is fully decoupling clojure-mode from CIDER.

Most of the projects are hosted under the following GitHub orgs:

Why is this work important to the Clojure community?
CIDER and nREPL are two of the pillars of the Clojure community and are widely used by Clojure developers. The libraries developed originally for CIDER (cider-nrepl, refactor-nrepl, orchard, etc) are used by many other development tools as well.

Adrian Bendel

https://github.com/onbreath

What do you plan to work on throughout the year?

Clay

Recently I’ve started to collaborate with people in the Scicloj-community on extending and improving Clay. Clay is superficially similar to other notebook environments, literate programming and visualization systems, but unique in that it acts as a companion to the REPL, situating itself in the workflow we’re used to.

We started work on features that were on halt for quite a while. For now this is primarily about extending Clay to be able to integrate with other runtimes, where we’re using Babashka for a prototype. This is still in an exploratory and design phase, though we already have Clay working in Babashka, there is testing and backwards compatibility to ensure. Further, just building whole notebooks in different Clojure dialects is not necessarily the end goal here, because it is much more interesting to use the large ecosystem of the JVM and Clojure proper to integrate and work with data from other runtimes and their Clojure dialects.

Overall this work is primarily to prepare for integrating with Jank, as soon as that is feasible. There are lots of C++-projects in scientific computing, machine learning and similar fields. Being able to interface with them directly, in a REPL integrated notebook environment, would potentially help a great deal in advancing Clojure’s use in those fields. Other Clojure dialects are of interest as well, but have a lower priority for now.

The second area that needs work is integrating Clay more with the different Clojure programming environments. While solutions for integration with Emacs, Calva, Conjure and Cursive exist, the error reporting of Clay should be improved and better integrated with the development environments where possible. Since some of the primary work above, with different runtimes, already encompasses possible nREPL-based integration, this could also be leveraged for improved error reporting in packages/extensions.

My great hope for Clay is that its use in Civitas (see link below), a community and publishing platform for articles, books, tutorials etc. on Clojure will, as its developer Timothy Pratley intended, further the exchange of ideas in the Clojure community and beyond.

On Civitas there are also great opportunities to extend the Clay rendering system to support different kinds of Clojure code visualization. With Stratify (see below), clj-kondo and Flowstorm among many others, we have great sources for code structure, metrics, analysis and traces of our program. In many cases those tools are not used, only used very situated or are vendor locked, as Stratify’s DGML based code structure graphs, which can only be viewed properly in Visual Studio on Windows.

At the same time, we have a lot of the tools needed to mold this information into polished code quality reports, internal documentation and similar. A common complaint about Clojure is its dynamic nature and dense, opaque code structure. But what if we leveraged readily available technology to introspect and visualize our programs? I want to approach this topic by writing articles on the work we do on Clay, in Clay, publishing to Civitas, showcasing Clay’s architecture and operation. This should exemplify some of the tools available in everyday work with Clojure. It is also an opportunity to develop a library that uses readily available automatic graph layout engines to render DGML to SVG, to visualize and possibly interact with code structure. Other visualizations necessary for the reporting mentioned before are also of interest.

I know, this seems very broad, but I rely on and deeply appreciate the collaboration with the other maintainers at Scicloj, to keep focus and set priorities as they seem feasible and necessary.

https://scicloj.github.io
https://clojurecivitas.github.io
https://github.com/dundalek/stratify

Why is this work important to the Clojure community?
Integrating Clay with Clojure dialects on runtimes that are used in scientific computing etc. Showcasing and extending the ecosystem of tools to make sense (and images!) of all our work.

Is there anything else you would like us to know?
I have another, older GitHub account that shows I’ve been around for a while, though not as a prolific open source contributor, but great explorer:

Michiel Borkent

https://github.com/borkdude

What do you plan to work on throughout the year?
My main projects are clj-kondo, babashka / SCI, and squint/cherry.

Links:
https://github.com/clj-kondo/clj-kondo
https://github.com/babashka/babashka
https://github.com/babashka/sci
https://github.com/squint-cljs/squint

I have identified the following long-term goals that I want to focus on in 2026:

Clj-kondo: run macros directly from source code
Clj-kondo: run exported configs/hooks directly from classpath (instead of having to copy files to a local dir)
Squint/Cherry: browser nREPL support
Squint/Cherry: source maps
Squint: protocolize coll functions so you can extend them to e.g. ImmutableJS or other custom collections
Scittle2 (working name): better/faster/smaller version of Scittle using Cherry (in-browser CLJS compiler)
Babashka: support CIDER middleware from source directly in bb
Babashka: distinguished parallel task output (e.g. colors or prefix)
Clj-kondo: add first-class support for Clojure dialects like ClojureDart and Jank
Clojure CLI: help improve UX via a new tools working group
Clj-kondo: performance improvements for bigger projects

Why is this work important to the Clojure community?
Clj-kondo and babashka are used by a large portion of the community and available in popular editors like Calva and Cursive. I think it’s fair to say they are established projects and lots of people rely on them from day to day.

Babashka is used by 90% of Clojure Survey respondents who answered the question “What Clojure dialects do you use”, as shown in Alex Miller’s 2024 Conj talk. Babashka and clj-kondo have 4.4k and 1.8k stars on GitHub respectively. Their channels on Clojurians Slack have almost 1900 + 1000 users.

Is there anything else you would like us to know?
Thank you so much to Clojurists Together for keeping the Clojure OSS ecosystem sustainable!

Clojure Camp (Rafal Dittwald, Jordan Miller, and others)

https://clojure.camp

What do you plan to work on throughout the year?

Continue various existing Clojure Camp projects:

supporting new developers to attend Conj and other Clojure conferences (travel bursaries, and or/ organizing and subsidizing shared accommodation)
continue our peer-to-peer pairing program, with a new goal to also appeal to existing Clojurians
continue offering weekly online vents (mobs, office hours, etc)
improve communication of our offerings (by regularly posting)

Explore new Clojure Camp projects:

develop our “curriculum map” into a learning roadmap and badge system
facilitate a mentorship program, pairing Clojure OSS devs with other devs (junior and senior)
experiment with hosting “micro-conjs” (6-10 person, in-person weekend coding retreats)

Why is this work important to the Clojure community?
Clojure Camp aims to help new Clojurians integrate into the Clojure community, particularly those who may be under-served by existing self-directed methods. We’d like to be the place for existing Clojurians to send anyone struggling with getting started with Clojure. Our current approach is to foster a welcoming community and provide educational scaffolding (pairing, events, resource lists, roadmap). Going forward, we hope to focus more on “connection”: creating more opportunities for new Clojurians and existing Clojurians to interact and work together.

Is there anything else you would like us to know?
Clojure Camp is now an incorporated non-profit (in Ontario, Canada). Ideally, this funding would go to the organization, not to an individual.

Thomas Cothran

https://github.com/thomascothran

What do you plan to work on throughout the year?
I plan to work on pavlov:

Pavlov is a functional implementation of behavioral programming, which is a programming paradigm invented by David Harel, the creator of statecharts. This ACM article is a good introduction to the idea:

Pavlov is currently in alpha status. It is well tested (in Clojure) and has been reliable in production use. It has a number of useful features on top of the behavioral programming core:

A model checker that verifies safety properties (though not yet liveness properties)
Program states can be programmatically navigated using datafy and nav
A portal-based program explorer, where you can point and click through program execution paths (including time travel)

However, there are a few things I’d like to do to get it to a stable release:

Better testing with Clojurescript. While the Clojure test suite is comprehensive, the Clojurescript tests do not provide as much coverage.
Recipes document showing how to solve common problems with pavlov.
LLM instructions. Context7 has not been adequate in production, and LLMs need a bit more guidance.

After the stable release, I would like to work on:

A more robust program explorer. The portal-based one uses the nav support. However, it is clunky and it doesn’t visualize the program execution paths in a single view as a graph.
Durable execution. Pavlov’s behavioral programming implementation is designed to be fully serialized. Durable execution is not yet implemented.
Demo applications. Since behavioral programming is not a well-known paradigm, demo applications will be useful to help the community understand it.

Why is this work important to the Clojure community?
Behavioral programming is, I believe, uniquely suited to Clojure. In part, this is because behavioral programming is, in principle, very loosely coupled. At the same time, it enables developer tooling that makes it easy to use and test.

But Clojure’s functional and data-oriented approach solves a lot of problems with implementing behavioral programs. For example, the canonical implementation on the JVM relies on serializing threads. With Clojure, we represent behavioral threads as data. This opens the door to a lot of nice tooling, such as program explorer GUIs and durable execution.

I previously wrote an article expanding on this question here:.

Alex Coyle

https://github.com/alza-bitz

What do you plan to work on throughout the year?
My Clojure API for Snowflake:

This project is non-commercial and open-source. I planned to develop and test it in collaboration with academics, data scientists and others in the Clojure community, in order to help solve real-world data challenges.

The aims are as stated in the readme, with specific focus on extending the API coverage and adding features that are planned but not yet elaborated

Note: the build is only failing because my Snowflake license has expired.

Why is this work important to the Clojure community?
I recently wrote on Civitas concerning the extent of Clojure support for the popular on-cluster data tools and why it’s important. In the article I also introduced my new Clojure API for Snowflake:

I believe these efforts are beneficial to Clojure because it puts the language in front of a different community and makes it more accessible in a space where it doesn’t really have any visibility at the moment.

Is there anything else you would like us to know?
This proposal isn’t strictly limited to Snowflake, the scope could most definitely include other on-cluster tools that I write about in my article. For example, I identified some key fixes and improvements for using Spark from Clojure, either to be made in the existing Geni library or in a completely new library:

Supporting Spark Connect:. This would reduce the complexity of using Spark SQL & Dataframe APIs directly from the Clojure REPL and also align with client usage for GoLang, Python, etc. I already did some investigation on this:
Supporting Databricks:

Jeremiah Coyle

https://github.com/paintparty

What do you plan to work on throughout the year?
These are the 5 projects that I have been working on in 2025, and plan to continue working on in 2026. All are fairly mature alpha-stage projects.

Project #1 Bling
Bling provides hifi console printing for Clojure, ClojureScript, and Babashka.
Thanks to the generous support from Clojurists Together, I’m happy to report that a great deal of progress was made in Q2 of 2025. Building on the momentum, I would love to continue to grow and improvement the project going forward.

The 2026 Roadmap for Bling can be found here:

Project #2 - Kushi
Kushi is UI design library for ClojureScript
Source repo:
Interactive docs:

Progress in 2025:
Thanks to the generous support of an experimental projects grant from Clojurists Together in Q3 of 2024, great progress was made towards the goal of delivering a rich, first class, Clojure(Script)-native UI framework for building and evolving web projects. That momentum was leveraged to maintain an increased focus on the project in Q1 of 2025, with an emphasis on refining the architecture and performance of the build system. In q2, I updated the design for the project splash page. I resumed work on the project in Q3 & Q4, concentrating on the Malli-driven runtime safety / warning system, as well as rethinking and implementing an improved shared property system for styling of the library of stock UI components.

Goals for Kushi in 2026:

Continued refinement of the build system. This part of the project has recently been re-written and evolved to efficiently precompile all css via source analyzation at build-time. The build system currently assumes shadow-cljs. I would like to keep it moving in the direction it is currently headed, towards a completely standalone side-process.
The styling story is very much evolving in a direction which promotes the tweaking of UI via making adjustments to Kushi’s well-thought-out design token system. In concert with the pre-built ui components, this means there is a reduced need for CSS and style syntax within components themselves.
Like most UI libs, Kushi is designed to be agnostic with regard to the underlying rendering framework. I am currently working towards providing a comprehensive quickstart kitchen-sink project for both Reagent and Uix.
Add more functionality, docs, and examples for working with the kushi.playground namespace. The playground gives the user an elegant way to build their own white-labeled interactive documentation site that features Kushi base components in addition to any custom components specific to their project. It is similar to Storybook.js or Portfolio (cjohansen/portfolio). The playground namespace was used to create the current project website at kushi.design. I would like to add a separate section for configurable cut-and-paste Design Blocks. Design Blocks are like recipes for composing library UI primitives into common UI patterns. Many of these could be transpiled from existing open-source examples in mainstream JS-land. I think this could offer tremendous value when combined with the above mentioned universal component transpiler.
Design and implement 4-5 global themes, using a variety of styles, and incorporate them via a theme switcher into the kushi.design site. I think this would open up a lot of possibilities for users. I am confident that the implementation of this will pave the way for a next-level experience of pre-tuning a design system. On any given team, something like this this could be used in collaboration with a non-technical designer to save weeks of time.
Add additional ui library components. Components followed by an asterisk are internally complete and just need to be turned into public functions with documentation:
- Avatar*
- Tabs*
- Blockquote
- Treeviewer
- Carousel
- Dropdown menu
- Context menu (right-click)
- Table
- Data List
- More card layouts (with inset margins)
- Keyboard input / hotkey e.g. ⌘ C styled as button
- Aspect Ratio (displays content within a desired ratio)
- Wrapper for native color picker input
Browser-based interactive design tweaking, with round trip to file system. An initial spike was prototyped last year, and I have since been wanting to revisit the idea. Even a simple version of this that worked reliably could massively reduce iteration cycles when implementing a dense, highly-polished UI.

Project #3 - Fireworks
Fireworks is a themeable tapping library and color pretty-printing engine.

Thanks to the generous support from Clojurists Together, I’m happy to report that a great deal of progress was made in Q3 of 2025. Building on the momentum, I would love to continue to grow and improve the project going forward.

Goals for Fireworks in 2026:

Address all current issues (mostly enhancements)
Editor extensions/integrations have been created for Cursive and VSCode. Initial work has commenced on an Emacs integration. I would like to turn the existing VSCode Joyride user script into an actual VSCode extension, in order to provide an even smoother beginner experience.
- https://github.com/paintparty/fireworks/blob/main/docs/editors/cursive/cursive.md
- https://github.com/paintparty/fireworks/blob/main/docs/editors/vscode/vscode.md
Produce written and/or video documentation of my current live hot-reloading dev environment for JVM Clojure, with versions for both Leiningen and Deps. I recently got a PR merged that adds this to test-refresh.
For ClojureScript developers using Fireworks in a browser dev console, I made a dedicated Chrome extension to enable the setting of the Chrome DevTools console background and foreground color with a very nice GUI interface. Would be cool to get updated and also work in most other [Chromium-based browsers, and potentially Firefox, if there is any demand for it.](https://github.com/paintparty/fireworks? tab=readme-ov-file#setting-the-background-color-and-font-in-chrome-devtools-clojurescript)

Project #4 - Domo
Domo is a modern ClojureScript DOM utility library.

Goals for Domo in 2026:

Write quality docstrings with examples for all 82 public functions.
Add simple validation and dev-time warnings for all public functions (very useful when working with the DOM). Make sure this code is elided for production builds so as not to add extra weight
Continue to add useful utility functions as the need for them arises within the context of real-world project work.
Add more tests to the existing browser test suite at in starter.browser.browser-tests.cljs namespace.
The starter.browser namespace in the examples/browser dir currently serves as a quickstart and (exhaustive) API tour. I would like to get user feedback on this to determine its effectiveness/usefulness.
Many of the core functions should “just work” as they are written in the context of a Squint project. I would like to make most, if not all of the public API available in Squint-land.

Project #5 Lasertag
Lasertag is a utility for categorizing types of values in Clojure, ClojureScript, and Babaskha.

Goals for Lasertag in 2026:

Solidify current public API
Extensive coverage for all Java and Javascript types/classes
Extensive test suite for all types and classes
Make cool demo for usage in ClojureScript

Why is this work important to the Clojure community?
I believe work on these projects could benefit the Clojure community for the following reasons (listed out project-by-project):

#1 - Bling

Many mature language communities have a library for rich text printing in the terminal, for example Rich (Python), Chalk (JS), LipGloss (Go), etc.

With Clojure, the main existing option seems to be org.clj-commons/pretty. The original impetus for creating Bling came out of my experience of trying to use Pretty extensively for formatting error and warning messages.

The most unique thing that Bling offers is a carefully curated palette of 11 basic colors which are readable on both light and dark backgrounds. Because these colors are located in the 16-255 ansi range, they are guaranteed to look the same on almost any terminal, regardless of the user’s terminal theme. Other libraries, including Pretty, leave the colorizing up to the user’s terminal emulator profile/theme, which often leads to wildly different colorized output in the user space.

Bling also offers two simple functions for creating “blocks” of text in the console. Check out the readme for exhaustive visual examples - These can be semantically colored (errors, warnings, info). Bling also offers a simple function for constructing a point-of-interest diagram, like when you want to call out the namespace, line, column and show some source code with a red squiggly underline. I think the Clojure community would benefit from more library authors adding neatly-formatted, actionable warning and error messages to their codebases. It would also be great if such warnings and messages where formatted in a way that loosely followed some set of conventions. Perhaps Bling could play a small role in fostering this within the Clojure community.

#2 - Kushi
Kushi aims to provide a complete solution to the design layer of web UI projects. It is an ambitious project, but I believe there is an opportunity for Kushi to offer a UI dev experience that is unique and more compelling than any equivalent in any other language. This could lead to increased organizational awareness and consideration of ClojureScript as an attractive choice for building mission-critical UI. If more companies used ClojureScript to build UI, I think it would be very beneficial for the community.

#3 - Fireworks
Fireworks is the only lib to provide a colorizing and themeable pretty-printer that works beautifully in both Clojure and ClojureScript (and Babashka).

The output is, arguably, orders of magnitude faster and easier to read than equivalent output from clojure.pprint/pprint. This is especially true in the case of maps with data-structures as keys, or any kind of collection that features metadata.

The library also provides very powerful debugging and tapping macros. These macros provide a lightweight complement to discovery-centric, UI-heavy data exploration tools such as Portal and Flowstorm. With a simple hot-reloading setup in clj or cljs, and minimal editor integration (now available in Cursive and VSCode), Fireworks can drive an extremely compelling live-feedback dev experience without any reliance on a repl connection, or repl-related concepts. I think the continued codification, documentation, and demonstration of such a workflow could make a difference in the on-ramping of newcomers to Clojure. The maturation of this kind of workflow could also benefit existing users of similar community tools such as playback, debux, hashp, telemere, ken, spyscope, omni-trace, postmortem, and sayid.

#4 - Domo
This lib has been slow-cooking over a 3 years to serve various web projects, including Kushi. The syntax is very Clojure-y, and feels much nicer than writing gnarly JS interop code. To my knowledge, there are only a few ClojureScript DOM libs (Dommy, Enlive, Enfocus), and all were written 9-10 years ago.

Compared to these libs, Domo offers even more specific functionality across 83 public functions and macros such as:

copy-to-clipboard
Getting viewport information
Geometry for elements
Getting screen quadrant for element or event
Attribute querying and manipulation
Computed styles of elements
Adding, removing, and toggling attributes and classes
Optional zipper-like syntax for selecting elements
matches-media? helpers
a11y-friendly on-mouse-down helper (zippier alternative to on-click)
Helper for keyboard-based tab navigation
& much, much more!

#5 - Lasertag
Lasertag is a utility library that was spun out of Fireworks. I believe it to be quite unique in the current landscape of cljc libraries that deal with reflection and categorization of values.

lasertag.core/tag-map makes it easy to get detailed information about values, particularly in the context of interop with Java or JavaScript.

I think that Lasertag could potentially offer great utility to rich-tooling projects developed in the Clojure community of the present and future.

Is there anything else you would like us to know?
Very much appreciate the recent support from Clojurists Together for these projects, would love to keep it going!

Eric Dallo

https://github.com/ericdallo

What do you plan to work on throughout the year?
ECA (Editor Code Assistant)
This project was born 5 months ago (with clj-together’s help!) and it’s growing, there are so many improvements to this project related to features and parity with other big tools like Claude/Cursor, compatibility with more editors, fix and support community issues. This AI tool is written in Clojure but works in any language which is huge for discoverability of Clojure community outside Clojure bubble, it has a lot of potential in my opinion, and projects for each editor to maintain and evolve.

metrepl
I want to help with guide and examples of metrics of your repl and how that can help companies understand developers REPL usage

Why is this work important to the Clojure community?
I believe those are really important tools for the developer, especially clojure-lsp and ECA which run in all major editors during daily programming. In my opinion, developer tools for programming are critical for user happiness with Clojure language, especially new users arriving in the Clojure land.

Is there anything else you would like us to know?
Thank you for the magnificent work you do!

Dragan Djuric

https://dragan.rocks, https://github.com/uncomplicate

What do you plan to work on throughout the year?

Uncomplicate, Neanderthal, Clojure AI and ML
My goal with this funding in 2026 is to continuously develop Clojure AI, ML, and high-performance ecosystem of Uncomplicate libraries (Neanderthal and many more), on Nvidia GPUs, Apple Silicon, and traditional PC.

In this year, I will also focus on writing tutorials on my blog and creating websites for the projects involved, which is something that I wanted for years, but didn’t have time to do because I spent all time on programming.

This work will highly benefit the Clojure community as this is THE AI ecosystem for Clojure, and supporting AI is arguably the main focus on probably all software platforms. Clojure has something to offer on that front, beyond just calling OpenAI API as a web service!

Uncomplicate grew to quite a few libraries (of which some are quite big; just Neanderthal is 28,000 lines of highly-condensed, aggresively macroized, and reusable code): Diamond ONNX Runtime, Neanderthal, Deep Diamond, ClojureCUDA, ClojureCPP, Apple Presets, ClojureCL, Fluokitten, Bayadera, Clojure Sound, and Commons.

Here’s a word or two of how I hope to improve each of these libraries with Clojurists Together funding in 2026.

Neanderthal (Clojure’s alternative to NumPy, on steroids)
In 2025, Neanderthal celebrated its 10th birthday. It started as a humble but fast matrix and vector library for Clojure, but after 10 years of relentless improvements, now it boasts a general matrix/vector/linear algebra API implemented by no less than 5(!) engines for CPUs, GPU (Nvidia CUDA), GPU (OpenCL: AMD, Intel, Nvidia), Apple Silicon (Accelerate), and general CPU (OpenBLAS). And this is not a superficial support for the sake of ticking a checking; each of these engines support much more operations on exotic structures, and configuration options, than I’ve seen elsewhere. It has almost everything, but it doesn’t (YET!) have a METAL-based engine for Apple GPUs. Let’s work on that!

Deep Diamond (the Clojure Tensor and Deep Learning library, not quite unlike PyTorch, but of different philosophy)
In 2019, I started Deep Diamond as a demo showcase for Neanderthal’s capabilities as the foundation for high-performance number-crunching software. It quickly outgrew that, and became a general Tensor/Deep Learning API, implemented by several fast, native optimized, backends, that run on both CPUs and GPUs, across hardware platforms (x86_64, GPUs, arm64, Apple Silicon, you name it) and operating systems (Linux, MasOS, Windows). Of course, it does not clash with Neanderthal, but complements it, in the best manner of highly focused Clojure libraries that do one job and do it well.

Deep Diamond is quite capable, but it cries for a METAL-based engine for Apple GPUs, too.

Diamond ONNX Runtime (the Clojure library for executing AI models)
This is the latest gem in Uncomplicate’s store, and I developed it thanks to Clojurists Together funding in Q3 2025. Similarly to how I started Deep Diamond mainly as a teaching showcase for Neanderthal, I started this to show Clojure programmers how close we, Clojurists, are to the latest and shiniest AI stuff that everyone’s raving about. But of course, being close does not mean that we can close the gap to the multi-billion funded Python ecosystem in a few afternoons. It needs laser-focused development and knowing what to do, when, and where. Nevertheless, Clojure is there. Now we can run inference on the trained models from Hugging Face and other vibrant AI communities directly in Clojure’s REPL. Does this make an effortless billion-dollar AI startup? NO. Does it bring Clojurians to the party? YES! And there’s more to come.

Not only that this library is new, but the whole wider ecosystem exploded in the last year with the wide availability of open-weights model that you can run at home. So, lots of functionality is added upstream all the time, and I hope to be able to stay current and have the best and newest stuff in Clojure..

ClojureCUDA (REPL-based low-level CUDA development)
Not many Clojurians may prefer to work with GPU directly, or to write their own kernels. Neither do I. But, this library is one of the un-celebrated workhorses that enables me to implement whatever I want in Neanderthal, Deep Diamond, and Diamond ONNX Runtime, instead of just trying to wrap whatever there is in upstream C++ libraries. ClojureCUDA gives us the superpower of choice: wrap whatever works, but then implement the missing parts yourself!

As CUDA is receiving a steady stream of changes and improvements, I’d like to improve and extend ClojureCUDA to always be in top shape! It is not as easy as it seems to the casual onlooker.

ClojureCPP (the gateway to native C++ libraries)
From 20,000 feet, integrating a native library to JVM and Clojure may look straightforward. Oh, how wrong they are. Virtually every C++ library is a special kind of jungle, with its own structures, patterns and inventions. What might seem a minor technical detail might require special acrobatics to support it on the JVM. Masking that mess under the hood so that a Clojurian do not need to care might be insanely brittle if it weren’t for ClojureCPP! It is not as large as Neanderthal or Deep Diamond, but it is one of the reasons that enables these upper level libraries stay on the 25,000 or 3,000 lines of code mark, instead of being 500,000 or 50,000, as many of their counterparts in other languages.

Apple Presets (native JNI bindings for various Apple libraries)
Yup. To support Apple Silicon in Neanderthal and Deep Diamond I had to make these bindings, since there weren’t any to “just” wrap. And to support more Apple high performance computing apis, I’ll have to create additional bindings (for example, for METAL) and only then develop the Clojure part.

Fluokitten, Bayadera, ClojureCL, Commons, Clojure Sound, etc.
These libraries will not be in focus in 2026., but will probably need some care and assorted improvements here and there.

Summary: In short, my focus with this funding with Clojurists Together will have two main branches:

Development of new functionalities, supporting more hardware and platforms for existing functionality, and fixing issues for a dozen Uncomplicate libraries that already exist. This is what is described in the text you’ve just read.
Develop an unified website for Uncomplicate and stuff it with useful information in one place. Currently, some libraries have websites that I wrote many years ago, while some rely on GitHub Clojure tests, in-code documentation, tutorials on dragan.rocks and my books. There are many resources, some of which are quite detailed (2 full books!), but people without experience (which is the majority of Clojure programmers) have a hard time using all these in organized way.
I hope to solve this with the unified website!

Projects directly involved:
https://github.com/uncomplicate/diamond-onnxrt
https://github.com/uncomplicate/neanderthal
https://github.com/uncomplicate/deep-diamond
https://github.com/uncomplicate/clojurecuda
https://github.com/uncomplicate/clojure-cpp
https://github.com/uncomplicate/clojurecl
https://github.com/uncomplicate/apple-presets
https://github.com/uncomplicate/fluokitten

Why is this work important to the Clojure community?
This will highly benefit the Clojure community as this is THE AI ecosystem for Clojure, and supporting AI is arguably the main focus on probably all software platforms. Clojure has something to offer on that front, beyond just calling OpenAI API as a web service!

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate?
I’m outside the USA and EU, but other than that I guess it’s just the usual challenges of open-source developers worldwide.

Is there anything else you would like us to know?
Yes! Clojurists Together funding in the past years greatly helped me in making Uncomplicate as awesome as it is today. Developing large open source projects for 10 years can be tough!

Siavash Mohammady

https://github.com/siavashmohammady66

What do you plan to work on throughout the year?
Easy data dashboard builder like Shiny dashboards + adding capability building dashboard using prompts.

Why is this work important to the Clojure community?
Development productivity is essential for adaptation of a language, as python & R has such a feature which make life simpler for their data-scientists, Clojure so needs to become a viable data-science alternative choice.

Nikita Prokopov

https://github.com/tonsky

What do you plan to work on throughout the year?
I want to resume working on Humble UI, a desktop UI for Clojure that is based on Skia and doesn’t involve a browser.

In 2024, with Clojurists Together support, we got the basics of layout figured out, implemented a VDOM-like API, and started working on a self-documented component library. We’ve got labels, buttons, scroll containers, splits, and tables.

In 2026, I would like to iron out the underlying API model, so the fundamentals will become stable and Humble can be extended with just implementing more components. I also aim at production-grade multi-line text based on ICU and Harfbuzz, finalizing text inputs, and figuring out packaging. This should get Humble to the point where real-world applications can be built with it.

This will be accompanied by detailed progress reports describing the problem space and thinking process, in the form of regular blog posts.

In addition to Humble, there’s a small amount of maintenance work with already existing projects like DataScript, clj-reload, Clojure+, fast-edn, Clojure Sublimed, and such.

Why is this work important to the Clojure community?
Desktop UIs are not in a good place right now, with only the viable option being Electron and other web-based solutions. These have downsides of a complex execution model and poor performance.

At the same time, people are getting tired of slow, complex software that runs in a browser and that you can’t own. A lot of things simply can’t be done in a browser, or security is questionable, or it can disappear on a whim.

Clojure really has a chance to make a difference here. Being so pragmatic, dynamic, and extensible, it is nice to use it to build web servers, but I always felt that a huge class of programs – the ones with GUI – is missing, and will be a great fit.

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate?
I am an immigrant from Russia (living in Germany for 6 years now).

Is there anything else you would like us to know?
I loved working with Clojurists Together in the past – would love to do it again.

James Reeves

https://github.com/weavejester

What do you plan to work on throughout the year?
I plan on continuing development on cljfmt, a formatting tool for Clojure that’s both a standalone tool, and used in other projects like Clojure-LSP. I’m particularly interested in making it easier for people to include custom styling in their libraries, similar to how clj-kondo handles custom linting rules.

I’m also working on a stable version of Duct, a data-oriented framework for Clojure based on Integrant. My focus is on ensuring it has excellent documentation and will serve as an easy way to write web applications in Clojure.

In addition to these two projects, I’m also maintaining Ring. My current goal with Ring is to submit PRs to third-party Ring adapters (like httpkit) that improve their overall compatibility with the Ring specification.

Why is this work important to the Clojure community?
Having a good Clojure formatter keeps codebases consistent and readable.

Having a good and well documented web framework in Clojure gives developers a quick way to get started with a very common use case (web applications).

Finally, increasing compatibility between Ring adapters ensures that developers can create code that isn’t tied to a particular adapter.

Tomasz Sulej

https://github.com/genmeblog

What do you plan to work on throughout the year?
Here is the set of things I want to do in 2026:

fastmath
• Document most of the functions and build more holistic documentation – it’s a really time consuming task, current status:
• Validate crucial functions by increasing test coverage
• Implement GAM regression modelling as an enhancement of existing LM and GLM models. PoC is done.

Clojure2D
• Extract a clojure2d.color namespace as a separate library
• Add a SVG drawing support. PoC is done.

cljplot
• Revisit currently postponed cljplot library and start to refactor it to give it a new life, inc. the following things:
- Highly decouple chart processing pipeline making each step testable and easy to enhance - Better use of grammar of graphics concept
- Add SVG rendering
- Build more specific, scientific charts
- (optional) declarative chart generation to allow binding to tableplot library
• Revisit examples and create the library of chart types

Other • Review and update the following libraries:
- wadogo – scales for charts
- fitdistr – distribution fitting / modelling
- (optional) inferme – Bayesian inference library
• Continue an user support which I do online though Slack/Zulip chats.
• Prepare workshops and talks for incoming Clojure Jam / Clojure Creative Coding conference in April 2026
• Build more Clojure Civitas notebooks showing Clojure2d capabilities.

Why is this work important to the Clojure community?
I’m a creator and maintainer of several projects in the mathematics, data science and visualization areas which I did under the nickname GenerateMe/genmeblog. My main and notable projects are:
• tablecloth - a dataset library
• fastmath – general mathematics and science library
• clojure2d – visualization library
• clojisr - a bridge for seamless R interoperability (co-creator)
• cljplot - pure Clojure charts library
• fitdistr - statistical distribution modelling
• inferme - Bayesian modelling and inference.

As a member of the Scicloj community I want to build much more awareness of these libraries, boost the quality and make better adoption of them in existing or future projects.

My other activities include also mentoring in the Scicloj open-source mentoring program:
2026 funding will help me with to focus on two libraries which are require much more care and quality:

A fastmath is not only a pure math library but aims to be a complete toolset for doing fast scientific and numerical computing in Clojure. My personal goal is to bring the scope of SciPy (Python) or JuliaStats (Julia) suites. I believe that coverage is really high already but still needs a lot of work to validate and document all the functions.

Clojure2d covers not only 2d drawing and binding to Java2d but also allow pixel manipulation, various pixel rendering methods and aims to cover all possible color manipulation functions including color space conversion, palette/gradient generation and colorimetry.

I believe support from Clojurists Together will help me to focus more on Clojure open source and community support which I’ve been doing for more than 8 years.

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate?
No really. But I quit my current job (I’m on the C-level, management side in a software house) as of January 2026 and I am trying to switch to a Clojure programming side.

Is there anything else you would like us to know?
As a Scicloj member I would like to be more visible next year in various on/offline activities like conferences, meetups, jams etc. The first opportunity will be on the Clojure Jam 2026, where I plan to present details of fastmath/clojure2d libraries as a creative toolset and also host some workshop around the topic.

Peter Taoussanis

https://www.taoensso.com/clojure

What do you plan to work on throughout the year?
Multiple projects, incl. significant work on Nippy and Carmine, possibly working on Babashka support for more libraries (e.g. Telemere)

Why is this work important to the Clojure community?
Nippy: want to experiment with porting a subset of Nippy (binary serialization library) to ClojureScript. Nippy’s pretty widely used, and it’d be nice to have data portability between Clj and Cljs. Recently worked on a Clj/s implementation of MessagePack, which ended up being a nice PoC for this effort. MessagePack itself isn’t ideal for Clojure data though, we can do better with a Clojure-first format. A cross-platform Nippy would be particularly useful for Sente and Clojure/Script web apps.

Carmine: recently (finally!) pushed the first publicly available version of the core v4 API, but there’s still tons of work to do to get it properly polished and documented for wider use. Also seeing increased enquiries recently re: Redis Cluster and/or Sentinel. Have an early prototype ready for Sentinel support, and foundations laid for Cluster - but both would also require substantial effort to bring to a usable state. This alone would probably be several months of work to do right.

Increased Babashka support: plenty of folks have asked for this, esp. re: Telemere. Expect this may also be a non-trivial job, but should be doable in steps. Would need to investigate further re: specific timeline, etc.

Is there anything else you would like us to know?
Would just make a similar statement to last year: I’m super grateful to have been able to receive support from Clojurists Together for the past few years. From my side I’d of course be thrilled to continue as long as the community sees value in my work.

But I also totally understand if it’s not possible to continue with funding - I know you must get a lot of great applications each year!

Whatever the outcome re: funding I’ll of course keep trying to contribute where I can.

And again, a big thanks to all the folks quietly keeping Clojurists Together running so well behind the scenes! This has been such a great project, and something awesome to be involved in.

Jeaye Wilkerson

https://github.com/jeaye

What do you plan to work on throughout the year?
I will be working full-time on jank.

Overall, my goal for EOY 2026 is production readiness for jank. This is an aggressive goal, but I will work aggressively on it.

Why is this work important to the Clojure community?
jank is still the only native Clojure dialect which has its own JIT and embraces interactive programming. It unlocks REPL-driven development for a whole ecosystem previously unserved by Clojure.

Clojurists have demonstrated their desire for native executables with their use of GraalVM. Compared to Graal, jank will offer REPL support, better performance, better native interop, smaller binaries, and faster compilation times.

Oleksandr Yakushev

https://github.com/alexander-yakushev
https://github.com/clojure-goes-fast

What do you plan to work on throughout the year?
On Clojure Goes Fast side, during 2025, I’ve released several versions of clj-async-profiler (added dynamic diff modes), clj-memory-meter (heap usage tracing), Flamebin (encrypted private flamegraphs). I’ve also started working on integrating the latest async-profiler features into clj-async-profiler and transitioning to more compact and efficient JFR-compatible profiles. For 2026, I plan to:

Wrap up the JFR transition in clj-async-profiler and upgrade to async-profiler 4.0+.
Release the new flamegraph type that includes the time dimension.
Implement CPU time and allocation heatmaps.
Flamebin: add support for the new flamegraph type supported by clj-async-profiler.
Add the converter between JFR and clj-async-profiler dense profiles, allowing to upload Java Flight Recorder profiles directly to Flamebin.
clj-java-decompiler: add support for alternative decompiler backends (e.g. Fernflower) and make the decompilers pluggable and auto-discoverable via dependencies.
New performance-oriented libraries (e.g., event-passport for efficient in-memory event timestamping).

As for CIDER and related tooling, which I returned to as a co-maintainer and primary contributor, a great deal has been achieved in 2025 (multiple big releases of CIDER and nREPL), but there is still a lot to be done:

Adopt and modernize refactor-nrepl - a widely used part of CIDER that doesn’t currently have an active maintainer.
Rework cider-nrepl codebase to rely less on dependency “shading” (which is done by mranderson).
Improve and unify nREPL configuration approach.
Enhance CIDER inspector, improve feature discoverability.
Improve multi-REPL experience.

Why is this work important to the Clojure community?
Clojure Goes Fast is the centerpiece of Clojure performance-related tools and information (1.2K stars, 2.8M total Clojars downloads, 4000 unique site visitors in 2025, 18k page views).

CIDER is still the most used Clojure IDE according to the last State of Clojure survey. nREPL is the primary backend for all popular Clojure IDEs (including Calva and Cursive).

Annually-Funded Developers' Update: September/October 2025

Fri, 28 Nov 2025 14:00:00 +1200

Hello Fellow Clojurists! This is the fifth report from the 5 developers receiving Annual Funding in 2025. Thanks everyone for the fantastic work!

Dragan Djuric: Clojure ML, Clojure CUDA, Neanderthal, Deep Diamond, Commons
Eric Dallo: ECA, clojure-lsp
Michiel Borkent: Eucalypt, Reagent, Squint, babashka, and more…
Oleksandr Yakushev: CIDER, nREPL, JDK25
Peter Taoussanis: Sente, Tempel, Carmine

Dragan Djuric

2025 Annual Funding Report 5. Published November 9, 2025.

My goal with this funding in 2025 is to support Apple silicon (M cpus) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

Having a decent Apple CPU engine for Neanderthal and a BNNS-based CPU engine for Deep Diamond completed in the previous periods, my main focus was on improving things achieved in the previous periods to support features and fix bugs that discovered while working on Clojure ML (diamond-onnxrt), the other major project funded by CT.

The first milestone for THIS project is that I supproted Intel’s DNNL (the Deep Diamond’s CPU backend) on Apple’s MacOS (both arm64 and older intel based). Due to Deep Diamond’s flexible design, this required only small changes to DD code, while the main issue was enabling and testing that architecture in the build of upstream libraries.

Several other areas fixed/improved throughout Uncomplicate libraries during this period include:

Upgrading CUDA to the major new version 13.0, including improvements in code
Working with upstream libraries on improving support for functionality that we need in Clojure/Uncomplicate
Improving the UX of the distribution of dependency artifacts for CUDA and other dependencies that we use.
Upgrading DNNL to 3.9.2
Enable standalone activations, and other small changes to make sure DD accomodate onnx models inside DD network machinery
Assorted improvements in supported types
Helped in enabling CoreML in upstream onnxruntime build on MacOS

I released several new versions of Uncomplicate libraries with these user-facing improvements including:

Deep Diamond
Neanderthal
ClojureCUDA
Commons

Hammock time. Researched available native libraries that we can integrate next into Clojure ecosystem, including Nvidia’r TensorRT and Triton, Intel’s OpenVino, and similar AI-related stuff.

I wrote two tutorials and published them on dragan.rocks blog. They were received quite favorably, and it seems to me that Clojure programmers are quite eager to learn how to apply the stuff I’ve worked on.

Eric Dallo

2025 Annual Funding Report 5. Published November 10, 2025.

In these last 2 months I mainly focused on ECA development and related projects and improvements along with my Clojure Conj talk that’s coming this week, excited for it!

eca

ECA (Editor Code Assistant) is a OpenSource, free, standardized server written in Clojure to make any editor have AI features like Cursor, Continue, Claude and others.
There were so many releases and changes to ECA making it way more stable, with new features and fixing lots of bugs, especially with way more people using it daily and contributing!

0.44.0 - 0.78.1

Most important changes:

Hooks support: This makes ECA one of the few opensource public tools with high customizable hooks support, hooks allow users to react to certain events like pre or post request or tool call.
Rewrite: A new brand feature allowing to select a code and tell LLM to do something.
Completion (alpha): First big step to allow completion, requiring only improvements in LLM output quality via model/prompt tunning.
Plan behavior: Hugely improve plan behavior, making ECA one of the best tools for planning code changes, really a key feature of ECA.
Clojure MCP integration: ECA is extensible so we can make it behave differently for MCPs, and we did for clojureMCP with Bruce’s help, making ECA show diffs beautifully before they actually happen.
Contexts improvements: better context management via user/system prompts with options to unwrap files or just mention, making more token effective/controllable.
More providers: Support google and more providers via more API improvements, making ECA compatible with most models at market and local.
Native tool improving: Improved lots of ECA tools, based on tests and user feedback, making way more assertive and precise.
Metrics via Opentelemetry: If you wanna take metrics of prompts and tools, ECA supports that now, really useful for companies that wanna track LLM usage.

And many more, check all changes below:

Fix regression: completion broken after rewrite feature API changes.
Prefix tool name with server to LLM: __. #196
Remove eca_ prefix from eca tools, we already pass server prefix (eca) after #196.
Add approval arg to preToolCall hook input.
Add error rewrite message content message.
Fix token renew when using rewrite feature.
Improve rewrite error handling.
Custom providers do not require the existense of key or keyEnv. #194
New feature: rewrite. #13
Updated instructions for /login command and invalid input handling.
Fix server name on chat/contentReceived when preparing tool call.
Fix variable replacing in some tool prompts.
Improve planning mode prompt and tool docs; clarify absolute-path usage and preview rules.
Centralize path approval for tools and always list all missing required params in INVALID_ARGS.
Fix 0.75.3 regression on custom openai-chat providers.
Support custom think tag start and end for openai-chat models via think-tag-start and think-tag-end provider configs. #188
Bump MCP java sdk to 0.15.0.
Add missing models supported by Github Copilot
Fix regression: openai-chat tool call arguments error on some models.
Improve protocol for tool call output formatting for tools that output json.
Fix inconsistencies in eca_read_file not passing correct content to LLM when json.
Improved file contexts: now use :lines-range
BREAKING ECA now only supports standard plain-text netrc as credential file reading. Drop authinfo and gpg decryption support. Users can choose to pass in their own provisioned netrc file from various secure source with :netrcFile in ECA config.
Improved eca_edit_file to automatically handle whitespace and indentation differences in single-occurrence edits.
Fix contexts in user prompts (not system contexts) not parsing lines ranges properly.
Support non-stream providers on openai-chat API. #174
Support use API keys even if subscription is logged. #175
Fix tool call approval ignoring eca tools.
Fix tool call approval ignoring configs for mcp servers.
Fix tool call approval thread lock.
Improve chat title generation.
Fix completion error handling.
Default to openai/gpt-4.1 on completion.
Add :config-file cli option to pass in config.
Add support for completion. #12
Run preToolCall hook before user approval if any. #170
Only include parallel_tool_calls to openai-responses and openai-chat if true. #169
Support clojureMCP dry-run flags for edit/write tools, being able to show preview of diffs before running tool.
Assoc parallel_tool_calls to openai-chat only if truth.
Fix regression in /compact command. #162
Fix to use local zone for time presentation in /resume.
Use web-search false if model capabiltiies are not found.
Support /resume a specific chat.
Fix openai-chat api not following completionUrlRelativePath.
Fix web-search not working for custom models using openai/anthropic apis.
Support visible field in hooks configuration to show or not in client.
Deprecate prePrompt and postPrompt in favor of preRequest and prePrompt.
Fix model capabilities for models with custom names.
Fix prePrompt hook.
Add hooks support. #43
Fix regression on models with no extraPayload.
Support multiple model configs with different payloads using same model name via modelName config. (Ex: gpt-5 and gpt-5-high but both use gpt-5)
Add anthropic/haiku-4.5 model by default.
Unwrap mentioned @contexts in prompt appending as user message its content. #154
Improved flaky test #150
Obfuscate env vars in /doctor.
Bump clj-otel to 0.2.10
Rename $ARGS to $ARGUMENTS placeholder alias for custom commands.
Support recursive AGENTS.md file inclusions with @file mention. #140
Improve plan behavior prompt. #139
Add support for secrets stored in authinfo and netrc files
Added tests for stopping concurrent tool calls. #147
Improve logging.
Improve performance of chat/queryContext.
Added ability to cancel tool calls. Only the shell tool currently. #145
Bump mcp java sdk to 0.14.1.
Improve json output for tools that output json.
Fix duplicated arguments on toolCallPrepare for openai-chat API models. https://github.com/editor-code-assistant/eca-emacs/issues/56
Add server to tool call messages.
Fix last word going after tool call for openai-chat API.
Fix retrocompatibility with some models not working with openai-chat like deepseek.
Add gpt-5-codex model as default for openai provider.
Support “accept and remember” tool call per session and name.
Avoid generating huge chat titles.
Add claude-sonnet-4.5 for github-copilot provider.
Add prompt-received metric.
Use a default of 32k tokens for max_tokens in openai-chat API.
Improve rejection prompt for tool calls.
Use max_completion_tokens instead of max_tokens in openai-chat API.
Support context/tokens usage/cost for openai-chat API.
Support anthropic/claude-sonnet-4.5 by default.
More tolerant whitespace handling after data:.
Fix login for google provider. #134
Fix chat titles not working for some providers.
Enable reasoning for google models.
Support reasoning blocks in models who use openai-chat api.
Support google gemini as built-in models. #50
Deprecate repoMap context, will be removed in the future.
- After lots of tunnings and improvements, the repoMap is no longer relevant as eca_directory_tree provides similar and more specific view for LLM to use.
Support toolCall shellCommand summaryMaxLength to configure UX of command length. #130
Fix MCP prompt for native image.
Improve progress notification when tool is running.
Bump MCP java sdk to 0.13.1
Improve MCP logs on stderr.
Support tool call rejection with reasons inputed by user. #127
Greatly reduce token consuming of eca_directory_tree
- Ignoring files in gitignore
- Improving tool output for LLM removing token consuming chars.
Fix renew oauth tokens when it expires in the same session.
Fix metrics exception when saving to db.
Fix db exception.
Fix usage reporting.
Return new chat metadata content.
- Add chat title via prompt to LLM.
Add support for Opentelemetry via otlp config.
- Export metrics of server tasks, tool calls, prompts, resources.
Use jsonrpc4clj instead of lsp4clj.
Bump graalvm to 24 and java to 24 improving native binary perf.
Avoid errors on multiple same MCP server calls in parallel.
Fix openai cache tokens cost calculation.
Improve welcome message.
Improve large file handling in read-file tool:
- Replace basic truncation notice with detailed line range information and next-step instructions.
- Allow users to customize default line limit through tools.readFile.maxLines configuration (keep the current 2000 as default).
Moved the future in :on-tools-called and stored it in the db. #119
Support compactPromptFile config.
Fix tools not being listed for servers using mcp-remote.
Add /compact command to summarize the current conversation helping reduce context size.
Add support for images as contexts.
Support http-streamable http servers (non auth support for now)
Fix promtps that send assistant messages not working for anthropic.
Fix manual anthropic login to save credentials in global config instead of cache.
Minor log improvement of failed to start MCPs.
Bump mcp java sdk to 1.12.1.
Fix mcp servers default timeout from 20s -> 60s.
Support timeout on eca_shell_command with default to 1min.
Support @cursor context representing the current editor cursor position. #103
Fix setting the web-search capability in the relevant models
Fix summary text for tool calls using openai-chat api.
Bump mcp-java-sdk to 0.12.0.
Added missing parameters to toolCallRejected where possible. PR #109
Improve plan prompt present plan step.
Add custom behavior configuration support. #79
- Behaviors can now define defaultModel, disabledTools, systemPromptFile, and toolCall approval rules.
- Built-in agent and plan behaviors are pre-configured.
- Replace systemPromptTemplateFile with systemPromptFile for complete prompt files instead of templates.
Remove nativeTools configuration in favor of toolCall approval and disabledTools.
- Native tools are now always enabled by default, controlled via disabledTools and toolCall approval.
Add totalTimeMs to reason and toolCall content blocks.
Add nix flake build.
Stop prompt does not change the status of the last running toolCall. #65
Add toolCallRunning content to chat/contentReceived.
Support more providers login via /login.
- openai
- openrouter
- deepseek
- azure
- z-ai
Remove the need to pass requestId on prompt messages.
Support empty /login command to ask what provider to login.
Support user configured custom tools via customTools config. #92
Fix default approval for read only tools to be allow instead of ask.
Fix renew token regression.
Improve error feedback when failed to renew token.
Support deny tool calls via toolCall approval deny setting.

clojure-lsp

I worked together with @weavejester from cljfmt to fix some bugs and finally deliver vertical alignment of maps to Clojure via LSP!
I should release these changes when coming back from Conj.

Michiel Borkent

2025 Annual Funding Report 5. Published November 3, 2025.

In this post I’ll give updates about open source I worked on during September and October 2025.
To see previous OSS updates, go here.

Sponsors

Current top tier sponsors:

Open the details section for more info about sponsoring.

Sponsor info

Clojars Maintenance and Support: August-October 2025 Update

Fri, 28 Nov 2025 14:00:00 +1200

2025 Critical Infrastructure: Clojars Maintentance and Support Update by Toby Crawley

August-October, 2025. Published November 22, 2025

This is an update on the work I’ve done maintaining Clojars with the support of Clojurists Together in August through October of 2025. Most of my work on Clojars is reactive, based on issues reported through the community or noticed through monitoring.
If you have any issues or questions about Clojars, you can find me in the #clojars channel on the Clojurians Slack, or you can file an issue on the main Clojars GitHub repository.

Below are some highlights for work done in August through October:

I enabled backups of the artifact repository S3 bucket. I thought I had done this years ago, but had not, so fixed this oversight.
I upgraded Clojars to Clojure 1.12.3 (from 1.12.1) and Java 25 (from 21)
We had a couple of places where invalid input would trigger 500s, which resulted in noise from Sentry. One was invalid emails on password reset, and the other was null bytes on in project browsing url The latter one was pretty common, as I believe some fuzzing tools do this to try and find vulnerabilities. There are a couple of other places where I need to address them as well.

Though after October, I enjoyed the opportunity to chat with Clojars users at Clojure/Conj in Charlotte, NC! It was great to see old friends and make some new ones!

You can find earlier updates re Clojar fixes and updates here: March - July 2025

November 2025 Short-Term Q3 Project Updates

Fri, 14 Nov 2025 14:00:00 +1200

This is the second project update for three of our Q3 2025 Funded Projects. (Reports for the others are on a different schedule). A brief summary of each project is included to provide overall context. Thanks everyone for your awesome work!

Jank: Jeaye Wilkerson
This quarter, I’ll be building packages for Ubuntu, Arch, Homebrew, and Nix. I’ll be minimizing jank’s dependencies, automating builds, filling in test suites for module loading, AOT building, and the Clojure runtime. I’ll be working to get the final Clang and LLVM changes I have upstreamed into LLVM 22, adding a health check to jank to diagnose installation issues, and filling in some C++ interop functionality I couldn’t get to last quarter. Altogether, this quarter is going to be a hodgepodge of all of the various tasks needed to get jank shipped.

Malli: Ambrose Bonnaire-Sergeant
Malli’s core algorithms for transforming schemas into things like validators and generators are quite sensitive to the the input schema. Even seemingly equivalent schemas can have different performance characteristics and different generators.
I would like to create a schema analyzer that can simplify complex schemas, such that two different but equivalent schemas could have the same representation. Using this analyzer, we can build more efficient validators, more reliable generators, more helpful error messages, more succinct translations to other specification tools, and beyond.

Uncomplicate Clojure ML: Dragan Duric
My goal with this funding in Q3 2005 is to develop a new Uncomplicate library, ClojureML.

a Clojure developer-friendly API for AI/DL/ML models (in the first iteration based on ONNX Runtime, but later refined to be even more general).
Implement its first backend engine (based on ONNX Runtime).
support relevant operations as Clojure functions.
an extension infrastructure for various future backend implementations.
a clean low-level integration with Uncomplicate, Neanderthal, Deep Diamond and Clojure abstractions.
assorted improvements to Uncomplicate, Neanderthal, Deep Diamond, to support these additions.
develop examples for helping people getting started.
related bugfixes.
TESTS (of course!).

AND NOW FOR THE REPORTS!

Jank: Jeaye Wilkerson

Q3 2025 $9K, Report No. 2, Published October 31, 2025

Thank you so much for the sponsorship this quarter! This past month of jank development has been focused on stability of all existing features in preparation for the alpha release in December. Of note, I done the following:

Stabilized binary builds for macOS, Ubuntu, Arch, and Nix
Improved loop IR to support native values without boxing
Merged all pending LLVM changes upstream, so jank can build with LLVM 22 (releasing in January 2026)
The lein-jank plugin and template have been improved so that starting a new jank project is now just a couple of commands
libzip has been removed as a dependency, which enables Ubuntu 25.04 support
AOT building on all supported platforms has been stabilized
Added a daily scheduled CI binary package check for macOS, Ubuntu, and Arch
Added runtime type validation for cpp/unbox usages
Added C preprocessor value support, so cpp/FOO can refer to any #define
Improved IR gen and static type checking for if so that both branches must provide the same type

Normally I have an associated blog post, but as I’ll be leaving for Clojure Conj 2025 next week, I’m taking the time to polish my talk.

Malli: Ambrose Bonnaire-Sergeant

Q3 2025 $0K, Report No. 2, Published November 11, 2025

This month I fixed a bug in the work I merged last month: Robust :and parser, add :andn

The bugfix got me thinking about recursive refs again (following on from my work on recursive generators in malli.generator from a few years ago), which is a major part of the performance work I proposed for this Clojurists Together project (compiling efficient validators for recursive schemas).

I realized that we can use the cycle detection logic from malli.generator to detect cycles in validators! A major performance difference between Plumatic Schema/Spec and Malli is in recursive validators: Malli never “ties the knot” and will lazily compile and cache every layer of recursion. This means Malli uses linear space for recursive validators, while Schema/Spec use constant space, and Malli can never fully compile a recursive validator and must pay a time cost for compiling schemas at “runtime” (e.g., when your webserver is accepting requests).

I submitted a Malli “discussion” PR Sketch: tying the knot for ref validator proposing an approach to fixing this performance issue for recursive validators. See the PR if you’re interested in the exact details, as it contains a full explanation of the problem and (mostly) the solution, as well as a reference implementation that passes all the tests.

A neat part of this approach is that it is a completely transparent optimization from a user’s perspective, with no extra configuration or changes needed. Similar optimizations may be possible for other operations like m/explain and m/parse, but that’s future work.

For now, the maintainers showed interest in accepting this optimization and my next step will be to further test and validate the approach, and propose a final PR.

Uncomplicate Clojure ML: Dragan Duric

Q3 2025 $9K, Report No. 2, Published October 31, 2025

My goal with this funding in Q3 2005 is to develop a new Uncomplicate library, ClojureML (see above).

Progress during the second month:

In the first month, I have already implemented the first version, which I released to Clojars as org.uncomplicate/diamond-onnxrt version 0.5.0.

So, what has been done since then, in the second month?

We are at version 0.17.0 now!

As I already established solid foundations in the first month, in the second month, I focused on expanding the coverage of ONNX Runtime’s C api in Clojure, writing tests to get a feel how it works, working on hiding the difficult parts under a nicer Clojure API, fixing bugs. It wasn’t always a smooth sail, but with every storm I got a better understanding of the ways things work in ONNX Runtime, and I also covered most of the API available by ONNX Runtime version 1.22.2, at least the relevant part that can be used by Deep Diamond right now (which excludes sparse tensors and string tensors). The majority is covered and well tested.

The second area was using the newly added core API in higher-level integration with Deep Diamond. The result is that the public onnx function can now be integrated with the rest of DD Tensor machinery! And the public API that the user has to see is only one function, while everything related to ONNX is automatically wired under the hood! I am quite pleased with what I achieved on that front. Of course, I also implemented custom configurations that the user can provide as a Clojure map, and the underlying machinery will call the right onnx runtime function to set everything up.

The third big area is CUDA support. Since the whole setup up to this point was quite elegant (I’m sorry for having to praise my own work :), especially having lots of supporting functionality in Deep Diamond and Neanderthal, the Clojure code for this in diamond-onnx was not too demanding. However, the upstream library for this, namely ONNX Runtime’s backend for CUDA, and the build provided by javacpp-presets, was quite difficult to tame. I had to run many multi-hour C++ compilations, thaw through C++ compilation errors, dig to unearth causes, finding ways to fix, helping upstream, and this took lots and lots of time. But, that’s what it had to be done. That’s why I’ll have to wait for upgrade to the newest ONNX Runtime 1.23.2, but I managed to tame version 1.22.2.

During all this, I did numerous refinements to the codebase, so future library improvements will be easier. This is not a one-shot, I hope that this library will be a staple in the Clojure AI/ML community for the years to come, and that I’ll be able to further expand it and improve it as the requirements expand.

I probably forgot to mentioned some stuff that I worked on, too, but I hope I’ve mentioned the most important things.

Call for Applications: 2026 Annual Funding

Wed, 12 Nov 2025 08:30:00 +0800

Greetings folks!

Thanks to our members' generous support, this is the 5th year we we will be awarding annual funding to 5 developers - paid in twelve $1,500 monthly stipends (for a total of $90,000 USD). In the past 4 years, we have seen that giving developers flexible, long-term funding gives them the space to do high-impact work. This might be continuing maintenance on existing projects, new feature development, or perhaps a brand-new project.

We’ve been excited with what they came up with in the last few years and are looking forward to seeing more great work in 2026! Thanks all and good luck!

PROCESS

Apply: Anyone interested in receiving annual funding submits the application outlining what they intend to work on and how that work will benefit the Clojure community. The deadline for applications is Nov. 25th, 2025 midnight Pacific Time. Please note that past grantees must re-apply each year.

Board Review: The Clojurists Together board will review the applications and select finalists to present to the members by Dec. 3rd.

Members Vote: The final ballot will go out to members using a Ranked Vote election to determine the final recipients. As always, your input and participation is important and helps make Clojurists Together effective by ensuring members’ voices inform the work undertaken. Deadline Dec. 12, 2025 midnight Pacific time.

Awards will be announced no later than Dec. 18, 2025.

Project Updates: Recipients are required to submit a report bi-monthly to the membership.

A special call-out to Latacora, Roam Research, Whimsical, Nubank, Cisco, JUXT, Metosin, Solita, Adgoji, Grammarly, Nextjournal, ClojureStream, Shortcut, Flexiana, Toyokumo, doctronic, 180° Seguros, bevuta IT GmbH, Jepsen, Xcoo, Sharetribe, Basil, Cognician, Biotz SL, Matrix Operations, Strategic Blue. Eric Normand, Nubizzi, Oiiku, and Singlewire Software. They have all contributed significant amounts to Clojurists Together which lets us award approximately $90,000 in long-term funding to Clojure developers.

2025 Board Election Results. Annual Meeting October 29.

Thu, 23 Oct 2025 14:09:25 +1200

2025 Board Election Results

The Clojurists Together board is happy to announce the results of our elections. We have two new board members and two returning board members filling our open 2-year slots (Nov. 2025 through Oct. 2027).

-Daniel Compton (returning)
-Heather Moore-Farley (returning)
-Christoph Neumann
-Daniel Slutsky

Thanks to everyone who stood for election, it was an incredibly strong slate of candidates. Board members continuing for the remainder of their 2-year term are lvh (Board President), Lorelai Lyons, and Maria Geller.

A HUGE SHOUT-OUT AND THANKS to the outgoing board members Felix Barbalet and Max Penet for their years of service to the board and the Clojure community.

Annual Meeting: 29th October (10 am PT)

Members, please join us on October 29th (10 am Pacific Time) for our 2025 Annual Board Meeting. You’ll find the call in information for Zoom in your email. For anyone that has been thinking about becoming a member (developers or company), now is your time!!

Please contact me if you have any questions at kdavis@clojuriststogether.org

Kathy Davis, Program Manager, Clojurists Together Foundation

October 2025 Short-Term Q3 Project Updates

Tue, 21 Oct 2025 14:00:00 +1200

This is the first project update for five of our Q3 2025 Funded Projects. (Reports for the other one are on a different schedule). A brief summary of each project is included to provide overall context. Thanks everyone for your awesome work!

Fireworks: Jeremiah Coyle

Publish Fireworks editor plugins/extensions/integrations for Emacs, VS Code, and IntelliJ. These are fairly simple extensions that involve some basic form rewriting for wrapping/unwrapping forms.
Add support for automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to Chalk. #42
Documentation of interactive workflow.
Enhanced documentation for theme creation.
Call-site options for quick formatting changes. For hifi printing, support call-site option to disable all truncation and ellipsis #14

UIx: Roman Liutikov
I’m currently experimenting with auto memoizing compiler for UIx, an optimization similar to React’s Compiler https://react.dev/learn/react-compiler. This blog post describes the feature in detail https://romanliutikov.com/blog/bringing-granular-updates-to-react-the-clojure-way. As a result of this work UIx apps should get better baseline performance out of the box, with fewer work needed from developers.

Uncomplicate Clojure ML: Dragan Duric
My goal with this funding in Q3 2005 is to develop a new Uncomplicate library, ClojureML.

a Clojure developer-friendly API for AI/DL/ML models (in the first iteration based on ONNX Runtime, but later refined to be even more general).
Implement its first backend engine (based on ONNX Runtime).
support relevant operations as Clojure functions.
an extension infrastructure for various future backend implementations.
a clean low-level integration with Uncomplicate, Neanderthal, Deep Diamond and Clojure abstractions.
assorted improvements to Uncomplicate, Neanderthal, Deep Diamond, to support these additions.
develop examples for helping people getting started.
related bugfixes.
TESTS (of course!).

AND NOW FOR THE REPORTS!

Fireworks: Jeremiah Coyle

Q3 2025 $2K, Report No. 1, Published October 15, 2025

I’m happy to report that 2 of the primary goals and 2 of the secondary goals were achieved in the first half of Q3. The remainder of the primary goals will be prioritized for the second half of Q3, and hopefully there will be time to knockout the rest of the secondary goals. Many thanks to Clojurists Together for supporting this work!

Summary of goals achieved in the first half of Q3:
Primary goals

Add support for automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to Chalk.#42 Completed
Support call-site option to disable all truncation and ellipsis #14 Completed

Secondary goals

Allow for call-site changes to the label color for Fireworks output. #53 Completed
Add option to the produce bold Fireworks output. #70 Completed

The latest release is v0.13.0, which features the enhancements listed above.

Jank: Jeaye Wilkerson

Q3 2025 $9K, Report No. 1, Published October 1, 2025

Hi folks! Thanks so much for the sponsorship this quarter. To kick it off, I have been focusing on stabilizing jank’s seamless C++ interop, which includes more robust handling for C++ enums, pointers to arrays, pointers to functions, implicit conversions, non-type template parameters, lambda captures, initial array support via cpp/aget, and better syntax error detection in the special cpp/value and cpp/type forms. Furthermore, jank’s interop support is now robust enough to handle all of jank’s clojure.core functions which need interop. This has allowed us to rip out some of the old code which set up those functions from C++ instead.

Aside from robust C++ interop, my focus these past several weeks has been on making jank easy to build and install on major Linux distros and macOS. The main announcement here is that jank now has an Ubuntu PPA which is hosting jank binaries compatible with Ubuntu 24.04 and 24.10. These binaries are built continuously. If you’d like to try out the latest version of jank on Ubuntu, you can look at the installation docs here.

Additionally, we now continuously build jank using macOS, as well as the previous Linux setup. While jank already has a build-from-source Homebrew formula, in the coming weeks, we’ll also have a binary Homebrew formula so folks on macOS (aarch64) can easily and quickly try out jank.

I have much more detail, if you’re interested, in my latest blog post here.

Malli: Ambrose Bonnaire-Sergeant

Q3 2025 $9K, Report No. 1, Published October 16, 2025

This month I finished some lingering work from earlier in the year, and it is now merged into Malli’s main branch:
Robust :and parser, add :andn
This work solves a tricky problem inherited from spec’s original design. spec2-alpha provided a solution with its “non-flowing and” spec, but in prototying a port to Malli we realized a “flowing and” schema was difficult to justify, where the parsing results are passed to the next conjunct’s parser. On the other hand, parsing :and has many use cases. I proposed instead we:

improve :and parsing to be more predictable and
introduce a new schema :andn which parses all its branches, but returns them all independently.

The solution to the first problem relies on a new extension point for schemas m/-parser-infowhich describes the parsing behavior of the schema. Simple schemas like :int and :string have simple or non-transforming parsers, and should return {:simple-parser true}. Compound schemas like :orn return tagged values from parsing that are different from their input, which we designate as transforming parsers (and return nil or don’t implement m/-parser-info). Other parsers are not as clear cut: :or is sometimes one or the other depending on its children, and most compound schemas inherit parsers from their children. This is why m/-parser-info is a function, not a static configuration.

We use m/-parser-info to improve :and’s parsing behavior by identifying up to one transforming parser from its children, and designating that as the parser for the entire schema. The other conjuncts are used only to validate the input value. This works for unparsing too, but in reverse: the transforming schema is used to unparse the value, and then the other conjuncts validate the unparsed output value.

An error is thrown if more than one transforming parser is detected when creating :and [un]parsers. There is a property to override which conjunct to use for transforming, if any.

Our hope is that the parser analysis is precise enough that it only throws an error in genuinely problematic cases. So far there have been no reports of real-world problems, most notably against Metosin’s codebase, though it is pre-release at the moment.

Follow-up work on improving the parser analysis for regex schemas was identified after a fruitful discussion on the #malli Slack channel. I also successfully used the new abstraction to build a new schema classifier/linter for identifying schemas that “roundtrip” with respect to (comp (m/unparser s) (m/parser s)).

Malli’s new maintainer Matti reached out to me to coordinate my next steps. We hope to merge some of my open PR’s and then I will coordinate with community members on the details of the proposed project: an optimizer for Malli schemas.

UIx: Roman Liutikov

Q3 2025 $2K, Report No. 1, Published October 15, 2025

Last month I focused on benchmarking and testing auto-memoizing compiler to measure potential gains in real world projects and ensure correctness of the output.

While synthetic testing showed ~60% improvement in re-render times, in real projects the gain is more conservative, up to 30% in most cases. The numbers will obviously differ between codebases. As the compiler will be evolving, it will be able to optimize more constructs, as long as your UIx/React code is clean and idiomatic ofcourse :)

In the meantime, while the compiler is able to optimize only basic constructs, I added a few compiler warnings in UIx to guide users and let them know what code locations should be fixed in their code. A positive side effect of those small refactorings is, well, more idiomatic React code.

However, all optimizations have their downsides. While your UIx apps will automatically reduce amount of updates during runtime, at startup time (when your app renders for the first time) UIx will need slightly more time than the version of UIx without auto-memoizing compiler. Fear not, this delta is negligible.

Next steps

The plan is to keep working on edge cases and improve how deep the compiler can reach into user’s code and optimize it.

Uncomplicate Clojure ML: Dragan Duric

Q3 2025 $9K, Report No. 1, Published Sept. 30, 2025

The proposal was:

My goal with this funding in Q3 2005 is to develop a new Uncomplicate library, ClojureML.

a Clojure developer-friendly API for AI/DL/ML models (in the first iteration based on ONNX Runtime, but later refined to be even more general).
Implement its first backend engine (based on ONNX Runtime).
support relevant operations as Clojure functions.
an extension infrastructure for various future backend implementations.
a clean low-level integration with Uncomplicate, Neanderthal, Deep Diamond and Clojure abstractions.
assorted improvements to Uncomplicate, Neanderthal, Deep Diamond, to support these additions.
develop examples for helping people getting started.
related bugfixes.
TESTS (of course!).

Progress so far:

In the first month, I have already implemented the first version, which I released to Clojars as org.uncomplicate/diamond-onnxrt.

So, what has been done in this first version?

I have investigated various available ways to run ONNX runtime (ORT). There’s a Java binding that Oracle donated to the (Microsoft-led) ONNX Runtime project. It’s decent, but does not support all ORT functionality, and, more importantly, is not the best choice for Clojure, since it comes with their own Java-ness. Also, the public distribution only comes with vanilla execution engine, and does not include the real stuff, namely CUDA and DNNL engines, which require each user to build their own jars. So, this one was to avoid if possible.

That left me with the trusty JavaCPP, which was my first choice anyway, since Clojure CPP is based on it, and I use it for native bindings throughout Uncomplicate libraries. JavaCPP comes with two bindings for ORT: C++ based, and C-based API. I started with C++ based API, but it turns out the native generator is at odds with the way ORT does resource cleaning, so the default destructors are irreparably crashing the JVM.

I then ported whatever I implemented with the C++ API to the C API, and it turned out to be the right match for Clojure and Uncomplicate way of doing stuff. I then proceeded to discover the ORT API, write Clojure bindings, and create tests that help me shape things to fit into Clojure ergonomics.

Along the way, I discovered a few things that need to improved in JavaCPP’s ORT bingings themselves, and helped the upstream developers fixing/improving these.

I created a few higher-level example tests with common modeling problems and used these to guide improvements of the internals. The goal is to have an implementation that is, at the same time fast, easy to use, low on resources (as possible), fits into Clojure ergonomics, and capable of meeting the real world usage needs. It’s not perfect yet, but it looks to me that I’m getting there even more than I expected.

The thing that (pleasantly!) surprised me that I didn’t even need to introduce new API: the Deep Diamond API already conceptually supports what we want here! A few small adaptations were needed, but no breaking changes. I even managed to create example where an ONNX model is a part of Deep Diamond network! (in the ubiquitous MNIST example).

That, I think, gave a huge justification for Deep Diamond’s Tensor machinery. Normally, each new framework that we want to integrate comes with its own abstraction for data structures, needing ways to get data in and out, convert formats and data types, etc. Deep Diamond just handled these without sweat! It is already so featureful and flexible that I managed to blend ONNX runtime structures without much hitches.

So, I guess the remainder of the project will focus on just doing more of the same to broaden the ONNX feature coverage, making whatever can be configured automatically invisible, and making whatever must be configured by the user simple and approachable, making more examples, and generally polishing everything in several cycles of improvements.

The library is now renamed from Clojure ML to Diamond ML (and umbrella for diamond-onnxrt and a few possible future libraries such as diamond-tensorrt, diamond-torch, etc.) and can be found here: https://github.com/uncomplicate/diamond-ml. The idea now is that we don’t actually need a separate library and api for this, and that these integrations, as Diamond ML, are add-ons that seamlessly blend into Deep Diamond, the core library.

I’m quite pleased with the results in the first quarter, I hope the users would be, too!

2025 Board Nominations: Time to Vote

Mon, 06 Oct 2025 14:09:25 +1200

Clojurists Together is in the process of electing new board members to fill the four volunteer positions that are expiring this year. These positions are for two-year terms (approximately Nov. 2025 - Oct. 2027).

The board is responsible for governing the organization, selecting and administering the projects that are sponsored, and interacting with sponsors. It also facilitates decision-making and implementation for the future plans of Clojurists Together.

We received 10 applications from the Clojure Community. 4 are from current board members who would like to continue to serve. All of the candidates are talented Clojurists that we would love (and be honored) to have on our board.

The board has nominated all 10 candidates for the current board election (in alphabetical order of last names):

Felix Barbalet (current board member)
Daniel Compton (current Treasurer/Secretary)
Rafal Dittwald
Arthur Fücher
Heather Moore-Farley (current board member)
Felippe da Motta Raposo
Christoph Neumann
Max Penet (current board member)
Howard M. Lewis Ship
Daniel Slutsky

Next Steps

All current Clojurists Together Members should have received a link to their ballot to vote via email. If you haven’t received a ballot by 9th October (and you’ve checked your spam folder to see if it’s hiding there), please contact kdavis@clojuriststogether.org.

Voting will close on 16th October at midnight Pacific Time. The top four candidates, as voted on by members will fill our open slots. Please note that our bylaws stipulate that “there may not be more than two members under the control or close influence of the same entity. If this threshold is crossed then members must stand down until there are no more than two members from the same entity”. This year, there are 3 candidates from the same organization. So depending on the election results, we may need to make an adjustment after the votes are in.

We will announce the winners shortly afterward and you’ll be able to meet them at the Annual members meeting at 10 am Pacific time, October 29, 2025

Your Vote is Important!! Please Vote!

Meet the Candidates

Felix Barbalet

https://github.com/xlfe/

Company: Psithur
I’ve really enjoyed contributing to the Clojurists Together board over the past two years, and I hope I’ve brought a helpful view and been able to make a difference to help grow the Clojure ecosystem.

I’ve been using Clojure professionally for 5+ years and I’m now running a small software/data company which uses full stack Clojure. Clojure has been the continuation of a life-long learning journey for me, and I don’t see that slowing down. The kind of things I’m interested in are figuring out how to raise the profile of Clojure as a smart choice for large enterprises all the way down to startups, and to help reduce the barriers to entry to Clojure as a profession. I want to see Clojure continue to grow and I’d love to see more corporate support to bring Clojure to more people.

Bio: I’ve spent >15 years working as a technologist in a range of roles including analytics, data science, data engineering, software architecture and software engineering. I have experience across highly-regulated industries (Government), consulting and startups. I have a B Economics (Honours) with specialisation in advanced econometrics, statistics, game-theory and behavioral economics and a graduate certificate in Cyber Security.

Daniel Compton

https://github.com/danielcompton
x.com/danielwithmusic

Company: Whimsical
I’ve been a board member of Clojurists Together since the beginning, as well as the secretary/treasurer. I have been the main board member running day-to-day operations of Clojurists Together since we began.

Bio: I’m Daniel Compton. I live in New Zealand and have been a board member of Clojurists Together since it began, as well as the secretary/treasurer. I have been the primary board member running day-to-day operations of Clojurists Together since we began. I’d like to continue to serve the community through running Clojurists Together.

Rafal Dittwald

https://github.com/rafd

Company: Bloom Ventures
I see this as an opportunity to serve and give back to our great community. Clojurists Together is a critical part of the Clojure ecosystem, and I want to see it and the community grow. I believe CT could serve as the foundation, for, well, a Clojure Foundation, supporting the Clojure commons in various new ways - such as financial host on Open Collective, an intellectual property host, and maybe experiment with community participation in selecting projects (via, say, quadratic funding). …if other members are supportive, of course.

Bio: Rafal has been working with Clojure for over 10 years, primarily building web applications (many of which are open-source). He organizes Clojure Camp and has given a few talks (such as Solving Problems the Clojure Way). He has been a Clojurists Together member since its inception. He has served on the board of 3 for-profit corporations and 2 non-profit corporations.

Arthur Fücher

https://www.linkedin.com/in/arthur-fucher/
https://github.com/afucher ; https://www.youtube.com/@clojure-br
I am also member of InnerSource Commons (https://innersourcecommons.org/about/members/)

Company: Nubank
I’ve been working with Clojure for over five years, including three years on platform engineering and developer experience, building tools and infrastructure for developers. I also contribute to open-source Clojure projects and organize ClojureBR, the Brazilian Clojure community, which promotes meetups and content in Portuguese.

Clojure and its community have given me a lot, and I’d like to give back by helping Clojurists Together strengthen the Clojure ecosystem globally and bring the perspective of Brazil, where many companies and developers are producing high-quality open-source. My experience in tooling, open source, and community organizing equips me to evaluate projects, contribute ideas, and help make the organization more inclusive and impactful.

Bio: Arthur Fücher is a Clojure developer who in recent years has focused on improving developer experience and platform tooling. He contributes to open-source Clojure projects and organizes ClojureBR, the Brazilian Clojure community. Arthur is passionate about Clojure and dedicated to growing its community, sharing knowledge, and supporting initiatives that help more people discover and use the language.

Heather Moore-Farley

https://github.com/tophat8855

**Company:**Peerspace
I’ve been on the board for the past 4 years and have a good idea of the time commitment and work involved. I love working with Clojure and like learning about and funding projects that are important for the Clojure ecosystem.

Bio: Heather has been a software engineer for over 10 years and has been using Clojure and Clojurescript for almost 8 years. When she’s not coding, she’s biking and drumming.

Felippe da Motta Raposo

https://github.com/felippemr/
https://www.reanard.com/
https://www.linkedin.com/in/felippe-raposo/

Company: VitableHealth
I am inexperienced with Clojure and could provide a beginner’s perspective on projects and community initiatives that help people accelerate their learning experience. I could also help with creating targeted industry guides for fintech and healthtech – helping people clearly understand Clojure’s value proposition outlined to their specific needs.

Bio: Felippe has over a decade of experience building software, from a database-as-a-service platform managing thousands of resources to large-scale systems that power automated money movement in the venture ecosystem — and more recently, in healthcare. He’s contributed to open source projects and spoken at Python community events in Brazil. Outside of work, Felippe enjoys reading with his kids and has recently introduced his six-year-old son to the Captain Tsubasa manga.

I currently live in Sandy, UT. USA.

Christoph Neumann

https://christophneumann.dev/

Company: Nubank
I believe that it’s vital to fund open source development for Clojure to grow and remain viable for years to come. I’d like to join the board because I love the work Clojurists Together is doing, and I would like to help. I think I’m a good fit because I’ve been active in the Clojure community for a decade, and I’m the developer advocate on the Clojure core team.

Bio: Christoph is a Clojure fanatic, entrepreneur, and the Clojure team’s developer advocate. After earning a MS in Computer Science and most of a PhD, Christoph left academia to take functional programming and user-centric design back into industry. He went on to make exceptionally-reliable, high-performance Clojure systems for live sports and esports production. He’s worked with some of the biggest names in the industry, including the NFL, Wimbledon, Call of Duty, and The Overwatch League.

With his friend, Nate Jones, he hosts the “Functional Design in Clojure” podcast. For more than 100 episodes, they have helped object-oriented developers escape the perils of side effects through immutable, functional programming. Visit christophneumann.dev for links to everything.

Max Penet

https://github.com/mpenet

Company: Exoscale
I’m committed to continuing to make a positive impact on the community through CT’s work. I genuinely enjoy helping out whenever possible, especially through the various discussion channels. Having benefited greatly from this community myself, it feels only fair to give back by contributing my time and effort. Given my long-standing involvement and reliance on a healthy, thriving Clojure community for both personal and professional projects, I believe I could be a good fit for this role.

Bio: I currently work as a software engineer at Exoscale, a European cloud provider that depends heavily on Clojure. I’ve been an active member of the Clojure community and have used Clojure professionally for over a decade across various fields. Over the years, I have authored, contributed to, and maintain several open-source libraries. I also stay closely engaged with the community on a near-daily basis, always aiming to offer help whenever possible. Most importantly, I deeply appreciate what CT is doing and would love to be able to help sustain that effort for two more years.

Howard M. Lewis Ship

https://lewisship.net/
https://github.com/hlship

Company: Nubank
I have long experience contributing to the open source community as an individual and as a representative of my employers (such as Walmart and Nubank), and have a new role at Nubank leading our open source enablement team, where part of my mandate is to engage with existing open source organizations and communities. I’ve been interested in Clojure since approximately 2010 and actively using it professionally since 2013.

Bio: I’ve been involved in open source projects since at least 2003; starting with Java (and the Apache Tapestry framework, which I founded) and continuing more recently with Clojure projects, including the Lacinia GraphQL framework, the Pedestal web framework, and org.clj-commons/pretty, as well as other less prominent projects.

I’m very much interested in contributing back to the Clojure open source community, as I think these efforts are critical to the long-term viability of the Clojure language.

Daniel Slutsky

https://github.com/daslu

Company: consultant at Daniel Slutsky LTD, full-time contractor for endor.global.

I deeply care about the Clojure open-source communities and Clojure growth, and these topics have been my main focus during the last few years, at Scicloj and elsewhere.

Bio: I’m Daniel Slutsky, a mathematician and data science consultant who has been working with Clojure since 2013. I co-organize Scicloj, where our mission is “Helping Clojure grow in new fields” - including academia, research, education, and domains beyond traditional software engineering.

My approach to community building draws from years of experience in local social activist groups, emphasizing inclusive collaboration and helping newcomers find their place in action-oriented projects.

I help maintain several open-source projects including Clay (literate programming), Noj (data science toolkit), Tableplot (data visualization) and ClojisR (Clojure-R bridge). Through mentorship programs, conferences like SciNoj Light and Macroexapnd-2025, and ongoing study groups focused on tooling, AI, and real-world applications, I work to create accessible pathways for people to explore Clojure in their fields of interest.

As a recipient of Clojurists Together grants in 2024 and having collaborated with a few other grantees, I’ve seen firsthand how this support enables community-driven work that expands Clojure’s reach. I would welcome the opportunity to help CT in supporting projects that both strengthen our existing open-source ecosystem and welcome new voices from diverse fields.

Annually-Funded Developers' Update: July/August 2025

Wed, 17 Sep 2025 14:00:00 +1200

Hello Fellow Clojurists! This is the fourth report from the 5 developers receiving Annual Funding in 2025.

Dragan Djuric: Apple M Engine Neanderthal, Deep Diamond CPU
Eric Dallo: ECA, clojure-lsp, clojure-lsp-intellij
Michiel Borkent: clj-kondo, babashka, SCI, clj-kondo, scittle, and more…
Oleksandr Yakushev: CIDER, clj-async-profiler, nREPL
Peter Taoussanis: Sente, Truss, Trove, Telemere

Dragan Djuric

2025 Annual Funding Report 4. Published September 4, 2025.

My goal with this funding in 2025 is to support Apple silicon (M cpus) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

Having a decent Apple CPU engine for Neanderthal completed in the May-June period, I could continue building on the work on the Deep Diamond CPU engine for Apple hardware that I’ve started.

I had already found out that Apple’s low-level APIs (BNNS) are not very well thought out (as I wrote in the last report), so I expected it to be a not so pleasant march. And it wasn’t. No wonder why large parts of it are already deprecated, in favor of Graph API (which does not replace it’s functionality, but is a completely alternative way of dealing with tensors and Deep Learning).

However, there were no room for quitting, since we need at least a basic tensor functionality, regardless of DNN operations, so we can later potentially integrate the Graph API and other tensor-based libraries. Besides that, the NDArray and Tensor parts of BNNS is not deprecated, so that’s the stuff we have to work with.

I will spare you the gory details, including lots of segfaults and WTFs, but in the end I managed to tame it, and even fit it into the existing deep-diamond/dnnl API, with backward compatibility (not including the convolution and rnn ops which I found not worth trying to tame at this stage).

Then, just at the end of the month, I even managed to tidy up a Apple silicon enabled Deep Diamond release (0.35.2, 0.35.3).

It’s in the Clojars!

I didn’t have time and resources to advertise it wildly right away, and the next day I already started working on the ONNX Runtime integration, so it’s still an Easter egg for the dedicated folks who actually read these reports. :)

I’ve already worked on Neanderthal, and made a release with assorted bugfixes and improvements.

It’s not a glamurous work, working at these lower levels, but I see bright future for Clojure tensors. Cheers!

Eric Dallo

2025 Annual Funding Report 4. Published September 8, 2025.

In these last 2 months I mainly focused on my recently created project, ECA and its related projects, there were so many improvements and new features, the project grown a lot with lots of people using!

eca

ECA (Editor Code Assistant) is a OpenSource, free, standardized server written in Clojure to make any editor have AI features like Cursor, Continue, Claude and others.

0.2.0 - 0.43.1

There were so many releases I can’t just put the whole changelog here hehe, but the main highlights were:

Web page_: A whole new site detailing the project, docs and features: https://eca.dev
New models_: Anthropic (with subscription too), OpenAI, Github Copilot, Z.AI, OpenRouter, Azure and many others
Custom providers_: It’s possible to configure custom providers for your models.
Command support_: built-in commands + mcp commands + eca commands + custom prompts. Ex: /login, /my-prompt
Plan behavior_: Plan your changes before tellin LLM to act.
AGENTS.md_: /init your project to update/create a AGENTS.md file so ECA will have more context.
Editor diagnostics: New tool eca_editor_diagnostics which gets LSP diagnostics about your project.

And many more! come to #eca Clojurians channel.

eca-emacs

After testing other tools, improving a lot and receiving positive feedbacks, I believe ECA emacs offers the best Emacs tool for AI development right now, which is great, there are still so many features to add!

eca-intellij

New editor support! :tada:
Using the same UX from eca-vscode.

eca-vscode

Multiple improvements, especially extracted the webview to eca-webview so it can be used by eca-intellij as well.

clojure-lsp

There were mainly improvements in performance regarding clj-kondo bumps and some small fixes. Also now we have a new custom linter clojure-lsp/cyclic-dependencies!

2025.08.15-15.37.37 - 2025.08.25-14.21.46

Docs
- update neovim editor configuration for clojure lsp
General
- New feature: Add clojure-lsp/cyclic-dependencies linter to detect cyclic dependencies between namespaces in the project.
  - Change clojure-lsp/cyclic-dependencies custom linter default level to be off until corner cases are fixed.
- New optional :kondo-config-dir setting to configure clj-kondo execution.
- Parallelize and log the time spent on built-in linters execution.
- Fix #1851: Error when source files have non-ASCII characters in their path or name
- Fix caching issue when :source-aliases changes. #2081
- Fix emitting invalid messages if there’s an internal error.
- Bump clj-kondo to 2025.07.28 considerably improving memory usage.
Editor
- Avoid lint .lsp/stubs folder when starting.

Michiel Borkent

2025 Annual Funding Report 4. Published September 5, 2025.

In this post I’ll give updates about open source I worked on during July and August 2025.

To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you the below projects would not be as mature or wouldn’t exist or be maintained at all! So a sincere thank you to everyone who contributes to the sustainability of these projects.

c:\Users\kathl\Documents\Documents\Clojurists Together\2025 Reports\mayJune lng term 2025\mb-switzerland-2025.jpeg

Current top tier sponsors:

Open the details section for more info about sponsoring.

Sponsor info

August 2025 Clojars Support and Q2 Project Updates

Fri, 12 Sep 2025 14:00:00 +1200

Greetings all! We have updates from two Q2 projects and a new report from Toby Crawley who provides ongoing support and maintenance for Clojars. You’ll find a brief description of the all these projects below.

Toby Crawley: Clojars Support and Maintenance
Toby’s report includes links to Clojars Changelogs for March through July 2025 as well as an overview of fixes and updates. He monitors community channels on a regular basis. If you have any issues or questions about Clojars, you can find him in the #clojars channel on the Clojurians Slack, or you can file an issue on the main Clojars GitHub repository.

Karl Pietzrak: Code Combat
This project will focus on adding Clojure(Script) to CodeCombat. See Wiki page at https://github.com/codecombat/codecombat/wiki/Aether

Siyoung Byun: SciCloj Building Bridges to New Clojure Users
Scicloj aims to improve the accessibility of Clojure for individuals working with data, regardless of their programming backgrounds. The project aims to develop standardized templates to encourage greater consistency across the documentation of existing Scicloj ecosystem libraries, making those libraries more robust and user-friendly.

Clojars Support and Maintenance: Toby Crawley

This is an update on the work I’ve done maintaining Clojars in March through July 2025 with the ongoing support of Clojurists Together.

Most of my work on Clojars is reactive, based on issues reported through the community or noticed through monitoring. If you have any issues or questions about Clojars, you can find me in the #clojars channel on the Clojurians Slack, or you can file an issue on the main Clojars GitHub repository.

Below are some highlights for work done in March through July:

I finally addressed issues with running out of memory on occasion. It turned out to be the in-memory session store; we were using aging sessions, but we were generating enough sessions in 48 hours (the session ttl) to exhaust the heap. Adjusting the ttl to 1 hour solved the problem, but a better long-term solution would be to not create a session until a user logs in, as that is all we need a session for. Clojars currently creates a session for each visit to the site.
Clojars was storing uploads in /tmp during deploys, and there is no signal to when a deploy is complete, so we can’t delete them at the end of the deploy. This was causing the server to run out of disk space, so I moved upload storage to a larger partition, and made tmp file cleanup happen more often.
We had some client that was repeatedly connecting to Clojars, then failing TLS negotiation, then trying again. This caused our AWS load balancer expense to increase by several hundred dollars, so I blocked that IP address from accessing Clojars.
I upgraded a few dependencies to address some CVEs.
I worked on spiking out how to implement using Problem Details (rfc9457) to return deploy validation failures to the client. See this issue for more details.

I worked with Ambrose Bonnaire-Sergeant on some security (& other) fixes:

Fixing, then inlining a deps.edn alias we used to override versions to resolve CVEs. We weren’t actually using the alias when building the uberjar, and then realized we didn’t need the alias at all, as those dependencies could be top-level.
Adding a pom.xml to the repository to allow Dependabot to detect vulnerable dependencies.
Importing/adding clj-kondo configurations for dependencies to give better linting.

Code Combat: Karl Pietzrak

Q2 2025 $2k. Report No. 1, Published 9 September 2025

Successfully deployed CodeCombat on our own private cloud (GCP)
Some of CodeCombat’s dependencies are very old:
- for sandboxing user code, Aether, hasn’t been updated since 2017
- closer.js, which contains some Clojure support, hasn’t been touched since 2014.
  We are in the process of updating these so build in a modern context, as many of their dependencies are dead.

Progress update to follow in our next report.

SciCloj Building Bridges to New Clojure Users: Siyoung Byun

Q2 2025 $2k. Report No. 2, Published 14 August 2025

In the time since my previous update I have continued to focus on the community expansion side of the Scicloj initiative. The work and effort continues as a long-term goal alongside other dedicated contributors in the Scicloj community.

Macroexpand 2: Connecting Clojure Data Practitioners

I co-hosted and prepared a three-hour-long online discussion session called Macroexpand 2: Connecting Clojure Data Practitioners as part of Macroexpand gatherings on August 9th. Working with co-host Daniel Slutsky, I planned the event agenda and reached out to Clojurians from diverse backgrounds and positions to invite them to join and share their insights at this gathering.

This initiative represents a step forward in positioning Scicloj not only as a data science community, but as a platform for community expansion, networking, and outreach in the Clojure ecosystem by providing dedicated space and time for discussing and sharing knowledge between individuals and organizations.

Purpose of the Gathering

The gathering aimed to share real-world experiences and challenges, provide networking opportunities for fellow Clojurians while identifying and developing concrete solutions to common problems, and shape clearer direction for follow-up sessions.

Key Outcomes

The gathering brought together participants from different organizations with varied backgrounds, giving us an opportunity to collect valuable insights as individuals, groups, and as a community. The event included participant introductions, lightning rounds where some attendees presented ongoing projects, community expansion efforts, educational outreach initiatives, and discussions about potential tools or platforms for facilitating hiring and job opportunities within the Clojure ecosystem.

Through discussions about success stories of using Clojure in data work, current challenges, and hiring market impressions, we identified several key insights: including the critical importance of integration libraries and tools for other languages (particularly with an example with Python integration).

Other insights included the value of staying connected within the community not only for technological updates but also for accessing new job and collaboration opportunities, and the importance of using streamlined communication channels to maintain community connections. We also explored actionable strategies the community could implement to support and sustain a healthy, thriving Clojure ecosystem.

We partially recorded the gathering, and will publish an edited version soon.

Further Vision

This gathering represents an ongoing initiative rather than a one-time event. Following this successful first session, we are confident that such community discussions are both important and needed. I will continue organizing future gatherings, with formats evolving based on participants inputs and feedbacks along the way. I am excited about the potential impact of this initiative, and look forward to contributing and sharing its outcome in the future.

Macroexpand 2025: Two Upcoming Online Conferences

Macroexpand 2025(two online conferences) will be held in October 2025 hosted by Scicloj. I have been working as a co-organizer to prepare for the conferences, and this initiative will continue.

About the Conferences

Macroexpand-Noj (October 17-18, 2025) focuses on practical applications of the Noj toolkit in real-world data science, featuring talks on any data analysis related projects and methology, updates on the tool, documentation efforts. And Macroexpand-Deep (October 24-25, 2025) is dedicated to AI system research and applications in Clojure, exploring deep learning networks, large language models, vector embeddings, and supporting infrastructure.

Current Work

As one of the organizers, I am actively preparing and organizing both conferences. I published a post about the upcoming conferences on Clojure Civitas, including a call for speakers.

I will continue to assist potential speakers in preparing talks, brainstorm talk ideas with interested participants, reach out to community members, help others conceptualize their projects for presentation, contribute to Scicloj organizing team discussions, and plan the upcoming conferences. This remains an ongoing initiative with significant potential for community impact.

2025 Board Nominations and Our Annual Meeting

Fri, 05 Sep 2025 08:30:00 +0800

Clojurists Together is having our fifth board elections, and our fifth annual members meeting.

Key dates

(All dates are EOD, in Pacific Time)

Board nominations close: Sept. 25, 2025
Voting opens: a few days after submissions close and after the board has nominated candidates
Voting closes: October 16, 2025
Annual members meeting: Oct. 29, 2025 - 10 am Pacific time

Board Elections

As part of our commitment to transparency and community governance, Clojurists Together holds elections for board members. The Committee is responsible for governing the projects, selecting which projects are sponsored, administering the projects, and interacting with sponsors.

Committee members are elected for a two-year term. Each election cycle, half of our board seats come up for re-election. This year there are four seats available.

If you are interested in standing for election, please fill out this form by Sept. 25th, 2025 - 5 pm Pacific Time. If you can’t access the form, contact us, and we can accept your nomination by email. Nominations are open to anyone, you don’t have to be a Clojurists Together member to stand for election. Our bylaws do require you to be a member if elected to the board, though we provide a stipend that offsets the cost of your membership.

You don’t have to have lots of experience with Clojure to apply. We want a committee made up of a cross-section of the Clojure community so that we have a wide range of perspectives when making decisions on which projects to fund.

As part of the nomination, if we get more than 12 candidates for board membership, the board will nominate no more than 12 candidates. Our bylaws state:

The Board shall nominate no more than 12 candidates seeking board membership in any given election. In nominating candidates for Director positions and in choosing the number of candidates to nominate overall, the Board shall use reasonable efforts to maintain a Board composition consisting of at least: (1) 25% female Directors, (2) 25% non-Caucasian Directors, and (3) 35% from any category(ies) of persons (e.g., race, gender, ability) commonly considered to have suffered from discrimination at some time and then-currently under-represented in the technology industry, in each case as determined by the Board in its reasonable discretion.

The main responsibilities of a committee member are:

Participate in the general discussions of the month-to-month running of the program
Evaluate and vote on which open source projects to fund
Help in decision-making for the future plans of Clojurists Together
These responsibilities take roughly one hour/month, though there are peaks and troughs of activity as we go through our quarterly funding cycle. If you have more time to offer, there are lots more things that need developing, automating, designing, e.t.c. It would be great to have you help out with those things, but we don’t want to exclude people from standing because they don’t have a lot of spare time.

Our bylaws requires that we do not have more than two committee members from any one company. More than two people from a company can stand for election, but if more than two of these people were to be elected, only the top two ranked candidates would be elected and the other seats would go to the next most highly ranked candidates from other companies. If you have any questions about this, please get in touch.

Elections will be held once the candidates are announced, and all Clojurists Together members will be eligible to vote.

Annual Members Meeting

We are also holding our fifth members meeting at 10 am Pacific time, October 29, 2025. This will be an opportunity for Clojurists Together to share information about 2025 to date and discuss future plans, present the new board members, and most importantly take questions from and engage with members.

More details on this will follow including a videoconferencing link.

Please share this with anyone you think would be able to represent the interests of the Clojure community and Clojurists Together members. Thanks for your support of Clojurists Together, we appreciate it!

Q3 2025 Funding Announcement

Sat, 23 Aug 2025 08:30:00 +0800

Clojurists Together is excited to announce that we will be funding 6 projects in Q3 2025 for a total of $33K USD (3 for $9K and 3 shorter or more experimental projects for $2K). Thanks to all our members for making this happen! Congratulations to the 6 developers below - we’re looking forward to your project updates.

$9K USD Projects
Ambrose Bonnaire-Seargent: Malli
Dragan Duric: Uncomplicate Clojure ML
Jeaye Wilkerson: Jank

$2K USD Projects
Jeremiah Coyle: Fireworks
Roman Liutikov: Uix
Thomas Clark: FastMath

And here’s a project description from each developer:

Ambrose Bonnaire-Sergeant: Malli

Automatic Schema Optimizer and Simplifier

There are many different ways to organize schemas in malli based on your needs. You might write them manually, deciding between registries or top-level defs, and :multi vs :or. You can even generate them automatically from external data sources, with much less control over the final nested structure of your schemas.

Unfortunately, malli’s core algorithms for transforming schemas into things like validators and generators are quite sensitive to the the input schema. Even seemingly equivalent schemas can have different performance characteristics and different generators.

I would like to create a schema analyzer that can simplify complex schemas, such that two different but equivalent schemas could have the same representation. Using this analyzer, we can build more efficient validators, more reliable generators, more helpful error messages, more succinct translations to other specification tools, and beyond.

This work directly follows my previous Clojurists Together project on map constraints: https://www.clojuriststogether.org/news/nov.-2024-short-term-project-updates/

Dragan Duric: Uncomplicate Clojure ML

I propose to implement:

a Clojure developer-friendly API for AI/DL/ML models (in the first iteration based on ONNX Runtime, but later refined to be even more general).
Implement its first backend engine (based on ONNX Runtime).
support relevant operations as Clojure functions.
an extension infrastructure for various future backend implementations.
a clean low-level integration with Uncomplicate, Neanderthal, Deep Diamond and Clojure abstractions.
assorted improvements to Uncomplicate, Neanderthal, Deep Diamond, to support these additions.
develop examples for helping people getting started.
related bugfixes.
TESTS (of course!).

Jeaye Wilkerson: Jank

This next quarter of jank development is what ties everything together. We have a Clojure compiler and runtime. We have gorgeous error reporting. We have seamless C++ interop. Now we need jank to be easy to build and install on both macOS and Linux. We need stable and robust tooling, including leiningen and deps.edn support. We need to fill in all of the cracks, squash the bugs, document features, and get jank into a state which our adventurous alpha testers can use.

This quarter, I’ll be building packages for Ubuntu, Arch, Homebrew, and Nix. I’ll be minimizing jank’s dependencies, automating builds, filling in test suites for module loading, AOT building, and the Clojure runtime. I’ll be working to get the final Clang and LLVM changes I have upstreamed into LLVM 22, adding a health check to jank to diagnose installation issues, and filling in some C++ interop functionality I couldn’t get to last quarter.

Altogether, this quarter is going to be a hodgepodge of all of the various tasks needed to get jank shipped.

Jeremiah Coyle: Fireworks

Primary goals for Fireworks, Q3 2025

Editor integration
Publish Fireworks editor plugins/extensions/integrations for Emacs, VS Code, and IntelliJ. These are fairly simple extensions that involve some basic form rewriting for wrapping/unwrapping forms.

Automatic color support detection
Add support for automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to Chalk. #42

Documentation of interactive workflow.
Produce written and/or video documentation a live hot-reloading dev environment for JVM Clojure, powered by Fireworks and Bling.

Enhanced documentation for theme creation.
Produce written and/or video documentation that makes it easier for people to create their own themes to suite their tastes.

Call-site options for quick formatting changes.
For hifi printing, support call-site option to disable all truncation and ellipsis
#14

Secondary goals for Fireworks, Q3 2025

Pipeline for cljs browser console printing
Hifi output with Fireworks works just fine for printing to a browser dev console. Post-processing ansi-tagged output for browser console printing, would, however, be a big improvement vs the current implementation.

Option for changing label color at callsite
Allow for quick call-site changes to the label color for Fireworks output. #53

Support bold output
Allow for quick call-site changes to the produce bold Fireworks output. #70

Support for native JS sets and maps in CLJS
When hifi printing, properly display contents of JS Sets and Maps, when they are within a native cljs data structure. #46

Map layout flexibility
For hifi printing, support call-site option to force single-column map layout a la carte. This is sometimes preferable when map contains keys or values that are long strings. #45

Roman Liutikov: Uix

I’m currently experimenting with auto memoizing compiler for UIx, an optimization similar to React’s Compiler https://react.dev/learn/react-compiler. This blog post describes the feature in detail https://romanliutikov.com/blog/bringing-granular-updates-to-react-the-clojure-way. As a result of this work UIx apps should get better baseline performance out of the box, with fewer work needed from developers.

Thomas Clark: FastMath

Inasmuch as Lewis Carrol may have creatively objected, complex numbers are now an essential part of modern life: from quantum computing upwards and whether we are aware of it or not. Clojure’s support for these numbers however, remains sporadic while it’s biggest competitor, the well-known comedy snake - and scripting language https://www.geeksforgeeks.org/python/history-of-python/ treats complex numbers as first-class citizens.

With this funding, I would like to address the issue somewhat, particularly with regard to the implementation of complex matrices, but concerning a consistent complex API more generally.

Surveying the current field, the ‘emmy’ library seems to be the most developed option in this area, but it is focussed on symbolic manipulation. When dealing with large memory simulations, it is unlikely to be competitive. ‘core.matrix.complex’ seems to be the numerical choice, but its last commit was 5 years ago, it is a thin wrapper over apache commons and not all matrix protocols seem to have been extended to complex numbers. More confusingly, when dealing with numerical matrices more generally, the go-to choices are fastmath and neanderthal - neither of which have implemented complex matrices.

As the ecosystem is clearly fragmented, this project would seek to extend fastmath, which is the current high-level go-to for numerical matrices, to deal with complex numbers in an API-consistent way.

I would proceed as follows:

extended survey of the status and limitations of the present options (including performance tests for the current implementations)
decision on the best architecture for a competitive solution
Implementation/API creation for: ** complex vectors, arrays and fundamental matrix ops (including scaling/trace determinant etc.)
** LU decomposition and solver
Integration with:
**existing fastmath functions, e.g. including fourier analysis and polynomials
** Wolframite
** Clay / kind
Performance comparisons with (at least):
** Python
** Emmy
** Wolframite
Publication of a full blog report, outlining an introduction to working with complex numbers in Clojure, complete with the results and analysis of the above.

July 2025 Short-Term Q2 Project Updates

Mon, 04 Aug 2025 14:00:00 +1200

This is the July and final project update for four of our Q2 2025 Funded Projects. (Reports for the other two are on a different schedule). A brief summary of each project is included to provide overall context. Thanks everyone for your awesome work!

Jeremiah Coyle: Bling
Add support for using hiccup to style and format messages, a template string syntax to style and format messages, and 1-3 additional formatting templates for callouts, headers, and points-of-interest.

Brandon Ringe: CALVA
A new REPL output view for Calva, which is a webview in VS Code. The webview will allow us to add more rich features to the output webview, while also providing better performance.

Bozhidar Batsov: CIDER
Provide continued support for CIDER, nREPL and the related libraries (e.g. Orchard, cidernrepl, etc) and improve them in various ways.

Jeaye Wilkerson: Jank
Build jank’s seamless C++ interop system.

Bling: Jeremiah Coyle

Q2 2025 $2k. Report No. 2, Published 14 July 2025

I’m happy to report that all of the Q2 primary and secondary goals were completed. In addition, some tertiary goals and user requests that popped up along the way were addressed. Many thanks to Clojurists Together for supporting this work!

Summary of goals achieved in Q2:

Primary goals
- Enable Hi-Fidelity, theme-able, colorized, structural printing of values via Fireworks. #29. Docs
- Utilize callout to create a specialized template for Malli validation errors. #28. Docs
- Figlet banners with lolcat-style gradient coloring. Docs
- Opt-in optimization for enhanced contrast in light or dark terminals. #30. Docs
- Respect NO_COLOR env var #27. Docs

Secondary goals
- Add enhanced support for using hiccup to style and format messages. #15
- Create 1-3 additional formatting templates for callouts, headers, and points-of-interest.
- Add/update documentation about how to leverage Bling to create great-looking warnings and errors.

Tertiary goals that arose in the course of solving the above
- Enhanced test suite for JVM Clojure and Node (JS)
- Enhanced test suite for Babashka
- Hifi printing support for custom datatypes whose size cannot be determined #69

The latest release is v0.8.7, which features most of the enhancements listed above.

Detailed descriptions and screenshots of the above features:

Specialized template for Malli validation errors

#28

This is experimental, with more work to be done on optimizing for disjunctions and cases with multiple errors on same value. Docs here

Bling offers bling.explain/explain-malli to present Malli validation errors:

The above code would print the following:

You can also pass an option trailing options map to customize the appearance of the printed output. In the example below, we are leaving out the display of the schema within the callout block:

The above code would print the following:

High Fidelity Printing

#29

Docs here

Bling offers bling.hifi for colorized pretty-printing of values. bling.hifi/hifi will return an ansi-sgr decorated string, while bling.hifi/print-hifi will print such a string.

Under the hood, the formatting/colorizing is achieved with Fireworks.

By default, the theme of this output will be Universal Neutral.

If you set a valid BLING_MOOD env var, the theme of the hifi output will be Alabaster Light or Alabaster Dark.

You can choose one of the other available themes by following the instructions in the Fireworks readme and setting up a config.edn on your system, with a corresponding BLING_CONFIG env var. This config will also let you control many other aspects of the formatting with the hifi output.

Check out the other available themes here

_{Alabaster Dark}

_{Alabaster Light}

Figlet banners:

Docs here

Bling now features basic support for composing Figlet ascii-art banners with lolcat-like gradient overlays. Bling ships with a small handful of ported Figlet fonts. The glyph layout implementation is bare-bones and there is currently no support for standard figlet smushing. Figlet banners only work in terminal context (JVM Clojure or Node.js ClojureScript).

Enhanced contrast

#30

Docs here.

You can set a BLING_MOOD env var to enhance the contrast of Bling-formatted output. Only takes effect on your system, for your eyes only.

Respect `NO_COLOR` env var

#27

You can set a NO_COLOR="true"env var, which will disable any colorization on from any output generated by Bling. The de-colorization only applies locally, for your eyes only. More info on the informal standard.

Enhanced support for hiccup

#15

Deeper hiccup support for a cleaner template syntax

Utilize [:br]tags for line breaks
Introduce a [:p]tag, to enclose logical paragraphs and automatically add trailing newlines.
Properly support nesting of styles ala [:bold "Bold, " [:italic "bold italic, "] [:red "bold red, "] "bold."]

'(require bling.core :refer [print-bling])

(println "\n\n")
(print-bling [:p "First paragraph"]
             [:p [:bold
                  "Bold, "
                  [:italic "bold italic, "
                   [:red "bold italic red, "]]
                  "bold."]]
             "Last line")

The above code renders the following:

An initial working implementation of the above is complete on branch 0.9.0. Next step will be to consider alternate implementations (perf), test, refine, then merge into main branch.

New callout templates

Callout docs here

New callout template with {:theme :minimal}:

New option :side-label which may be useful for file info etc.

With {:theme :sideline :label-theme :marquee :side-label "foo.core:11:24"}:

Enhanced support & improved docs for creating custom and warning callouts

bling.core/callout now accepts any number of arguments, which makes the templatization a little more flexible:

(defn my-error-callout [{:keys [header body source]}]
  (callout {:type        :error
            :padding-top 1}
           header
           source
           body))

(my-error-callout
 {:header "Your header message goes here\n"
  :source (point-of-interest 
           {:type                  :error
            :file                  "example.ns.core"
            :line                  11
            :column                1
            :form                  '(+ foo baz)
            :text-decoration-index 2})
  :body   (str "The body of your template goes here.\n"
               "Second line of copy.\n"
               "Another line.")})

The above callout would render like this your terminal emulator:

Hifi printing support for custom datatypes

This was a bug fix + enhancement #69 in the upstream Fireworks lib, which enables the representation of custom datatypes when printing with bling.hifi/hifi

Enhanced test suites

A new suite of tests for both JVM Clojure and Babashka was added. Docs here.

CALVA: Brandon Ringe

Q2 2025 $9k. Report No. 3, Published 13 July 2025

Since the last report, I spent some time adding content reloading support to the output view. By that I mean that when the output view is closed and reopened, and when the VS Code window is reloaded, the output view would reload its contents. However, this became problematic in multiple ways, so I decided to remove the feature in favor of reducing maintenance burden. The benefit of the feature did not outweight the cost of maintaining it, in my opinion. The PR for removing it can serve as a reference for anyone who might want to try implementing the feature in the future.

Here’s the list of changes to the output view that have happened since the last report:

Thank you to Clojurists Together and its members for supporting this work! I hope Calva users will enjoy using this output view.

CIDER: Bozhidar Batsov

Q2 2025 $9k. Report No. 3, Published 16 July 2025

This month wasn’t as productive as the last two (mostly due to a bit of vacation time and my seasonal allergies draining my energy), but we still made some good progress:

CIDER 1.19 (“Skiathos”)
- The highlight of this release is that Java source downloading is now enabled by default, as we’re feeling quite confident about its stability
- There are also plenty of small improvements here and there (mostly in the inspector)
- You can now also specify default connection params, which will save you a bit of typing in certain cases
clojure-ts-mode
- Small improvements to the built-in completion source
- Added the clojure-mode functionality for browsing the Clojure guides and reporting issues

There are a lot more things in progress that I didn’t have manage to get to the finish line (or remained only the realm of research for the time being):

A new starter configuration for CIDER users (to be released soon)
I looked into replacing Antora (the docs engine CIDER and friends are using) with mdBook (made popular by Rust)
- I’m on the fence about this and I probably will stick with Antora
I’ve started work on a couple of blog posts (e.g. the long overdue analysis of the CIDER survey results), but I didn’t manage to finish them. Coming soon, though!
I’ve encountered a few small blockers while working on removing the hard dependency on clojure-mode in CIDER, but we’ll get there
I’ve played with some screencast apps to record some new CIDER tutorials and I think I have a winner with which to proceed

Anyways, I plan to drive those over the finish line and once again I’m I’d like to thank the members of “Clojurists Together” for their support of my work on Clojure development tooling. You rock!

Jank: Jeaye Wilkerson

Q2 2025 $9k. Report No. 3, Published 11 July 2025

Hi folks! Thank you so much for the sponsorship this quarter. jank has grown from not being able to reach into C++ at all, in April, to now working with some of the most popular C++ libraries. This past month, the highlights are:

Added support for manual memory management via cpp/new and cpp/delete
Added support for explicit C++ bools via cpp/true and cpp/false
Added complex type literals via (cpp/type "std::map")
Added opaque boxing of native values via cpp/box and cpp/unbox
Greatly improved stability and portability

Now, at the end of the quarter, jank’s seamless C++ support is incredible. For all of the details, you can check out the related blog post here:
https://jank-lang.org/blog/2025-07-11-jank-is-cpp/

There’s still so much work to do, so I hope to write to you again next quarter!

Annually-Funded Developers' Update: May/June 2025

Sat, 19 Jul 2025 14:00:00 +1200

Hello Fellow Clojurists! This is the third report from the 5 developers receiving Annual Funding in 2025.

Dragan Duric: Apple M Engine Neanderthal, MKL, OpenBlas
Eric Dallo: ECA, metrepl, clojure-lsp, clojure-lsp-intellij
Michiel Borkent: clj-kondo, babashka, SCI, quickblog, edamame, and more…
Oleksandr Yakushev: CIDER
Peter Taoussanis: Trove, Sente, Tufte

Dragan Duric

2025 Annual Funding Report 3. Published July 4, 2025.

My goal with this funding in 2025 is to support Apple silicon (M cpus) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

In May and June, I completed Neanderthal’s Apple Silicon engine, updated MKL and OpenBLAS engines to be compatible with the introduced improvements to the overall code, fixed and polished many incompatibilities between the engines, and bugs that were introduced or discovered during the process, and updated all technologies newer versions. One huge improvement that the users will notice is AOT version of Neanderthal that is loading engines quickly.

I also reorganized Deep Diamond as separate technology-specific projects (so the users can configure their own combination appropriate to their systems) and an AOT project. I started working on the CPU engine for tensors and neural networks. It’s an uphill battle, since Apple’s API are:

not very nice compared to Intel and Nvidia (which are atrocities themselves compared to Clojurians' standards :))
poorly documented
very inconsistent -
contain several generations of deprecations and new ways of doing things
buggy
(most annoyingly) there are literally no code examples anywhere on the internet, so I have to discover everything by poking inside the REPL (I can’t imagine how people do that without Clojure/REPL :) So, I made lots of progress, but not nearly enough for a stable engine. It will take time.

As I also made some contributions to JavaCPP, I had to wait for it to release new version for the proper release of Neanderthal. They finally did it on 1st July, so I released Neanderthal as soon as I could (not in June, but day or two later :)

I also made assorted improvements and bugfixes to related Uncomplicate projects, all of them under the hood, but some of them very useful!

Here’s what I’ve proposed when applying for the CT grant.

I proposed to Implement an Apple M engine for Neanderthal. This involves:

buying an Apple M2/3 Mac (the cheapest M3 in Serbia is almost 3000 USD (with VAT).
learning enough macOS tools (Xcode was terrible back in the days) to be able to do anything.
exploring JavaCPP support for ARM and macOS.
exploring relevant libraries (OpenBLAS may even work through JavaCPP).
exploring Apple Accelerate.
learning enough JavaCPP tooling to be able to see whether it is realistic that I build Accelerate wrapper (and if I can’t, at least to know how much I don’t know).
I forgot even little C/C++ that I did know back in the day. This may also give me some headaches, as I’ll have to quickly pick up whatever is needed.
writing articles about relevant topics so Clojurians can pick this functionality as it arrives.

Projects directly involved: https://github.com/uncomplicate/neanderthal
https://github.com/uncomplicate/deep-diamond
https://github.com/uncomplicate/clojure-cpp
https://github.com/uncomplicate/clojurecuda

Looking at the funding proposal, I can say that I’m very satisfied that all the features that I promised to build are nicely progressing.

As the Deep Diamond Tensor stuff is brewing, I might start looking into Apple Metal and low-level GPU computing, so I can hope to also provide GPU computing on Apple silicon at least for Neanderthal, if not for Deep Diamond.

All in all, I feel optimistic about how this project progresses!

Eric Dallo

2025 Annual Funding Report 3. Published June 30, 2025.

In these last 2 months I could work on 2 main things, multiple improvements for clojure-lsp with fixes and new features and a exciting new project called ECA.

eca

ECA (Editor Code Assistant) is a OpenSource, free, standardized server written in Clojure to make any editor have AI features like Cursor, Continue, Claude and others. The idea is simple, it has a protocol heavily inspired by LSP, and editors can communicate with the eca server which will have the logic to communicate with multiple LLMs and provide AI features like chat, edit, MCPs, completion etc.

The project is in alpha state and there are so many things to do, but I hope community will help make this project a success!

Give a star to the project 🌟 and for more details check the roadmap

clojure-lsp

There were so many improvements for clojure-lsp regarding performance, fixes, and new features. The most notable new feature is the support for custom linters defined by the user, it follows a similar logic of clj-kondo hooks, but with improved support for clojure-lsp in-memory data access, giving power for linters know about the project and not only a single file, with test support for linters. Check the missing-unit-test custom linter:

2025.05.27-13.56.57 - 2025.06.13-20.45.44

General
- Consider .lsp/config.edn as part of project code, removing false positives of unused-public-var linter.
- Consider full qualified symbols in edn files when checking for var references.
- Improve clojure-lsp linter capabilities, migrating unused-public-var and different-aliases linters to be built-in linters. #2050
  - Migrate from clj-kondo custom-lint-fn but considering kondo settings to avoid breaking changes.
  - Considerably improve performance of unused-public-var and different-aliases linters.
- Bump rewrite-clj to 1.2.50.
- New feature: Add support for custom project linters. #2043 #2058
- Publish to clojars com.github.clojure-lsp/clojure-lsp-test-helper to be able to test created custom linters.
- Bump clj-kondo to 2025.04.08-20250526.195207-12.
- Small performance improvements across clojure-lsp, especially on places with comparassions inside big loops.
- Bump clj-depend to 0.11.1.
- Provide analysis of unresolved namespaces, making features like definition, hover, references work.
- Fix .lsp/config.edn file not found diagnostic when it doesn’t exist on project.
- Fix custom linters source-paths analysis to consider all files in a source-path.
- Fix crash on files with empty ignore comments.
- Bump clj-kondo to 2025.06.05.
- Fix analysis consistency for internal files.
- Fix custom-linters not working for cases using clojure-lsp.custom-linters-api/find-nodes.
- Improve clojure-lsp.custom-linters-api/dir-uris->file-uris to consider file-uris as well on input.
Editor
- Add support for LSP feature textDocument/selectionRange. #1961
- Fix outdated analysis for watched created/deleted files (git branch switchs for example). #2046
API/CLI
- Replace tools.cli with babashka.cli. #2036

clojure-lsp-intellij

3.5.0

Add support for creating Clojure namespaces. #78

metrepl

0.3.1 - 0.4.1

Add compatibility with older opentelemetry versions.
Fix read config from classpath
Fix OpenTelemetry integration race condition corner case.
Replace event/first-op-requested with info/repl-ready adding more info about the project.
Add :first-time to :event/op-completed and :event/op-requested when op is load-file and first time processing it.
Bump opentelemetry to 1.51.0.

Michiel Borkent

2025 Annual Funding Report 3. Published July 1, 2025.

In this post I’ll give updates about open source I worked on during May and June 2025. To see previous OSS updates, go here.

Sponsors

Current top tier sponsors:

Open the details section for more info about sponsoring.

Sponsor info

Call for Proposals. June 2025 Member Survey

Mon, 07 Jul 2025 08:30:00 +0800

Greetings folks!

Clojurists Together is pleased to announce that we are opening our Q3 2025 funding round for Clojure Open Source Projects. Applications will be accepted through the 23rd of July 2025 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.

We will be awarding up to $35,000 USD for up to 6-7 projects. The $2k funding tier is for experimental projects or smaller proposals, whereas the $9k tier is for those that are more established. Projects generally run 3 months, however, the $9K projects can run between 3 and 12 months as needed. We expect projects to start between August 15 and September 1, 2025.

A BIG THANKS to all our members for your continued support. And we want to encourage you to reach out to your colleagues and companies to join Clojurists Together so that we can fund even more great projects throughout the year.

We surveyed our members again in June to find out what types of initiatives they would like us to focus on for this round of funding. Their responses are summarized below. In particular, it was great to see members' feedback relating to how often they used or referred to developers' work we have funded. Also noted that several of you plan to attend Clojure/Conj, or made your way to SciNoj Light and ReClojure.

June 2025 Member Survey

The Biggest Challenge

If you were only to name ONE, what is the biggest challenge facing Clojure developers today and how can Clojurists Together support you or your organization in addressing those challenges?

Acceptance in the industry.

Clojure is still a niche language. It is difficult to justify its use.
It’s still about getting people to take the language(s) seriously in a world that wants everything to be in Python, Java and TypeScript - at least that’s how I see the situation.
I think the biggest challenge is helping Clojure grow and become accessible and well-known in various domains where it is still considered a niche.
Friction in developer experience
Marketing clojure, there are a lot of success stories that fly under the radar.
There is so much interesting stuff happening but it is siloed within the Clojure community.
Obscurity. Celebrating and highlighting use of Clojure in the wild.
Most LLMs tend to replace Clojure with languages they know better.

New Users.

Ease of Adoption, Easy installation and set-up for beginners.
Getting new people in the community. Specially younger people, and not just male people.

Relevance of clojure in age of AI.

Perceived ability for AI to write code is creating skepticism of the value of notation optimized for humans (e.g., Clojure)
I personally feel behind the curve with all things AI. I’d love to see more tools/docs/videos that demonstrate how to use/build with AI technologies.
Make the stack traces easier for AI agents.

Other feedback.

Stable income, Clojurists Together does great work supporting the community
Mobile (iOS/iPadOS) development
I think we really need a sane, blessed, rails-for-clojure starting point.
It’s not a huge problem, but the dominance of reagent (react classes) does make for some challenges in plugging in to the hook-y broader ecosystem. I don’t think I’ve seen a reagent replacement that has the same refreshingly simple primitives, and I just can’t imagine leaving re-frame, ever.
Fund someone who makes a minimalistic visualization library? oz has been unmaintained for years.
We as a company are quite conscious of the fact that many of the libraries that we use are entirely the work of one person, and we fear that this puts them at risk of falling out of maintenance. I know this is true for a lot of open source software generally, but I think this is a particularly severe risk for the Clojure ecosystem.
I think it would be great if we could encourage maintainers to put in place a plan of succession, and to publish this in the project README files.

What would you like to be different in the Clojure community in the next 12 months?

Building the Clojure “Brand” to Drive Adoption

I would like a stronger “brand” for Clojure that can make it easier to successfully advocate for Clojure(script) in organizations. Technical merits haven’t seemed to matter to the leadership of orgs I’ve worked in, and shiny marketing seems to be the deciding factor.
More companies adopting it.
Public success story on Clojure AI, ML, DataSciene
I would like to see Clojure making some in-roads into breaking out of it’s mainstream perception as being an esoteric language, because it really is not at this point.
At the risk of sounding like broken record, we’d love to see an outreach program that is backed by a good strategy and some measurable outcomes.
I’d like the awesome happy-path for Clojure to be common knowledge and well agreed on. A new/exciting host (jank) with a lot of fresh takes on long standing (Jvm) clojure issues We need careful community building to initiate collaborations and support systems that will help the growth of open source projects in new domains. A lot of our recent and upcoming efforts at Scicloj have been around that.

Building the Community by Engaging New Users

More beginner-friendly local communities
_ Work on reaching new audiences would be great
More newcomers, and be friendlier to more standard approaches as it is inevitable that newcomers will try to approach the language with the experience of mainstream languages
Education outreach

More Feedback

Tooling support for AI agents
“Portability is a large, and still growing, potential strong suit of Clojure: especially with the appearance of ClojureDart and Jank-on-the-horizon. I would like ClojureDart to reach language-feature parity, even with the features its crew disdains like multimethod hierarchies. I would like ““cljc”” & clj/cljs/cljd compatibility to be encouraged in potentially-portable projects.
If Clojure’s Leiningen days were like having a cohesive culture of 4 TV channels chosen by a simple knob, Clojure CLI is like 8,192 channels of cable that most people can’t enjoy because they can’t work the remote. In place of ““lein test””, ““lein repl””, ““lein package””, there is no standardization. Even Maven provides well-known affordances (package, test, etc). I would like Lein-and-Maven’s ease-of-use brought to Clojure CLI without compromising Clojure CLI’s direct-from-Git library acquisition, etc., etc.
ClojureScript core better supported.
I hope we learn how to take advantage of LLM-based technologies in a way that leverages the unique aspects of the language and the REPL-driven workflow. We shouldn’t find ourselves worrying about being left behind by more popular languages and tools. Who knows, maybe we have some unique advantages that could be realised through a different approach to LLM-assisted development.

Are there any particular libraries, tools, or projects that are important to you that you would like to see supported? (In order of mentions):

3: CIDER,SciCloj
2: CALVA, Cherry, Clojure-lsp, ClojureScript, Jank, Malli, Neathderthal, noj, reagent, replicant, Shadow-cljs
1: Babashka, Burpless, Clay, Clojars, clojure-mcp, ClojureDart, Compujure, Datelevin, Emacs, flow storm, http-kit, humble UI, info-cojure, js-interop, KIndly, metosin, pathom, Portal, promesar, eframe, Ring, spy, Tableplot, Fastmath

What areas of the Clojure and ClojureScript ecosystem need support?

Many comments regarding marketing, new users, and AI are reported in sections above. The comments listed below are in addition to these themes.

I’d say everything that falls under the umbrella of developer experience - documentation, user-friendly tooling that minimises friction, and a comprehensive, centralised community source of information about the ecosystem. The last one probably needs some clarification. It would be great to have a bird’s-eye view of the ecosystem as it currently stands and where it’s heading, or ought to go. As a new user of Clojure, or as someone exploring a different area within the ecosystem, I’d like to understand which libraries or frameworks are available to meet the various needs I encounter. I want to know the current state of these libraries or frameworks - their pros and cons, key or distinguishing features, any major counterarguments against using them etc. Additionally, I’d like insight into what’s missing in the ecosystem in that particular area. Essentially, an “are we there yet?” perspective ideally with a vision and a roadmap how to get there.
We continue to worry about ClojureScript’s dependence on the Google Closure Compiler, as this is reaching end-of-life. It would be nice if there were a vision for the future of ClojureScript.
IDE support right now, with some people still working to get the old light table workflow restored (which is not a full notebook, but close - you see it in zed, but also in liquidz/Elin and in clojure sublimed), and other people exploring how to add AI assistants.
How to better leverage Java and JavaScript / TypeScript when there is no native Clojure / Clojurescript way to do the thing that you want to do and you don’t have time/energy/knowledge to implement your own, but there is an Interop option.
Errors and clean common build tooling for AI agents.
Clojure.spec, virtual thread support for core.async
LSP and AI tooling ecosystem
The CLJS compiler is slow, cumbersome and doesn’t play well with modern JS (ESM). Cherry is very exciting.

What areas of the Clojure and ClojureScript ecosystem are strong?

COMMUNITY
Initiatives like this
Internal culture, excellent engineering practices
Web stack (Metosin libs)
Everything else :D REPL, structural editing, editor support, strong tooling, functional programming, data-oriented etc.
The language itself is awesome. REPL-driven development is great.
It is simply the best way to build.
Backwards compatibility, stability of the language, the developer community. continuity of the libraries and base.
Conferences
Continuous commitment to backwards compatibility, keeping the core library small and well considered.
A big part of web development; working with data given the language and its view of the world, but also some aspects of data science are starting to get interesting; innovation and experimentation
Mostly various component of full-stack web development

June 2025 Short-Term Project Updates Q2 2025 Projects

Sat, 28 Jun 2025 14:00:00 +1200

This is the June project update for four of our Q2 2025 Funded Projects. (Reports for the other two are on a different schedule). A brief summary of each project is included to provide overall context.

Bozhidar Batsov: CIDER
Provide continued support for CIDER, nREPL and the related libraries (e.g. Orchard, cidernrepl, etc) and improve them in various ways.

Jeaye Wilkerson: Jank
Build jank’s seamless C++ interop system.

Siyoung Byun: SciCloj Building Bridges to New Clojure Users Scicloj aims to improve the accessibility of Clojure for individuals working with data, regardless of their programming backgrounds. The project aims to develop standardized templates to encourage greater consistency across the documentation of existing Scicloj ecosystem libraries, making those libraries more robust and user-friendly.

CALVA: Brandon Ringe

Q2 2025 $9K. Report 2. Published June 16, 2025.

Since the last project update, several improvements have been made to Calva’s new output view.

One of those improvements is a significant performance boost with high frequency output, such as logging to stdout hundreds or thousands of times within a minute. I realized that replicant (and rendering libraries like it), which is an awesome library, is not well-suited for this kind of use case. So I switched to using the DOM API directly, which is much faster and more efficient for this purpose.

Here’s a list of the changes to the output view since the last project update:

Fix: Whitespace is not preserved in non-code output in output view
Add padding to bottom of output view
Strip ANSI encoding in output view
Label evaluated code in output view so it’s easy to differentiate it from results
Fix: Some output from stderr and/or stdout is being broken up in the output view
Fix: Extra newline is printed before error output in output view
Fix: Performance of output view degrades as content grows (This is the change mentioned above, which removes replicant and uses the DOM API directly for rendering.)
Add copy button to code snippets in output view
Fix: Some output is not printed on a newline as expected in the output view

CIDER: Bozhidar Batsov

Q2 2025 $9K. Report 2. Published June 17, 2025.
The last month was another strong one for CIDER and friends, which featured many releases across the different tools and libraries. Below are some of the highlights:

inf-clojure 3.3
- This was the first inf-clojure release in 3 years
- It adds support for clojure-ts-mode and also features some fixes and small improvements
clojure-mode 5.20
- Adds clojuredart-mode and jank-mode for better support of ClojureDart and Jank
- Also features a couple of small fixes
clojure-ts-mode 0.5 was the biggest news in the past month for several reasons
- It uses an experimental version of the Clojure Tree-sitter grammar that allows us to deal better with Clojure metadata
- It features support for font-locking embedded JavaScript code in ClojureScript (and C++ code in Jank)
- Introduces the clojure-ts-extra-def-forms customization option to specify additional defn-like forms that should be treated as definitions (as it’s hard to reliably infer those)
- It features some simple built-in completion powered by Tree-sitter
  - I blogged about the concept here
CIDER also saw some work, but no new release. You can expect in the next release:
- better support for clojure-ts-mode
- more improvements to the Inspector
- user manual (documentation) improvements

On top of this, I’ve been reviewing the data from CIDER’s survey, improving the CI setups of various projects, providing user support and working on some ideas about restructuring the documentation of CIDER and nREPL to be more approachable. The process for streamlining (slimming down) CIDER, cider-nrepl and orchard is ongoing as well. (e.g. we’ve stopped bundling print engines with cider-nrepl and now those have to be supplied by the users)

clojure-ts-mode is shaping up really nicely and has mostly matched the features of clojure-mode. On top of this it does a few things better than clojure-mode, so I’m optimistic that we’ll mark it as ready for general usage before the end of the year. We’ve expanded the design docs recently and I think they can be useful both to potential contributors and to other people looking to create Tree-sitter based major modes. I’m also working in the background on a couple of article for best practices when working with Tree-sitter in Emacs.

Thanks to Clojurists Together for their continued support of my OSS work! You rock!

Jank: Jeaye Wilkerson

Q2 2025 $9K. Report 2. Published June 17, 2025.

Thank you!

Hi folks! Thanks so much for the sponsorship this quarter. Clojurists Together is my largest form of income this year, which makes this even more special.

Seamless interop

In the past month, I’ve implemented:

Many, many tests for the new interop functionality
Calling global C++ functions
Calling C++ member functions
Accessing C++ member variables
C++ reference semantics, including automatic referencing and dereferencing
Dozens of C++ operators

You can find all of the details in my latest blog post, here.

Next up

In the final month of this quarter, I aim to expand the test suite, fix the remaining known bugs, add manual memory management support, better template support, full destructor support, and finally the portability fixes necessary to make all of this work on both macOS and Linux.

SciCloj Building Bridges to New Clojure Users: Siyoung Byun

Q2 2025 $2K. Report 1. Published June 25, 2025.

Work Completed, In Progress and Further Plans

CFD Python into Clojure Project

I initiated the CFD Python into Clojure project, which translates computational fluid dynamics (CFD) learning steps from Python into Clojure. The project also includes a currently evolving notebook page that shows the learning steps progressed so far for the project.
This project showcases interactive, real-world scientific computing examples with an initiative to diversify the set of data science use cases available in Clojure.

I am working toward completing and polishing the project as a featured example of Clojure’s capability in handling scientific computing and numerical simulation use cases. I am planning to discuss the results and experiences at a future SciCloj Light Conference.

Conference Presentation at SciCloj Light #1

I presented a talk at SciCloj Light #1, highlighting the progress (implementing one-dimensional CFD using Burgers' equation), simulations, and future directions from the CFD Python into Clojure initiative. The talk demonstrated how Clojure can serve as a powerful tool in data science and data analysis.

Conference Reflections and Scicloj Community Video

I co-authored and released a video summarizing the SciCloj Light #1 conference experience, along with publishing a written conference survey to gather feedback and reflect on future SciCloj Light conferences with Daniel Slutsky. The video discusses the preparation process, key takeaways, and future directions for Scicloj as a community-driven initiative and as an individual contributor.

Community Outreach Initiative for Broader Participation

I initiated and participated in a community discussion on Clojurian Zulip to encourage Scicloj contributors and users to present at external data science conferences and share their experiences using Clojure and Scicloj libraries for their data science work. This outreach aims to amplify Clojure’s visibility in broader scientific and data communities to obtain more attention and bring newcomers to the community.

Documentation Improvements for Noj

I joined as one of the maintainers of Noj, an out-of-the-box Clojure library designed to simplify data science workflows. Currently, I’ve been focusing on improving the library’s introductory documentation, setup guides, and use cases in notebooks to make it more welcoming and useful to newcomers.
There are already good use cases, ideas, and documentation in the library, so my main goal is to make those resources more coherent, consistent, and organized to be easily searchable. Once we have well-tailored documentation in place for Noj, we hope to roll out the same documentation template for the rest of the Scicloj libraries.

Library Documentation Review and Feedback Collection

I am actively gathering feedback on gaps and pain points in the documentation of various Scicloj libraries through the Clojurian Zulip channel.

Improving “Getting Started” Experiences

I am continuing to improve the beginner documentation and setup processes across Scicloj libraries, with a goal of creating a smoother onboarding experience for users with diverse backgrounds.

Organizing ‘macroexpand’ Gatherings

I will co-organize a series of regular online community meetups called macroexpand gatherings. These are aimed at welcoming both new and existing Clojure users and will foster communication across communities working on professional data projects (data engineering, analysis, visualization, etc.) and identify shared challenges and opportunities for collaboration. By hosting a space to discuss the current status of the community/individuals and challenges together, we hope to prioritize our todos and initiatives better and create actionable items to move forward.

May 2025 Short-Term Project Updates Q2 2025 Projects

Wed, 04 Jun 2025 14:00:00 +1200

This is the April/May project update for four of our Q2 2025 Funded Projects. (Reports for the other two are on a different schedule). A brief summary of each project is included to provide overall context.

Bozhidar Batsov: CIDER
Provide continued support for CIDER, nREPL and the related libraries (e.g. Orchard, cidernrepl, etc) and improve them in various ways.

Jeaye Wilkerson: Jank
Build jank’s seamless C++ interop system.

Bling: Jeremiah Coyle

Q2 2025 $2k. Report No. 1, Published 1 June 2025

Upon commencing Q2 work on Bling, I reordered the list of priorities set forth in the initial project description.
Updated TO DO list:

Primary goals for Q2
- Respect NO_COLOR env var
- Opt-in optimization for enhanced contrast in light or dark terminals.
- Enable Hi-Fidelity, themeable, colorized, structural printing of values via Fireworks.
- Utilize callout to create a specialized template for Malli validation errors.
- Figlet banners with lolcat-style gradient coloring.
Secondary goals for Q2
- Add enhanced support for using hiccup to style and format messages
- Create 1-3 additional formatting templates for callouts, headers, and points-of-interest.
- Add documentation about how to leverage Bling to create great-looking warnings and errors in your own projects.

All the primary goals listed above are realized in [`v0.8.0`](https://clojars.org/io.github.paintparty/bling/versions/0.8.0).

Some highlights…

Figlet banners:

Docs here

Specialized template for Malli validation errors

This is experimental, with more work to be done on optimizing for disjunctions and cases with multiple errors on same value.

Docs here

Bling offers bling.explain/explain-malli to present Malli validation errors:

(require '[bling.explain :refer [explain-malli]])

(def Address
  [:map
   [:id string?]
   [:tags [:set keyword?]]
   [:address
    [:map
     [:street string?]
     [:city string?]
     [:zip int?]
     [:lonlat [:tuple double? double?]]]]])

(explain-malli
 Address
 {:id "Lillan",
  :tags #{:coffee :artesan :garden},
  :address
  {:street "Ahlmanintie 29", :zip 33100, :lonlat [61.4858322 87.34]}})

The above code would print the following:

You can also pass an option trailing options map to customize the appearance of the printed output. In the example below, we are leaving out the display of the schema within the callout block:

(explain-malli
 Address
 {:id "Lillan",
  :tags #{"coffee" :artesan :garden},
  :address
  {:city "Tempare" :street "Ahlmanintie 29", :zip 33100, :lonlat [61.4858322 87.34]}}
 {:display-schema? false})

The above code would print the following:

High Fidelity Printing

Docs here

Bling offers bling.hifi for colorized pretty-printing of Clojure, Java, and JavaScript data structures. bling.hifi/hifi will return an ansi-sgr decorated string, while bling.hifi/print-hifi will print such a string.

Under the hood, the formatting/colorizing is achieved with Fireworks.

By default, the theme of this output will be Universal Neutral.

If you set a valid BLING_MOOD env var, the theme of the hifi output will be Alabaster Light or Alabaster Dark.

_{Alabaster Dark}

_{Alabaster Light}

Check out the other available themes here

Enhanced contrast

You can set a BLING_MOOD env var to enhance the contrast of bling-formatted printings.

Docs here.

Brandon Ringe: CALVA

Q2 2025 $9K. Report 1, Published 13 May 2025.

The new REPL output view was released! It’s an opt-in feature for now and is not currently the default REPL output destination. It’s currently in a very MVP state. I’ll be fixing bugs and adding features in the coming weeks.

This output view is web-based (a VS Code webview), and is implemented entirely in ClojureScript. We use replicant for the UI.

There’s project board on GitHub that I’ve been using to track my work on this. I wanted the issues to be draft issues until the first version was released. I’ll be converting all of them to issues soon.

Here are a few issues I intend to tackle in the coming weeks:

Documentation:

Thanks to Thomas Heller for helping us (some time ago) explore ways of integrating ClojureScript and TypeScript in Calva. Thanks to Christian Johansen for replicant.

Bozhidar Batsov: CIDER

Q2 2025 $9K. Report 1, Published 16 May 2025.

The last month extremely fruitful for CIDER and friends and resulted in many notable releases and improvements. Below are some of the highlights:

clojure-ts-mode 0.3
- lots of improvements to the font-locking and indentation logic
- indentation rules are now consistent with cljfmt
clojure-ts-mode 0.4
- regular expressions are font-locked with a Tree-sitter grammar
- adds support for aligning forms
- implements many of the refactoring commands from clojure-mode
CIDER 1.18
- I also wrote a blog post about it
refactor-nrepl 3.11.0
- Before this update the project was broken on Clojure 1.12
- clj-refactor.el was also updated to use the latest version of the middleware

The were also several releases of cider-nrepl and orchard, related to CIDER 1.18. Work on CIDER 1.19 is already underway, and I’m also happy to report that clojure-ts-mode is now in a pretty good shape for general use.

Jeaye Wilkerson: Jank

Q2 2025 $9K. Report 1, Published 7 May 2025.

Thank you!

To start with, thank you, Clojurists Together, for the sponsorship this quarter. This is the largest income I have this year, so far, so it really makes a difference.

Seamless C++ interop

This quarter, I’m focusing on seamless interop with C++ from jank. Doing this from a lisp is unprecedented. One month in, I have implemented the following.

JIT compiling arbitrary C++ code
Reaching into C++ values
Constructing stack-allocated C++ values
Overload resolution
Implicit conversions from jank objects into native types and vice versa
Explicit casts

You can read about all of these in detail on the jank blog here.

Next month

We’re one month into the quarter and I’m pleased with the progress so far. However, there’s a lot remaining work to do. I still need to tackle free/static function calls, member access, member function calls, operators, dynamic allocations, complex type support, and automatic destructors for locals with the same guarantees C++ provides. On top of that, I need to make sure we can process C++ headers in a portable way. This will definitely keep me busy for the quarter! Stay tuned for my next update in a month.

Annually-Funded Developers' Update: Mar./April 2025

Mon, 12 May 2025 14:00:00 +1200

Hello Fellow Clojurists! This is the second report from the 5 developers receiving Annual Funding in 2025.

Dragan Duric: Apple M Engine Neanderthal
Eric Dallo: metrepl, lsp-intellij, repl-intellij. lsp, lsp4clj
Michiel Borkent: clj-kondo, squint, babashka, fs, SCI, and more…
Oleksandr Yakushev: CIDER, Compliment, JDK24
Peter Taoussanis: Telemere, Tufte, Truss

Dragan Duric

2025 Annual Funding Report 2. Published May 5, 2025.

My goal with this funding in 2025 is to support Apple silicon (M cpus) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

In March and April, I implemented the JNI bindings for 5 Apple Accelerate libraries (blas_new, lapack_new, Sparse, BNNS, BNNS Graph, vDSP, vForce and vImage) and implemented almost all functionality of Neaanderthal’s Apple M engine based on Accelerate. It will soon be ready for proper release (currently waiting some bugfixes, polishing, and a javacpp-presets release to be available in Maven Central).

In more detail:

Here’s what I’ve proposed when applying for the CT grant.
I proposed to Implement an Apple M engine for Neanderthal. This involves:

buying an Apple M2/3 Mac (the cheapest M3 in Serbia is almost 3000 USD (with VAT).
learning enough macOS tools (Xcode was terrible back in the days) to be able to do anything.
exploring JavaCPP support for ARM and macOS.
exploring relevant libraries (OpenBLAS may even work through JavaCPP).
exploring Apple Accelerate.
learning enough JavaCPP tooling to be able to see whether it is realistic that I build Accelerate wrapper (and if I can’t, at least to know how much I don’t know).
I forgot even little C/C++ that I did know back in the day. This may also give me some headaches, as I’ll have to quickly pick up whatever is needed.
writing articles about relevant topics so Clojurians can pick this functionality as it arrives.

Projects directly involved:
https://github.com/uncomplicate/neanderthal
https://github.com/uncomplicate/deep-diamond
https://github.com/uncomplicate/clojure-cpp

As I implemented and OpenBLAS-based engine in January-February, in March-April I tackled the main objective: Apple Accelerate bindings. As Apple’s documentation is not stellar, and there are multiple tools and languages involved, it was a slow and tedious work consisting of lots of experimentation and discovery. Even boring, I would say. But, slowly and steadily I discovered how relevant JavaCPP generators work, I unearthed Accelerate C++ intricacies, fought with them one by one, and slowly I managed to create the proper Java bindings! Along the way I even contributed some fixes and updates to JavaCPP itself! YAY! This is available as a new project under Uncomplicate umbrella at https://github.com/uncomplicate/apple-presets

Next, I returned to the pleasant part of work - programming in Clojure - and almost completed the dedicated Neanderthal engine that utilizes Apple Accelerate for BLAS, LAPACK, as well as Math functions and random generators on M Macs. This covers the core and linalg namespace, that was already supported by the alternative OpenBLAS engine (implemented in Jan-Feb) AND Math and RNG engines. I didn’t manage to iron out all the bugs so it could be ready for release, but this will certainly be ready in May-June. I also didn’t manage to tackle Sparse matrices, but as I managed to create Accelerate bindings for all types, including Sparse, I expect this to not be a problem and be completed during this funding round.

Looking at the funding proposal, I can say that I’m very satisfied that all the features that I promised to build are progressing even better than expected, so that will leave some time to try to do some of the features that I said I hope to be able to support, namely to explore Deep Diamond Tensor support on Apple M (via BNNS and/or BNNS Graph) and GPU support via Metal.

I even got some ideas for additional projects based on native Apple functionality related to machine learning and audio/video, but lets not getting too much ahead.

All in all, I feel optimistic about how this project progresses!

Eric Dallo

2025 Annual Funding Report 2. Published April 30, 2025.

In these 2 last months I could work on multiple projects and even focus on a new exciting project called metrepl, a nREPL middleware to help extract metrics about your REPL, really helpful when you have multiple coworkers working in multiple projects and you want to collect information about performance, time spent in REPL features and others! Besides that, I worked hard on keep improving the IntelliJ experience using the 2 OSS plugins of LSP + REPL, and of cource improving clojure-lsp the base of all major editors now.

metrepl

- 0.3.1

Improve export exception handler
Remove jvm started flaky metric
Fix event/op-completed metric to measure time correctly
Add event/test-executed event.
Add event/test-passed, event/test-errored and event/test-failed events.
Add session-time-ms to close op.
Add :project-path to metrics.
Add compatibility with older Clojure versions

clojure-lsp

2025.03.07-17.42.36 - 2025.04.23-18.16.46

General
- Bump clj-kondo to 2025.02.20.
- Add support for OpenTelemetry(otlp) log, enabled if configured. #1963
- Bump rewrite-clj to 0bb572a03c0025c01f9c36bfca2815254683fbde. #1984
- Bump clj-kondo to 2025.02.21-20250314.135629-7.
- Add support for ignoring tests references for the clojure-lsp/unused-public-var linter. #1878
- Add :test-locations-regex configuration to allow customizing test file detection for the unused-public-var linter’s :ignore-test-references? and test code lenses. #1878
- Improve and standardize all logs for better troubleshooting and metrics collection.
- Fix unused-public-var false positives when :ignore-test-references? true.
- Bump clj-kondo to 2025.04.07.
Editor
- Improve paredit slurp and barf corner cases. #1973 #1976
- Add Semantic Tokens support for the Clojure Reader Dispatch macro #_ (ignore next form). #1965
- Fix regression on previous version on snippets completion. #1978
- Add forward, forward-select, backward and backward-select paredit actions.
- Show add require code action for invalid syntax codes like my-alias/. #1957
- Improve startup performance for huge projects avoiding publish empty diagnostics for every file of the project unnecessarily.
- Improve timbre context log.
- Fix suggestion for add require code action. #2017
- Improve find definition so it works on declare forms too. #1986

clojure-lsp-intellij

3.1.1 - 3.4.0

Remove : lexer check since this is delegated to clojure-lsp/clj-kondo already.
Fix comment form complain about missing paren.
Improve server installation fixing concurrency bugs + using lsp4ij install API.
Bump clj4intellij to 0.7.1
Support Namespaces on search everywhere (Shift + shift). #64
Add support for forward, backward, forward-select, backward-select paredit actions. #72
Fix go to declaration or usages. #70

clojure-repl-intellij

Together with the help of @afucher, we improved so much the IntelliJ REPL experience, fixing multiple issues and adding multiple features, the experience now is pretty close to other REPL experiences in other editors!

2.3.0 - 2.5.2

Update repl window ns after switching ns.
Fix exception on settings page.
Fix special form evaluations. #135
Add support for JVM args on local REPL configuration. #124
Send to REPL eval results. #92
Fix repl input when evaluated the same input of last eval.
Fix history navigation via shortcut not working after 2.0.0.
Enhance REPL evaluations. #108
- Isolate ns from REPL windows and file editors
- Evaluate ns form from file automatically to avoid namespace-not-found errors.
Fix REPL window horizontal scrollbar not working.
Fix REPL window broken after making any change to its layout. #144
Disable “clear REPL” action when REPL is not connected. #126
Bump clj4intellij to 0.8.0
Configure project with IntelliJ integration tests (headless)

lsp4clj

1.12.0 - 1.13.0

Add textDocument/selectionRange LSP feature coercers.
Add inlay-hint LSP feature coercers.

clj4intellij

0.7.0 - 0.8.0

Create def-extension to create plugin.xml extension points easily and more idiomatic.
Fix clojure-lsp hook
Drop support of older IntelliJ versions (2021/2022). Now requires minimum IntelliJ 2023.3 (Build 233)
Bump JAVA min version to 17
Add support for tests.

Michiel Borkent

2025 Annual Funding Report 2. Published May 2, 2025.

In this post I’ll give updates about open source I worked on during March and April 2025.

To see previous OSS updates, go here.

Sponsors

Current top tier sponsors:

Open the details section for more info about sponsoring.

Sponsor info

Q2 2025 Funding Announcement

Sun, 20 Apr 2025 08:30:00 +0800

Clojurists Together is excited to announce that we will be funding 6 projects in Q2 2025 for a total of $33K USD (3 for $9K and 3 shorter or more experimental projects for $2K). Thanks to all our members for making this happen! Congratulations to the 6 developers below:

$9K Projects
Bozhidar Batsov: CIDER
Brandon Ringe: CALVA
Jeaye Wilkerson: Jank

$2K Projects
Jeremiah Coyle: Bling
Karl Pietrzak: CodeCombat
Siyoung Byun: Scicloj - Building Bridges to New Clojure Users

Bozhidar Batsov: CIDER

Provide continued support for CIDER, nREPL and the related libraries (e.g. Orchard, cidernrepl, etc) and improve them in various ways.

Some ideas that I have in my mind:

Improve support for alternative Clojure runtimes
Simplify some of CIDER’s internals (e.g. jack-in, session management)
Improve CIDER’s documentation (potentially record a few up-to-date video tutorials as well)
Improve clojure-ts-mode and continue the work towards it replacing clojure-mode
Add support for clojure-ts-mode in inf-clojure
Continue to move logic outside of cider-nrepl
Improvement to the nREPL specification and documentation; potentially built some test suite for nREPL specification compatibility
Various improvements to the nREPL protocol
Stabilize Orchard and cider-nrepl enough to do a 1.0 release for both projects
Build a roadmap for CIDER 2.0
Write up an analysis of the State of Clojure 2024 survey results (connected to the roadmap item)

Brandon Ringe: CALVA

I’ll be working on a new REPL output view for Calva, which is a webview in VS Code. The current default REPL output view utilizes an editor and somewhat emulates a terminal prompt. The performance of the editor view degrades when there’s a high volume of output and/or when there are large data structures printed in it. The webview will allow us to add more rich features to the output webview, while also providing better performance.

I’ve started this work, the and I’ll use the funding of Clojurists Together to get the work over the finish line and release an initial, opt-in version of the REPL output webview. I’ll also be adding tests, responding to user feedback about the feature, fixing bugs, and adding features to it.

This is the first feature of Calva that integrates with VS Code’s API directly from ClojureScript. This is partly an experiment to see if writing more of Calva in ClojureScript is a good idea; I suspect that it is.

Jeaye Wilkerson: Jank

In Q1 2025, I built out jank’s error reporting to stand completely in a category of its own, within the lisp world. We have macro expansion stack tracing, source info preserved across expansions so we can point at specific forms in a syntax quote, and even clever solutions for deducing source info for non-meta objects like numbers and keywords. All of this is coupled with gorgeous terminal reporting with syntax highlighting, underlining, and box formatting.

In Q2, I plan to aim even higher. I’m going to build jank’s seamless C++ interop system. We had native/raw, previously, for embedding C++ strings right inside of jank code. This worked alright, but it was tied to jank having C++ codegen. Now that we have LLVM IR codegen, embedding C++ is less practical. Beyond that, though, we want to do better. Here’s a snippet of what I have designed for jank this quarter.
; Feed some C++ into Clang so we can start working on it.
; Including files can also be done in a similar way.
; This is very similar to native/raw, but is only used for declarations.
; It cannot run code.
(c++/declare “struct person{ std::string name; };")
; let is a Clojure construct, but c++/person. creates a value
; of the person struct we just defined above, in automatic memory (i.e. no heap allocation). (let [s (c++/person. “sally siu”)
; We can then access structs using Clojure’s normal interop syntax. n (.-name s)
; We can call member functions on native values, too.
; Here we call std::string::size on the name member.
l (.size n)]
; When we try to gives these native values to println, jank will
; detect that they need boxing and will automatically find a
; conversion function from their native type to jank’s boxed
; object_ptr type. If such a function doesn’t exist, the
; jank compiler fails with a type error.
(println n l))

In truth, this is basically the same exact syntax that Clojure has for Java interop, except for the c++ namespace to disambiguate. Since I want jank to work with other langs in the future, I think it makes sense to spell out the lang. Later, we may have a swift or rust namespace which works similarly. But let’s talk about this code.

This interop would be unprecedented. Sure, Clojure JVM does it, but we’re talking about the native world. We’re talking about C++. Ruby, Python, Lua, etc. can all reach into C. The C ABI is the lingua franca of the native world. But here, we’re reaching into C++ from a dynamic lang. We’ll call constructors, pull out members, call member functions, and jank will automatically ensure that destructors are called for any locals. Furthermore, jank already has full JIT compilation abilities for C++ code, so that means we can use our seamless interop to instantiate templates, define new structs which never existed before, etc.

Jeremiah Coyle: Bling

Bling is a library for rich text formatting in the console. https://github.com/paintparty/bling Work on Bling in Q2 of 2025 will focus on the following 3 goals:

Add support for using hiccup to style and format messages
Add support a template string syntax to style and format messages
Create 1-3 additional formatting templates for callouts, headers, and points-of-interest.

The following 4 features are stretch goals for Q2. They will be pursued in the following order when the initial 3 goals are completed.

Add support automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to https://github.com/chalk/supports-color
Add documentation about how to leverage Bling to create great-looking warnings and errors in your own projects. Example of using bling’s templates to create nice warnings can be found {here:](https://github.com/paintparty/fireworks?tab=readme-ov-file#helpful-warnings-forbad-option-values)
Add documentation about using Bling in conjunction with existing libraries which format Spec and Malli messages into human readable form.
Support arbitrary hex colors, and their conversion, if necessary, to x256

Karl Pietrzak: Code Combat

My project will focus on adding Clojure(Script) to CodeCombat
See Wiki page at https://github.com/codecombat/codecombat/wiki/Aether

Siyoung Byun: Scicloj - Building Bridges to New Clojure Users

In 2025, Scicloj aims to improve the accessibility of Clojure for individuals working with data, regardless of their programming backgrounds. The project will initially focus on reviewing existing Scicloj libraries, analyzing their codebases, and actively using them to better understand their documentation structure. Specifically, the initial effort will concentrate on clearly organizing and distinguishing between tutorials and API documentation. From these insights, the project aims to develop standardized templates to encourage greater consistency across the documentation of existing Scicloj ecosystem libraries, making those libraries more robust and user-friendly.

Annually-Funded Developers' Update: Jan./Feb. 2025

Sat, 08 Mar 2025 14:00:00 +1200

Hello Fellow Clojurists! This is the first report from the 5 developers receiving Annual Funding in 2025. (Highlights listed on the list below - but the reports include much more).

Dragan Duric: Apple M Engine Neanderthal
Eric Dallo: lsp-intellij, repl-intellij. lsp, lsp4clj
Michiel Borkent: clj-kondo, squint, babashka, fs, SCI, and more…
Peter Taoussanis: Truss v2, Telemere v1 RC3
Oleksandr Yakushev: CIDER, clj-async-profiler and Flamebin, clj-memory-meter

Dragan Duric

2025 Annual Funding Report 1. Published February 27, 2025.

My goal with this funding in 2025 is to support Apple silicon (M cpus) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

In January and February, I released the first version of Neanderhal that can run on Mac/Apple M!

My grant proposal: Here’s what I’ve proposed when applying for the CT grant.
I propose to * Implement an Apple M engine for Neanderthal.* This involves:

buying an Apple M2/3 Mac (the cheapest M3 in Serbia is almost 3000 USD (with VAT).
learning enough macOS tools (Xcode was terrible back in the days) to be able to do anything.
exploring JavaCPP support for ARM and macOS.
exploring relevant libraries (OpenBLAS may even work through JavaCPP).
exploring Apple Accelerate.
learning enough JavaCPP tooling to be able to see whether it is realistic that I build Accelerate wrapper (and if I can’t, at least to know how much I don’t know).
I forgot even little C/C++ that I did know back in the day. This may also give me some headaches, as I’ll have to quickly pick up whatever is needed.
writing articles about relevant topics so Clojurians can pick this functionality as it arrives.

Projects directly involved:
https://github.com/uncomplicate/neanderthal
https://github.com/uncomplicate/deep-diamond
https://github.com/uncomplicate/clojure-cpp

First, I set to the task of tidying up the existing versions of Uncomplicate libraries (Neanderthal, Deep Diamond, etc.) to bring them up with the latest versions of native libraries, cuda, etc., and to fix some outstanding issues/bugs that might complicate work on Apple M support. After that, it was time for the main task, the beginnings of Apple M support.

The plan was to buy an Apple M2/M3, but in the meantime the nice Clojurians from Prague donated a used (but fantastically beefed up) MacBook Pro Max M1, so this was covered quickly!

I explored OpenBLAS as the first choice (the other is Apple Accelerate), as it can also work on Linux and Windows, and could be immediately beneficial to all users and easier to start with (I didn’t need to switch to Apple yet).

I implemented the OpenBLAS engine for the part of functionality that was supported by JavaCPP’s openblas preset. A lot of critical functionality was not present there (although some of it was there in the openblas itself), so I jumped at the opportunity to learn some JavaCPP preset building, and improved JavaCPP’s OpenBLAS. After a bit of experimentation and lot of waiting on the compiler and github tools, this is now contributed upstream.

Next, I returned to the pleasant part of work - programming in Clojure - and completed the first Neanderthal engine that runs in Apple M Macs. This covers the core and linalg namespace, because this is what OpenBLAS covers. The rest of Neanderthal functionality is waiting for me to explore Apple Accelerate, and to create engine based on that.

I managed to release Neanderthal 0.53.2, which enables Clojurians to use this on their Macs, just in time for this report.

I hope they’ll have immediate benefits, and have fun doing some high performance hacking on their Macs.

Many thanks for CT for sponsoring this work!

Eric Dallo

2025 Annual Funding Report 1. Published February 27, 2025.

In the first two months of sponsorship I could work on so many things related to IDE development which made me really glad of this sponsorship! :heart:

I spend most of the time improving the Clojure development on IntelliJ, improving both clojure-lsp-intellij and clojure-repl-intellij plugins releasing 2 major extremally important versions. The IntelliJ Clojure development using those plugins are way better and mature, please test and give feedback!

clojure-lsp-intellij

The 3.0.0 major version was a refactor on most of the plugin to use lsp4ij, an OSS plugin for IntelliJ which makes easier to code and use LSP features, so this integration removed tons of code from this plugin that I needed to implement manually (and some had some bugs) and added support for lots of missing features that I didn’t even plan to add. The lsp4ij plugin is used by multiple languages already which makes this plugin more resilient and stable. Check it out the call hierarchy feature on the image.

Kudos to @angelozerr for the help during lsp4ij integration on their side.

3.0.0 - 3.1.0

Fix brace matcher to insert closing brace for some missing cases.
Add imcompatible tag with Cursive and Clojure-Kit plugins.
Integrate with lsp4ij, a LSP client plugin, removing lots of logics from this plugin and fixing multiple bugs and issues. Fixes #63, #61, #59, #57, #53, #36, #21, #9, #5
Drop support for older intellijs, supporting 2023.3 onwards.
Bump clj4intellij to 0.6.3.
Fix code lens references not working when more than a project is opened. #67
Fix Settings page exception when more than a project was opened and closed.
Fix comment form complain about missing paren.
Improve server installation fixing concurrency bugs + using lsp4ij install API.

clojure-repl-intellij

This 2.0.0 major release included multiple fixes and new features like the new _Inlay hint eval result + _REPL syntax coloring.

Kudos to @afucher for the help on some of those features.

2.0.0 - 2.2.0

Add icons of REPL commands to REPL window (clear and entry history navigation). #99
Drop support of older IntelliJ versions (2021/2022). Now requires minimum IntelliJ 2023.3 (Build 233)
Fix namespace-not-found error handling. Now shows a message to the user. #107
Add eval inlay hint support. #106
Add action to interrupt evals on the REPL session (shift alt R + shift alt S). #104
Add color settings page for customization of some tokens.
Add default name for RunConfigurations instead of save as Unnamed. #123
Add REPL syntax highlight. #18
Fix eval defun at cursor action error. #121
Create view error on test error. #128
Block backspace on repl input.

clojure-lsp

clojure-lsp is the base for all Clojure language handle logic and analysis, so lots of fixes and improvements are made all the time.

2025.01.22-23.28.23 - 2025.02.07-16.11.24

General
- Bump clj-kondo to 2025.01.16
- Bump lsp4clj to 1.11.0.
- Add semantic version sorting in completion lib versions. #1913
- Fix internal error in range formatting. #1931
- Drop support for jdk 8. #1942
Editor
- Change simple keyword completion to return all known keywords. #1920
- Return textEdit to CompletionItems to fix completion in Zed #1933
- Restrict linked edits to namespace aliases only, and fix a few related issues #1947
- Add :hover :hide-signature-call? settings option to disable showing the surrounding call. #1954, @NoahTheDuke
- Revert #1933, which caused a regression on completion adding extra text.
- Fix fetching libs exception causing progress notification to be stuck. #1958
API/CLI
- Add :project-and-shallow-analysis type to dump command
- Add :diagnostics to dump command output (successor of :findings)

lsp4clj

lsp4lj is the base of clojure-lsp, it’s the layer that has all the LSP communication layer, making easy to build LSP clients/servers of any language in Clojure.

v1.11.0

Add a :response-executor option to control on which thread responses to server-initiated requests are run, defaulting to Promesa’s :default executor, i.e. ForkJoinPool/commonPool.
Fix work done progress notification to allow nullable message.

clj4intellij

clj4intellij is a lib that makes possible to code IntelliJ plugins in Clojure, it’s used by both clojure-lsp-intellij and clojure-repl-intellij plugins.

0.6.0 - 0.6.3

Add unregister-action! and improve register-action!
Add clj-kondo hook for proxy+.

Michiel Borkent

2025 Annual Funding Report 1. Published February 28, 2025.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all. Top sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch. Thank you! On to the projects that I’ve been working on!

As I’m writing this I’m still recovering from a flu that has kept me bedridden for a good few days, but I’m starting to feel better now. Here are updates about the projects/libraries I’ve worked on in the last two months.
As I’m writing this I’m still recovering from a flu that has kept me bedridden for a good few days, but I’m starting to feel better now.

Here are updates about the projects/libraries I’ve worked on in the last two months.

clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- Unreleased:
- #2493: reduce image size of native image
- 2025.02.20:
- #2473: New linter: :unknown-ns-options will warn on malformed (ns) calls. The linter is {:level :warning} by default. (@Noahtheduke)
- #2475: add :do-template linter to check args & values counts (@imrekoszo)
- #2465: fix :discouraged-var linter for fixed arities
- #2277: prefer an array class symbol over (Class/forName …) in defprotocol and extend-type
- #2466: fix false positive with tagged literal in macroexpand hook
- #2463: using :min-clj-kondo-version results in incorrect warning (@imrekoszo)
- #2464: :min-clj-kondo-version warning/error should have a location in config.edn (@imrekoszo)
- #2472 hooks api/resolve should return nil for unresolved symbols and locals
- #2472: add api/env to determine if symbol is local
- #2482: Upgrade to Oracle GraalVM 23
- #2483: add api/quote-node and api/quote-node? to hooks API (@camsaul)
- #2490: restore unofficial support for ignore hints via metadata
squint: CLJS syntax to JS compiler
- Fix #609: make remove return a transducer when no collection is provided
- Fix #611: Implement the set? function (@jonasseglare)
- Fix #613: Optimize aset
- Fix #626: Implement take-last
- Fix #615: (zero? “0”) should return false
- Fix #617: deftype field name munging problem
- Fix #618: Named multi-arity fn args don’t get munged (@grayrest)
- Fix #622: operator precendence issue with | and if
- Add clojure.string functions lower-case, upper-case, capitalize (@plexus)
- Fix #605: merge command line –paths with squint.edn config properly
- Fix #607: make mapcat return a transducer if no collections are provided (@jonasseglare)
babashka: native, fast starting Clojure interpreter for scripting.
- Experimenting upgrading to new beta core.async, work in is a branch ready to be merged
- #1785: Allow subclasses of Throwable to have instance methods invoked (@bobisageek)
- #1791: interop problem on Jsoup form element
- #1793: Bump rewrite-clj to 1.1.49 (fixes parsing of foo// among other things)
- Bump deps.clj
- Bump fs
fs - File system utility library for Clojure
- v0.5.24 (2025-01-09)
- #135: additional fix for preserving protocol when calling fs/path on multiple arguments (@Sohalt)
SCI: Configurable Clojure/Script interpreter suitable for scripting
- Records should have keys present and set to nil
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Catch up with several new versions of clojure CLI
- Fix #132: copy install tools.edn to config dir when install version is newer, similar to clojure CLI bash script
- Adds support for XDG_DATA_HOME environment variable according to XDG Base Directory Specification
sql pods: babashka pods for SQL databases
- Add support for DuckDB (@avelino)
edamame: Configurable EDN/Clojure parser with location metadata
- Fix #115: add location to exception for invalid keyword
rewrite-edn: Utility lib on top of rewrite-clj with common operations to update EDN while preserving whitespace and comments
- #40: assoc/update now handles map keys that have no indent at all (@lread)
- #43: bump rewrite-clj to 1.1.49 (@lread)
- #40: assoc/update now handles map keys that have no indent at all (@lread)
- #40: assoc/update now aligns indent to comment if that’s all that is in the map (@lread)
- #40: update now indents new entries in same way as assoc (@lread)

Other projects I’ve been working on this month. See Click for More Details.

Peter Taoussanis

2025 Annual Funding Report 1. Published February 27, 2025.

A big thanks to Clojurists Together, Nubank, and other sponsors of my open source work! I realise that it’s a tough time for a lot of folks and businesses lately, and that sponsorships aren’t always easy 🙏
- Peter Taoussanis

Hi everyone! 👋

I’ve been focused recently on getting Telemere v1 over the finish line. That’s been a lot of ongoing work, in part because I’m trying to establish patterns that can be easily shared between a suite of complementary libs (Telemere, Tufte, and Truss).

I’ve also been considering long-term plans for how to better modularize Encore to help reduce dependency and build sizes where relevant. More on that later in the year.

Truss v2 - an opinionated micro toolkit for Clj/s errors

I’ve recently released Truss v2, which has enlarged the scope of the library from just assertion utils to a general error toolkit for Clojure and ClojureScript.

v2 includes:

A ground-up rewrite of the existing assertion utils to improve performance, reduce build size, and improve integration with Telemere.
A new set of small but high-value error utils moved from Encore as part of the ongoing modularization effort.
A new contextual exception type that’s already used by Encore and Telemere, and will be used by all of my other libraries in future.
Updated docs and a new Slack channel.
Truss v2 basically packages together a minimal set of mature tools and patterns that I’ve used over many years to help tame Clojure’s often unruly errors. It’s simple stuff, but practical - and it helps.
For more info see the README and docstrings.

Telemere v1 RC3 - structured logging and telemetry for Clj/s

I was hoping to release Telemere v1 final this month, but decided that a third release candidate was warranted.

The latest improvements are focused on harmonizing relevant terminology, concepts, and API between Telemere, Truss, and the forthcoming v3 of Tufte.

Big thanks to everyone that’s been helping test and give feedback! v1 final really should (finally) be available next month 🙏

Upcoming work

The next major release planned is Tufte v3. I’ve already got an early draft prepared, but there’s polish needed - and new docs.

v3 improves performance and significantly improves interop with Telemere, offering what I believe to be a pretty compelling combination for Clojure/Script observability and monitoring.

For plans after that, you can see my 2025 roadmap), which as usual I’ll keep updated along the way 👍

Cheers everyone! :-)

Oleksandr Yakushev

2025 Annual Funding Report 1. Published February 28, 2025.

Hello friends! Here’s a short summary of my January-February Clojurists Together 2025 sponsorship work.

CIDER

I spearheaded the 1.17 and 1.17.1 releases of CIDER.
The biggest feature of the release is the support for automatic downloading of Java sources (details: https://clojurians.slack.com/archives/C06MAR553/p1739810631203369).
Auxiliary releases: nrepl 1.3.1, cider-nrepl 0.52.1, Orchard 0.30.1.

clj-async-profiler and Flamebin

New releases: 1.6.0 and 1.6.1.
New feature: switchable viewing modes for diffgraphs (details: https://clojurians.slack.com/archives/C06MAR553/p1736447669594659)
New feature: total percentage is automatically calculated for highlighted frames.
Both features are also supported at Flamebin (https://flamebin.dev/).

clj-memory-meter

New release: 0.4.0.
New feature: memory usage tracing.
New blog post: I have written about this new clj-memory-meter feature on Clojure Goes Fast blog: Tracking memory usage with clj-memory-meter.trace.

Misc projects

New release: virgil 0.3.2 - bugfixes.
New release: clj-java-decompiler 0.3.7 - bugfixes.

Call for Proposals. Feb. 2025 Member Survey

Thu, 06 Mar 2025 08:30:00 +0800

Greetings folks!

Clojurists Together is pleased to announce that we are opening our Q2 2025 funding round for Clojure Open Source Projects. Applications will be accepted through the 17th of March 2025 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.

We surveyed our members again in February to find out what types of initiatives they would like us to focus on for this round of funding. Their responses are summarized below. In particular, it was great to see members' feedback relating to how often they used or referred to developers' work we have funded. Also noted that several of you plan to attend Clojure/Conj, Clojure Berlin MeetUps, SciNoj Light, ClojureX, and ReClojure. CLojurists Together will be one of the sponsors of ReClojure in London this May.

Here is more from our February Members' survey.

What areas of the Clojure and ClojureScript ecosystem need support?

• “Beginners” onboarding. I think we need to make a concerted effort to attract new people (not only people without programming experience) and make the initial stages of “getting into Clojure(Script)” much more guided. Even if that initially means “opinionated”. Once a person has a minimum level of confidence, she can always explore other “opinionated options”. Otherwise, we risk fragmenting the efforts, and making the learners confused (which can led them to rejecting the language).
• We need to gain more hype and visibility in the wider software development community
• Outreach to new developers
• Learning experience for people who are not senior developers. Build tooling and getting started material for newcomers
• Data Science - can I make an R-quality chart without Python?
• Shadow - linting and bus-factor - Shadow is fiendishly complex judging by the rate of questions on Slack, and there is just one expert.
• ClojureDart
• New use cases, data analysis, clojure in academia, beginner resources, interop
• JS Ecosystem interop. How to use stuff like shadcn, tailwind etc. These things should not be so different from how people do it in JS.
• Scientific Clojure and Clojure for data processing
• DX tools.
• Build tooling the introduction of deps has made the ecosystem more difficult to get into
• The developer experience - it is already good, but it could be so much better. Better, more usable error messages, stack traces and better / easier to use profiling tools and tools for structuring builds
• The core is stagnant, especially the spec debacle.

What areas of the Clojure and ClojureScript ecosystem are strong?

• Just a great community
• Clojure-JVM language maintenance
• Web development, data processing
• The language. The tooling is becoming stronger, but more to go I think.
• Developer Experience Tools for experienced devs
• Very excited about all the work around the data science scene ie noj, clerk
• Clojure async, scripting, and web use cases are well covered
• Core language
• Build tooling
• The backwards compatibility and stability of libraries
• Linting
• Core libraries for config, web apps, routing, database interaction are all well served
• In general everything just works and is very stable, can’t wish for a better ecosystem to build on.

Are there any particular libraries, tools, or projects that are important to you that you would like to see supported?

• Jank (3) Jank seems increasingly important to use all the C++ AI related libs and models.
• Malli (3)
• shadow-cljs (3)
• Everything borkdude is doing (3)
• Babashka (2)
• Calva (2)
• CIDER (2)
• ClojureDart (2)
• Clojure LSP (2)
• Datalevin (2)
• Reitit (2)
• SciCloj (2)
• BB, carmine, Cheshire, clang, clay, clj-kondo, Clojars, clojupyter, clojure.jdbc, Cloverage, Conjure, Datahike, datomic-related, dtype-next, Duct (for deps.edn), Elasticsearch (spandex), fastmath, FlowStorm, Fulcro, girouette, http-kit, honeysql, HugSQL, kindly, Neanderthal, next-jdbc, nippy, noj, parinfer, Pathom, Portal, python-clj, Reagent, Shadow, snitch. NBBAero, squint/cherry. tableplot. tech.ml.dataset. A continuation of oz. Statistical libraries (say brms), uix

• I would LOVE to see some additional testing and cleanup work on Bifurcan–I’ve been using it a ton recently and it’s a big step up from the standard Clojure data structures

What would you like to be different in the Clojure community in the next 12 months?

• That AI’s get better at writing/reviewing Clojure code.
• I would love to see wider adoption of cljs on node.
• More cljc portable libraries usable in the JVM, browser, and Dart
• A plan for growth into new use cases, fields, and user personas
• Good integrations of Clojure IDEs with LLMs
• User-friendly developer tools: easy bootstrap, easy frameworks, a starting point to move fast from the start
• Moldable development
• Clojure data science tools with paths to reach parity with R and python
• I would love an online course for free
• Better support and tutorials around datalog databases beyond datomic
• Some kind of consensus as to how to create “quickstart” applications for various usecases that will make the Clojure ecosystem easier for new users to approach and for existing Clojurians to “sell” the stack into the teams that they work with. Ruby had / has Rails, Elixir has Phoenix, Node had / has Express, Python had / has Flask - Clojure needs a toolchain to create the same skeletons without departing from the many libraries approach that makes Clojure eventually far more versatile, down the road.
• Show the broader dev community that choosing Clojure for new projects is viable.
• We need to gain more hype and visibility in the wider software development community.
• More outreach, articles and so on to new developers.
• Improve adoption for non-Clojure users.
• It would be great to think of how we can grow the Clojure community so that it will be sustainable in the long run. What are some ways we can reach new audiences and bring more people into the community?
• I’d like it to be easier for newcomers to Clojure to get started.

Nov. and Dec. 2024 Project Updates

Thu, 09 Jan 2025 14:00:00 +1200

Happy New Year all! This is the last set up updates from our developers who received 2024 annual funding - and the final reports from Ambrose Bonnaire-Sergeant and Daniel Slutsky who were funded in Q3 2024. Thanks to everyone for their amazing work throughout the year!

Long-Term Project Updates

Bozhidar Batsov: CIDER
Michiel Borkent: squint, babashka, neil, cherry, clj-kondo, and more
Toby Crawley: clojars-web
Thomas Heller: shadow-cljs, shadow-grove
Kira Howe: Scicloj Libraries. tcutils, Clojure Data Cookbook, and more
Nikita Prokopov: Humble UI, Datascript, AlleKinos, Clj-reload, and more
Tommi Reiman: Reitit 7.0. Malli, jsonista, and more
Peter Taoussanis: Carmine, Nippy, Telemere, and more

Q3 2024 Project Update

Ambrose Bonnaire-Sergeant: Malli
Daniel Slutsky:SciCloj

Bozhidar Batsov

Report 6. Published January 1, 2025

Happy New Year, everyone!
The last couple of months were a bit slower than usual for CIDER and friends, but still we managed to make some good progress. Below are a list of highlights:

CIDER 1.16.1 was released in early December with a bunch of bug-fixes
nREPL 1.3.1 is also out with a couple of small fixes.
Work has been done in Orchard to simplify the parsing of Java source files
- We’ve dropped support for Java source parsing on Java 8 to make the codebase more maintainable
- Now you no longer need to have the JDK sources on the classpath (Orchard will look for them in several common places)
- This (and some other improvements) with be integrated with CIDER for its next release (1.17), which I’m hoping to launch in the next month or so.
Piggieback 0.6 is out with improved compatibility for nREPL 1.3.
- That’s the first release in over 3 years, btw!
We’ve launched a State of CIDER 2024 to gather input from the users about they way they are currently using CIDER. The data from this survey will help us shape up the roadmap for 2025. The survey will remain open until the end of January.

That’s all from me for now. Thanks again for supporting CIDER’s development in 2024!

Michiel Borkent

Report 6. Published December 30, 2024

Updates In this post I’ll give updates about open source I worked on during November and December 2024. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all.

Current top tier sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which aren’t listed above, please get in touch. On to the projects that I’ve been working on!

Updates

Clojurists Together announced that I’m among the 5 developers who were voted to receive the Long Term Funding in 2025. You can see the announcement here. Thanks so much!
Here are updates about the projects/libraries I’ve worked on in the last two months.

babashka: native, fast starting Clojure interpreter for scripting.
- #1771: *e* in REPL should contain exception thrown by user, not a wrapped one
- #1777 Add java.nio.file.attribute.UserDefinedFileAttributeView
- #1776 Add java.nio.file.attribute.PosixFileAttributes
- #1761 Support calling clojure.lang.RT/iter
- #1760 For compatibility with Fireworks v0.10.3, added the following to :instance-checks entry in babashka.impl.classes/classes(@paintparty)
  - clojure.lang.PersistentArrayMap$TransientArrayMap
  - clojure.lang.PersistentHashMap$TransientHashMap
  - clojure.lang.PersistentVector$TransientVector
  - java.lang.NoSuchFieldException
  - java.util.AbstractMap
  - java.util.AbstractSet
  - java.util.AbstractList
- #1760 For compatibility with Fireworks v0.10.3, added volatile? entry to babashka.impl.clojure.core/core-extras(@paintparty)
- Bump babashka.cli to 0.8.61
- Bump clj-yaml to 1.0.29
- #1768: Add taoensso.timbre color-str function
- Add classes:
  - javax.crypto.KeyAgreement
  - java.security.KeyPairGenerator
  - java.security.KeyPair
  - java.security.spec.ECGenParameterSpec
  - java.security.spec.PKCS8EncodedKeySpec
  - java.security.spec.X509EncodedKeySpec
  - java.security.Signature
- Add java.util.concurrent.CompletionStage
- Bump core.async to 1.7.701
- Bump org.babashka/cli to 0.8.162
- Include jsoup for HTML parsing. This makes bb compatible with the hickory library (and possibly other libraries?).
- #1752: include java.lang.SecurityException for java.net.http.HttpClient support (@grzm)
- #1748: add clojure.core/ensure
- Upgrade taoensso/timbreto v6.6.0
- Upgrade babashka.http-client to v0.4.22
- Add :git/sha from build to bb describe output (@lispyclouds)
- Fix NPE with determining if executing from self-contained executable
squint: CLJS syntax to JS compiler
- Fix #255: fn literal with rest args
- #596: fix unary division to produce reciprocal
- #592: fix clj->js to not process custom classes
- #585: fix clj->js to realize lazy seqs into arrays
- #586: support extending protocol to nil
- #581: support docstring in defprotocol
- #582: add extend-protocol
- Add delay
- Fix #575: map? should not return true for array
- Fix #577: support $default + :refer
- Fix #572: prevent vite page reload
CLI: Turn Clojure functions into CLIs!
- Fix #109: allow options to start with a number
scittle: Execute Clojure(Script) directly from browser script tags via SCI
- #99: make js/import work
- #55: create gh-pages dir before using.
- #89: allow evaluate_script_tags to specify individual scripts.
- #87: prod build on fresh checkout fails
clj-kondo: static analyzer and linter for Clojure code that sparks joy. \
- Unreleased
- #2272: Lint for nil return from if-like forms
- Add printf to vars linted by analyze-format. (@tomdl89)
- #2272: Report var usage in if-let etc condition as always truthy
- #2272: Report var usage in if-not condition as always truthy
- #2433: false positive redundant ignore with hook
- Document :cljc config option. (@NoahTheDuke)
- #2439: uneval may apply to nnext form if reader conditional doesn’t yield a form (@NoahTheDuke)
- #2431: only apply redundant-nested-call linter for nested exprs
- Relax :redundant-nested-call for comp, concat, every-pred and some-fn since it may affect performance
- #2446: false positive :redundant-ignore
- #2448: redundant nested call in hook gen’ed code
- #2424: fix combination of :config-in-ns and :discouraged-namespace
- 2024.11.14
- #2212: NEW linter: :redundant-nested-call (@tomdl89), set to level :info by default
- Bump :redundant-ignore, :redundant-str-call linters to level :info
- #1784: detect :redundant-do in catch
- #2410: add --report-level flag
- #2416: detect empty require and :require forms (@NoahTheDuke)
- #1786: Support gen-interface (by suppressing unresolved symbols)
- #2407: support ignore hint on called symbol
- #2420: Detect uneven number of clauses in cond-> and cond->> (@tomdl89)
- #2415: false positive type checking issue with str/replace and ^String annotation
nbb: Scripting in Clojure on Node.js using SCI
- 1.3.196 (2024-11-25)
- Add locking macro for compatibility with CLJS
- 1.3.195 (2024-11-07)
- #343: support :reload for reloading CLJS namespaces and JS code
rewrite-clj: Rewrite Clojure code and edn
- Fix parsing of b// symbol
pod-babashka-go-sqlite3: A babashka pod for interacting with sqlite3
- #19: Restore mac intel support (this time for real)
tools-deps-native and tools.bbuild: use tools.deps directly from babashka
- Fix #30: pod won’t run on newer versions of macOS
http-client: babashka’s http-client \
- #73: Allow implicit ports when specifying the URL as a map (@lvh)
- #71: Link back to sources in release artifact(@lread)

Other projects

There are many other projects I’m involved with but that had little to no activity in the past month. Check out the Other Projects section (more details) of my blog here to see a full list.

Toby Crawley

Report 6. Published December 31, 2024

CHANGELOG | clojars-web commits

Added a new API to provide a release feed

November 2024

CHANGELOG | clojars-web commits | infrastructure commits

Worked with a new contributor (Osei Poku) to implement a sitemap
Constrained heap usages for cron tasks to prevent competition with the webapp
(this was causing the server instance to become unavailable on occasion)

Thomas Heller

Report 6. Published January 6, 2025

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (e.g. Clojurians Slack).

Current shadow-cljs version: 2.28.20 Changelog

Kira Howe

Report 6. Published December 31, 2024.

This is a summary of the open source work I spent my time on throughout November and December 2024. This was the last period of my ongoing funding from Clojurists together. It’s been such a magical year in many ways and I’m so grateful to have had the opportunity to spend so much time focusing on open source this year. It was a fantastic experience and I hope to be able to take another professional hiatus at some point in the future to do it again.

I’ve really enjoyed writing these summaries, too, and I find knowing they’re coming helps motivate me to stay more organized and keep better track of things, so I’ll probably continue to publish them even though I’ll be spending less time on side projects as my focus shifts to other priorities this year.

Sponsors

I always start these posts with a sincere thank you to the generous ongoing support of my sponsors that make this work possible. I can’t say how much I appreciate all of the support the community has given to my work and would like to give a special thanks to Clojurists Together and Nubank for providing incredibly generous grants that allowed me reduce my client work significantly and afford to spend more time on projects for the Clojure ecosystem for nearly a year.

If you find my work valuable, please share it with others and consider supporting it financially. There are details about how to do that on my GitHub sponsors page. On to the updates!

BOBKonf 2025

One exciting update is that a workshop I proposed got accepted to BOBKonf, which will be in Berlin next March. It’ll be similar to the types of talks and workshops I’ve been doing over the last couple of years at e.g. the Conj and London Clojurians, of course updated to show off the latest and greatest developments in the Clojure-for-data ecosystem. I spent some time in December beginning work on the content and now I’m in full conference-driven-development mode, figuring out what’s realistic to finish in time to demo at the event and what we should consider stable “enough” for now and just include. This preliminary work also sparked a couple of minor conversations, one about quarto theming of Clay notebooks and another about parsing dates from Excel workbooks.

Anyway there are still a couple of months to work on it, which on one hand feels like a long time but on the other hand is also no time at all. Before I know it I’ll be landing in Berlin ready to share the wonders of Clojure with a new eager audience.

Clojure Data Cookbook

This has been a very long-running, very ongoing project of mine. The high level goal was always (and still is) to create resources that would allow people to figure out how to be productive with Clojure’s data stack. In reality what this particular project morphed into was a process for discovering the gaps in the ecosystem and guiding development of new tools, uncovering missing features to implement or new libraries to write every time I’d start work on a new chapter.

We’ve come a long way over the past couple of years and there’s still work to do but the ecosystem is reasonably mature now. The Noj book has taken on covering a lot of the topics I wanted to document thanks to Daniel Slutsky’s incredible efforts at coordinating the community to produce this amazing content. The list of draft articles demonstrates many of the areas where work is still very ongoing in the development of the various libraries. Tutorials are mostly not left unfinished because the authors haven’t gotten around to finishing them, but more because the question of what exactly to write about is yet to be answered.

On the Clojure Data Cookbook itself, the current work in progress is available here and includes only sections that document stable and established functionality. The goal of making Clojure’s data stack accessible and easy to work with is still at the top of my priority list but conversations are underway about what the best way to do that is in the context of the current ecosystem.

ggclj

Another project I’ve been poking away at the last couple of months is my implementation of the grammar of graphics in Clojure. Most of my effort here is spent learning more and more about the core concepts of data visualization and how graphics can be represented using a grammar, and then how that grammar could be implemented in an existing programming language. This along with exploring prior implementations in other languages. I have a very rudimentary build process working for transforming an arbitrary dataset into a standardized, graph-able dataset, but nothing yet on the actual graphic rendering. It’s very interesting and satisfying but I’m not sure how useful. But, in the spirit of heeding Rich’s advice from the last Conj about doing projects for fun, I haven’t let it go completely. It’s still something I’d love to get working someday.

Reflecting on a year of open source

As I mentioned above I really enjoyed having the time this year to work on so many interesting projects for the Clojure community. It’s so rewarding to see how far we’ve come. Even though it feels like there is still so much to do, I think it’s important to reflect on the progress we have made and think about how the problems we encountered along the way shaped the path we took.

When I first started working on the Clojure Data Cookbook, there wasn’t even a way to publish a book made out of Clojure files. Clerk was brand new and Clay barely existed. Now we can render a pile of Clojure files as a Quarto book! And the need for better documentation has spurred tons of amazing development in this space. The literate programming story in Clojure is better than in any other language.

We’ve also made huge strides in connecting the various libraries of the ecosystem together. At the beginning of the year there were many amazing but disconnected libraries. I’ve been really inspired by the ideas behind the tidyverse and have been trying to communicate the idea of sharing common idioms and data structures. An ecosystem is starting to emerge in Noj that offers a coherent, standardized, shared paradigm for using all of the amazing tools of the Clojure data ecosystem together. The default stack has been chosen, and serious efforts are now underway toward making these libraries feature complete and interoperable. And I plan to continue working on tutorials, guides, and workshops as much as I can to help promote it all.

I’m grateful for all the changes in my life that have taken my time away from working on side projects as much as I used to, like marriage and a great new job, but in many ways I miss doing more of this work and I sincerely hope I find myself in a position to veer off of this “standard” life track in the future to take a period to focus on this kind of stuff full time again. Even better would be figuring out a way to make it sustainable so that I could continue to do it full time. If you have any idea how to make that work, let me know :)

It turns out I am not the kind of market-oriented, entrepreneurially-minded person who can turn coding skills into a business that generates steady income for my family. I like contracting and the slow-and-steady community building type of work that constitutes a career in open source, but unfortunately continuing down this road is just not in the cards for me this year. Though I’ll never be able to completely resist working on it whenever I can :) Thanks so much for reading this far, and hope to see you around the Clojureverse!

Nikita Prokopov

Report 6. Published December 30, 2024

Hi, this is Niki Tonsky and past two month I was working on Fast EDN parser.

Fast EDN, a faster EDN parser for Clojure.

This project started with a question: why does EDN parse so much slower than JSON? Is there a good reason for that? Turned out, no! That’s how Fast EDN was born.

~6× speed improvement over clojure.edn.
Outperforms transit-clj.
More consistent error reporting.
Much cleaner code.

Clojure Sublimed, Clojure support for Sublime Text 4:

New Select Topmost Form command
New Align Cursors command
Fixed evaluation of () (closes 131)
Add | to the allowed symbols chars 132
Clarified some symbol/keyword edge cases in syntax
Color scheme adjustments

Sublime Executor, executable runner for Sublime Text:

Put 0.2 sec limit on find_executables. Large project shouldn’t be a problem anymore

Misc:

New icons for clj-async-profiler
Throw on fail for virgil

Both of these libraries were crucial in developing Fast EDN, so I contributed back.

And the most important news of all. tonsky.me, my personal website:

Now has a winter theme!

Overall, what a year! Thanks Clojurists Together and my patrons for making it possible to work almost entire year on open-source full time. Best year of my life (so far!)

Happy New Year everyone!

Tommi Reiman

Report 6. Published January 1, 2025

Reflected on my year of working with Open Source. Having authored tens of Clojure Open Source Libraries makes you look things from another angle. Instead of just adding more (fun) features, I dedicated time to go through all old issues and open PRs from 2024 for the active and stable libraries where there is no clear lead developer or it’s me.

Closed a lot of support tickets, answered questions and reviewed and merged PRs. Thanks to all contributors and sorry to not doing this earlier!

Some releases:

Malli 0.17.0

Don’t output :definitions nil in swagger. #1134
BREAKING: :gen/fmap property requires its schema to create a generator.
- previous behavior defaulted to a nil-returning generator, even if the schema doesn’t accept nil
- use :gen/return nil property to restore this behavior
Support decoding map keys into keywords for [:map schemas in json-transformer #1135
:not humanizer #1138
FIX: :seqable generates nil when :min is greater than 0 #1121
FIX: malli.registry/{mode,type} not respected in Babashka #1124
FIX: :float accepts doubles but never generates them #1132
FIX: :float missing humanizer #1122
Updated dependencies:

fipp/fipp '0.6.26' to '0.6.27'

Ring-http-response 0.9.5

Fix pre-expr syntax #34
updated dependencies:

[ring/ring-core "1.13.0"] is available but we use "1.12.2"

Going Forward to 2025

Yes, it’s already 1.1! I did not apply for Clojurists Together funding as I didn’t have the time I wished for to work on Open Source. Not going anywhere, but need to figure out a way to continue the work in a sustaineable way. Cheers.

Something Else

Vegan Pizza from Metosin pikkujoulu.

Peter Taoussanis

Report 6. Published December 31, 2024

- Peter Taoussanis

Hey folks, it’s the end of the year again! 🍾🎉

Will keep today’s update short-

This was another busy year for open source work, with almost 50 public releases (🫣). The biggest can be easily seen on my 2024 roadmap.

The headline focus was Telemere - a modern rewrite of Timbre that offers an improved API to cover traditional logging, structured logging, tracing, basic performance measurement, and more.

That’s been a lot of ongoing work - getting things polished for v1 final. I’m pretty happy with the present state: v1 RC2 was recently released, and I expect that to become v1 final in January 🎉

The agenda for next year (2025) currently includes:

Telemere v1 final
Tempel v1 final (sorry for the delay on this!)
Sente v1.21 (with lots of planned improvements)
Tufte v3 (incl. sharing Telemere’s core)
Truss v2 (incl. improved integration with Telemere)
Continued long-term work on Carmine v4 (currently in early alpha)

Looking forward to it :-)

As usual, my up-to-date roadmap will be available here once it’s ready.

Thank you everyone, see you next year! 👋🫶

Ambrose Bonnaire-Sergeant: Malli

Report 3 (Q3 2024). Published January 14, 2025

This is the final of three reports in the project to extend Malli with constraints.

Report 1
Report 2

Thanks to everyone who made this project possible.

Background

This project aims to improve the expressiveness of Malli schemas, in particular to improve the ability to specify complex invariants about the keysets of a :map schema.

Progress

open PR’s
- Introduce schemas for map key constraints
  - Some promising feedback on slack:
    - “This is amazing. The virtue of being “open to changes” often results in this kind of implicit rules. I think I’m going to use this a lot once this PR is merged.”
merged PR’s
- :not humanizer
- don’t generate nil if :seqable is non-empty
- add :float humanizer
- align :float and :double generators
- refactor generator ns with -never-gen helpers
  - malli.generator: 646 => 557 LOC
- Propagate options to 1-child -reducing, disallow 0-child

In my previous report, I speculated whether :map could be made more expressive without changing the :map schema itself or any new features to Malli. I think I’ve now achieved that.

I’ve proposed adding six new schemas to Malli that are designed to be combined using [:and [:map ...] S1 S2 S3 ...]. Some custom code is needed to support humanization.

If this gets merged, the next step is to improve the generator for :and. My original hunch to avoid :and was because of its probabilistic generator, which inspired the initial design to add constraints to the :map schema itself to avoid the problem altogether.

Throughout this project, I designed a more accurate :and generator that I will work on next. The basic strategy to generate [:and S T] will be to generate S but propagate T as extra information to the S generator in a canonical form. This requires a backwards-compatible update to each schema’s generator to make use of this information before returning the generator.

The more exciting part is the representation used to improve generators could be reused for other tasks like simplifying schemas and optimizing validators.

Demo

I will end this report with a demo of the proposed schemas from #1161: Introduce schemas for map key constraints.

The :and schema can be used to constrain an existing schema to be more specific.
In this section we show how to constrain a :map schema with more specific keys.

The schema [:has K] asserts the key K must be present.
This is the main building block for key constraints that will be combined with other schemas.

(me/humanize
  (m/explain
    [:and :map [:has :x]]
    {}))
; => {:x ["missing required key"]}

(me/humanize
  (m/explain
    [:and :map [:has nil nil] [:has []]]
    {}))
; => ["missing required key"]

The :or schema asserts that at least one of its children is satisfied.

;; at least one padding direction must be provided
(def Padding
  [:and
   [:map
    [:top {:optional true} number?]
    [:bottom {:optional true} number?]
    [:left {:optional true} number?]
    [:right {:optional true} number?]]
   [:or
    [:has :top]
    [:has :bottom]
    [:has :left]
    [:has :right]])

(m/validate Padding {:left 1 :right 10 :up 25 :down 50}) ;=> true
(me/humanize
  (m/explain Padding {}))
; => {:top ["missing required key"],
;     :bottom ["missing required key"],
;     :left ["missing required key"],
;     :right ["missing required key"]}

The :xor schema requires exactly one of its children to be satisfied.

;; :mvn/version or :git/sha must be provided, but not both
(def GitOrMvn
  [:and
   [:map
    [:mvn/version {:optional true} :string]
    [:git/sha {:optional true} :string]]
   [:xor
    [:has :mvn/version]
    [:has :git/sha]]])

(m/validate GitOrMvn {:mvn/version "1.0.0"}) ; => true

(m/validate GitOrMvn {:mvn/version "1.0.0" :git/sha "123"})) ; => false

(me/humanize
  (m/explain GitOrMvn
             {:mvn/version "1.0.0"
              :git/sha "123"}))
; => ["should not have key :git/sha"]

(me/humanize
  (m/explain GitOrMvn
             {}))
; => {:mvn/version ["missing required key"],
;     :git/sha ["missing required key"]}

The :iff schema requires either all or none of its children to be satisfied.

;; either both :user and :pass are provided, or neither
(def UserPass
  [:and
   [:map
    [:user {:optional true} string?]
    [:pass {:optional true} string?]]
   [:iff [:has :user] [:has :pass]]])

(m/validate UserPass {}) ; => true
(m/validate UserPass {:user "a" :pass "b"}) ; => true

(me/humanize
  (m/explain UserPass {:user "a"}))
; => {:pass ["missing required key"]}

The :implies schema is satisfied if either its first child is not satisfied or all of its children are satisfied.

;; if :git/tag is provided, then so should :git/sha
(def TagImpliesSha
  [:and
   [:map
    [:git/sha {:optional true} :string]
    [:git/tag {:optional true} :string]]
   [:implies [:has :git/tag] [:has :git/sha]]])

(m/validate TagImpliesSha {:git/sha "abc123"}) ;=> true
(m/validate TagImpliesSha {:git/tag "v1.0.0" :git/sha "abc123"}) ; => true

(me/humanize
  (m/explain TagImpliesSha {:git/tag "v1.0.0"}))
; => {:git/sha ["missing required key"]}

The :disjoint schema is similar to :xor but also permits zero schemas to match.

;; :mvn/* and :git/* keys should not coexist
(def SeparateMvnGit
  [:and
   [:map
    [:mvn/version {:optional true} :string]
    [:git/sha {:optional true} :string]
    [:git/tag {:optional true} :string]
    [:git/url {:optional true} :string]]
   [:disjoint
    [:has :mvn/version]
    [:or
     [:has :git/sha]
     [:has :git/url]
     [:has :git/tag]]]])

(m/validate SeparateMvnGit {}) ; => true
(m/validate SeparateMvnGit {:mvn/version "1.0.0"}) ; => true
(m/validate SeparateMvnGit {:git/sha "1.0.0"}) ; => true
(m/validate SeparateMvnGit {:mvn/version "1.0.0" :git/sha "abc123"}) ; => false

(me/humanize
  (m/explain SeparateMvnGit
             {:mvn/version "1.0.0"
              :git/sha "abc123"}))
; => ["should not have key :git/sha"]

For multiple sets of disjoint keys, use multiple :disjoint schemas.

;; cannot hold :up + :down or :left + :right
(def DPad
  [:and
   [:map
    [:down {:optional true} [:= 1]]
    [:left {:optional true} [:= 1]]
    [:right {:optional true} [:= 1]]
    [:up {:optional true} [:= 1]]]
   [:disjoint [:has :down] [:has :up]]
   [:disjoint [:has :left] [:has :right]]])

(m/validate DPad {}) ; => true
(m/validate DPad {:up 1}) ; => true
(m/validate DPad {:down 1}) ; => true
(m/validate DPad {:right 1}) ; => true
(m/validate DPad {:left 1}) ; => true
(m/validate DPad {:up 1 :left 1}) ; => true
(m/validate DPad {:down 1 :left 1}) ; => true
(m/validate DPad {:up 1 :right 1}) ; => true
(m/validate DPad {:down 1 :right 1}) ; => true

(me/humanize
  (m/explain DPad {:up 1 :down 1}))
; => ["should not have key :up"]

(me/humanize
  (m/explain DPad {:left 1 :right 1}))
; => ["should not have key :right"]

In this example, we nest :and in :or to assert that either a secret or user/pass must be provided. The :disjoint schema is used to ensure both are not provided. Even if we used :xor instead of :or, it would still be legal to provide {:secret "1234" :user "user"} without this additional constraint.

(def SecretOrCreds
  [:and
   [:map
    [:secret {:optional true} string?]
    [:user {:optional true} string?]
    [:pass {:optional true} string?]]
   [:or
    [:has :secret]
    [:and [:has :user] [:has :pass]]]
   [:disjoint
    [:has :secret]
    [:or [:has :user] [:has :pass]]]])

(m/validate SecretOrCreds {:secret "1234"}) ; => true
(m/validate SecretOrCreds {:user "user" :pass "hello"}) ; => true

(me/humanize
  (m/explain SecretOrCreds {:user "user"}))
; => {:secret ["missing required key"], :pass ["missing required key"]}

;; combining :or with :disjoint helps enforce this case
(me/humanize
  (m/explain SecretOrCreds {:secret "1234" :user "user"}))
; => ["should not have key :user"]

Daniel Slutsky: SciCloj

Report 3 (Q3 2024). Published December 19, 2024.

The Clojurists Together organization has decided to sponsor Scicloj community building for Q3 2024, as a project by Daniel Slutsky. This is the second time the project has been selected this year. Here is Daniel’s last update for this period.

This overview of November’s work is extended by a few recent updates from the first half of December.

Comments and ideas would help. :pray:

November 2024

Scicloj is a Clojure group developing a stack of tools and libraries for data science. Alongside the technical challenges, community building has been an essential part of its efforts since the beginning of 2019. Our current main community-oriented goal is making the existing data science stack easy to use through the maturing of the Noj library, mentioned below. In particular, we are working on example-based documentation, easy setup, and recommended workflows for common tasks.

All these, and the tools to support them, grow organically, driven by real-world use cases.

I serve as a community organizer at Scicloj, and this project was accepted for Clojurists Together funding in 2024 Q1 & Q3. I also receive regular funding through Github Sponsors, mostly from Nubank.

As some parts of November’s work have only matured during the beginning of December, I am writing this report a couple of weeks late. It overviews my involvement during November, the first half of December, and then comments about the proposed directions for the near future.

I had 31 meetings during November and 25 meetings during the first half of December. Most of them were one-on-one meetings for open-source mentoring or similar contexts.

All the projects mentioned below are done in collaboration with others. I will mention at least a few of the people involved.

November 2024 and early December highlights

Design discussions

This has been a thoughtful period in the Clojurians Zulip chat. We faced a few questions regarding how we organize functionality across libraries and went through a careful thinking process to reach a common ground of understanding. A lot of the details shared below are the fruit of those discussions.

Noj

The Noj library is the entry point to data science with Clojure, collecting a stack of relevant libraries. During this period, it was officially announced as Beta stage. We kept extending it and mostly worked on documentation. Carsten Behring kept improving the documentation workflow, partially automating it, and creating extensive documentation for a few major Noj components. I also took part in documentation and in helping other community members contribute a few drafts.

Tableplot

Tableplot, the plotting library based on the layered grammar of graphics idea, was one of my main foci of development. I implemented quite a few additional types of plots and control parameters and put a lot of work into the documentation reference.

Tablemath

Tablemath is one result of our recent design discussions. It is a new library for math and statistics that composes well with tech.ml.dataset and Tablecloth datasets and uses the functionality of Fastmath. Tablemath is highly inspired by R and its packages and is intended to compose well with Tableplot layered plotting. During this period, I released an initial version after exploring a few directions.

Clay

Clay, the REPL-friendly notebook and data visualization tool, received a few updates from other community members. On my side, I explored the different ways it consumes JS and CSS dependencies. We want to make this part more modular for various use cases. At the moment, I am struggling with a few technical difficulties.

Kindly-render

Kindly-render is a tool-agnosic implementation of the Kindly data visualization standard. Timothy Pratley kept developing it, and it looks very promising. My involvement was not intensive, except for a few joint coding sessions and reviews of the code.

Scicloj open-source mentoring

In this period, we continued the collaboration of quite a few mentees and the current four mentors, including myself. To focus on progress with currently ongoing projects, we did slow down the growth of the project and could only accept a few new mentees.

Meeting new community members

In the last few weeks, I did meet a few new community members: Clojurians who wish to get involved in data science and people of scientific or data background who wish to get involved in Clojure. There is a good momentum in adopting the Scicloj toolkit for various needs. With a few of the new friends, I started meeting more or less regularly and exploring their concrete use cases.

Clojure in Academia

Following an initiative of Thomas Clark, we started an active exploration of pathways to make Clojure more present in academia. I reached out to about a dozen people who are active in academia and known to be involved in Clojure and scheduled a couple of meetings to discuss possible directions. There has been a warm response from most of the relevant people, who expressed their willingness to help explore this direction.

Three main directions were proposed: (1) Working on academic papers to discuss technical aspects of Clojure’s scientific stack. (2) Collaborating with researchers on specific use cases of Clojure. (3) Demonstrating the potential of Clojure in academic teaching.

The teaching perspective, which was proposed by Blaine Mooers, will receive the highest priority in the short term.

As a first step, we are considering organizing an online conference to make one or more of the above directions more visible and encourage further interest.

Tutorial meetings

During our work on documenting Noj, we experimented with various workflows of writing tutorials together. Recently, we converged on a format that is working. We meet quite often and write tutorial drafts together. The same draft will typically be handled by different people in different meetings. Each time, we review everything so that the session is self-contained. This way, more people learn about topics they care about, and the content we write gets to be reviewed by more people and more perspectives.

Linear Algebra meetings

The weekly linear algebra meetings keep happening every week. They typically go by the tutorial format mentioned above.

Website

This period has been a usual period in terms of website maintenance.

real-world-data group

The real-world-data group is a space for Clojure data practitioners to share their experiences. It keeps going, meeting every two weeks. In the three meetings we had in November and the one we had in December so far, we mainly discussed the topics mentioned above in this report, as well as a few work experiences of group members.

Near term goals

Noj

In the near future, we should bring the Noj documentation to a state that is good enough to be clear and welcoming to new users.

Tablemath

Tablemath will probably be the main experimental project on my agenda. The main goals are to combine the underlying libraries (Fastmath, dtype-next, tech.ml.dataset, Tablecloth) to benefit from the advantages of each of them in terms of ergonomics as well as performance and to provide a user-friendly API inspired by R. (2)

Clojure in academia

This project is still in its very early stages. We should explore various directions and carefully pick those which might be promising.

Tooling

I will join Timothy Pratley on the goal of helping different tools support the Kindly standard. Cursive, Calva, Quarto, and Clojupyter are a few of the relevant candidates.

Thanks..and more

Sun, 29 Dec 2024 14:00:00 +1200

As 2024 comes to a close we want to reach out and thank you for supporting Clojure, open-source, and the Clojurists Together community.

We’ve been able to accomplish a lot this year with your support.

In 2024, we funded a total of $254,000 of projects. 17 developers completed 22 shorter-term projects ($110,000 USD). 8 developers received a monthly stipend for the year ($144,000 USD in long-term funding). Since 2018, Clojurists Together has awarded more than $1.1 million to 86 developers working on more than 142 projects.

Your input on our quarterly surveys is critical to ensuring that we are funding work that is needed, valued, and adopted by the community at large. 26% of members participate every quarter.

33% of members participated in the new process for selecting the developers to receive 2025 annual funding. Thank you for reviewing the proposals and voting!

We were able to sponsor and attend the Heart of Clojure conference in Belgium in September - and it was a pleasure to talk with many of you again in person after a long CoVid hiatus.

The developer’s work we fund is highly valued - and used daily.

Short-Term Projects Funded in 2024

Q1 2024: CIDER, clojure-lsp, Instaparse, Jank, scicloj, sitefox, UnifyBio, Wolframite

Q2 2024: Clj-kondo, babashka, SCI, nbb, squint/cherry, Clj-merge tool, compojure-api, Enjure, Jank, Lost in Lambduhhs podcast, Plexus

Q3 2024: clj-Nix, Clojure Goes Fast, Jank, Kushi, Malli, ScioCloj, Standard Clojure Style

2024 developers receiving annual funding: Bozhidar Batsov, Michiel Borkent, Thomas Heller, Kira McLean, Nikita Prokopov, Tommi Reiman, Peter Taoussanis, Toby Crawley.

Fun Facts and Thank You’s

We are truly an international group bringing a wide range of experience. From Q1 2022 to Q3 2024, we funded developers working in 20 countries including Austria, Belgium, Brazil, Bulgaria, Canada, Denmark, England, Finland, France, Germany, Israel, Lithuania, Netherlands, Norway, Poland, Serbia, Spain, Sweden, UK and the US.

This staggering amount of work has benefited our members and the broader Clojurist community.
A thanks goes out to all the developers for their commitment and contributions to the community over the last 7 years: Adam Helins, Alexander Oloo, Ambrose Bonnaire-Sergeant, Arne Brasseur, Ashima Panjwani, Baptiste Dupuch, Benjamin Kamphaus, Ben Brinckerhoff, Bobbi Tower, Bozhidar Batsov, Brandon Ringe, Bruce Hauman, Chris Badahdah, Chris McCormick, Charles Comstock, Chris Oakman, Christian Johansen, Christophe Grand, Dainius Jocas, Daniel Higginbotham, Daniel Slutsky,Danny Freeman, David Levy, David Nolen, Dragan Duric, Eric Dallo, Ethan Miller, Gert Goet, Grodziski, Henry Widd, Iizuka Masashi, Isaac Johnston, Jack Rusher, Jacob O’Bryant, James Reeves, Janet Carr, Jeaye Wilkerson, Jeremiah Coyle, John Collins, John Stevenson, Joakim Tengstrand, Joel Holdbrooks, José Luis Lafuente, Juho Teperi, Karol Wójcik, Kira McLean, Konrad Kühne, Kury Harringer, L. Jordan Miller, Lee Hinman, Lukas Domagala, Mark Engelberg, Martin Kavalar, Matthew Davidson, Matthew Huebert, Matthew Ratzke, Michael Sappler, Michiel Borkent, Mike Fikes, Mitesh Shah, Nikita Prokopov, Oleksandr Yakushev, Oleksii Kachaiev, Oliver Caldwell, Othman Azil, Peter Stromberg, Peter Taoussanis, Rafael Krzyważnia, Sam Ritchie, Savo Djuric, Sean Corfield, Sebastian Zartner, Thomas Clark, Thomas Heller, Tim Pope, Toby Crawley, Tommi Jalkanen, Tommi Reiman, VEMV, Vladislav Protsenko, William Acton, Zach Oakes, Žygis Medelis, and the team at Gaiwan.

And a shout out to the Into, Cons and Assoc Members who Contributed in 2024!
bevuta IT GmbH, QA Wolf, Inc, Jepsen, Xcoo, Sharetribe, Halal Booking, Basil, Cognician, Biotz SL, Matrix Operations, Strategic Blue, Eric Normand, Nubizzi, Bloom Ventures, Mastodon C, Ardoq AS, Condense, Mediquest, Vane GmbH, Codesmith GmbH, ELiT Ltd. Thorax informatieprojecten & advies, Fern Flower Labs, Joshua Miller and Revenue Share member Jacek Schae (Learn Reagent, Learn re-frame).

… and another thank you to all the 2024 Contributing Members. All of you make this work possible!

Let’s join in celebrating this wonderful community - and hoping for peace in the New Year.
lvh, Maria, Daniel, Heather, Felix, Max, and Lorelai (Clojurists Together Board), Kathy (Program Manager).

Clojurists Together 2025 Long-Term Funding Announcement

Tue, 10 Dec 2024 14:00:00 +1200

Michiel Borkent
Eric Dallo
Dragan Djuric
Peter Taoussanis
Oleksandr Yakushev

Thanks to the all of you - the Members - who took the time to review the applications and make the difficult decision to select just 5 from many excellent proposals. Congratulations are in order to Michiel, Eric, Dragan, Peter, and Oleksandr! For everyone else who submitted their projects, there will be more grant opportunities in 2025 - so keep posted.

Michiel Borkent

My main projects are clj-kondo, babashka / SCI, and squint/cherry. I will develop new features, specified below per project. As usual I’ll also work on ongoing maintenance and offering support on Slack and Github.

Eric Dallo

I want to dedicate more time on big features for anything related to the Clojure LSP ecosystem, this includes: clojure-lsp and all integrations with editors, intellij, calva, lsp-mode, and so on. Also, I want to improve the IntelliJ experience to be as good as Cursive, improving clojure-repl-intellij and clojure-lsp-intellij projects so we can have good options for LSP in any editors.

Dragan Djuric

My goal with this funding in 2025 is to support Apple silicon (M cpu) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible). This will hugely streamline user experience regarding high performance computing in Clojure for Apple macOS users, which is a considerable chunk of Clojure community.

Peter Taoussanis

Multiple projects, incl. further work on Telemere, Tufte, Tempel, and more. I have been trying to focus recent work on practical areas where Clojure either doesn’t already have great solution/s, or where Clojure might be able to offer something uniquely advantageous over other languages/platforms. There’s still a lot of low-hanging fruit re: both observability and data security for example. Beyond that, just focusing on practical tools that work at scale while being approachable for beginners

Oleksandr Yakushev

I plan to continue working on Clojure Goes Fast tooling. During Q3 2024, I’ve covered a lot of ground with new features and redesign of clj-async-profiler and the first release of Flamebin. This also opened a lot of ideas and opportunities for further improvement of those tools. I have a large backlog of tasks for:

Flamebin – implement authorization and social login, client-side encrypted private flamegraphs, collaborative commenting, configuration editing and saving;
clj-async-profiler – unified configuration, configuration reuse between flamegraphs, automatic analysis and performance improvement suggestions;
Clojure Goes Fast knowledge base – populate the list of bad performance practices that can be later be linked to by the clj-async-profiler analyzer;
clj-java-decompiler – CIDER integration which I wished to do in Q3 but couldn’t get to in this quarter.

Thanks

Thanks again to all of our members for selecting these developers. If it wasn’t for your generous support, this wouldn’t be possible. I wanted to add a special thanks to Latacora, Roam Research, Whimsical, Nubank, Cisco, JUXT, Metosin, Solita, Adgoji, Grammarly, Nextjournal, ClojureStream, Shortcut, Flexiana, Toyokumo, Griffin, doctronic, and 180° Seguros. They have all contributed significant amounts to Clojurists Together which lets us award $90,000 in long-term funding to Clojure developers.

Nov. 2024 Short-Term Project Updates

Mon, 09 Dec 2024 14:00:00 +1200

We’ve got our second (and one third) set of reports from developers working on short-term projects funded in Q3 2024. You’ll find a brief description of each project at the top of the page to provide some context – followed by current project updates.

clj-Nix: José Luis Lafuente

Develop an alternative builder for Nix that uses Babashka / SCI instead of Bash. It provides a way for constructing complex Nix derivations using Babashka/SCI entirely, eliminating the need to write any Bash code.
Also, will be adding a Babashka writer to nixpkgs. Nixpkgs supports creating self-contained scripts, called “nix writers.” Traditionally written in Bash, recent versions of nixpkgs include the ability to write these scripts in Python, Ruby, or Rust.

Clojure Goes Fast: Oleksandr Yakushev

Create a new web application for clj-async-profiler that will allow users to host and share the generated flamegraphs. At the moment, even though flamegraphs are just self-contained HTML files, sending them to somebody is a chore. The new service can make this much easier and offer extra features like saving and sharing dynamic transforms on the fly. Additionally, I’d like to focus on the UI side of clj-async-profiler - add new dynamic transforms, improve aesthetics and the UX.
For clj-java-decompiler, expand its preprocessing abilities to present clearer results to the user and integrate it more tightly with established Clojure IDEs like CIDER and Calva, which requires some groundwork.
Adapting and updating benchmarking content in the Clojure Goes Fast knowledge base

Jank: Jeaye Wilkerson

Jank feels like Clojure now, with 92% syntax parity and nearly 40% clojure.core parity. But it only feels like Clojure to me because none of you are using it yet. My top priority is to change that. I’ll be working on building out jank’s nREPL server, which involves implementing bencode support, clojure.test, improving native interop, supporting pre-compiled binary modules, and ultimately adding AOT compilation support.

Kushi: Jeremiah Coyle

Continue development of Kushi, a foundation for building web UI with ClojureScript. Work this funding cycle will focus on finishing the new css transpilation pipeline, significant build system performance upgrades, and implementing a reimagined theming system.

Malli: Ambrose Bonnaire-Sergeant

This project (Constraints and Humanization) aims to drastically improve the expressivity of Malli schemas to help address current user feedback and enable future extensions. The basic idea is to add a constraint language to each schema to express fine-grained invariants and then make this constraint language compatible with validators/explainers/generators/etc so that Malli users can write high-level, precise schemas without resorting to partial workarounds. See prototype here: https://github.com/frenchy64/malli/pull/12

SciCloj: Daniel Slutsky

Check out Daniel’s video: https://www.youtube.com/watch?v=WO6mVURUky4. Scicloj is a Clojure group developing a stack of tools & libraries for data science. Alongside the technical challenges, community building has been an essential part of its efforts since the beginning of 2019. Our community-oriented goal is making the existing data-science stack easy to use through the maturing of the Noj library, mentioned below. In particular, we are working on example-based documentation, easy setup, and recommended workflows for common tasks. All these, and the tools to support them, grow organically, driven by real-world use-cases. See updates for progress on Q3 projects and documentation.

Standard Clojure Style:Chris Oakman

Continue work on Standard Clojure Style - which is a “no config, runs everywhere, follows simple rules” formatter for Clojure code. More information about the genesis of the project can be found on Issue #1: https://github.com/oakmac/standard-clojure-style-js/issues/1

clj-nix: José Luis Lafuente

Q3 2024 Report No. 2 (final), Published Nov. 29, 2024

Nix babashka builder

I’ve made some progress with the Babashka builder. The builder should still be considered experimental, and the API may change . It’s now possible to create and override derivations, as well as have interdependencies between different derivations created with the Babashka builder.

I’m particularly happy with the reduction in Nix code. The Babashka builder allows you to create Nix derivations with minimal Nix code. While it might still feel a bit hacky, it’s possible to define Nix dependencies between derivations directly within Clojure code.

On the less positive side, I think it’s currently difficult to reuse some of the build helpers available in Nixpkgs. I definitely don’t want to reimplement all those helpers, so I’ll try to find a way to reuse those Nixpkgs helpers (even if they’re written in Bash) from the Babashka builder.

I also wrote some documentation for it. If you want to know more, see

I also created a repository with some examples, covering four topics:

A basic derivation
An override
How to wrap other programs to capture all runtime dependencies
Dependencies between multiple derivations created with the Babashka builder

Here is the link:

Improvements for clj-nix

While it’s not directly related to this proposal, I’d also like to mention some improvements I made to clj-nix on my own time. These improvements primarily focus on how clj-nix generates lock files.

I’ve also released a new version with these changes:
Release 0.4.0

The Nix Babashka builder is not included in this release (as I believe it’s still too early for a stable release). However, I’ve already merged it into the main branch, making it easier for people to test it out.

Clojure Goes Fast: Oleksandr Yakushev

Q3 2024 Reports No. 2 and 3 (final), Published Oct. 31 and Nov. 30, 2024

Report 2:
During the second month of my Clojurists Together project I published a major update of clj-async-profiler. The new release contains a redesigned and improved profile list page with better UI, convenient sorting, and easy access to diffing functionality. The rest of the time I’ve spent working on the flamegraph sharing webapp that I plan to release into a public betatest at the beginning of the third month. As a bullet list:

Published the release of clj-async-profiler 1.4.0. Big changes:
- New index page design.
- Diffgraph generation functionality accessible from UI.
- Flamegraph rendering fixes - prevent horizontal scrollbar from appearing and the tooltip from clipping near screen borders.
- Stability fix for JDK23.
Wrote a blogpost about 1.4.0 release highlighting the main changes:.
Set up infrastructure, deployment, and proof-of-concept implementation of the flamegraph sharing site. Got very close to the initial public release.

Report 3:
I’ve spent the third month of my Clojureists Together project working primarily on Flamebin — a new web application that allows uploading and sharing flamegraphs. At the beginning of the month I launched it as public beta, and by the end of the November I finally published it as a first stable release. A more detailed report below:

Made a public release of Flamebin
- Set up a public repository
- Created and configured a VPS instance to host the web application
- Configured CI for testing, buildign the application and deploying it to two environemnts (QA and prod)
- Flamebin allows uploading profiles to later render them as flamegraphs:
  - Supports two formats of uploads — collapsed stackframes (compatible with perf, async-profiler, and other profiling tools) and dense profiles.
  - Uploading is possible using a web page or through clj-async-profiler integration.
  - An uploaded profile can either be publicly visible or private. Private uploads are encrypted by a secret read-token that is required for viewing the profile and is not stored on the server.
  - Accidentally uploaded profiles can be deleted by providing a secret edit-token.
- Uploaded flamegraphs have a stable URL that can be viewed by anyone (for public flamegraphs) or only by those with a read-token (for private flamegraphs). The flamegraph renderer is reused from clj-async-profiler. User can explore the flamegraph interactively, change the viewing preferences, and also save those preferences so that other users can open the pre-configured flamegraph later.

I also made two releases of clj-async-profiler — 1.5.0 and 1.5.1 follow-up. These releases unified the approach to flamegraph configuration, enabling different ways to change the configuration:

Specify the configuration before generate a flamegraph, using code.
Save the current configuration (set in UI) to the server for the subsequently generated flamegraphs to inherit.
Copy and paste configuration between different flamegraphs in the UI.
Provide configuration in the URL parameter.
All of the configuration improvements were ported to Flamebin as well.

Finally, I’ve been updating the Clojure Goes Fast knowledge base to cover the new clj-async-profiler and Flamebin features.

Jank: Jeaye Wilkerson

Q3 2024 Report No. 2, Published Nov. 30, 2024

Hi everyone! It’s been a very busy couple of months as I’ve been developing jank’s LLVM IR generation, improving jank’s semantic analysis, and furthering jank’s module loading system. Thank you to all of my Github sponsors and to Clojurists Together, who help me pay the bills. As of January 2025, I’ll be working on jank full-time and every new sponsor means that much more. Without further ado, let’s dive into the details of the past couple of months.

LLVM IR

The main focus of the past couple of months has been filling out jank’s LLVM IR generation. This has required further improving some of its semantic analysis since I was previously able to cut some corners when generating C++ code.

At this point, all AST nodes in jank have working and tested IR generation except for try, since doing so requires hooking into the C++ runtime’s unwind mechanism and I’ve been saving that rabbit hole for last.

IR generation has caused so many fun bugs the past couple of months that I had to look into a better way of organizing my notes for this quarter. There was just too much. When developing a language, especially in a pre-alpha stage like jank, when something crashes or is otherwise completely wrong, the issue could be anywhere from lexing to parsing to semantic analysis to code generation to object modeling to core function algorithms to data structures. I think there were some of each discovered in the past couple of months, but the majority of them were in the new IR generation.

Named recursion

One of the fun bugs I ran into was with how Clojure handles recursion through the function’s own name. This doesn’t go through the var; it just references the function object directly. The same applies with just a self-reference. For example:

(fn foo []
  foo)

(defn foo []
  foo)

In Clojure, and in jank with C++ generation, each function is an object (struct or class). A self-reference can literally just mean this. But with the LLVM IR generation, each function, and more specifically each function arity, is compiled to a dedicated C function. Aside from closures, which get an implicit first argument which is a generated struct of the captured values, the function itself has no other identifying state or object. This means a self-reference actually needs to build a new object. Previously, I would always just generate a local into each function like so:

auto const foo{ this };

Then I would register that local automatically during semantic analysis for functions. A self-reference would then just be a local_reference AST node. This can’t carry over well to IR generation, so I’ve added two new AST nodes:

recursion_reference, which is created when we analyze that we’re referring to the current function by name somewhere
named_recursion, which is created when we’re analyzing a call and find that the source expression is a recursion_reference

This does mean that a self-reference within a function wouldn’t be identical? to the invoking object, but that’s something we can document and otherwise really not care about.

Startup performance

Ultimately, the main reason for generating LLVM IR is that C++ is too slow to compile. If compiling clojure.core means generating 100K lines of C++ to compile, we end up waiting far too long for jank to start up. On my machine, it took around 12 seconds.

Now, with IR generation, and a lot more functionality baked into jank itself, rather than JIT compiled, compiling clojure.core from source takes only 2 seconds. This is fast enough to where we can easily include it as part of jank’s build system. We can then pre-compile the sources to binaries and load those instead.

When I tried this with C++ generation, it took 4 minutes to compile all of the C++ generated for clojure.core into a C++20 module with a backing shared library. It then took 300ms to load at runtime, which dropped the start time from 12 seconds to 300ms. That AOT compilation cost was huge, but the gain was also big.

With IR generation, we can also generate object files. Amazingly, it can be done within the same 2 seconds used to compile clojure.core in the first place. When loading that object file at runtime, jank can now start up in 150ms. So, we spend a fraction of the time actually compiling the code and even less time loading it. Overall, for startup performance, LLVM IR has been a huge win. This is exactly what I wanted and I’m very pleased with the results.

Note, when all of this is baked into the executable AOT, startup time is around 50ms. jank doesn’t support AOT compilation of full programs yet, but I’ve manually added the object files to jank’s CMake build in order to test this out. Once we do have AOT compilation to binaries, we can also add direct linking, link-time optimizations (LTO), etc. and drop these numbers down even further.

Runtime performance

Runtime performance will be negatively impacted by IR generation, at least to start. The C++ code jank used to generate was quite optimized. I was taking advantage of various C++ features, like function overloading, type inference, and easy (yet ambiguous) unboxing of numerical values. With IR gen, we need to do all of those manually, rather than rely on a C++ compiler to help. This will take more work, but it also allows us to tailor the optimizations to best fit jank.

I’m not ready to report any benchmark results for runtime performance differences yet, since I don’t think measuring the initial IR generation against the previous C++ generation is a good usage of time. Optimizing IR can happen as we go, without breaking any ABI compatibility. I’m more focused on getting jank released right now.

Build system and portability improvements

Apart from working on LLVM IR generation the past couple of months, I’ve put a fair amount of time into improving jank’s builds system and dependency management. In particular, vcpkg has been removed entirely. I was using vcpkg to bring in some C and C++ source dependencies, but some of them regularly fail to build from source on very normal setups and vcpkg on its own causes issues with build systems such as Nix. Altogether, it’s well known that the build system and dependency tooling for C and C++ is terrible. While I aim for jank to improve that, in its own way, we still need to suffer through it for the compiler itself.

In order to remove vcpkg, I had to address all of the dependencies it was pulling in.

bdwgc (Boehm GC) requires compilation
- Added a submodule and hooked into CMake
- Required a PR for CMake compatibility
fmt requires compilation
- Added a submodule and hooked into CMake
libzipp requires compilation
- Added a submodule and hooked into CMake
immer is header-only
- Added a submodule
magic_enum is header-only
- Added a submodule
cli11 is header-only
- Added a submodule
doctest is in all major package repos
boost is in all major package repos
- boost::preprocessor isn’t found by CMake on Ubuntu, but it’s there
  - Doesn’t exist in brew’s package, though
  - Had to add as a submodule
- Causes Clang to crash while building incremental.pch

All in all, this required seven new git submodules. Even something as commonplace as boost led to dependency issues across various platforms. I did all of my testing on Ubuntu, Arch, NixOS, and macOS. Once I had all of those submodules, I still ran into some issues with Clang hard crashing while trying to compile an incremental pre-compiled header (PCH) with boost. This was the final straw with PCHs for me.

Pre-compiled headers

jank started out with PCHs from the beginning. I was concerned about compile-times and I knew that many source files would need access to the whole object model in order to compile. While this remains true, I didn’t expect that PCHs would be such a headache when JIT compiling C++. There have been a handful of Cling bugs and then Clang bugs related to loading PCHs into the incremental C++ environment. I’ve spent entire days compiling Clang/LLVM while bisecting in order to find root causes. Haruki has been so close to building jank on Nix but has been running into issues when compiling the incremental PCH. This has been a long time coming.

After removing the PCHs, fixing all source files to include what they need, refactoring some heavy headers so they can be used less often, and running some tooling to further clean things up, we can wipe our hands of all of that. jank does still need to JIT compile C++ code, but it can do so using both a C API and a C++ API. Devs using jank can include what they need.

Previously, just loading the incremental PCH with all of jank’s headers took a whopping 2.5 seconds every start up and we always paid that cost. Now, better following the (intended) nature of C++, we can pay for what we use.

Community update

I have not been the only one working on jank. The past couple of months, my newest mentee through the SciCloj mentorship program, Monty Bichouna, has wrapped up Unicode lexing support. This allows jank the important ability to properly represent Unicode symbols and keywords. Monty’s work builds on Saket’s recent work to add Unicode support for character objects.

To further jank’s interop story, Saket Patel also recently merged some changes which allow jank to accept include paths, linker paths, and linked shared libraries. This means that you can now include other C and C++ libraries from your JIT compiled bridge code and have the JIT linker resolve those symbols in your libraries. In other words, it’s now possible to use jank to wrap arbitrary C and C++ libraries. Saket took this further by adding an opaque pointer wrapper object which can store any non-owned native pointer to be passed through any jank function and stored in any jank data structure. Each of these is a small step toward a much richer interop story. Saket also added persistent history to jank’s CLI REPL and improved its usability by hooking into LLVM’s line editing capabilities.

Jianling Zhong added support for ratio objects in jank, including the whole polymorphic math treatment necessary for them. He also implemented jank’s delay object and corresponding clojure.core/delay macro as well as jank’s repeat object, which backs the clojure.core/repeat function.

Finally, Paula Gearon has been making excellent progress on a sister project to jank, clojure.core-test, which is a cross-dialect test suite for all of clojure.core. Ultimately, my goal with this is to aid Clojure dialect developers by providing a thorough test suite for Clojure’s core functions. By being able to run and pass this suite, my confidence in jank will be strong. I’m sure other dialect developers will feel similarly.

What’s next?

I need to fix a couple remaining bugs with the LLVM IR generation and then implement IR generation for try nodes, in the next couple of weeks. After that, the next big goal is error reporting. This is an exciting task to tackle, since the impact of it is going to feel so rewarding. I have been suffering jank’s terrible error messages for years. Even worse, we as an industry have been suffering terrible error messages for decades. There’s been some exciting progress in Elm, Rust, etc for improving the way errors are reported, providing actionable feedback, and including sufficient context to make errors less cryptic. I don’t think that Clojure does well in this area, currently, and I aim to raise the bar.

If that sounds interesting, stay tuned for my next update!

Kushi: Jeremiah Coyle

Q3 2024 Report No. 2 (final), Published Nov. 30, 2024

Q3 Milestones

Thanks to the funding from Clojurists Together, the Q3 development of Kushi pursued the following 3 milestones:

Finishing the new css transpilation API.
Reimplementing the build system for enhanced performance.
A reimagined theming system.

Progress

Milestone #1: Finishing the new css transpilation API.

Goals
1. Solidify the API design and implementation of Kushi’s CSS transpilation functionality.
2. Incorporate the use of lightingcss for CSS transformation (older browsers) and minification.
3. Refactor existing public functions for injecting stylesheets, google fonts, etc.
Progress: Complete on branch new-build-system. The majority of the time spent working on Kushi in the first half of the funding period was focused on implementing a new CSS transpilation pipeline. An updated set of public macros and supporting functions was designed and implemented around this. A broad test suite was written, which consists of 7 tests containing 54 assertions. Additional refinement of the implementation was done during the course of realizing milestone #2. Updated documentation of this API is reflected in the README.md on this branch.
Next steps: Continue to test this new API by upgrading existing UI work (such as Kushi’s interactive documentation site) that uses the current (soon to be previous) API, then adjust and refine implementation details as necessary.

Milestone #2: Reimplementing the build system for enhanced performance.

Goal: Reimplement the build system for performance, and eliminate the use of side-effecting macros.
Progress: Complete on branch new-build-system
Next steps:
- Support the use of the new version of the sx macro.
- Adopt new conventions to Kushi documentation site source.
- Merge this work into main branch.

Milestone #3: A reimagined theming system.

Goal: Based on learnings from using Kushi to build a lot of production UI over that last 2-3 years, redesign and implement a new theming system. This will involve harmonizing 3 principled subsystems:
1. Design tokens (a global system of CSS custom properties).
2. Utility classes.
3. Component-level data-attribute conventions.
Progress: 80% complete implementation on branch oklch.
Next steps: .
- Refine syntactical conventions of data- attributes
- Reconcile new (oklch) and legacy (hsl) color system, with realistic backwards compatibility
- After merging new-build-system branch into main branch, adopt new conventions to Kushi documentation site source.
- Merget this work into main branch

Malli: Ambrose Bonnaire-Sergeant

Q3 2024 Report No. 2, Published Nov. 30, 2024

This is the second report of three in the project to extend Malli with constraints. [Report 1] is here. (https://www.clojuriststogether.org/news/sept.-and-oct.-2024-short-term-project-updates/#malli-ambrose-bonnaire-sergeant)

Background

In this project, I proposed to extend the runtime verification library Malli with constraints with the goal of making the library more expressive and powerful.

With this addition, schemas can be extended with extra invariants (constraints) that must be satisfied for the schema to be satisfied. Anyone can add a constraint to a schema. Crucially, these extensions should work as seamlessly as if the author of the schema added it themselves.

Progress

I finished my prototype porting existing :min/:max schema properties to a new “constraint” framework. This seems like a useful framework in general but I’m not fully convinced it’s the simplest solution to having more expressive :map keyset constraints.

I spent the rest of the month iterating and reviewing various design decisions.

First I learnt how cljs bundle size works, and refactored the constraint to live in malli.core while still being removable from the cljs bundle. This simplified a few things, but at this point I reviewed my notes and started pulling apart the solution by the problems they solved.

This constraints project was inspired as a “big” solution to multiple problems:

:map keyset constraints are not expressive enough, forcing use of :fn schemas
:and and :not generators are not reliable enough for complex keyset constraints
humanization for :not, :and and :or errors are too confusing for complex keyset constraints

If all of these problems were solved, we could possibly avoid changing :map constraints at all and just add one new schema [:contains k] that tests #(contains? % k).
A schema like this could be used for a map that either has :secret or both :user and :pass:

[:and [:map
       [:secret {:optional true} :string]
       [:user {:optional true} :string]
       [:pass {:optional true} :string]]
      [:or
       [:and
        [:contains :secret]
        [:not [:contains :user]]
        [:not [:contains :password]]]
       [:and 
        [:not [:contains :secret]]
        [:contains :user]
        [:contains :pass]]]]

My thinking is, if we can make m/explain and mg/generate work with this kind of schema, we could reapply those insights to other schema transformations like OpenAPI or JSON Schema and perhaps move away from monolithic schemas like :map which accumulate features (::m/default, :min, :max, :optional) and instead decomplect their features into independent repurposable schemas that can be combined with composite schemas like :and and :or without compromising performance or expressivity.

My prototype for this idea introduces a new namespace malli.solver that transforms schemas into descriptions of all the values they represent. By rewriting the :and generator to propagate extra information to the first schema conjunct from the other conjuncts, we could, for example have a schema like [:and :string [:min-count 10]] generate identically to [:string {:min 10}] by utilizing the extra information in the :string generator. Perhaps the latter could even m/deref to the former, which starts to look very similar to my original “constraint” solution where schemas contain other schemas at the same “level”, without extra machinery.

Here’s a list of some of the directions I’ve worked on in the last few months:

min/max constraints
- finish constraints for schemas supporting :min/:max properties:
  - :int, :double, :float, :string, :vector, :sequential, :seqable, :set`
min/max constraints by default
- like previous work, but move constraints to malli.core
- can disable constraints via system property to preserve cljs bundle size
opened issues
merged pr’s
- Require generator for :gen/fmap
- only assume string interning in cljs
wip
- reliable :and generator
  - includes new namespace malli.solver which turns schemas in to maps describing values they represent
  - includes three demonstrated usages:
    - malli.generator: new :and generator that never guesses
      - e.g., these always succeed to generate values
        
        [:and [:>= 2] [:<= 2]]
        
        [:and [:<= 3] [:fn {:gen/schema :int} int?]]
      - better error message for unsolvable schemas:
        
        e.g., [:and :int [:>= 1.5] [:<= 1.5]] => Exception: :malli.generator/unsatisfiable-schema
    - malli.optimize: faster version of m/validate
      - e.g., checks [:map [:a :int] [::m/default [:map-of :int :int]]] in single pass, checks map? once
    - malli.simplify: simplifies schemas
      - e.g., [:and number? [:<= 10] [:<= 20] [:<= 30]] => [:and number? [:<= 10]])
  - includes new schema [:contains k] that checks if :k key exists
    - next: connect with generator to reliably generate schemas like:
      - [:and [:map] [:or [:contains :secret] [:and [:contains :user] [:contains :password]]]]
    - next: humanizer for [:not [:contains k]] (pr below)
- rewrite malli.generator and fix bugs
  - ~20% shorter
proposed pr’s
- :not humanizer
  - relevant so [:not [:contains k]] can be explained

I’m going to see if decomplecting the constraints solution is actually usable in practice and propose various smaller improvements to malli based on my experience so far.

SciCloj: Daniel Slutsky

Q3 2024 Report No. 2, Published Nov. 3, 2024

The Clojurists Together organisation has decided to sponsor Scicloj community building for Q3 2024, as a project by Daniel Slutsky. This is the second time the project is selected this year. Here is Daniel’s update for October. and a video providing insights on the project.. Comments and ideas would help. :pray:

Update for October 2024

Scicloj is a Clojure group developing a stack of tools and libraries for data science. Alongside the technical challenges, community building has been an essential part of its efforts since the beginning of 2019. Our current main community-oriented goal is making the existing data-science stack easy to use through the maturing of the Noj library, mentioned below. In particular, we are working on example-based documentation, easy setup, and recommended workflows for common tasks.

All these, and the tools to support them, grow organically, driven by real-world use cases.

I serve as a community organizer at Scicloj, and this project was accepted for Clojurists Together funding in 2024 Q1 & Q3. I also receive regular funding through Github Sponsors, mostly from Nubank.

In this post, I am reporting on my involvement during October 2024, as well as the proposed goals for October. I had 57 meetings during September. Most of them were one-on-one meetings for open-source mentoring or similar contexts. All the projects mentioned below are done in collaboration with others. I will mention at least a few of the people involved. For consistency, I use people’s github handles when mentioning their work on the projects, and their full names when mentioning public talks.

October 2024 highlights

Scicloj open-source mentoring

This month, we contined working with mentees under the open-source mentoring program.

@generatme, @phronmophobic, @jeaye, and myself have been active as mentors this month. Since the program’s beginning at the middle of August, 62 people have applied – 15 of them during the last month. 39 are still actively exploring various topics, and out of them, 15 have already made important contributions.

One notable change happened during the last few months: we started working with a few mentees who are completely new to Clojure, some even to programming. This is part of Scicloj’s gradual process of opening up to broader audiences.

Some of the recent experiences and insights on this project were discussed in our recent video report (2024-10-25).

Noj

The Noj library is the entry point to data science with Clojure, collecting a stack of relevant libraries. This month, we worked towards its release into Beta stage, which is almost complete.

At the Zulip chat, we had quite a few insightful discussions with important feedback by community members about the scope and the organization of the project.

Most of our efforts in this project have been into writing additional tutorials. A broad group of people are working on these, and a few promosing tutorials are currently in draft stage. See some details below in the Tutorials section.

@behrica has made additional improvements to the automation and whole workflow of Noj in Github Pages.

I worked on clarifying many details and improving the main documentation pages.

Tableplot (previously called Hanamicloth)

Towards reaching Beta stage, our acively-developed plotting library recieved a new name: Tableplot.

I continued working on extending its features, adding flexibility to the way data can be specified throughout the pipelines, and integrating metamorph.ml to allow for a more flexible smoothing functionality, where the user can specify the model details and the design matrix.

Composing Fastmath with Tablecloth

During this month, a few substantial design discussions took place in the Zulip chat, with quite a few community members helping with their insights. One of the important realizations was that we should integrate Fastmath (the math library) into Tablecloth (the user-friendly table-processing library). This will allow for better composability, ergonomics, and performance in various cases where data processing meets math and statistics.

Scittle Emmy-viewers plugin

Recently, @reedho has made some progress in the Scittle plugin that supports Emmy-viewers data visualizations. I was helping in testing and figuring out some of the details. This progress is expected to extend the reach of Emmy-viewers to a broader set of use cases and integrate it better into Scicloj workflows.

Clay

Clay, the REPL-friendly notebook and data visualation tool, recieved a few new features:

initial Emmy-viewers support
support for nesting of special visualization kinds
support for live-reload on file save by @whatacold

Additionally, @a13 and I are working on improving the process of reading Clojure code, building on previous work by @timothypratley at the read-kinds project.

Kindly-advice

Kindly-advice is a small library that helps tools know how certain values should be visualized.

Following the developments with Emmy-viewers, it can now recognize these automatically, so that tools can handle them appropriately.

Kindly-render

Kindly-render is a tool-agnosic implementation of the Kindly standard.

During October, @timothypratley and @kpassapk kept working on this project. I started exploring its intergation into Clay.

Tutorials

Documenting and demonstrating the use of the Scicloj stack is one of the main goals at the moment, and quite a few of us are working on various tutorials. This is often a slow process that involved introspection and discussion of the recommended ways to explain certain notions and perform certain tasks.

I was involved in writing some tutorials and in reviewing a few others.

A few of the current drafts people have been working on can already be shared:

intro to probability and statistics by @mavbozo
intro to linear algebra with Fastmath by @radovanne
2d and 3d geometry with Fastmath by @radovanne and @Epidiah
intro to datavis with Apache Echarts by @zuzhi and @whatacold
analysing Chicago bike times by myself
Bayesian statistics with PyMC by myself

Website

This month has been a usual month in terms of website maintenance.

real-world-data group

The real-world-data group is a space for Clojure data practitioners to share their experiences. During October, the group had two meetings. We decided to share some parts of the recordings publicly:

Oct 4th 2024 - meeting 15:
- Kyle Passarelli: OAuth2 with Clojure and Temporal
- Adham Omram: Experience Conducting a Clojure Training
Oct 16th 2024 - meeting 16:
- Jarkko Saltiola: tools for pipelines, bb-glitchtip

Scicloj weekly catchup

During October, we tried the approach of weekly group meetings for the open-source-mentoring program, in addition to the small and 1-1 meetings.

We had four group meetings of this kind. A few people have shared their work, and we explored some topics as a group. Eventually, we realized that the timing and format were not optimal for most people, so this series is currently on hold.

Linear Algebra meetings

A few of use are working on tutorials related to linear algebra and vector processing, and have started meeting weekly on these topics. We had four meetings of this kind.

Clojure Conj

Eventually, we organized only one talk run before the Clojure Conj conference. This was an early run of the talk by Thomas Clark. The actual talk has already been published online. It is a fantastic overview of the Clojure stack for scientific computing.

On my side, I helped a little bit in the preparations for the talk.

November 2024 goals

Noj

Annouce Beta stage.
Continue the current efforts on documenting the libraries.

Fastmath

Continue the documetation effort.

Tablecloth

Start working on drafts integrating Fastmath-related functionality.

Tableplot

Annouce Beta stage after a minor changes.
Keep extending and documenting the library.

Tooling

Return to the work on kindly-render.
Explore improving the support of various tools for scientific Clojure. Most importantly: VSCode, Quarto, and Jupyter.
Continue Clay maintenance.

Standard Clojure Style: Chris Oakman

Q3 2024 Report No. 2 (final), Published Dec. 3, 2024

Standard Clojure Style is a project to create a “follows simple rules, no config, runs everywhere” formatter for Clojure code.

tl;dr

[Clojure/conj talk] was well received
[Standard Clojure Style is available in Lua] 🌙
several bugs found and fixed - thank you testers!
try it online here

Update

I gave a 10-minute introduction and demo of Standard Clojure Style at Clojure/conj 2024
- you can watch the talk online here
- the talk and project were well-received
- thank you to everyone who said Hello and shared feedback 😁
Standard Clojure Style is available as a single-file Lua library
- hopefully this opens the door for more editor integrations
- I am seeking an aspirational Neovim user to help make a Standard Clojure Style plugin 🤓
As of [v0.18.0], Standard Clojure Style is ready for most codebases
- you can try it online here (no purchase necessary 😜)
- Give it a try on your codebase!
Thank you to all the testers who ran Standard Clojure Style on your codebase and reported bugs 🙌
- If you want to help test, please see the instructions [in the README]

Next Up

road to 1.0.0
- I want to stabilize the algorithm and release a v1.0.0
- the target goal for this is in the next few months
- here is the [punchlist of issues] currently blocking that release
documentation and website are still needed
- I would like to create a website for the project in order to socialize the idea and be a reference for teams who are deciding to to adopt a formatter tool

Thank you!

Thank you to Clojurists Together for the funding and everyone who has contributed kind words and encouragement for this project. Your support is greatly appreciated ♥️

More resources: Clojure/conj talk
Standard Clojure Style is available in Lua
in the README
v0.18.0 punchlist of issues

Vote on 2025 Long-Term Funding Applications

Mon, 25 Nov 2024 14:00:00 +1200

Greetings Clojurists Together Members! This year, we are trying a new process to determine who will receive a monthly stipend of $1,500 to support their development work.

We put out the call - and we received 18 thoughtful applications for you to consider. You can also review past long-term project updates on our website to get an idea of what past long-term grant recipients have been able to accomplish with your past support (pretty amazing!)

Please review the applications below and select 5 developers to receive funding in 2025. Be on the lookout for an email that contains the link to your Ranked Vote ballot. Here we go ..in alphabetical order (by last name)….

Deadline for your vote to be counted: December 4, 2024 Midnight Pacific Time

-Michiel Borkent
-Thomas Clark
-Jeremiah Coyle
-Toby Crawley
-Eric Dallo
-Rafal Dittwald
-Dragan Djuric
-Robert Gersak
-Kira Howe (McLean)
-Roman Liutikov
-Mateusz Mazurczak and Anthony Caumond
-Jack Rusher
-Daniel Slutsky
-Adrian Smith
-Peter Strömberg
-Dan Sutton
-Peter Taoussanis
-Oleksandr Yakushev

Michiel Borkent

https://github.com/borkdude

What do you plan to work on throughout the year? My main projects are clj-kondo, babashka / SCI, and squint/cherry. I will develop new features, specified below per project. As usual I’ll also work on ongoing maintenance and offering support on Slack and Github.

Links: clj-kondo, babashka, SCI, squint

Clj-kondo

Linter for partially extended protocols
Extend :discouraged-var to allow specifying arities
Ongoing maintenance, there’s always plenty to do! See the project board and see here for a list of most upvoted issues
Experiment with adding the notion of a project classpath such that command line linting becomes easier. Possibly configurations could be read from the classpath as well.
As clj-kondo is the foundation for the static analysis in clojure-lsp: improvements in the interaction between the two, most specifically the analysis data.

Babashka / SCI

Maintenance of included bb libraries: SCI, babashka.fs, babashka.process, deps.clj, babashka.http-client, edamame
Babashka tasks: prefix parallel prcoess output such that you can distuingish tasks
Better error locations for clojure.test output (https://github.com/babashka/babashka/issues/1518)
Report exception causes in console error report (https://github.com/babashka/babashka/issues/1515)
Several other issues: https://github.com/babashka/babashka/issues

Squint (and cherry)

Browser REPL support
Source map support (some work has been done, but far from finished)
Increase overall compatibility with CLJS
Support dependencies from the ClojureScript ecosystem from clojars and git depsAll other related projects
Nbb, jet, scittle, neil, edamame, rewrite-edn, carve

Why is this work important to the Clojure community? Babashka is used by 90% of Clojure Survey respondents as shown in Alex Miller’s Conj 2024 talk. Babashka and clj-kondo have 4.1k and 1.7k stars on Github respectively, their slack channel on Clojurians have almost 1800 + 1000 users. Clj-kondo and babashka are used by a large portion of the community. I think it’s fair to say they are established project.

Is there anything else you would like us to know? Thank you so much for Clojurists Together and keeping the Clojure OSS ecosystem sustainable!

Thomas Clark

https://clojurians.zulipchat.com/#user/386018

What do you plan to work on throughout the year? In a nutshell, my plan would be to help expand Clojure’s scientific ecosystem, particularly in regards to the mathematical sciences. This would take the form of developing and creating libraries, continuing and creating documentation and to initiate a serious attempt at academic outreach.

Libraries

Wolframite

Last year, CT supported Jakub Holy and I for a quarter in our attempt to resurrect and document the Wofram-Clojure bridge. We’re very happy with the progress we made in this time, but of course there are many other things that could (and should?) be done - we really feel like we’re just getting started. In particular, a key feature of Wolframite, that is missing in Wolfram itself, is the REPL experience.

In this, we want to fully integrate Wolframite with Clojure’s visual tools for all manner of datatypes that Wolfram supports. And in particular, to make data passing and memory management efficient. More functionally, we want to create a special viewer for symbolic expressions, that not only allows the user to copy and switch between maths in Wolfram, LisP and TeX forms but that automatically generates sliders for each parameter for exploration, as inspired by Wolfram’s Manipulate function.

exp (name to be decided)

In Clojure, there are now two libraries to interact with symbolic expressions and this new project would seek to integrate them: both Wolframite and Emmy. This would be powerful because although Emmy brings symbolic manipulation to Clojure and Clojurescript simultaneously, it is still missing many key features and algorithms that only Wolfram can provide. One can then imagine a situation where mathematical problems could be defined and explored in the browser (Emmy), passed to the server to be simplified algebraically (Wolframite) and then crunched numerically (Emmy).

Not only would this bridge two existing libraries but it might even lay the foundation for developing a standard for representing equations more generally.

SciCloj

More generally, there are many SciCloj libraries that I have been involved with and so with funding I would happily step up my contributions.

I can particularly see a lot of scope in the further development of Clay. I have particular notions regarding it’s use for generating presentations and can imagine creating a specific API around this purpose. I can also imagine it being the first visual tool with which I could create the special equation viewer mentioned above.

Also in regards to tableplot. Specifically, I would like to be involved in its generalization to deal with 3D plotting as I have a lot of specific use cases in this area.

Another area of interest at the moment is in improving the SciCloj API for working with common matrix operations (specifically the generation and manipulation of Hadamard-like matrices). This is an open area and it’s not clear whether this will be abstracted into a separate library or wheter this would be an extension of dtype-next.

Documentation

Another big area of focus would be improving SciCloj documentation, at both the library and project level.

Libraries

Putting aside the libraries that I have contributed code to, there are many SciCloj libraries that I use that I would be happy to contribute documentation. A bridging example would be regarding a Clojure-Blender bridge. Although I started to develop a new library for this, basilisp-blender has emerged as potentially a stronger candidate and so I would like to make detailed tutorial examples of creating ‘scientific’ outputs using this.

Projects

As discovered while writing the Wolframite documentation what is often needed is not so much a manual but examples of how to use the tool (or how to integrate many tools) in a real project. With this in mind, I would like to document the overall process of how to use the ecosystem to solve real problems, supplying both real problems and real solutions, e.g. the source and details behind my past talk and large contributions to noj.

Outreach

Outside of building library bridges to Clojure for specialist academic projects as well as collecting SciCloj talk sources in a centralised location, I would make a concerted effort to reach out to non-Clojure scientists about the benefits of Clojure.

Where I might have an advantage here is that I am a scientist before I am a programmer and so have direct connections into a world where very few people have heard of the language. With funding (see the biases section for why) I could potentially give department seminars at different institutions as well as international and online conferences: using existing academic contacts.

Furthermore, something that I am particularly excited about, I have started to initiate a grouping of research-minded Clojurians to consider publishing papers in the field. With the right support, I think this could really help raise awareness.

Why is this work important to the Clojure community?
I guess I should really have checked the following questions before filling up the previous box… :)

In regards to library creation and expansion, I think that scientific computing is an exciting growth area for Clojure. It is an area that really benefits from Clojure’s key principles and one that already has a growing number of users: users who will benefit from the changes. It is also an area that is at a tipping point in regards to reaching practical parity with other key languages and the tools that I would like to focus on are not so much now about matching competitors, but rather about providing new features and features that lead towards a completely integrated ecosystem: something that I would like to find, no matter which language provided it!

The Emmy system in particular is bringing open-source symbolic computation to both the back- and front-ends but it is missing key features and advanced libraries. A Wolfram-Emmy bridge could serve as a sure foundation and help create the real possibility of an almost unique physics programming space.

This work would also be important in regards to expanding the community itself. Following on from above, there is a large section of the numerical scientific community who are not programmers but who rely on tools like Mathematica and Matlab and so interop in these areas will be crucial for community cross-over in the future. Generalized language interop is particularly important for safe onboarding of new users and experience suggests that there is a willing ‘market’ for integrating specialist tools within more comfortable general languages like Clojure.

Beyond this however, the interactive development and documentation experience that is available now is a solution that simply needs to be shown to scientists' problems. The proposal to organise academic publishing and presentation of what the Clojure experience is like feels like an important stepping stone to the future.

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate?
Depending on what you mean by ‘systemic bias’, my disadvantage is a classical one. Living in eastern Europe and working in the public sector, I suspect my Clojure friends would be shocked at what is paid to scientists here. I don’t pretend that Hungary is as cash-strapped as some other continental countries, but compared to most other countries in ‘the west’, even those a two hour drive away, the salaries are low. If it helps, I can be more specific, but suffice it to say that this funding would go much further here and would enable a much bigger shift in what I’m able to contribute than it would for many other applicants.

Jeremiah Coyle

https://github.com/paintparty

What do you plan to work on throughout the year?
These are the 5 projects that I am planning to work on throughout the year :) All are fairly mature alpha-stage projects. Kushi and Fireworks have already been announced. I plan to announce the latest Fireworks release, and the other 3, over the next few weeks.

#1 - Kushi

Kushi is a base for building web UI with ClojureScript.

Goals for Kushi in 2025:

Universal transpiler for kushi UI components to automatically generate components for established ClojureScript UI Rendering frameworks such as Uix, Helix, Biff, shadow-grove, etc.
Add a quickstart repo for each supported framework Uix, Helix, Biff, shadow-grove etc., with a deluxe todo-mvp/kitchen sink example set to make it very easy to cut and paste working UI.
Browser-based interactive design tweaking, with round trip to file system.
Add more functionality, docs, and examples for working with the kushi.playground namespace. This gives the user a very elegant way to build their own white-labeled interactive documentation site that features Kushi’s components as well as any custom components specific to their project. It is similar to Storybook.js or Portfolio (cjohansen/portfolio). The playground namespace was used to create the current project website at kushi.design.
Design and implement 4-5 global themes, using a variety of styles. In order to show off the power of the new theming system, I would like to add at least a couple very playful themes (sci-fi, fantasy-rpg) and incorporate them via a theme switcher into the kushi.design site.
Add additional ui library components. Components followed by an asterisk are internally complete and just need to be turned into public functions with documentation:
- Avatar*
- Tabs*
- Blockquote
- Treeviewer
- Carousel
- Dropdown menu
- Context menu (right-click)
- Table
- Data List
- More card layouts (with inset margins)
- Keyboard input / hotkey e.g. ⌘ C styled as button
- Aspect Ratio (displays content within a desired ratio)
- Wrapper for native color picker input

#2 Domo

Domo is a modern ClojureScript DOM utility library.

Goals for Domo in 2025:

Curate the current API of approximately 75 public functions
Write docstrings for all public functions
Add simple validation and dev-time warnings for all public functions
Figure out best approach for automated test suite
Leverage kushi.playground to create interactive documentation

#3 - Fireworks

Fireworks is a themeable tapping library and color pretty-printing engine.

Goals for Fireworks in 2025:

Solidify current public API
Address all 12 current issues (mostly enhancements)
Publish editor plugins/extensions for Emacs and VS Code. These are fairly simple extensions that just involve some basic clj-rewrite functionality for wrapping/unwrapping forms. I’ve already created initial working versions of both (emacs and VSCode) locally.
Produce written and/or video documentation of my current live hot-reloading dev environment for JVM Clojure, with versions for both Leiningen and Deps. I recently issued a PR to add this to test-refresh. This sort of thing could also potentially be incorporated into other similar projects such as metabase/hawk and tonsky/clj-reload.
For ClojureScript developers using Fireworks in a browser dev console, I went off the deep-end and made a dedicated Chrome extension to enable the setting of the Chrome DevTools console background and foreground color with a very nice GUI interface. Would be cool to get this working in most other Chromium-based browsers, and potentially Firefox, if there is any demand for it.
https://github.com/paintparty/fireworks?tab=readme-ov-file#setting-the-background-color-and-font-in-chrome-devtools-clojurescript

#4 - Bling

Bling is a library for rich text in the console

Goals for Bling in 2025:

Support automatic detection of the 3 levels of color support (16-color, 256-color, or Truecolor), using an approach similar to https://github.com/chalk/supports-color
Support arbitrary hex colors, and their conversion, if necessary, to 256. I’ve already created an efficient Manhattan distance algorithm for doing this conversion in Fireworks
Create more formatting templates for callouts, headers, and points-of-interest
Add documentation about how to leverage Bling to create great-looking warnings and errors in any project. Example of using bling’s templates to create nice warnings can be found here:
Add documentation about using Bling in conjunction with existing libraries which format Spec and Malli messages into human readable form.
Although lower priority, it would be fun to explore enhancing the flexibility and utility of bling.core/stack-trace-preview, and exposing it as a public function, as it may be a cheap way to get give some additional context to many kinds of error messages.

#5 Lasertag

Lasertag is a utility for categorizing types of values in Clojure, ClojureScript, and Babaskha.

Goals for Lasertag in 2025:

Solidify current public API
Extensive coverage for all Java and Javascript types/classes
Extensive test suite for all types and classes
Leverage kushi.playground to make cool demo for usage in ClojureScript

Why is this work important to the Clojure community?
I believe work on these projects could benefit the Clojure community for the following reasons (listed out project-by-project):

#1 - Kushi
Kushi aims to provide a complete solution to the design layer of web UI projects.

It is an ambitious project, but I believe there is an opportunity for Kushi to offer a UI dev experience that is unique and more compelling than any equivalent in any other language. This could lead to increased organizational awareness and consideration of ClojureScript as an attractive choice for building mission-critical UI. If more companies used ClojureScript to build UI, I think it would be very beneficial for the community.

#2 - Domo
This lib has been slow-cooking over a couple years to serve various web projects, including Kushi.

The syntax is very Clojure-y, and feels much nicer than writing gnarly JS interop code. To my knowledge, there are only a few ClojureScript DOM libs (Dommy, Enlive, Enfocus), and all were written 9-10 years ago.

Compared to these libs, Domo offers even more specific functionality such as:

copy-to-clipboard
Getting viewport information
Geometry for elements
Getting screen quadrant for element or event
Attribute querying and manipulation
Computed styles of elements
Adding, removing, and toggling attributes and classes
Optional zipper-like syntax for selecting elements
matches-media? helpers
a11y-friendly on-mouse-down helper (faster alternative to on-click)
Helper for keyboard-based tab navigation
& much more!

#3 - Fireworks

Fireworks is the only lib to provide a colorizing and themeable pretty-printer that works beautifully in both Clojure and ClojureScript (and Babashka).

The library also provides very powerful debugging and tapping macros. These macros provide a lightweight complement to discovery-centric, UI-heavy data exploration tools such as Portal and Flowstorm. With a simple hot-reloading setup (in clj or cljs), and minimal editor integration, Fireworks can drive an extremely compelling live-feedback dev experience without any reliance on a repl connection, or repl-related concepts. I think the continued codification, documentation, and demonstration of such a workflow could make a difference in bringing new people to Clojure. The maturation of this kind of workflow could also benefit existing users of community tools such as playback, debux, hashp, telemere, ken, spyscope, omni-trace, postmortem, and sayid.

#4 - Bling

Many mature language communities have a library for rich text printing in the terminal, for example Rich (Python), Chalk (JS), LipGloss (Go), etc.

With Clojure, the main existing option seems to be org.clj-commons/pretty. The original impetus for creating Bling came out of my experience of trying to use this lib extensively for formatting error and warning messages.

The most unique thing that Bling offers is a carefully curated palette of 11 basic colors which are readable on both light and dark backgrounds. Because these colors are located in the 16-255 ansi range, they are guaranteed to look the same on almost any terminal, regardless of the user’s theme. Most libraries leave the colorizing up to the user’s emulator profile/theme, which often leads to wildly different colorized output in the user space.

Bling also offers two simple functions for creating blocks of text in the console. Check out the readme for exhaustive visual examples. These can be semantically colored (errors, warnings, info). Bling also offers a simple function for constructing a point-of-interest diagram, like when you want to call out the namespace, line, column and show some source code with a red squiggly underline. I think the Clojure community would benefit from more library authors adding neatly-formatted, actionable warning and error messages to their codebases. It would also be great if such warnings and messages where formatted in a way that loosely followed some set of conventions. Perhaps Bling could play a small role in fostering this within the Clojure community.

#5 - Lasertag

Lasertag is a utility library that was spun out of Fireworks. I believe it to be quite unique in the current landscape of cljc libraries that deal with reflection and categorization of values.
Lasertag makes it easy to get detailed information about values, particularly in the context of interop with Java or JavaScript. See this section of the readme for an example.

I think that Lasertag could potentially offer great utility to rich-tooling projects developed in the Clojure community of the present and future.

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate? Although I did not study computer science, I do think of myself as an individual with a unique perspective and something to offer.

Toby Crawley

tobias

What do you plan to work on throughout the year?
https://github.com/clojars/

Why is this work important to the Clojure community?
Clojars provides critical infrastructure to the Clojure community. This funding would cover routine maintenance and adding new features as needed.

Eric Dallo

@ericdallo

What do you plan to work on throughout the year? I want to dedicate more time on big features for anything related to the Clojure LSP ecosystem, this includes: clojure-lsp and all integrations with editors, intellij, calva, lsp-mode, and so on. Also, I want to improve the IntelliJ experience to be as good as Cursive, improving clojure-repl-intellij and clojure-lsp-intellij projects so we can have good options for LSP in any editors.

Why is this work important to the Clojure community?
Because with that everyone coding Clojure will be using the same features improving dev xp.

Rafal Dittwald

https://github.com/clojure-camp/

What do you plan to work on throughout the year?

Clojure Camp

My primary focus will be on our topic map, particularly, creating an interface to add Clojure resources from around the web and link them to learning outcomes. Later, crowd-sourcing submissions and doing some of that linking manually. Also exploring using LLMs to automate of that process.

Additionally, I would like to mentor community contributions to other resources at Clojure Camp: developing faded example / parson’s problems for our library of exercises; a badge system; and improvements to our pairing scheduling tool and mob programming tool. I will offer up some of the funding as bounties for our community members.

And of course, I will continue to run regular mob sessions and stewarding the community.

I maintain a list of “TODOs” in this spreadsheet:

Jordan and I presented a Clojure Camp update at the Conj.

Why is this work important to the Clojure community?
Clojure has sustained itself, so far, as a language (and community) “for experts, by experts.” But for long term sustainability, we should be open to exploring other avenues for people to enter the Clojure-verse.

Clojure Camp aims to offer a learning experience to support would-be Clojure developers currently under-served by existing offerings. We achieve this by:

translating best practices of pedagogical research of teaching programming to Clojure
fostering a welcoming community of learners and mentors
providing supportive infrastructure to motivate learning

Dragan Djuric

https://dragan.rocks/

What do you plan to work on throughout the year?
My goal with this funding in 2025 is to support Apple silicon (M cpu) in Neanderthal (and other Uncomplicate libraries where that makes sense and where it’s possible).

This will hugely streamline user experience regarding high performance computing in Clojure for Apple macOS users, which is a considerable chunk of Clojure community. They ask for it all the time, and I am always sorry to tell them that I still don’t have a solution. Once upon a time, Neanderthal worked on Mac too, but then Apple did one of their complete turnarounds with M1… This basically broke all number crunching software on macs, and the world is slow to catch up.

Several Clojure developers started exploring high performance computing on Apple, but didn’t get too far; it’s LOTS of functionality. So, having Neandeathal support Apple would enable several Clojure data processing communities to leapfrog the whole milestone and concentrate on more high-level tasks.

This affects Neanderthal (matrices & vectors), and Deep Diamond (tensors & deep learning) the most. Nvidia’s CUDA is not physically available on Macs at all, while OpenCL is discontinued in favor of Apple’s proprietary Metal (and who knows what else they’ve came up with since).

Neanderthal is a Clojure library for fast matrix computations based on the highly optimized native libraries and computation routines for both CPU and GPU. It is a lean, high performance, infrastructure for working with vectors and matrices in Clojure, which is the foundation for implementing high performance computing related tasks, including, but not limited to, machine learning and artificial intelligence.

Deep Diamond is a tensor and deep learning Clojure library that uses Neanderthal and ClojureCUDA under the hood (among other things).

So, what are the missing parts for Apple silicon?

A good C++/native interop. That is more or less solved by JavaCPP, but their ARM support is still in its infancy, especially regarding distribution. But it is improving.
A good BLAS/LAPACK alternative. There’s OpenBLAS, and there’s Apple’s Accelerate. Both support only a part of Intel’s MKL functionality. But, if we don’t insist on 100% coverage (we’re not) and are willing to accept missing operations to be slower, I could implement the most important ones in Clojure if nothing else is available.
A good GPU computing alternative. CUDA is not supported on Apple, and OpenCL has been discontinued by Apple. So that leaves us with Apple’s Metal, which is a mess (or so I hear). So I wouldn’t put too much hope on GPU, at the moment. Maybe much, much, later, with much, much, more experience…
Assorted auxiliary operations that are not in BLAS/LAPACK/Apple Accelerate, which are usually programmed in C++ in native-land. I’d have to see how many appear, and what I have to do with them.
Explore what’s the situation related to tensors and deep learning on Apple. I doubt that Intel’s DNNL can cover this, but who knows. Also, Apple certainly supports something, but how compatible it is with cuDNN and DNNL, is a complete unknown to me…
Who knows which roadblocks can pop up.

So, there’s a lots of functionality to be implemented, and there’s a lots of unknowns.

I propose to * Implement an Apple M engine for Neanderthal.* This involves:

buying an Apple M2/3 Mac since I don’t have it (the cheapest M3 in Serbia is almost 3000 USD with VAT).
learning enough macOS tools (Xcode was terrible back in the days) to be able to do anything.
exploring JavaCPP support for ARM and macOS.
exploring relevant libraries (OpenBLAS may even work through JavaCPP).
exploring Apple Accelerate.
learning enough JavaCPP tooling to be able to see whether it is realistic that I build Accelerate wrapper (and if I can’t, at least to know how much I don’t know).
I forgot even little C/C++ that I did know back in the day. This may also give me some headaches, as I’ll have to quickly pick up whatever is needed.
writing articles about relevant topics so Clojurians can pick this functionality as it arrives.

It may include implementing Tensor & Deep Learning support for Apple in Deep Diamond, but that depends on how far I get with Neanderthal. I hope that I can do it, but can’t promise it.

By the end of 2025, I am fairly sure that I can provide Apple support for Neanderthal (and ClojureCPP) and I hope that I can even add it for Deep Diamond.

Projects directly involved: https://github.com/uncomplicate/neanderthal
https://github.com/uncomplicate/deep-diamond
https://github.com/uncomplicate/clojure-cpp

Why is this work important to the Clojure community?
This will hugely streamline user experience regarding high performance computing in Clojure for Apple macOS users, which is a considerable chunk of Clojure community. They ask for it all the time, and I am always sorry to tell them that I still don’t have a solution since I don’t have a recent Mac hardware. Once upon a time, Neanderthal worked on Mac too, but then Apple did one of their complete turnarounds with M1… This basically broke all number crunching software on macs, and the world is slow to catch up.

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate?
The major obstacle that I have is that I live in a country outside USA and EU, so most work opportunities are unavailable from here (Serbia is a small country with poor economy that is still recovering from civil wars and whatnot, and the local IT market is mostly based on outrourcing). Other than that, I guess I’m in a similar position like everyone else.

Robert Gersak

https://github.com/gersak

What do you plan to work on throughout the year? https://github.com/neyho/eywa-core

Why is this work important to the Clojure community?
This project is about providing sane approach to identity access management based on OAuth2.1 specification and OpenID connect, specification that is common standard for identity management across professional services. ( it is important for everyone)

In addition, this project provides Data Modelling with out of the box GraphQL generic API exposure, that can be managed and controlled through UI. In terms of modelling entities and relations and what role can read, write, delete or own some entity or relation.

Currently this is applicable to PostgreSQL DB, but in future more similar DB will be covered.

Summary would be that this project is well suited for rapid development as well as for minimizing maintenance and change cost. It is fusion of IAM, Data Modelling and replacement for CRUD approach.

Is there anything else you would like us to know? I would like to share that IAM has been one of important subjects when working on enterprise level projects. Project applied above helped us in many ways to overcome enterprise level presence and onboard people towards common goal through usage of Data Modeling

Kira Howe (McLean)

http://github.com/kirahowe

What do you plan to work on throughout the year? I would like to continue working on stewarding Clojure’s data science ecosystem into a state of maturity. This would include specifically working on developing ggclj (a grammar of graphics implementation in Clojure – https://github.com/kirahowe/ggclj) guides and tutorials for Clojure’s data science stack (including the Clojure data cookbook and Clojure Tidy Tuesdays,https://github.com/scicloj/clojure-data-cookbook or https://github.com/kirahowe/clojure-tidy-tuesdays and conference talks. I would like to pitch some talks to broader data-focused conferences in 2025 outside the Clojure community in hopes of reaching a broader audience. These would include at least PyData Global, Fossdem, Open Data Science Conference, and Lambda world.

Why is this work important to the Clojure community?
I think this work will help expand Clojure’s user base and reach new audiences who can benefit from the unique tools and approaches Clojure brings to some of the biggest problems in data science today.

Are you part of a group that is affected by systemic bias, particularly in technology? If so, can you elaborate? I’m female and feel women are underrepresented in tech and especially in open source.

Roman Liutikov

https://github.com/roman01la

What do you plan to work on throughout the year? https://github.com/pitch-io/uix

Why is this work important to the Clojure community? UIx is one of the most dev friendly React wrappers, currently used by a number of companies known in Clojure community, including Pitch, Metosin and Cognician. UIx builds on modern React and encourages to rely more on existing React ecosystem in JS world. The library was in particular developed to be beginner friendly and close to React conceptually so that Clojure companies could onboard JavaScript developers quicker, allowing them to reuse most of their experience from JS/React world. I think UIx succeeded at this, at least judging based on feedback from companies mentioned above.

Both Pitch and Cognician hired frontend folks from JS community and they were able to pick up UIx relatively quickly. I also gave a talk on UIx at London Clojurians
I have a couple of ideas on improving the library further, preparing for React v19, also documentation needs more work and interactive examples. In general today after some years UIx is pretty stable, now I want to invest more in learning materials and templates for various types of projects, to make the library more accessible to devs.

Mateusz Mazurczak and Anthony Caumond

https://github.com/Kaspazza
https://caumond.com/#/

What do you plan to work on throughout the year? We are planning to work on discrete event simulation and discrete optimization.
Planning to add:

A data oriented language to be able to model simulation by non-technical people.
Add scenario management for creating multiple simulations.
Add rendering module to give the highest possible quality insights to the modeler about the behavior of a model

Project name: Automaton simulation discrete event
Link: https://github.com/hephaistox/automaton-simulation-de

Why is this work important to the Clojure community?
First, as a little introduction:
We have over two decades of expertise in the supply chain on board and a decade of software development with software craftsmanship in our hearts. We plan to create it as an open-source alternative to existing solutions (like Rockwell Arena https://www.rockwellautomation.com/en-us/products/software/arena-simulation.html or https://www.anylogic.com/

With the difference, that thanks to Clojure and data-centric approach our software will be at much higher flexibility.
This is crucial for this kind of software, as each supply-chain industry’s needs for simulation are different. So current off-the-shelf software is either not flexible enough for their usage or to expensive to adapt (ranging in millions of euro).

Future development of this library can bring more interest in Clojure for supply-chain-related projects (especially since we are putting related topics to separate libraries, e.g., https://github.com/hephaistox/automaton-optimization

By being highly flexible in architecture, other people can extend this library to meet their needs. This can benefit college students of the supply chain and people working in supply-chain (e.g. warehouses, factories). Especially when their company or revenue is too small to require consultants and high-cost software.

This will be also a great showcase for clojure data-oriented approach, as this kind of scheduling systems are much harder to create to be so flexible using classical languages (java, c++) while keeping costs small (small team).

Is there anything else you would like us to know? As automaton-simulation-de is built with a non-monolith approach, each of its parts could be seen, on its own as a product providing value to the community.

For example:

PRNG and probabilistic distribution clojure / clojurescript lib
Technology agnostic discrete optimization library (random walk, descent, genetic algorithm, …)
Scenario management,
Scheduler engine
Data-oriented UI components library (separating well the HTML+css part, behavior, and where the setup data comes from).
Or other libraries that are already separated as a side-effect of the main work e.g. https://github.com/hephaistox/automaton-build for working with monorepo

Jack Rusher

https://github.com/jackrusher

What do you plan to work on throughout the year? I would like to devote a certain number of hours every month in 2025 to work on Clerk.

Why is this work important to the Clojure community? Clerk is used by a large number of community members for literate programming, data analysis and visualization, &c.

Daniel Slutsky

https://github.com/daslu

What do you plan to work on throughout the year? Scicloj https://github.com/scicloj/
Scicloj community building and open-source projects

Why is this work important to the Clojure community? Clojure can be a fantastic fit for many kinds of scientific and data-intensive projects. Fulfilling that potential is a years-long effort, on the technical as well as the community side.

Since early 2019, we, the Scicloj group, have been working on creating a stack of tools and libraries for data and science in Clojure. https://scicloj.github.io/

The stack we are building is addressing many needs which are useful non only in scientific context. High-performance computing, data processing, data visualization, literate programming, and literate testing are a few examples.

You may find more details about current developments in a few recent talks by Scicloj members:
Kira Howe (McLean) at London Clojurians
Sami Kallinen at Heart of Clojure
Thomas Clark at Clojure Conj

We have also been continuously working on building the Clojure community: running workshops, meetup groups, study groups and dev groups, and helping with the organization of a couple of conference. We have been mentoring many Clojurians in becoming involved in open-source and in expanding their use of Clojure to new contexts.

Based on that experience, we recently initiated the Scicloj open-source-mentorship program.
63 people have applied, and 34 of them are currently active in looking into projects and meeting regularly. The program was discussed in our recent status report (2024-10-25):

A few project mentees are new to Clojure and sometimes new to programming. We meet regularly and help them in their learning process.

We have been persistently exploring the expansion of Clojure to new fields of application and research, such as biology, linguistics, physics, statistics, and geography. We are actively working with practitioners in various fields (some new to programming and some experienced) to help them out and learn from their use cases.

Is there anything else you would like us to know? My role in Scicloj is both in community building and as an open-source maintainer of a few tools and libraries. I have been involved since the beginning (2019). Since I left my day job in 2023, Scicloj has been my main focus.

Adrian Smith

https://github.com/phronmophobic/

What do you plan to work on throughout the year?

Grease: The goal for this year is to make a free, open source app similar to pythonista (http://www.omz-software.com/pythonista/) but for clojure. This project is already in-progress. More info at https://clojurians.slack.com/archives/C0260KHN0Q0 on the clojurians slack.
AI tools like llama.clj: llama.clj is a library that allows running open source LLMs directly from the JVM with a clojure-friendly API.
Dewey: Dewey is a public dataset that scans and analyzes clojure github repos weekly. These datasets are currently being used by tools like tutkain and clojure-lsp. The goal is to improve access to ecosystem data in order to be even more useful for developer tooling.
Membrane: A pure clojure, cross-platform UI library

Why is this work important to the Clojure community? The goal for the Grease project is to make a fully scriptable iOS app. This would allow any clojure developer to write apps for their iPhone without requiring developers to jump through hoops like the Apple submission process. The app (currently code named LearnLisp) is compiled using graalvm’s native-image and scripts are executed using an embedded sci interpreter. A subgoal for this project is to make the app approachable to any developer that might be interested in learning a Lisp while also having fun making something useful for their phone. In principle, the same approach can be used to target android. A stretch goal is to also release an android app with the same features.

Many of the latest AI tools are written in python and c++. I have 15 years of experience writing python and c++. One of the goals for the next year is to continue writing clojure libraries like llama.clj that make the best AI tools available to clojure. Some examples of similar libraries are whisper.clj, usearch.clj, and clip. clj.

One of the challenges commonly cited by new clojure users is finding libraries. Dewey collects and indexes information about the clojure open source ecosystem. The dewey frontends are already quite capable of finding the right library for a particular task, but the UX needs to be improved.

The current dewey frontends:

Library Search - Search for clojure libraries by keyword, name, author, and description.
Cloogle - Search for any clojure function by its doc string. Queries are indexed by semantic meaning using a vector db.

The goals for this year:

Consolidate frontends into a single, unified frontend
Make the UI prettier
Create an API to support developer tools
Extract the semantic search code into its own standalone library

Membrane is a UI library written in pure clojure aimed at building complex, interactive UI applications in a functional style. One pitfall I’m trying to avoid with membrane is to solve the easy problems, but ignore the hard problems. The most recent work on membrane has been about solving some of the hard problems facing desktop UIs so that membrane can be a real alternative to the browser for complex desktop applications. These projects include clj-media (video playback), clj-cef2 (an embedded web browser based on chromium), clj-webgpu (3d graphics), and membrane.term (terminal emulator). Now that I feel comfortable that I won’t be leading users down a dead end, the goal for this year is to improve documentation and provide a good looking, high quality, component library. Membrane UIs aren’t tied to any particular graphics library. This means that membrane UIs can be embedded in any UI library that can draw shapes, texts, and rectangles.

Peter Strömberg

https://github.com/PEZ

What do you plan to work on throughout the year?
Calva - https://calva.io - I’d like to tackle repl session management, technical and ux debt and integration with CoPilot.

Why is this work important to the Clojure community? Calva runs on the important VS Code platform, which includes editors like Cursor. The uptake of Calva increases steadily and is now close to 25% of Clojurians. Especially the lacking session management and the technical debt are increasingly problematic.

Dan Sutton

https://github.com/dpsutton/

What do you plan to work on throughout the year? inf-clojure

Why is this work important to the Clojure community? The Clojure Community always benefits from editor integrations. I think the socket repl is the underused super power of Clojure. It is the great equalizer of development environments and is built into the language.

I would want to do two things:

Work on inf-clojure to make it more robust and accessible to both beginners and experienced devs alike. NREPL does lots of amazing and convenient stuff. But it can leave developers unable to run tests without a UI. It requires lots of configuration and takes over your main entrypoint. The socket repl is incredibly helpful. A REPL based on source is almost completely indistinguishable from one based on an AOT’ed, production jar.
To complement this, I will also write tutorials and create videos showcasing how easy it is to (a) start repls, (b) work with repls, and (c) lots of helpful additions that make it so powerful and flexible.
I’ve got lots of local functions that I need to package up and get into the inf-clojure repo. Some examples:

starting a repl: clj -J"$(socket-repl 6000)" which expands out to the command line args required for a socket repl
m-x personal/repl [RET] 6000 will connect to a socket repl running on port 6000 and wire up a sub repl in it that shortens the displayed prompt to the last segment of the namespace and hook up clojure.pprint/pprint as the pretty printer
save-to/eval-from registers. Using registers in emacs is lovely. Throwing different snippets into registers (t for run all tests, i for individual test, etc) is an amazing way to run. I’ve used this system for years now and it’s time it made it back into inf-clojure.
a hotkey to require the repl-requires: (inf-clojure--send-string inf-proc "(apply require clojure.main/repl-requires)")
a helpful debugging REPL. We have macros that create temporary things during testing. It’s often the easiest way to create some complicated state to exercise and inspect a bug. But the tests run so quickly that I can’t play around. I wanted something that would be blocking and still allow me to play around with the state: THIS IS A REPL. Using subrepls to pause the world is an amazing super power that is fundamentally incompatible with nrepl. But it’s transparently powerful with socket repls. I wrote a macro that throws all locals into a namespace and lets you introspect it.
using a remote repl is amazing with a bit of ssh tunneling. The loveliest usecase is a failing test in Circle CI, rerunning with ssh and then connecting your REPL to your CI instance! This is straightforward with a socket repl.

I also want to highlight how queryable the Clojure runtime is. The repl helpers: source, apropos, dir, pst, doc, find-doc, add-libs, etc are INCREDIBLE. Learning to use the tools built into the language and not built into the IDE is a super power. Every Clojure REPL is an amazingly helpful repl.

I don’t want this to appear as it would be tutorial focused. I would hope that is 40% or less of my output. I want to contribute to inf-clojure, watch it grow, and share videos and articles about how it can unlock so much productivity.

Is there anything else you would like us to know? If this project sounds interesting, I’m also open to doing a shorter commitment. I wonder if there are others who have just a few months of work and we could combine to have several smaller projects.
But I could also improve this over 12 months as well. I think the clojurescript story is a bit underdeveloped. Shadow-cljs provides a socket repl that can easily upgrade. Using cljs.main is a bit harder but achieved with a different “accept” function. The documentation should be much easier.

I also want an easy way for it to just use a terminal repl easier. Using ssh tunneling is one thing, but it would be amazing to have a vterm window open and easily sending forms over to the repl.

In short, I think this tooling is a super power. I would love to build this out over a few months or the full year and share the knowledge and improve the tools.

Peter Taoussanis

https://www.taoensso.com

What do you plan to work on throughout the year?
Multiple projects, incl. further work on Telemere, Tufte, Tempel, and more

Why is this work important to the Clojure community? Have been trying to focus recent work on practical areas where Clojure either doesn’t already have great solution/s, or where Clojure might be able to offer something uniquely advantageous over other languages/platforms. There’s still a lot of low-hanging fruit re: both observability and data security for example. Beyond that, just focusing on practical tools that work at scale while being approachable for beginners.

Is there anything else you would like us to know?
Mostly, just thank you! I’ve been lucky and grateful to already receive long-term funding from Clojurists Together for 2023 and 2024.

I’d definitely be up for continuing this way if there’s interest from the community. It’s been awesome to dedicate more time to my open source, and Clojurists Together funding has undoubtedly helped with that (esp. for the more complex / high-effort stuff).

Have a lot of exciting things that I’d love to still expand on or explore in 2025. But I also understand that I’ve already received a couple years of funding now - and that there’s probably many great and deserving applicants with exciting proposals :-)

Whatever the outcome for 2025, I plan to continue to try contribute as much as I can.

Clojurists Together is a really awesome undertaking, and an inspiration. So thanks to everyone that’s been involved in helping make it reality and in keeping it running so smoothly.

Cheers! :-) - Peter

Oleksandr Yakushev

https://github.com/alexander-yakushev
https://github.com/clojure-goes-fast

What do you plan to work on throughout the year?
I plan to continue working on Clojure Goes Fast tooling. During Q3 2024, I’ve covered a lot of ground with new features and redesign of clj-async-profiler and the first release of Flamebin. This also opened a lot of ideas and opportunities for further improvement of those tools. I have a large backlog of tasks for:

Flamebin – implement authorization and social login, client-side encrypted private flamegraphs, collaborative commenting, configuration editing and saving;
clj-async-profiler – unified configuration, configuration reuse between flamegraphs, automatic analysis and performance improvement suggestions;
Clojure Goes Fast knowledge base – populate the list of bad performance practices that can be later be linked to by the clj-async-profiler analyzer;
clj-java-decompiler – CIDER integration which I wished to do in Q3 but couldn’t get to in this quarter.

Also, in 2024 I’ve once again become an active contributor and co-maintainer of CIDER, cider-nrepl, Orchard, and Compliment (250 total commits in 2024) and I want to continue doing this in 2025.

Why is this work important to the Clojure community?
Clojure Goes Fast continues to be the primary spot of performance-related projects and guides about Clojure (1.1K stars, 1.1M total Clojars downloads, 7000 unique site visitors in 2024).

CIDER is used by 40% of Clojure developers according to State of Clojure 2024 survey.

Sept. and Oct. 2024 Long-Term Project Updates

Sat, 16 Nov 2024 14:00:00 +1200

Check out their latest project updates from our 2024 long-term developers! These reports just in for September and October. Thanks to all!

Long-Term Project Updates

Bozhidar Batsov: CIDER
Michiel Borkent: squint, babashka, neil, cherry, clj-kondo, and more
Toby Crawley: clojars-web
Thomas Heller: shadow-cljs, shadow-grove
Kira McLean: Scicloj Libraries. tcutils, Clojure Data Cookbook, and more
Nikita Prokopov: Humble UI, Datascript, AlleKinos, Clj-reload, and more
Tommi Reiman: Reitit 7.0. Malli, jsonista, and more
Peter Taoussanis: Carmine, Nippy, Telemere, and more

Bozhidar Batsov

The big news for the past couple of months was the release of CIDER 1.16 (“Kherson”).
It was a fairly small release, mainly focused on adding support for nREPL 1.3 (which brought a lot of internal improvements). The other interesting bit about CIDER 1.16 was switching to an “in-house” tracing back-end that resulted in slightly nicer tracing output. Check the release notes for more details.

Other interesting things that happened in the realm of CIDER & friends were:

Orchard 0.28 brought improvements to the inspector and simplified the Java parser codebase
We’ve fixed the font-locking of CIDER results in the minibuffer
We’ve revived the cider completion style (details here)
You can now display the available log frameworks with cider-log-show-frameworks
A few bugs were fixed in clojure-ts-mode and we’ve started to port clojure-mode’s tests over there

In other news - I turned 40 in October, which means I’ve spent 30% of my life working on CIDER & co! :D As usual - huge thanks for supporting my work!

Michiel Borkent

Updates In this post I’ll give updates about open source I worked on during September and October 2024. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all.

Current top tier sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which aren’t listed above, please get in touch. On to the projects that I’ve been working on!

Updates

In September I visited Heart of Clojure where Christian, Teodor and I did a workshop on babashka. The first workshop was soon fully booked so we even did a second one and had a lot of fun doing so. It was so good to see familiar Clojure faces in real life again. Thanks Arne and Gaiwan team for organizing this amazing conference.

Although I didn’t make it to the USA for the Clojure conj in October, Alex Miller did invite me to appear towards the end of his closing talk when he mentioned that 90% of survey respondents used babashka.

If you are interested in a full stack web framework with babashka and squint, check out borkweb.

Here are updates about the projects/libraries I’ve worked on in the last two months.

clj-kondo: static analyzer and linter for Clojure code that sparks joy. \
- Unreleased
- #1784: detect :redundant-do in catch
- #2410: add --report-level flag
- 2024.09.27
- #2404: fix regression with metadata on node in hook caused by :redundant-ignore linter
- 2024.09.26
- #2366: new linter: :redundant-ignore. See docs
- #2386: fix regression introduced in #2364 in letfn
- #2389: add new hooks-api/callstack function
- #2392: don’t skip jars that were analyzed with --skip-lint
- #2395: enum constant call warnings
- #2400: deftype and defrecord constructors can be used with Type/new
- #2394: add :sort option to :unsorted-required-namespaces linter to enable case-sensitive sort to match other tools
- #2384: recognize gen/fmap var in cljs.spec.gen.alpha
babashka: native, fast starting Clojure interpreter for scripting.
- #1752: include java.lang.SecurityException for java.net.http.HttpClient support
- #1748: add clojure.core/ensure
- Upgrade to taoensso/timbre v6.6.0
- Upgrade to GraalVM 23
- #1743: fix new fully qualified instance method in call position with GraalVM 23
- Clojure 1.12 interop: method thunks, FI coercion, array notation (see below)
- Upgrade SCI reflector based on clojure 1.12 and remove specific workaround for Thread/sleep interop
- Add tools.reader.edn/read
- Fix #1741: (taoensso.timbre/spy) now relies on macros from taoensso.encore previously not available in bb
- Upgrade Clojure to 1.12.0
- #1722: add new clojure 1.12 vars
- #1720: include new clojure 1.12’s clojure.java.process
- #1719: add new clojure 1.12 clojure.repl.deps namespace. Only calls with explicit versions are supported.
- #1598: use Rosetta on CircleCI to build x64 images
- #1716: expose babashka.http-client.interceptors namespace
- #1707: support aset on primitive array
- #1676: restore compatibility with newest at-at version (1.3.58)
- Bump SCI
- Bump fs
- Bump process
- Bump deps.clj
- Bump http-client
- Bump clj-yaml
- Bump edamame
- Bump rewrite-clj
- Add java.io.LineNumberReader
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Fix #942: improve error location of invalid destructuring
- Fix #917: support new Clojure 1.12 Java interop: String/new, String/.length and Integer/parseInt as fns
- Fix #925: support new Clojure 1.12 array notation: String/1, byte/2
- Fix #926: Support add-watch on vars in CLJS
- Support aset on primitive array using reflection
- Fix #928: record constructor supports optional meta + ext map
- Fix #934: :allow may contain namespaced symbols
- Fix #937: throw when copying non-existent namespace
- Update sci.impl.Reflector (used for implementing JVM interop) to match Clojure 1.12
squint: CLJS syntax to JS compiler
- Fix watcher and compiler not overriding squint.edn configurations with command line options.
- Allow passing --extension and --paths via CLI
- Fix #563: prioritize refer over core built-in
- Update chokidar to v4 which reduces the number of dependencies
- BREAKING: Dynamic CSS in #html must now be explicitly passed as map literal: (let [m {:color :green}] #html [:div {:style {:& m}}]). Fixes issue when using lit-html in combination with classMap. See demo
- #556: fix referring to var in other namespace via global object in REPL mode
- Pass --repl opts to watch subcommand in CLI
- #552: fix REPL output with hyphen in ns name
- Ongoing work on browser REPL. Stay tuned.
cherry: Experimental ClojureScript to ES6 module compiler
- Fix referring to vars in other namespaces globally
- Allow defclass to be referenced through other macros, e.g. as cherry.core/defclass
- Fix emitting keyword in HTML
- #138: Support #html literals, ported from squint
http-client: babashka’s http-client \
- #68 Fix accidental URI path decoding in uri-with-query (@hxtmdev)
- #71: Link back to sources in release artifact (@lread)
- #73: Allow implicit ports when specifying the URL as a map (@lvh)
http-server: serve static assets
- #16: support range requests (jmglov)
- #13: add an ending slash to the dir link, and don’t encode the slashes (@KDr2)
- #12: Add headers to index page (rather than just file responses)
bbin: Install any Babashka script or project with one command \
- Fix #88: bbin ls with 0-length files doesn’t crash
scittle: Execute Clojure(Script) directly from browser script tags via SCI
- Add cljs.pprint/code-dispatch and cljs.pprint/with-pprint-dispatch
clojurescript
- Throw when calling ana-api/ns-publics on non-existing ns
neil: A CLI to add common aliases and features to deps.edn-based projects. \
- #241: ignore missing deps file (instead of throwing) in neil new (@bobisageek)
sci.configs: A collection of ready to be used SCI configs.
- Added a configuration for cljs.spec.alpha and related namespaces
nbb: Scripting in Clojure on Node.js using SCI
- Include cljs.spec.alpha, cljs.spec.gen.alpha, cljs.spec.test.alpha
qualify-methods
- Initial release of experimental tool to rewrite instance calls to use fully qualified methods (Clojure 1.12 only0
clerk: Moldable Live Programming for Clojure
- Add support for :require-cljs which allows you to use .cljs files for render functions
- Add support for nREPL for developing render functions
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Upgrade/sync with clojure CLI v1.12.0.1479
process: Clojure library for shelling out / spawning sub-processes
- Work has started to support prepending output (in support for babashka parallel tasks). Stay tuned.

Other projects

There are many other projects I’m involved with but that had little to no activity in the past month. Check out the Other Projects section (more details) of my blog here to see a full list.
Published: 2024-11-01

Toby Crawley

October 2024

Commit Logs: clojars-web, infrastructure

Increased max upload size from 20MB to 30MB This is to allow larger artifacts to be uploaded, now that we see native builds more often.
Addressed CVEs

September 2024

Commit Logs: clojars-web, infrastructure

Thomas Heller

shadow-cljs Update

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (eg. Clojurians Slack).

Current shadow-cljs version: 2.28.18 Changelog

Notable Updates

Added support for package.json "imports"

Blog

Wrote 2 new blog posts describing my personal REPL-based Workflow using shadow-cljs

Kira McLean

This is a summary of the open source work I spent my time on throughout September and October 2024. This was a very busy period in my personal life and I didn’t make much progress on my projects, but I did have more time than usual to think about things, which prompted many further thoughts. Keep reading for details :)

Sponsors

If you find my work valuable, please share it with others and consider supporting it financially. There are details about how to do that on my GitHub sponsors page. On to the updates!

Personal update

I’ll save the long version for the end but there is one important personal update that’s worth mentioning up front: I go by Kira Howe now. I used be known as Kira McLean, and all of my talks, writing, and commits up to this point use Kira McLean, but I’m still the same person! Just with a new name. I even updated my GitHub handle, which went remarkably smoothly.

Conj 2024

The main Clojure-related thing I did during this period was attend the Conj. It’s always cool to meet people in person who you’ve only ever worked with online, and I finally got to meet so many of the wonderful people from Clojure Camp and Scicloj who I’ve had the pleasure of working with virtually. I also had the chance to meet some of my new co-workers, which was great. There were tons of amazing talks and as always insightful and inspiring conversations. I always leave conferences with tons of energy and ideas. Then get back to reality and realize there’s no time to implement them all :) But still, below are some of the main ideas I’m working through after a wonderful conference.

SVGs for visualizing graphics

Tim Pratley and Chris Houser gave a fun talk about SVGs, among other things, that made me realize using SVGs might be the perfect way to implement the “graphics” side of a grammar of graphics.

Some of you may be following the development of tableplot (formerly hanamicloth), in which Daniel Slutsky has been implementing an elegant, layered, grammar-of-graphics-inspired way to describe graphics in Clojure. This library takes this description of a graphic and translates it into a specification for one of the supported underlying Javascript visualization libraries (currently vega-lite or plotly, via hanami). Another way to think about it is as the “grammar” part of a grammar of graphics; a way to declaratively transform an arbitrary dataset into a standardized set of instructions that a generic visualization library can turn into a graphic. This is the first half of what we need for a pure Clojure implementation of a grammar of graphics.

The second key piece we need is a Clojure implementation of the actual graphics rendering. Whether we adopt a similar underlying representation for the data as vega-lite, plotly, or whatever else is less consequential at this stage. Currently we just “translate” our Clojure code into vega-lite or plotly specs and call it a day. What I want to implement is a Clojure library that can take some data and turn it into a visualization. There are many ways to implement such a thing, all with different trade-offs, but Tim and Chouser’s talk made me realize SVGs might be a great tool for the job. They’re fast, efficient, simple to style and edit, plus they offer potentially the most promising avenues toward making graphics accessible and interactive since they’re really just XML, which is semantic, supports ARIA labels, and is easy to work with in JS.

Humble UI also came up in a few conversations, which is a totally tangential concern, but it was interesting to start thinking about how all of this could come together into a really elegant, fully Clojure-based data visualization tool for people who don’t write code.

A Clojurey way of working with data

I also had a super interesting conversation on my last night in Alexandria about Clojure’s position in the broader data science ecosystem. It’s fair to say that we have more or less achieved feature parity now for all the essential things a person working with data would need to do. Work is ongoing organizing these tools into a coherent and accessible stack (see noj), but the pieces are all there.

The main insight I left with, though, was that we shouldn’t be aiming for mere feature parity. It’s important, but if you’re a working data scientist doing everything you already do just with Clojure is only a very marginal improvement and presents a very high switching cost for potentially not enough payoff. In short, it’s a tough sell to someone who’s doesn’t already have some prior reason to prefer Clojure.

What we should do is leverage Clojure’s strengths to build tools that could leapfrog the existing solutions, rather than just providing better implementations of them. I.e. think about new ways to solve the fundamental problems in data science, rather than just offering better tools to work within the current dominant paradigm.

For example, a fundamental problem in science is reproducibility. The current ways data is prepared and managed in most data (and regular) science workflows is madness, and versioning is virtually non-existent. If you pick up any given scientific paper that does some sort of data analysis, the chances that you will be able to reproduce the results are near zero, let alone using the same tools the author used. If you do manage to, you will have had to use a different implementation than the authors, re-inventing wheels and reverse-engineering their thought process. The problem isn’t that scientists are bad at working with data, it’s the fundamental chaos of the underlying ecosystem that’s impossible to fight.

If you’ve ever worked with Python code, you know that dependency management is a nightmare, never mind state management within a single program. Stateful objects are just a bad mental model for computing because they require us to hold more information in our heads in order to reason about a system than our brains can handle. And when your mental model for a small amount of local data is a stateful, mutable thing, the natural inclination is to scale that mental model to your entire system. Tracking data provenance, versions, and lineage at scale is impossible when you’re thinking about your problem as one giant, mutable, interdependent pile of unorganized information.

Clojure allows for some really interesting ways of thinking about data that could offer novel solutions to problems like these, because we think of data as immutable and have the tools to make working with such data efficient. None of this is new. Somehow at this Conj between some really interesting talks focused on ways of working with immutable data and subsequent conversations it clicked for me, though. If we apply the same ways we think about data in the small, like in a given program, more broadly to an entire system or workflow, I think the benefits could be huge. It’s basically implementing the ideas from Rich Hickey’s “Value of values” talk over 10 years ago to a modern data science workflow.

Other problems that Clojure is well-placed to support are:

Scalability – Current dominant data science tools are slow and inefficient. People try to work around it by implementing libraries in C, Rust, Java, etc. and using them from e.g. Python, but this can only get you so far and adds even more brittleness and dependency management problems to the mix.
Tracking data and model drift – This problem has a very similar underlying cause as the reproducibility issue, also fundamentally caused by a faulty mental model of data models as mutation machines.
Testing and validation – Software engineering practices have not really permeated the data science community and as such most pipelines are fragile. Bringing a values-first and data-driven paradigm to pipeline development could make them much more robust and reliable.

Anyway I’m not exactly sure what any of this will look like as software yet, but I know it will be written in Clojure and I know it will be super cool. It’s what I’m thinking about and experimenting with now. And I think the key point that thinking about higher-level problems and how Clojure can be applied to them is the right path toward introducing Clojure into the broader data science ecosystem.

Software engineers as designers

Alex Miller’s keynote was all about designing software and how they applied a process similar to the one described in Rich Hickey’s keynote from last year’s conj to Clojure 1.12 (among other things). The main thing I took away from it was that the best use of an experienced software engineer’s time is not programming. I’ve had the good fortune of working with a lot of really productive teams over the years, and this talk made me realize that one thing the best ones all had in common is that at least a couple of people with a lot of experience were not in the weeds writing code all the time. Conversely a common thread between all of the worst teams I’ve been a part of is that team leads and managers were way too in the weeds, worrying too much about implementation details and not enough about what was being implemented.

I’ve come to believe that it’s not possible to reason about systems at both levels simultaneously. My brain at least just can’t handle both the intense attention to detail and very concrete, specific steps required to write software that actually works and the abstract, general conceptual type of thinking that’s required to build systems that work. The same person can do both things at different times, but not at the same time, and the cost of switching between both contexts is high.

Following the process described by Rich and then Alex is a really great way to add structure and coherence to what can otherwise come across as just “thinking”, but it requires that we admit that writing code is not always the best use of our time, which is a hard sell. I think if we let experienced software engineers spend more time thinking and less time coding we’d end up with much better software, but this requires the industry to find better ways to measure productivity.

Long version of personal updates

As most of you know or will have inferred by now, I got married in September! It was the best day ever and the subsequent vacation was wonderful, but it did more or less cancel my productivity for over a month. If you’re into weddings or just want a glimpse into my personal life, we had a reel made of our wedding day that’s available here on instagram via our wedding coordinator.

Immediately after I got back from my honeymoon I also started a new job at BroadPeak, which is going great so far, but also means I have far less time than I used for open source and community work. I’m back to strictly evening and weekend availability, and sadly (or happily, depending how you see it) I’m at a stage of my life where not all of that is free time I can spend programming anymore.

I appreciate everyone’s patience and understanding as I took these last couple of months to focus on life priorities outside of this work. I’m working on figuring out what my involvement in the community will look like going forward, but there are definitely tons of interesting things I want to work on. I’m looking forward to rounding out this year with some progress on at least some of them, but no doubt the end of December will come before I know it and there will be an infinite list of things left to do.

Thanks for reading all of this. As always, feel free to reach out anytime, and hope to see you around the Clojureverse :)

Nikita Prokopov

Hi, this is Niki Tonsky and past two month we made a huge progress on Humble UI, culminating in Heart of Clojure workshop. Clojure Sublimed also saw some love. Enjoy!

Humble UI, Clojure Desktop UI framework:

Documentation is now part of Humble UI jar, can be opened from any app as a second window
Lots of components were documented
Declarative paints
Support oklch color model
More options for containers (column/row/grid)
hsplit component
Button styles
Added user-facing ui/measure that only needs a component
Tuned measurement/sizing caching, still a bit buggy
Add bring-to-front to ui/window, cmd/ctrl+w to close docs, signal to ui namespace
Convenience: default focusable on top level
Convenience: allow ^{:stretch true} as a most common use case
Fixed: with-bounds, draggable, vscrollable after resize,
Fixed: crash on window close
Demo: humble-file-picker demo as a separate application, with step-by-step progression
Demo: new Sand sandbox
Demo: new Mirrors demo, mirrored from Philippa Markovics

Clojure Sublimed, Clojure support for Sublime Text 4:

Support Clojure 1.12 array type annotations
Pretty print selection #123
Toggle Comment command that uses #_ instead of ;;
Execute code from inside top-level ; ... and #_... #124
Handle eval of #_ forms in nREPL JVM
Better handle socket close
Highlight namespace name as entity.name, same as defs
Simplified formatting rules: if list’s first form is a symbol, indent 2, in other cases, indent to opening paren
Better handle selection after formatting with cljfmt
Tests for indentation, cljfmt default config
cljfmt correctly indents forms with custom rules
Tuned color scheme a bit

Sublime Executor, executable runner for Sublime Text:

Fixed result_file_regex/result_line_regex, clear them on clear_output

Clerk, Moldable Live Programming for Clojure:

Better drop-in implementation of clojure.walk (should make it into a library)

Tommi Reiman

My planned Open Source Time got postponed due to small family crisis, so no big releases.

Had some time to help people, do PR reviews and small updates to viesti, to be released later this year or early next.

Reserved OS time for December, to (╯°□°)╯︵ LIBS out!

Something Else

Peter Taoussanis

- Peter Taoussanis

Recent work

Hi folks! 👋 I’m a bit crunched for time atm, so will keep this update short for a change :-) Hope everyone’s well!

Telemere

Telemere is a modern rewrite of Timbre that offers an improved API to cover traditional logging, structured logging, tracing, basic performance measurement, and more.

v1.0.0-RC1 is now available! 🎉

It’s been a lot of work getting here, but I’m happy with the results. Big thanks to everyone that’s been testing the (many) betas and giving valuable feedback! 🙏

Have also recorded a new lightning intro video that gives a 7-min tour of what Telemere is and roughly what it can do. If you’ve been curious but short on time, this might be a good way to get started.

Timbre

Timbre is a pure Clojure/Script logging library.

v6.6.0 was released, and v6.6.1 shortly after.

These mark the stable final release of the previous release candidate. Main highlight is Timbre’s new out-the-box SLF4Jv2 support.

Nippy

Nippy is fast serialization library for Clojure.

v3.5.0-RC1 is out now, which updates dependencies and adds read support for some new primitive array types that’ll follow shortly in a v3.6.

Sente

Sente is a realtime web comms library for Clojure/Script

v1.20.0-RC1 is out now, and includes an experimental new Jetty adapter and a number of internal improvements.

Upcoming work

Can’t believe it’s almost the end of the year! It’s been a productive one, and I’d like to focus on wrapping up a few dangling ends before the year’s out.

Plans include:

Telemere v1 final before year’s end.
Tempel v1 final before year’s end.
Tufte v3 pre-release (hopefully) before year’s end. Have actually already invested quite a bit of time in this - but it’s turned out to be a bigger job than expected, and I want to get it right.

Also hoping to find some time for some http-kit maintenance, and I have a couple talks I’d like to record at some point - though those’ll probably need to wait until next year.

On a background thread, I’m continuing to make progress on Carmine v4. Just recently deployed my first production code using v4’s alpha branch, so that’ll be a good opportunity for testing.

Thanks everyone! Cheers 👋

Applications Open for 2025 Long-Term Funding

Thu, 31 Oct 2024 14:00:00 +1200

6 Developers will each be awarded $1,500 USD per month in 2025.

This is the 4th year we are awarding annual funding. We’ve received an unmanageable number of nominations in the past few years, so based on member input, we’ve decided to try a new approach for 2025.

APPLY: Anyone interested in receiving annual funding submits an APPLICATION outlining what they intend to work on and how that work will benefit the Clojure community. The deadline for applications is Nov. 12th, 2024 midnight Pacific Time.
BOARD REVIEW: The Clojurists Together board will review the applications and select finalists to present to the members.
MEMBERS VOTE: Ballot will go out to members no later than Nov. 20th. Members will vote on the finalists using Ranked Voting. Deadline Dec. 2. midnight Pacific Time.
AWARDS: 6 developers will receive $1,500 USD per month in 2025. Awards will be announced no later than Dec. 9th, 2024.
REPORTS: Developers submit bi-monthly reports to the membership.

In the past 3 years, we have seen that giving developers flexible, long-term funding gives them the space to do high-impact work. This might be continuing maintenance on existing projects, new feature development, or perhaps a brand-new project. We’ve been excited with what they came up with in the last few years and are looking forward to seeing more great work in 2025! Thanks all and good luck!

Sept. and Oct. 2024 Short-Term Project Updates

Sun, 27 Oct 2024 14:00:00 +1200

We’ve got our first set of reports from developers working on short-term projects funded in Q3 2024. You’ll find a brief description of each project at the top of the page to provide some context – followed by current project updates.

clj-Nix: José Luis Lafuente

Develop an alternative builder for Nix that uses Babashka / SCI instead of Bash. It provides a way for constructing complex Nix derivations using Babashka/SCI entirely, eliminating the need to write any Bash code.
Also, will be adding a Babashka writer to nixpkgs. Nixpkgs supports creating self-contained scripts, called “nix writers.” Traditionally written in Bash, recent versions of nixpkgs include the ability to write these scripts in Python, Ruby, or Rust.

Clojure Goes Fast: Oleksandr Yakushev

Create a new web application for clj-async-profiler that will allow users to host and share the generated flamegraphs. At the moment, even though flamegraphs are just self-contained HTML files, sending them to somebody is a chore. The new service can make this much easier and offer extra features like saving and sharing dynamic transforms on the fly. Additionally, I’d like to focus on the UI side of clj-async-profiler - add new dynamic transforms, improve aesthetics and the UX.
For clj-java-decompiler, expand its preprocessing abilities to present clearer results to the user and integrate it more tightly with established Clojure IDEs like CIDER and Calva, which requires some groundwork.
Adapting and updating benchmarking content in the Clojure Goes Fast knowledge base

Jank: Jeaye Wilkerson

Kushi: Jeremiah Coyle

Malli: Ambrose Bonnaire-Sergeant

SciCloj: Daniel Slutsky

Standard Clojure Style:Chris Oakman

Project Updates: Sept. and Oct. 2024

clj-Nix: José Luis Lafuente

Q3 2024 Report No. 1, Published Oct. 13, 2024

In this first half of the funding round, I made progress on two fronts:

Babashka writer on nixpkgs

I added a new writer, writeBabashka, to nixpkgs. It’s already merged and currently available on the nixpkgs and nixos unstable branch.

Documentation about this new helper function can be found here: writeBabashka on Noogle

As you can see in the documentation, there are two versions, writeBabashka and writeBabashkaBin. Both produce the same output script. The only difference is that the latter places the script within a bin subdirectory. That’s a common pattern in nixpkgs, for consistency with the convention of software packages placing executables under bin.

Something I still want to do is to create a repository with some examples about how to use the Babashka writer.

Nix Derivation Builder with Babashka

The build step of a Nix derivation is defined by a Bash script. I want to provide an alternative builder written in Clojure (using Babashka).

I have a working prototype, but the API is still under development and may change in the future. You can find the initial version on the bbenv branch: clj-nix/extra-pkgs/bbenv

A pull request for early feedback is available here: clj-nix PR #147

Here’s a glimpse of how it currently works. This example builds the GNU Hello Project:

mkBabashkaDerivation {
  build = ./my/build.clj;
  deps-build = [ pkgs.gcc ];
}

(require '[babashka.process :refer [shell]])

(defn build
  [{:keys [out src]}]
  (shell {:dir src} (format "./configure --prefix=%s" out))
  (shell {:dir src} "make install"))

(def version  "2.12.1");

(def pkg
  {:name "hello"
   :version version
   :src {:fetcher :fetchurl
         :url (format "mirror://gnu/hello/hello-%s.tar.gz" version)
         :hash "sha256-jZkUKv2SV28wsM18tCqNxoCZmLxdYH2Idh9RLibH2yA="}
   :build build})

Clojure Goes Fast: Oleksandr Yakushev

Q3 2024 Report No. 1, Published Sept.30, 2024

I’ve spent the first month of my Clojurists Together project polishing the user experience for clj-async-profiler. The profile viewer UI (the flamegraph renderer) received big improvements in navigation, ease of access, consistency, and overall look. As a bullet list:

Published one big release of clj-async-profiler (1.3.0) and two small releases (1.3.1 and 1.3.2). Most important changes:
- Completely redesigned collapsible sidebar.
- Better rendering performance and responsiveness.
- New custom on-hover tooltip.
- Fewer configuration options for better out-of-the-box experience.
Blogged about 1.3.0 release describing in detail and with demonstration what has changed: https://clojure-goes-fast.com/blog/clj-async-profiler-130/
Prepared multiple UI mockups for the flamegraph sharing website that I’m starting to work on in the second month.

Jank: Jeaye Wilkerson

Q3 2024 Report No. 1, Published Oct. 14, 2024

Hi everyone! It’s been a few months since the last update and I’m excited to outline what’s been going on and what’s upcoming for jank, the native Clojure dialect. Many thanks to Clojurists Together and my Github sponsors for the support. Let’s get into it!

Heart of Clojure

In September, I flew from Seattle to Belgium to speak at Heart of Clojure. For the talk, I wanted to dig deep into the jank details, so I created a walk-through of implementing exception handling in jank. You can watch my talk here.

Announcement

Part of my Heart of Clojure talk was an announcement that, starting in January 2025, I’ll be quitting my job at EA to focus on jank full-time. Two years ago, I switched from full-time to part-time at EA in order to have more time for jank. Now, with the momentum we have, the interest I’ve gathered, and the motivation backing this huge effort, I’m taking things all the way.

I don’t have funding figured out yet, though. It’s hard for companies to invest in jank now when they’re not using it, when it’s not providing them value. So my goal is to get jank out there and start creating value in the native Clojure space. If using jank interests you and you want white glove support for onboarding jank once it’s released, reach out to me.

Mentoring

On top of working on jank full-time, next year, I have joined the SciCloj mentorship program as a mentor and have two official mentees with whom I meet weekly (or at least once every two weeks) in order to help them learn to be compiler hackers by working on jank. This is in tandem with the other mentee I had prior to the SciCloj program.

What’s so inspiring is that there were half a dozen interested people, who either reached out to me directly or went through the application process, and we had to pare down the list to just two for the sake of time. Each of those folks wants to push jank forward and learn something along the way.

JIT compilation speeds

Now, jumping into the development work which has happened in the past few months, it all starts with me looking into optimizing jank’s startup time. You might think this is a small issue, given that jank needs more development tooling, improved error messages, better Clojure library support, etc. However, this is the crux of the problem.

jank is generating C++ from its AST right now. This has some great benefits, particularly since jank’s runtime is implemented in C++. It allows us to take advantage of C++’s type inference, overloading, templates, and virtual dispatch, whereas we’d have none of those things if we were generating LLVM IR, machine code, or even C.

However, JIT compiling C++ as our primary codegen comes with on big problem: C++ is one of the slowest to compile languages there is. As a concrete example, in jank, clojure.core is about 4k (formatted) lines of jank code. This codegens to around 80k (formatted) lines of C++ code. On my beefy desktop machine, it takes 12 seconds to JIT compile all of that C++. This means that starting jank, with no other dependencies than clojure.core, takes 12 seconds.

To be fair, all of this disappears in AOT builds, where startup time is more like 50ms. But starting a REPL is something we do every day. If it takes 12 seconds now, how long will it take when you start a REPL for your company’s large jank project? What if your machine is not as beefy? A brave user who recently compiled jank for WSL reported that it took a minute to JIT compile clojure.core for them.

So, this leads us to look for solutions. jank is already using a pre-compiled header to speed up JIT compilation. Before abandoning C++ codegen, I wanted to explore how we could pre-compile modules like clojure.core, too. Very pleasantly, the startup time improvements were great. jank went from 12 seconds to 0.3 seconds to start up, when clojure.core is pre-compiled as a C++20 module and then loaded in as a shared library.

There’s a catch, though. It takes 2 full minutes to AOT compile clojure.core to a C++20 pre-compiled module. So, we’re back to the same problem. jank could compile all of your dependencies to pre-compiled modules, but it may take 30 minutes to do so, even on a reasonable machine. For non-dependency code, your own source code, jank could use a compilation cache, but you’ll still need to pay the JIT compilation cost whenever you do a clean build, whenever you eval a whole file from the REPL, etc.

Before digging deeper into this, I wanted to explore what things would look like in a world where we don’t codegen C++.

LLVM IR

LLVM has support for JIT compiling its own intermediate representation (IR), which is basically a high level assembly language. Compared to generating C++, though, we run into some problems here:

Calling into C++ is tough, since C++ uses name mangling and working C++ value types involves non-trivial IR
We can’t do things like instantiate C++ templates, since those don’t exist in IR land

So we need to work with jank at a lower level. As I was designing this, in my brain, I realized that we just need a C API. jank has a C++ API, which is what we’re currently using, but if we had a C API then we could just call into that from assembly. Heck, if we can just write out the C we want, translating that to assembly (or IR) is generally pretty easy. That’s what I did. I took an example bit of Clojure code and I wrote out some equivalent C-ish code, using a made-up API:

Clojure

(defn say-hi [who]
  (println "hi " who "!"))

C

static jank_object_ptr const_1 = jank_create_string("hi ");   
static jank_object_ptr const_2 = jank_create_string("!");  

jank_object_ptr say_hi(jank_object_ptr who)  
{
  jank_object_ptr println_var = jank_var_intern("clojure.core", "println");  
  jank_object_ptr println = jank_deref(println_var);  
  return jank_call3(println, const_1, who, const_2);  
}  

static jank_object_ptr fn_1()  
{  
  jank_object_ptr say_hi_var = jank_var_intern("clojure.core", "say-hi");  
  jank_object_ptr say_hi_obj = jank_create_function1(&say_hi);  
  jank_var_bind_root(say_hi_var, say_hi_obj);  
  return say_hi_var;  
}

This was motivating. Furthermore, after two weekends, I have the LLVM IR codegen almost entirely done!
The only thing missing is codegen for closures (functions with captures) and try expressions, since those involve some extra work. I’ll give an example of how this looks, with exactly the IR we’re generating, before LLVM runs any optimization passes.

Clojure

(let [a 1
      b "meow"]
  (println b a))

LLVM IR

; ModuleID = 'clojure.core-24'
source_filename = "clojure.core-24"  

; Each C function we reference gets declared.  
declare ptr @jank_create_integer(ptr)
declare ptr @jank_create_string(ptr)
declare ptr @jank_var_intern(ptr, ptr)
declare ptr @jank_deref(ptr)
declare ptr @jank_call2(ptr, ptr, ptr)

; All constants and vars are lifted into internal  
; globals and initialized once using a global ctor.
@int_1 = internal global ptr 0
@string_2025564121 = internal global ptr 0
@0 = private unnamed_addr constant [5 x i8] c"meow\00", align 1
@var_clojure.core_SLASH_println = internal global ptr 0
@string_4144411177 = internal global ptr 0
@1 = private unnamed_addr constant [13 x i8] c"clojure.core\00", align 1
@string_4052785392 = internal global ptr 0
@2 = private unnamed_addr constant [8 x i8] c"println\00", align 1  

; Our global ctor function. It boxes all our
; ints and strings while interning our vars.
define void @jank_global_init_23() {
entry:  
  %0 = call ptr @jank_create_integer(i64 1)
  store ptr %0, ptr @int_1, align 8
  %1 = call ptr @jank_create_string(ptr @0)
  store ptr %1, ptr @string_2025564121, align 8
  %2 = call ptr @jank_create_string(ptr @1)
  store ptr %2, ptr @string_4144411177, align 8
  %3 = call ptr @jank_create_string(ptr @2)
  store ptr %3, ptr @string_4052785392, align 8
  %4 = call ptr @jank_var_intern(ptr %2, ptr %3)
  store ptr %4, ptr @var_clojure.core_SLASH_println, align 8
  ret void  
}
  
; Our effecting fn which does the work of the actual code.
; Here, that just means derefing the println var and calling it.
define ptr @repl_fn_22() {
entry:
  %0 = load ptr, ptr @int_1, align 8
  %1 = load ptr, ptr @string_2025564121, align 8
  %2 = load ptr, ptr @var_clojure.core_SLASH_println, align 8
  %3 = call ptr @jank_deref(ptr %2)
  %4 = call ptr @jank_call2(ptr %3, ptr %1, ptr %0)
  ret ptr %4
}

There’s still more to do before I can get some real numbers for how long it takes to JIT compile LLVM IR, compared to C++. However, I’m very optimistic. By using a C API, instead of our C++ API, handling codegen optimizations like unboxing ends up being even more complex, but we also have even more power.

How this affects interop

Currently, jank has two forms of native interop (one in each direction):

A special native/raw form which allows embedding C++ within your jank code
The ability to require a C++ as though it’s a Clojure namespace, where that C++ code then uses jank’s runtime to register types/functions

When we’re generating C++, a native/raw just gets code-generated right into place. However, when we’re generating IR, we can’t sanely do that without involving a C++ compiler. This means that native/raw will need to go away, to move forward with IR. However, I think this may be a good move. If we buy into the second form of interop more strongly, we can rely on actual native source files to reach into the jank runtime and register their types/functions. Then, in the actual jank code, everything feels like Clojure.

This means that we still have a need for JIT compiling C++. Whenever you require a module from your jank code, which is backed by a C++ file, that code is JIT compiled. Generally, what the C++ code will do is register the necessary functions into the jank runtime so that way you can then drive the rest of your program with jank code. I think this is a happy medium, where we still have the full power of C++ at our disposal, but all of our jank code will result in IR, which will JIT compile much more quickly than C++.

This means the answer to the question of C++ or IR is: why not both?

jank as THE native Clojure dialect

There’s another reason which leads me to explore LLVM IR within jank. While jank is embracing modern C++, it doesn’t need to be so tightly coupled to it. By using just the C ABI as our runtime library, everything can talk to jank. You could talk to jank from Ruby, Lua, Rust, and even Clojure JVM. Just as importantly, jank can JIT compile any LLVM IR, which means any language which compiles on the LLVM stack can then be JIT compiled into your jank program.

Just as jank can load C++ files as required namespaces, seamlessly, so too could it do the same for Rust, in the future. Furthermore, as the public interface for jank becomes C, the internal representation and implementation can change opaquely, which would also open the door for more Rust within the jank compiler.

In short, any native work you want to do in Clojure should be suited for jank. Your jank code can remain Clojure, but you can package C, C++, and later languages like Rust inside your jank projects and require then from your jank code. The jank compiler and runtime will handle JIT compilation and AOT compilation for you.

Community update

This has been a long update which hopefully created some more excitement for jank’s direction. I want to wrap up with what the community has been up to recently, though, since that alone warrants celebration.

Characters, scientific notation, and to_code_string

Saket has been improving jank’s runtime character objects, which he originally implemented, to be more efficient and support Unicode. He also recently added scientific notation for floating point values, as well as an extension of jank’s object concept to support to_code_string, which allows us to now implement pr-str.

At this point, Saket has the most knowledge of jank’s internals, aside from me, so I’ve been giving him heftier tasks and he’s been super helpful.

More robust escape sequences

One of my SciCloj mentees, Jianling, recently merged support for all of the ASCII escape sequences for jank’s strings. Previously, we only had rudimentary support. Now he’s working on support for hexadecimal, octal, and arbitrary radix literals, to further jank’s syntax parity with Clojure.

Nix build

We have a newcomer to jank, Haruki, helping to rework the build system and dependencies to allow for easy building with Nix! There’s a draft PR here. I’m excited for this, since I’m currently using NixOS and I need to do a lot of jank dev in a distrobox for easy building. This will also help with stable CI builds and ultimately getting jank into nixpkgs (the central package repo for Nix).

LLVM 19 support

The last JIT hard crash fix in LLVM is being backported to the 19.x branch, which means we should be able to start using Clang/LLVM binaries starting 19.2! This is going to drastically simplify the developer experience and allow for packaging jank using the system Clang/LLVM install. My backport ticket has been closed as complete, though the PR into the 19.x branch is still open.

Summary

More people are working on jank now than ever have; I expect this number to keep growing in the coming year. I’ll see you folks at the Conj and, after that, in my next update during the holiday season, when I’ll have some final numbers comparing jank’s startup times with LLVM IR vs C++, as well as some updates on other things I’ve been tackling.

Kushi: Jeremiah Coyle

Q3 2024 Report No. 1, Published Oct. 15, 2024

Q3 Milestones

Thanks to the funding from Clojurists Together, the Q3 development of Kushi is aimed at achieving the following 3 milestones:

Finishing the new css transpilation API.
Reimplementing the build system for enhanced performance.
A reimagined theming system.

Progress

Milestone #1: Finishing the new css transpilation API.

Goals
1. Solidify the API design and implementation of Kushi’s CSS transpilation functionality.
2. Incorporate the use of lightingcss for CSS transformation (older browsers) and minification.
3. Refactor existing public functions for injecting stylesheets, google fonts, etc.
Progress: Complete. The majority of the time spent working on Kushi in the first half of the funding period was focused on implementing a new CSS transpilation pipeline. An updated set of public macros and supporting functions was designed and implemented around this. A broad test suite was written, which consists of 7 tests containing 54 assertions.
Next steps: When the work on the new build system (milestone #2) is complete, test this new API by upgrading existing UI work (such as Kushi’s interactive documentation site) that uses the current (soon to be previous) API, then adjust and refine implementation details as necessary.

Milestone #2: Reimplementing the build system for enhanced performance.

Goal: Reimplement the build system for performance, and eliminate the use of side-effecting macros.
Progress: 75% of the initial design, discovery, and experimentation phase is complete.
Next steps: I anticipate moving it into the implementation phase by the last week of October. Roughly half of the the remaining 6 weeks of the Q3 period will be spent building this out.

Milestone #3: A reimagined theming system.

Goal: Based on learnings from using Kushi to build a lot of production UI over that last 2-3 years, redesign and implement a new theming system. This will involve harmonizing 3 principled subsystems:
1. Design tokens (a global system of CSS custom properties).
2. Utility classes.
3. Component-level data-attribute conventions.
Progress: 90% of the initial design, discovery, and experimentation phase is complete.
Next steps: I am hoping that enough progress will be made on the build system so that I can focus Kushi dev time on this new theming system for the last 3 weeks of November.

Details

All of the work related to Milestone #1 has been happening in a sandbox repo called kushi-css. Additional in-depth detail and documentation around this work can be found here. When all 3 of the above grated into the main kushi repo.

Malli: Ambrose Bonnaire-Sergeant

Q3 2024 Report No. 1, Published Oct. 18, 2024

Malli Constraints - Report 1

This is the first report of three in the project to extend Malli with constraints.

tldr; I gave a talk and started implementation and reflect its successes and failures below.

Thanks to Tommi (Malli lead dev) for working with me to propose the project, and the encouragement I received from the Malli community and my friends.

This is a long update that really helps me get my thoughts in order for such a complex project. Thanks for reading and feel free to email me any questions or comments.

Background

In this project, I proposed to extend the runtime verification library Malli with constraints with the goal of making the library more expressive and powerful.

Before the project started, I had completed an extensive prototype that generated many ideas. The authors of Malli were interested in integrating these ideas in Malli and this project aims to have their final forms fit with Malli in collaboration with the Malli devs.

Talk

It had been several months since I had built the prototype of Malli constraints, so I gave a talk at Madison Clojure which I live-streamed. You can watch it here.

It was well received and very enjoyable to give. I’m thankful to the attendees for their engagement and encouragement, and for checking in on my progress during the project.

In the talk, I motivate the need for more expressive yet reliable schemas, propose a solution in the form of constraints, and sketch some of the design ideas for making it extensible. I gave this talk a few days before the project started and I hit the ground running.

Design Goals (Constraints)

I’ve had many fruitful interactions with the Malli community its developers and I have a good idea what the project values. If this constraints project is to be successful, it must check all the boxes as if it came straight from the brain of Tommi (well, that’s my goal, Tommi is busy and has enjoyably high standards). Given how deeply this project aims to integrate with Malli, that attitude has definitely helped prune ideas (when was the last time :string or :int changed it’s implementation? We’re doing exactly that here).

There is a mundane but critical issue that Malli has been steadily increasing its CLJS bundle size. I decided early on that my design for constraints would be opt-in, so that the Malli devs can decide whether its worth including by default. If adding constraints irreversibly increased the CLJS bundle size to the point that Malli devs started worrying, this project would be in jeopardy.

My prototype made constraints an entirely custom construct, unrelated to the rest of Malli. It’s helpful to look at a related project under similar circumstances: extending Malli to add sequence expressions like :alt and :*. Sequence expressions are a different abstraction than schemas, and yet they share many implementation concepts, both even implementing m/Schema. Sequence expressions then implement additional protocols for their characterizing operations. I wanted to take inspiration from this: constraints should be like schemas in their overlapping concepts, introducing new abstractions only for differences.

I would like the constraints framework be merged incrementally, starting with very simple constraints on the count and size of collections and numbers. However, the framework itself should be fully realized and be able to support much more complex constraints.

The last few goals are easy to list, but maximizing them all simultaneously might be difficult as seem in deep tension. Constraints should be fast, extensible, and robust. It should be possible to achieve equivalent performance to a “hand-coded” implementation of the constraint. It should be possible to implement as many kinds of constraints as possible without having to change the constraint framework itself. Constraints should have predictable, reliable semantics that are congruent to the rest of Malli’s design.

Summary of goals:

control bundle size
backwards compatibility
equivalent performance
- in tension with extensibility and compilation
extensibility
- provide expressivity and power of primitives
robustness
- think about Malli’s unwritten rules (properties round-trip)
first iteration should be fully realized but minimal

Development

Diff

Branch

My first attempt at an idiomatic implementation of schema constraints was completed in the first half of September. Since then it’s been hammock-time pondering the results. I have surprisingly strong feelings in both directions.

I go into more detail below.

Opt-in for CLJS Bundle size

I was able to separate the constraints framework from malli.core so it can be opt-in to control CLJS bundle size. The main code path adds several functions and a couple of protocols, but the constraints themselves are loaded separately via an atom that also lives in malli.core. This atom m/constraint-extensions can be empty which will disable constraints, kicking in a backwards-compatibility mode for schemas that migrated their custom properties to constraints (like :string’s :min and :max).

I went back and forth about whether to use a single global atom or to add some internal mutable state to each schema that could be upgraded to support constraints. In this implementation, I decided a global atom was more appropriate for two reasons. First, registries can hold multiple copies of the same schema but only one will “win”. We don’t want situations where we extend a schema with constraints and then it gets “shadowed” by another instance of the same schema, since that is functionally equivalent in all other situations. Second, we already have an established way of extending schemas to new operations in the form of a multimethod dispatching on m/type. I wanted a similar experience where an entire class of extension is self-contained in one global mutable variable.

Extending schemas with constraints is subtly different to many other kinds of schema extensions, in that it is much finer grained. defmulti is appropriate for defining generators or JSON Schema transformers where a schema extension maps precisely to a function (defmethod), but extending constraints is more like having a separate atom for each schema containing a map where each field can themselves be extended with namespaced keywords. A single global atom containing a map from schemas to constraint configuration became the natural choice (an atom of atoms is rarely a good idea).

Ultimately the constraint implementation is activated by calling (malli.constraint/activate-base-constraints!).

Reusing existing abstractions

Constraints implement m/Schema and their m/IntoSchema’s live in the registry. They differ from schemas in how they are constructed and print (it depends which schema the constraint is attached to) so they have their own equivalent to m/schema in malli.constraint/constraint.

As I outlined in my talk, it was important to have multiple ways to parse the same constraint for maximum reuse. For example, [:string {:min 10}] and [:vector {:min 10}] should yield equivalent constraints on count, while [:int {:min 10}] and [:float {:min 10}] yield constraints on size. This is useful when solving constraints for generators (malli.constraint.solver).

Extensibility

The new implementation converts the :min, :max, :gen/min, and :gen/max properties on the :string schema to constraints. They are implemented separately from :string itself in a successful test of the extensibility of constraints.

malli.constraint/base-constraint-extensions contains the configuration for these :string constraints, which consist of the :true, :and, and :count constraints. There are several ways to attach :count constraints to a :string, each of which has a corresponding parser. For example, a string with a count between 1 and 5 (inclusive) can be created via [:string {:min 1 :max 5}] or [:string {:and [:count 1 5]}]. The :string :parse-properties :{min,max} configuration shows how to parse the former and :string :parse-constraint :count the latter.

Performance

Extensibility and performance are somewhat at odds here. While it’s great that two unrelated parties could define :min and :max in [:string {:min 1 :max 5}], we are left with a compound constraint [:and [:count 1] [:count nil 5]] (for the :min and :max properties, respectively). To generate an efficient validator for the overall constraint we must simplify the constraint to [:count 1 5]. The difference in validators before and after intersecting are #(and (<= 1 (count %)) (<= (count %) 5)) and #(<= 1 (count %) 5). Depending on the performance of count`, choosing incorrectly could be a large regression in performance.

Constraints have an -intersect method to merge with another constraint which :and calls when generating a validator. While we regain the performance of validation, we pay an extra cost in having to create multiple constraints and then simplify them.

Robustness

My main concern is a little esoteric but worth considering. Malli has specific expectations about properties that constraints might break, specifically that properties won’t change if roundtripping a schema.

A constrained schema such as [:string {:min 1}] is really two schemas: :string and [:count 1], the latter the result of the new -get-constraint method on -simple-schema’s like :string. The problem comes when serializing this schema back to the vector syntax: how do we know that [:count 1] should be serialized to [:string {:min 1}] instead of [:string {:and [:count 1]}]? I don’t think this is a problem for simple constraints like :min since we can just return the same properties as we started with. There are several odd cases I’m not sure what do with.

For instance, when the :min property is changed:

(-update-properties [:string {:min 1}] :min inc)
;=> [:string {:min 2}]

In this case, the :string schema is recreated along with a new constraint [:count 2].

Or, the constraint itself is updated with the new -set-constraint:

(-set-constraint [:string {:min 1}] [:count 2])
;=> [:string {:min 2}] OR [:string {:and [:count 2]}] ?

Here -set-constraint removes all properties related to constraints (since we’re replacing the entire constraint) and then must infer the properties to serialize the new constraint to. In this case the constraint configuration in :string :unparse-properties ::count-constraint chooses [:string {:min 2}], but its resemblance to the initial schema is coincidental and might yield surprises.

The big task here is thinking about (future) constraints that contain schemas. For example, you could imagine a constraint [:string {:edn :int}] that describes strings that edn/read-string to integers. This is very similar to [:string {:registry {::a :int}}] in that the properties of the schema are actually different before and after parsing the schema (in this case, m/-property-registry is used to parse and unparse the registry).

Part of the rationale of using -get-constraint as the external interface for extracting a constraint from a schema is to treat each schema as having one constraint instead of many small ones is for schema-walking purposes. Property registries don’t play well with schema walking and it takes a lot of work to ensure schemas are walked correctly (for example, ensuring a particular OpenAPI property is set on every schema, even those in local registries). Walking schemas inside constraints will be more straightforward. To support constraints, a schema will extend their -walk algorithm to automatically walk constraints with a separate “constraint walker”, and constraints like :edn will revert to the original “schema walker” to walk :int in [:string {:edn :int}]. This logic lives in malli.constraint/-walk-leaf+constraints.

This walking setup is intended to cleanly handle refs inside schemas such as:

[:schema {:registry {::a :int}}
 [:string {:edn ::a}]]

Having schemas in properties leaves us in a fragile place in terms of the consistency of schema serialization. For example, after walking [:string {:edn :int}] to add an OpenAPI property on each schema, we might end up with either

[:string {:edn [:int {:a/b :c}], :a/b :c}]
;; or
[:string {:and [:edn [:int {:a/b :c}]], :a/b :c}]

depending on the :unparse-property attached to :edn constraints under :string.

Or even more fundamentally, the properties of [:string {:edn :int}] become {:edn (m/schema :int)} when parsed, but how do we figure out it was originally {:edn :int}? The current approach (which is a consequence of treating each schema as having one constraint via -{get,set}-constraint) depends on the unparser in :string :unparse-properties ::edn-constraint to guess correctly.

It is unclear how big of a problem this is. My fundamental worry is that schemas will not round-trip syntactically, but is this lot of worry about nothing? Plenty of schemas don’t round-trip syntactically at first, but stabilize after the first trip, for example [:string {}] => :string => :string. The important thing is that they are semantically identical. This is similar to what I propose for constraints: deterministically attempt to find the smallest serialization for the constraint within the properties. If inconsistencies occur, at best might annoy some users, or at worst it could make constraints incomprehensible (to humans) be restating them in technically-equivalent ways.

I need to resolve this roadblock of constraint serialization inconsistency. Is it a problem? If it is, do I need to throw out the entire design and start again?

SciCloj: Daniel Slutsky

Q3 2024 Report No. 1, Published Oct. 3, 2024
The Clojurists Together organisation has decided to sponsor Scicloj community building for Q3 2024, as a project by Daniel Slutsky. This is the second time the project is selected this year. Here is Daniel’s update for September.

Comments and ideas would help. :pray:

Scicloj is a Clojure group developing a stack of tools and libraries for data science. Alongside the technical challenges, community building has been an essential part of its efforts since the beginning of 2019. Our current main community-oriented goal is making the existing data-science stack easy to use through the maturing of the Noj library, mentioned below. In particular, we are working on example-based documentation, easy setup, and recommended workflows for common tasks.

All these, and the tools to support them, grow organically, driven by real-world use cases.

I serve as a community organizer at Scicloj, and this project was accepted for Clojurists Together funding in 2024 Q1 & Q3. I also receive regular funding from Nubank.

In this post, I am reporting on my involvement during September 2024, as well as the proposed goals for October.

I had 77 meetings during September. Most of them were one-on-one meetings for open-source mentoring or similar contexts.

All the projects mentioned below are done in collaboration with others. I will mention at least a few of the main people involved.

September 2024 highlights

Scicloj open-source mentoring

Scicloj is providing mentoring to Clojurians who wish to get involved in open-source. This initiative began in August and has been growing rapidly in September. This program is transforming Scicloj, and I believe it will influence the Clojure community as a whole.

We are meeting so many incredible people who are typically experienced, wise, and open-minded and have not been involved in the past. Making it all work is a special challenge. We have to embrace the uncertainty of working with people of varying availability and dynamically adapt to changes in the team. Building on our years-long experience in community building and open-source collaboration, we know we can support at least some of our new friends in finding impactful paths to contribute. We are already seeing some fruits of this work and still have a lot to improve.

47 people have applied so far. 34 are still active, and 10 have already made meaningful contributions to diverse projects.

I am coordinating the process, meeting all the participants, and serving as one of the mentors alongside generateme, Kira McLean, Adrian Smith, and Jeaye Wilkerson. The primary near-term goals are writing testable tutorials and docs for the Fastmath and Noj libraries. Quite a few participants will be working on parts of this core effort. A few other projects where people get involved are Clay, Kindly, Jank, and ggml.clj.

A few notable contributions were by Avicenna (mavbozo), who added a lot to the Fastmath documentation and tutorials; Jacob Windle, who added printing functionality to Fastmath regression models; Muhammad Ridho, who started working on portability of Emmy Viewers data visualizations; Lin Zihao, who improved the Reagent support to the Kindly standard; Epidiah Ravachol, who worked on insightful tutorials for dtype-next array-programming; Oleh Sedletskyi, who started working on statistics tutorials; Ken Huang, who’ve made various contributions to Clay; and Prakash Balodi, who worked on Tablecloth issues and started organizing the Scicloj weekly group (see below).

Noj

Noj is an entry point to data and science. It integrates a set of underlying libraries through a set of testable tutorials. Here, there were great additions by generateme and Carsten Behering, and I helped a bit with the integration.

generateme has made a big release of Fastmath version 3.0.0 alpha - a result of work in the last few months - which is affecting a few of the underlying libraries.
Carsten Behring has released new versions of a few of the machine learning libraries.
Carsten also made important changes to Noj in adding integration tests and automating the dev workflow.
I helped in gradually adapting and testing a few of the underlying libraries.
I helped initiate a few documentation chapters that are being written by new community members.

Kindly

Kindly is the standard of data visualizations used by Scicloj tutorials and docs.

Timothy Pratley has improved the way the user controls various options.
I helped test and integrate the new features.
We collaborated in creating a kindly-dev team, and a few of the new friends have started contributing to the stack of libraries around Kindly.

Kindly-render

Kindly-render is a general rendering library which serves as a foundation for tools to support Kindly.

Timothy Pratley has reinitiating this project.
I joined in design discussions and testing.

Clay

Clay is a REPL-friendly tool for data visualization and literate programming.

I worked on two new release versions. Each was a combination of bugfixes and feature requests.

real-world-data group

The real-world-data group is a space for people to share updates on their data projects at work.

Meeting #13 was dedicated to talk runs and discussions preceding the Heart of Clojure conference. Meeting #14 was an interactive coding session of a data science tutorial.

Scicloj weekly

Together with Prakash Balodi, we initiated a new weekly meeting for new community members working on open-source projects.

Intentionally, we use a time slot which is more friendly to East and Central Asia time zones, unlike most Clojure meetups.

We have had three meetings so far, with 4, 15, and 6 participants.

Linear Algebra meetings

We organized a new group that will collaborate on implementing and teaching applied linear algebra algorithms in Clojure.

The first meeting actually took place in October 2nd, so we will update more in the next month.

Heart of Clojure

Sami Kallinen represented Scicloj at Heart of Clojure with an incredbible talk about data modelling. The talk was extremely helpful in exploring and demonstrating a lot of the new additions to the Scicloj stack.

I collaborated with Sami on preparing the talk and improving the relevant tools and libraries to support the process.

October 2024 goals

This is the tentative plan. Comments and ideas would be welcome.

Noj and Fastmath

Both these libraries will recieve lots of attention in the form of (testable) tutorials and docs. I will be working with a few people on vairous chapters of that effort.
We will keep working on stabilizing the set of libraries behind Noj and improving the integration tests.

Open-source mentoring

We are expecting more participants to join.

I will keep working on supporting participants in new beginnings and ongoing projects.

Tableplot

Tableplot is a layered grammar of graphics library.

The goal for the coming few weeks is to bring it to beta stage and mostly improve the documentation.

Tooling

We will keep working on maturing kindly-render and refactoring Clay to use it internally.
Clay will be in active development for code quality, bugixes, and user requests.

Clojure Conj

The coming Clojure Conj conference will feature a few Scicloj-related talks. At Scicloj, we have a habit of helping each other in talk preparations. We will do that as much as the speakers will find it helpful. We will also organize a couple more pre-conference meetings with speakers, as we did in August.

Standard Clojure Style: Chris Oakman

Q3 2024 Report No. 1, Published Oct. 14, 2024

Standard Clojure Style is a project to create a “follows simple rules, no config, runs everywhere” formatter for Clojure code.

tl;dr

project is usable for most codebases in its current state
many bugs fixed
I will be presenting Standard Clojure Style at Clojure/conj 2024
website is next

Update

As of v0.7.0, Standard Clojure Style is ready for most codebases
- Give it a try!
- Standard Clojure Style is fast: Shaun Lebron shared some benchmarking on Issue #77
Several adventurous Clojure developers have ran Standard Clojure Style against their codebases and found bugs.
- I have fixed most of the reported ones.
- Seems like most new bugs are “small edge cases” as opposed to “large, fundamentally broken”
- A big thank you to these developers and their helpful bug reports!
- If you want to help test, please see the instructions in the README
I will be presenting Standard Clojure Style next week at Clojure/conj 2024 :tada:
- Come say hello if you will be attending
- I will also socialize the project at the conference

Next Up

I will continue work to stabilize the library and algorithm
I will work on a website to explain the project
- There should be a “try it online” demo
- Explanation of the formatting rules (what are the rules? and why?)
- Something that teams can reference when they are deciding to adopt a formatter tool for their Clojure project

2024 Annual Members' Meeting

Sat, 26 Oct 2024 14:00:00 +1200

Please Join Us for our 4th Annual Members' Meeting

Our annual meeting is fast-approaching. Just a reminder to join us for our 2024 update and discussion. If you are planning on dialing in, please contact me at kdavis@clojuriststogether.org and I will send you our Zoom link.

Meeting Details: Oct. 29, 2024 - 10 am Pacific time

Some select times to help you plan: Auckland Wed., Oct 30, 6 am
Chicago Tues., Oct 29. 12 pm (noon)
New York, Tues., Oct 29, 1 pm
São Paulo, Brazil, Tues., Oct 29, 2 pm
London, Tues. Oct 29, 5 pm
Amsterdam, Barcelona, Belgrade, Berlin, Paris Tues., Oct. 29, 6 pm

Looking forward to seeing you soon!

July & August 2024 Project Updates

Sat, 14 Sep 2024 14:00:00 +1200

This month we have reports from both our 2024 long-term developers as well as from two shorter-term projects. Thanks everyone for the great work!

Short-Term Projects

Janet A. Carr: Enjure
Thomas Clark: Wolframite

2024 Long Term Projects

Bozhidar Batsov: CIDER. Orchard
Michiel Borkent: squint, babashka, neil, cherry, clj-kondo, and more
Toby Crawley: clojars-web
Thomas Heller: shadow-cljs
Kira McLean: Scicloj Libraries. tcutils, Clojure Data Cookbook, Mentoring
Nikita Prokopov: Humble UI, Clojure Sublimed
Tommi Reiman: Reitit 7.0. Malli
Peter Taoussanis: Tempel, Tufte, Telemere

Short-Term Projects

Janet A. Carr: Enjure

Progress has been a bit slow in this latter half of the project. I haven’t elaborated too much of the implementation of Enjure, rather I’ve written some documentation in the github repository as well as deployed a website for the project over at enjure.org. The website covers the basic philosophy and architecture as well as how to get started with Enjure by using the CLI. I’m hoping to give both Enjure and it’s website some more love in the future when I have time. However, for the couple month span of the project thus far, I think it’s been relatively successful in flushing out some of the ideas I have for the project. A true OSS MVP, if you will.

Thomas Clark: Wolframite

Overview (TL;DR)
Initialization
Evaluation model
Documentation, packaging and literate programming
Future outlook

Overview (TL;DR)

In a nutshell, our proposal was about reawakening and increasing the ease of Wolfram interop with Clojure. In this second part of the project we continued to fix some minor bugs across the board (quelle surprise), as well as some bigger ones that had crept in with respect to jlink setup and initialization. The main focus however, was on user experience, particularly in regards to customizability: we don’t just want access to Wolfram, but to a user-configurable Wolfram! In this regard, we fundamentally changed the initialization system, such that the user can now pass options to the library at runtime: particularly in regard to user-defined function and symbol aliasing. In a similar vein of explicitness, we remodelled the evaluation system such that expressions are only computed on command. This, as described below, should not only make computations more efficient to run, but also expressions more efficient to write. Last, but certainly not least, we put effort into the otherwise Sisyphean task of documentation. Aside from the usual docs, we put significant effort into revamping demo namespaces and creating short and long-form tutorials: integrating everything into a literately-programmed quarto-based website. On top of this, we created (with new build script) our first clojars package. In fact, it’s time to introduce Wolframite 1.0!

Initialization

The initialization system has been rebuilt to avoid implicit background loading on namespace imports. Making this wholly explicit adds an extra line to a user’s program, but clarifies that the operation is side-affecting, while givng the user control over how and when the Wolfram kernels are started and stopped. Most importantly, introducing a start function (with an options map) gives the user access to the internals of the bridge, such that user preferences can be delivered at runtime, on a document by document basis.

We hope that this will be increasingly useful in the future, but already allows the user to define their own aliases to Wolfram functions: greatly shortening and improving the readability of long expressions. Below, we can see what this looks like in practice. More than just giving the user the chance to rename symbols to their liking, the alias system (thanks to unicode support in clojure) allows the user to use real mathematical symbols in their analysis, rather than reverting to awkward function naming. Remember, Wolfram only allows lower- and upper-case latin and numbers!

    (def aliases
      '{** Power
        ++ Conjugate
        ++<-> ComplexExpand
        >< Simplify
        >><< FullSimplify
        ⮾ NonCommutativeMultiply
        √ Sqrt
        ∫ Integrate})
    
    (wl/start {:aliases aliases})
    
    (w/>><< (w/∫ (w/++<-> (w/+ (w/** 'x 4)
                               (w/√ (w/++ 'x))
                               (w/* 3 'x)))))

Evaluation model

A big part of this work has been rebuilding the evaluation model. It was not an easy decision, but was motivated by several factors. First of all, Wolfram expressions can be long and yet, previously, all loaded symbols became executable functions. This meant that every nested s-expression led to a separate call to the underlying kernel, which did not seem efficient. Similarly to the case of initialization, part of the solution was to drop auto-evaluation entirely and to require an explicit eval call. This adds a small step for the user, but gives back control. It also allows you to pass runtime options and preferences to the evaluation, such as last-minute aliasing.

Another problem was the ergonomics of mixing Clojure and Wolfram expressions. Previously, familiar numerical clojure operators were reused as Wolfram operators and so the first line below would run fine when evaluated with Wolfram. Unfortunately however, it was very easy to write the second line, which would fail. Also, when relying on the quoting of symbols, you quickly run into trouble with standard macros (third line). In general therefore, we want to separate Clojure and Wolfram functions and have as little raw symbol manipulation as possible (even though it’s still useful to fall back on).

    '(+ 2 (Plus 3 4))
    
    (+ 2 '(Plus 3 4))
    
    (-> 'x
        '(Integrate x)
        wl/eval) ;; fails with error!

A previous solution to these problems was to load Wolfram functions at runtime under a clojure symbol; this helped alleviate the situation, but, as it wasn’t a real namespace, then the functions could not be required and therefore not consistently used in a library: what if someone picked a different symbol next time? Instead, Wolframite comes with a pre-generated Wolfram symbol namespace that can then be updated and extended by the user using the provided function, as demonstrated below.

    (comment (write/write-ns! "src/wolframite/wolfram.clj"
                              {:aliases '{** Power
                                          badger Subtract}}))
    (ns physics.cavity.simple-PRs
      (:require [wolframite.core :as wl]
                [wolframite.impl.wolfram-syms.write-ns :as write]
                [wolframite.wolfram :as w]))

This system is slightly brittle at the moment, but so far provides a best of both worlds approach. Wolfram symbols are now loaded (not as executable functions) as a real namespace and this leads to more composable expressions:

    (-> 'x
        (w/Integrate 'x)
        wl/eval) ;; (* 1/2 (Power x 2))

In general, it also removes the need to overload Clojure operators with Wolfram ones (different namespaces), allows you to treat aliases exactly the same as Wolfram functions and maintains editor autocompletion.

Documentation, packaging and literate programming

With usability in mind, another big part of this project was documentation and code hygiene. We’re still far from Knuth’s idea that:

Programs are meant to be read by humans and only incidentally for computers to execute.

, but we’re happy to have taken a significant steps in this direction. We moved the dial on API docstrings and the README; laid out a couple of substantial real-world physics examples and incorporated these into a website, along with updated versions of the introductory demos (where every page is a literate namespace). We also, with thanks to Daniel Slutsky, made Knuth happier by introducing a reliable method of displaying Wolfram expressions using TeX: particularly in the context of literate namespaces. Unfortunately, we have not yet got much feedback from the wider community (because we were late in launching and publicizing), but we have made a tentative start on integrating the library and maintainers with the data science community on zulip. We realize however, that there is still much to do in this space. And so it is worth mentioning that we are strongly commited to the development of this library in the medium term, with ongoing tech. support (of the IT, rather than Knuth variety).

Future outlook

Some things took less time than expected (making a convenient package system); other things took more (the unexpected new evaluation model). Such is the case, and since we’re currently waiting to hear back from the Wolfram staff, there are a couple of outlying goals that need more work. One of these is more explicit work on the underlying kernel parallelism. In principle, this hasn’t been affected by our work but we are currently still missing the promised documentation. The other goal that was approached more implicitly was the laying of foundations for integration with emmy. The actual integration with emmy will take a lot of work, but the fundamentals are now here, with the advanced aliasing system now allowing for functional transforms, rather than simply 1-1 symbol replacements. The best parts of this project therefore, we hope, are still to come.

2024 Long-Term Projects

Bozhidar Batsov

While the summer was a bit slower than the previous periods, we still made some solid progress on multiple fronts. The highlight of recent work is undoubtedly nREPL 1.3, which is one of the most ambitious nREPL releases in recent years. Most of the improvements are invisible to the users, but they improve the stability and predictability of nREPL. Here are the highlights:

Stacktraces got drastically shorter. Where the previous versions of nREPL would add 26 frames to the stack, now they are a lot shorter. (like 20 frames shorter)
clojure.main/repl has been replaced with a custom REPL implementation that is closer to how nREPL operates. This gave us more control over classloaders (which caused multiple issues in the past) and shortened the stack.
Support for sideloading has been removed. This experimental feature was not fully fleshed out and hasn’t seen much use by nREPL clients. It might be revived in the future in a different form.
nREPL now uses custom threadpools instead of calling future for its internal asynchronous actions.

CIDER’s snapshot already makes use of it and we’ve gotten reports that the big internal changes haven’t caused any issues. Good stuff!

Some other highlights from the past couple of months:

CIDER (and cider-nrepl) now support the new way of calling Java methods introduced in Clojure 1.11 (see https://github.com/clojure-emacs/cider-nrepl/pull/889)
Orchard now features its own implementation of tracing that replaces the use of tools.trace (see https://github.com/clojure-emacs/orchard/pull/284)
The CI setup for Orchard and cider-nrepl was reworked and now it takes a lot less time to run the tests there
Support for sideloading was removed from CIDER (following its removal from nREPL)
Several bug-fixes here and there

You can play with all of this in the current snapshot version of CIDER. I expect we’ll cut a new CIDER release in the next couple of weeks. Cheers!

Michiel Borkent

Updates In this post I’ll give updates about open source I worked on during July and August 2024. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all.

Current top tier sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which aren’t listed above, please get in touch. On to the projects that I’ve been working on!

Updates

Here are updates about the projects/libraries I’ve worked on in July and August.

clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- Unreleased:
- #2386: fix regression introduced in #2364 in letfn (unreleased)
- v2024.08.29:
- #2303: Support array class notation of Clojure 1.12 (byte/1)
- #916: New linter: :destructured-or-binding-of-same-map which warns about :or defaults referring to bindings of same map, which is undefined and may result in broken behavior
- #2362: turn min-version warning into lint warning
- #1603: Support Java classes in :analyze-call hook
- #2369: false positive unused value in quoted list
- #2374: Detect misplaced return Schemas (@frenchy64)
- #2364: performance: code that analyzed fn arity is ran twice
- #2355: support :as-alias with current namespace without warning about self-requiring namespace
- v2024.08.01:
- #2359: @x should warn with type error about x not being an IDeref, e.g. with @inc
- #2345: Fix SARIF output and some enhancements (@nxvipin)
- #2335: read causes side effect, thus not an unused value
- #2336: do and doto type checking (@yuhan0)
- #2322: report locations for more reader errors (@yuhan0)
- #2342: report unused maps, vectors, sets, regexes, functions as :unused-value
- #2352: type mismatch error for or without arguments
- #2344: copying configs and linting dependencies can now be done in one go with --dependencies --copy-configs
- #2357: :discouraged-namespace can have :level per namespace
babashka: native, fast starting Clojure interpreter for scripting.
- Mostly bumped library dependencies and improvements in SCI
edamame: Configurable EDN/Clojure parser with location metadata
- Support new Clojure 1.12 array notation
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Fix #923: check for duplicate keys in dynamic set or map literals
- Fix #926: Support add-watch on vars in CLJS
cherry: Experimental ClojureScript to ES6 module compiler
- #135: Fix UMD build
nbb: Scripting in Clojure on Node.js using SCI
- Bump org.babashka/cli
- Bump SCI
quickdoc: Quick and minimal API doc generation for Clojure
- Fix #39: fix link when var is named multiple times in docstring
http-server: serve static assets
- #13: add an ending slash to the dir link, and don’t encode the slashes (@KDr2)
- #16: support range requests
CLI: Turn Clojure functions into CLIs! \
- Fix #102: format-table correctly pads cells containing ANSI escape codes
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Upgrade/sync with clojure CLI v1.11.4.1474
- deps.clj is now available as clojure.exe via the clj-msi installer and the official installation method on plain Windows!
fs - File system utility library for Clojure
- #132: add read-link to resolve symbolic link, without target of link needing to exist
tools: a set of bbin installable scripts
- Updated antq
- Added --minimize option to the ddiff script
http-client: babashka’s http-client \
- Ensure that http-client works with Clojure 1.10 as the minimum supported Clojure version
sci.nrepl: nREPL server for SCI projects that run in the browser
- Mostly changes to accomodate running sci.nrepl with clerk viewer functions
clerk: Moldable Live Programming for Clojure
- Mostly worked on making viewer functions available from .cljs files and allow working on them via a nREPL session
squint: CLJS syntax to JS compiler
- Nikita Prokopov made the squint logo!
- #542: fix run on Windows

Other projects

Toby Crawley

August 2024

Commit Logs: clojars-web, infrastructure

July 2024

Commit Logs: clojars-web, infrastructure

Bug fix: Properly delete artifacts from S3
clj-kondo ugrade and linting cleanup
Upgrade to Clojure 1.12.0-beta2
Use latest AL2023 AMI as base when building our AMI

Thomas Heller

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (eg. Clojurians Slack).

Current shadow-cljs version: 2.28.14 Changelog

Notable Updates

Updated nREPL Server to 1.3.0

Kira McLean

This is a summary of the open source work I’ve spent my time on throughout July and August, 2024. There was a blog post, some library updates, and lots of community work.

Sponsors

This work is made possible by the generous ongoing support of my sponsors. I appreciate all of the support the community has given to my work and would like to give a special thanks to Clojurists Together and Nubank for providing me with lucrative enough grants that I can reduce my client work significantly and afford to spend more time on these projects.

If you find my work valuable, please share it with others and consider supporting it financially. There are details about how to do that on my GitHub sponsors page. On to the updates!

Blog post

At the beginning of the summer Daniel Slutsky and I were feeling very ambitious and thought we might be able to put together a course for data scientists coming to Clojure from other languages. For many reasons, this hasn’t materialized yet, but in service of these plans I wrote a blog post comparing tablecloth to other common data processing tools, like dplyr, pandas, and polars. My goal was to put tablecloth in perspective, illustrating some of the key differences between it and other standard, more popular, data processing tools.

`tcutils`

I added a few more helpers to tcutils, like between and duplicate-rows, and also made a docs website for the project. I also had many interesting conversations with people in the community about how Clojure’s data processing tools “feel” to work with, and how we might adopt APIs and conventions that are familiar to data scientists in the interest of making their transition to Clojure’s ecosystem as smooth as possible.

Clojure Data Cookbook

This month I added a chapter about working with data from databases, starting with SQL, and also continued to work on the end-to-end example for the introductory section. Working with real data is very difficult and interesting, and it’s a fun challenge to try to figure out the right balance between getting into the weeds and compromising on the final result. So much of data science is just cleaning up messy data from the world, but surprisingly often you have to make some assumptions about how you’re going to use the data in order to make decisions about how to do the cleaning. And there are tons of different ways to “clean” data, but the strategies you use depend on what information you’re after.

In the particular example of the housing dataset I’m working with there are many missing values to handle, and some questionable rows that look like duplicates but aren’t exactly duplicates. There are also lots of illogical data points, like house sales from the future or multiple sales for the same property on a given date. Deciding how to handle these cases to build up a “clean” dataset to actually work with is a very interesting exercise in domain modelling and goal setting.

Scicloj mentoring program

This one is really mostly Daniel Slutsky’s amazing work, but we collaborated on launching it and it’s definitely worth mentioning. We put together a structured way for people to get involved in contributing to Clojure’s open source data science ecosystem, and got an overwhelmingly positive response. Over 25 people reached out to express an interest in contributing their time to Scicloj projects. The structured parts of the program include having some help choosing a meaningful and impactful project to work on, and up to an hour per week of one-on-one time with a mentor to help things progress. Daniel is doing all the heavy lifting coordinating the mentors, but it’s been great so far participating as one and meeting some very keen and smart people who are willing to help us move things forward.

Another big part of this is thinking of the projects to work on. We came up with a list of projects that would deliver high value to the community but remain small enough to tackle by a single developer. We also tried to come up with ones that would require a wide range of skills and interests to try to accommodate as many people as possible. I am super excited to see how things go over the next few months with all of these projects.

Other community connections

I’m still doing my weekly data-science drop-in streaming with Clojure Camp. I really enjoy connecting with other people who are interested in Clojure for data science, and I often get great suggestions and tips, too.

I also met with a couple of groups of people who are presenting at the Conj this year to help brainstorm some ideas for how to make the most of the talks. Daniel has amazing vision for the community and organized these calls that I was lucky enough to join. The goal is to connect all of the people who are giving data-related talks to optimize the overall messaging, like minimizing duplication across talks or drawing examples from each other’s presentations. I love conference speaking and hope to do more of it in future years when my personal commitments allow for it, but in the meantime it’s really amazing getting to connect with such cool people in the community to learn about their talks and brainstorm ideas for making them the best they can be. I’m hoping to attend the conference this year to see some of these great talks in person.

Personal Updates

This has been a really amazing year professionally, having had the opportunity to spend much more time than in the past on open source and public work for the Clojure community. I’ve been trying to make the most of it and it’s been really rewarding. Over the next couple of months, there are some other parts of my life that will be taking precedence, however.

The main one is my relationship. I’m getting married in a couple of weeks and will be taking almost a month off between getting ready for the wedding, wrapping up all the loose ends afterward, and a nearly 3-week-long honeymoon. I’ve never taken this long off of work in my life, so I’m both excited and curious to see what it’s like. For over a decade now my career has been taking up most of my time and energy. It’s been well worth it and I’m really happy with my work now, but I’m also excited to be stepping into a new chapter of life where things can be more balanced.

Related to this, the other major update I have to share is that I’ve accepted a full time job with a company called BroadPeak which I will be starting as soon as I’m back from my honeymoon. It’s a small fintech company built primarily with Clojure that handles trade data management, commodities transaction surveillance, regulatory compliance, and other things related to the behind-the-scenes of commodities trading. I think it’s a perfect fit for my skills and interests, and I’m hoping to have a chance to build some bridges between a really exciting, growing company that uses Clojure for real-world financial data processing and the Clojure open source community. Initial conversations about how the engineering team there feels about open source and community involvement have been really promising, so I’m optimistic that it will work out well for everyone. I’m not sure yet what exactly my open source work will look like once this job starts, but at a minimum I will still be working on the various side projects, like I always was before I tried giving it a go full time.

No matter how things go, I’ll be back in two more months with another update. Thanks for reading. As always, feel free to reach out, and hopefully see some of you at the Conj! :)

Nikita Prokopov

Hello dear sponsors, thank you all for your continous support. Last two months have been really heavy on Humble UI and Clojure Sublimed.

Clojure Sublimed

Clojure support for Sublime Text 4:

New syntax that can highlight reader comments comment.reader together with the following form,
Highlight (comment ...) blocks as comment.form,
Highlight namespaces in symbols as meta.namespace.symbol,
Highlight unused symbols as source.symbol.unused,
Properly highlight entity.name in def* forms only at second position, skipping all meta/comments,
Quote & syntax quote highlight following form as meta.quoted and meta.quoted.syntax,
Metadata highlights following form as meta.metadata,
Octal & arbitrary radix integers 71,
Better keyword detection,
Built-in color scheme to utilize REPL and new syntax features,
clojure_sublimed_reindent command that reindents entire buffer if selection is empty and only selected lines if not,
Option to use cljfmt for code formatting,
Removed separate EDN syntax, merged with main Clojure (Sublimed),
Settings can now be specified in main Preferences.sublime-settings as well. Just prepend clojure_sublimed_ to each setting’s name,
REPL can detect namespaces with meta on ns form 116,
Detect .shadow-cljs/nrepl.port and .shadow-cljs/socket-repl.port 114,
Connect commands now accept timeout argument for automation scenarios like “start clojure, start trying to connect to REPL until port is available”,
Eval previous form at current level 118,
Auto-detect UNIX sockets, support relative paths,
Correctly parse escaped comma 120 via @oakmac

Humble UI

Clojure Desktop UI framework:

Renamings (halign/valing → align, width/height → size, rect → bounds, vscroll → vscrollable, vscrollbar → vscroll, use-size -> with-bounds, rounded-rect → rect, clip-rrect → clip),
Normalized most of the components to have opts as first argument,
Declarative font management,
Viewport & optimized rendering for components outside it,
.-parent node field on all ANodes,
-reconcile-opts to migrate props,
Built-in profiler,
Full-fledged demos & source examples for some components,
New components: ui/link,
New demos: whiteboard,
Better code organization,
Fixed REPL reloading,
Fixed crash on scale change,
Removed dynamic/with-context-classic,
Simplified memo-fn,
Added :window-scale-change event

JWM

Cross-platform window management and OS integration library for Java:

macOS: Stable screen ids
macOS: Do not stop cvdisplaylink

DataScript

immutable database and Datalog query engine for Clojure, ClojureScript, and JS:

Regression: transacting many ref value as a set of inline maps 476
Fixed find-datom on empty DB 477

Clj-Simple-Router

Simple order-independent Ring router:

Add a complete example to the README 2
Added clj-kondo analyzer for routes macro 3 with goshatch

Sublime Executor

Executable runner for Sublime Text:

1.5.1 Trim command name in status bar 7

Uberdeps

Uberjar builder for deps.edn:

merge :override-deps from :aliases 49 53 via @dkick

Blogging:

Designing:

A logo for squint, a light-weight dialect of ClojureScript.

Tommi Reiman

Two big release of malli and lot’s of WIP work. Explored existing and new Clojure-bindings (with Malli) with latest features of both Anthropic and OpenAIs APIs, one gist here.

Added Ambrose Bonnaire-Sergeant as a maintainer to malli. Lot’s of good disucssions on how the library should go forward. Here’s the Q3 Clojureist Together funding announcement for his work.

Library Releases

malli 0.16.4

Distribute :merge over :multi #1086, see documentation
:multi with keyword :dispatch accumulates data to generated values #1095
Allow m/-proxy-schema child to be a delay #1090
json-transformer decodes 123.0 into 123 for schemas like :int, pos-int? etc. #986
Fix malli.dev.pretty throws when explaining errors in nested maps #1094
Fix ClojureScript arithmetic warning
Fix (-some-pred []) should return false #1101
Doc mu/assoc and mu/dissoc only handle one key at a time #1099
Try to make map-of-min-max-test less flaky by fixing seed #1098
Updated dependencies:

borkdude/edamame '1.4.25' to '1.4.27'

malli 0.16.3

:-> added to default registry, see documentation.
New :seqable and :every schemas #1041, see docs
Fix OOM error with infinitely expanding schema #1069
Correctly form prop-less schemas that have map/nil as first child #1071
Support min/max on uncountables like eductions #1075
Fix clj-kondo can’t parse config.edn written by (malli.dev/start!) #1083
unstrument before instrumenting #1081
Replace .entryAt with .valAt during validation #1079
Corrected DEPRECATED warning for m/-simple-schema #1077

Something Else

Back in the baltics, this time in Lithuania.

Peter Taoussanis

Open source update

Recent work

Hi folks! 👋 I hope those of you in summer are enjoying the nice weather ☀️
Have some chonky updates for today!

Timbre

Timbre is a pure Clojure/Script logging library.

Timbre v6.6.0-RC1 is out now. There’s some internal improvements, but the highlight is added out-the-box support for Java logging interop via SLF4J.

This is handled via a new SLF4J provider/backend dependency available on Clojars - instructions here.

The implementation is back-ported from Telemere and includes support for legacy and modern (“fluent”) SLF4J logging APIs, MDC (context key/vals), markers, etc.

This was one of the upvoted items on my open source roadmap, and definitely something nice to have officially supported.

Previously many Timbre users used the separate slf4j-timbre library for such interop - and I’d like to say a warm thanks to that library’s original author Farid Zakaria and steward / maintainer rufoa.

Their job was a challenging one - needing to keep up with internal changes to Timbre over time, etc. With the new approach, Timbre’s SLF4J support will now always be automatically kept in sync and tested with Timbre’s latest release, which should help minimize future maintenance headaches.

Telemere

Telemere is a modern rewrite of Timbre that offers an improved API to cover traditional logging, structured logging, tracing, basic performance measurement, and more.

My big focus recently has been Telemere, with 8 new beta releases since June.

The latest as of this post is v1.0.0-beta22 (2024-08-28).

The basic API has been stable, including re: signal creation and signal content - but I’ve been continuing to polish things in preparation for RC1 (expected next month).

Recent improvements include:

Significantly improved OpenTelemetry interop

This was another upvoted item from my open source roadmap, and quite a bit of work to get just right.

Telemere can now send signals as OpenTelemetry LogRecords with correlated tracing data to configured OpenTelemetry Java exporters.

This allows output to go (via configured exporters) to a wide variety of targets like Jaeger, Zipkin, AWS X-Ray, AWS CloudWatch, etc.

See here for instructions.

A couple nice properties of the way Telemere handles OpenTelemetry interop:

Aside from configuring OpenTelemetry Java itself, Telemere’s OpenTelemetry interop doesn’t require any use of or familiarity with the OpenTelemetry Java API or concepts. So if you’re like me, you’ll be pleased to know that you can basically avoid all the usual OpenTelemetry API nonsense. You just use Telemere as you normally would, and it’ll act as your interface to OTel.
Creating OpenTelemetry tracing spans and attaching attributes can be expensive, which violates a unique design goal of Telemere - to make it possible to dynamically filter costs as you filter signals. Telemere works around this by creating only minimal spans at first (to enable full interop with auto-instrumentation and other OTel tools), and saving all the expensive work for the post-filter signal handlers. Basically this gives you best of both worlds: full auto interop, but also lazy costs well-suited to Telemere’s rich filtering architecture.

For feedback and/or experience reports, please feel free to ping me on the Slack channel or GitHub.

Significant doc improvements

A major focus for Telemere has been the docs and examples.
My hope is to build something friendly enough for complete beginners.

If you haven’t looked at them yet (or recently), it might be worth checking out the README, Wiki, or API docs.

Some good starting points:

Introduction (concepts, terminology)
Creating signals (how to log stuff)
Signal content (what gets logged)
Filtering signals (decide what does/not get logged)
Video demo (concepts, usage - 24 mins)

Facade API for library authors

Telemere now offers guidance for library authors/maintainers that might like to use Telemere in their own library, and offers a new super lightweight Facade API.

For a library using the facade:

If end users already have Telemere, then they’ll get Telemere signals out of the library. (And full filtering capabilities, etc.).
If end users don’t have Telemere, then the library can instead log using something like tools.logging.

General comments / status

Telemere may seem a bit of an odd animal at first since it looks like a logging library that’s hesitating to call itself a logging library. As it took shape, I struggled with how to describe it.

What I’d say today: Telemere’s basically meant to be a one-stop API for all the most common observability needs. These include traditional (string-oriented) logging, structured logging (arb nested Clojure data), events, tracing, and basic performance monitoring.

What I realised thinking about this problem space over the years - is that all of the above share fundamental ideas and needs:

We want to capture info in our systems at some point
We want to do it conditionally
We want to do something useful with that info

I suspected that a single API would do - but I wasn’t sure until I tried. When I did try, what I ended up with was actually a single macro (signal!) that handles all of the above through a handful of options.

I’m honestly very happy with the result - I find it elegant, easy to use and to understand, and deeply flexible. And I’m proud of the particular combination of ease-of-use and power - since these goals are often in conflict.

I’ll note that Telemere’s approach is possible only in a Lisp. And certain aspects of its implementation (esp. re: interop) are possible only in Clojure. So the value proposition here is unique.

At the risk of being overly blunt: observability matters, and in my opinion Telemere offers a code-side observability story that’s competitive with anything else I’m aware of in any language.

Part of my motivation in pursuing this particular project has been to try to use Clojure’s unique strengths to offer a unique and compelling advantage to Clojure projects/businesses/teams. Clojure enables Telemere, Telemere helps enable inexpensive and effective observability, observability helps enable more robust and debuggable systems. And used wisely, robustness and debugability can help enable successful projects.

So the idea (hope) is to be both a practical tool, and a reference example of one of the kinds of real-world advantages made possible by Clojure.

Upcoming work

As always please do help vote on what you’d like to see me working on!

Telemere

My aim is to release v1 RC1 in September, then v1 final before the end of 2024.

The big stuff is all done, what remains is to give folks the opportunity to kick tyres and report issues or request changes before locking down the API.

Please also vote on which signal handlers would be most useful.

After that, my hope will be for Telemere to basically be stable - and to redirect future efforts toward education and promotion. Telemere enables a lot of powerful but non-obvious stuff, which I’ll need to do more work to explain.

Tempel

Tempel is a new data security framework for Clojure.

I’d like to release v1 final before the end of 2024. Still have some last features to think through and design (multi-factor authentication, etc.).

Tufte

Tufte offers simple performance monitoring for Clojure/Script.

Once Telemere v1 RC1 is out, I’ll be ready to prepare Tufte v3 - which’ll include a move to the exact same signal architecture powering Telemere.

Tufte and Telemere will then share identical terminology, capabilities, and API for filtering, handlers, etc.

The two already work well together, but interop will be even smoother after v3. The aim is to offer Telemere and Tufte as partner (complementary) libraries to enable unique next-gen observability capabilities for Clojure and ClojureScript applications.

2024 Board Nominations and Our Annual Meeting

Mon, 02 Sep 2024 08:30:00 +0800

Clojurists Together is having our fourth board elections, and our fourth annual members meeting.

Key dates

(All dates are EOD, in Pacific Time)

Board nominations close: Sept. 23, 2024
Voting opens: a few days after submissions close and the board has nominated candidates
Voting closes: October 14, 2024
Annual members meeting: Oct. 29, 2024 - 10 am Pacific time

Board Elections

Committee members are elected for a two-year term. Each election cycle, half of our board seats come up for re-election. This year there are three seats available.

If you are interested in standing for election, please fill out this form by Sept. 23rd, 2024 - 5 pm Pacific Time. If you can’t access the form, contact us, and we can accept your nomination by email. Nominations are open to anyone, you don’t have to be a Clojurists Together member to stand for election. Our bylaws do require you to be a member if elected to the board, though we provide a stipend that offsets the cost of your membership.

As part of the nomination, if we get more than 12 candidates for board membership, the board will nominate no more than 12 candidates. Our bylaws state:

The Board shall nominate no more than 12 candidates seeking board membership in any given election. In nominating candidates for Director positions and in choosing the number of candidates to nominate overall, the Board shall use reasonable efforts to maintain a Board composition consisting of at least: (1) 25% female Directors, (2) 25% non-Caucasian Directors, and (3) 35% from any category(ies) of persons (e.g., race, gender, ability) commonly considered to have suffered from discrimination at some time and then-currently under-represented in the technology industry, in each case as determined by the Board in its reasonable discretion.

The main responsibilities of a committee member are:

Participate in the general discussions of the month-to-month running of the program
Evaluate and vote on which open source projects to fund
Help in decision-making for the future plans of Clojurists Together
These responsibilities take roughly one hour/month, though there are peaks and troughs of activity as we go through our quarterly funding cycle. If you have more time to offer, there are lots more things that need developing, automating, designing, e.t.c. It would be great to have you help out with those things, but we don’t want to exclude people from standing because they don’t have a lot of spare time.

Elections will be held once the candidates are announced, and all Clojurists Together members will be eligible to vote.

Annual Members Meeting

We are also holding our third members meeting at 10 am Pacific time, October 29, 2024. This will be an opportunity for Clojurists Together to share information about 2023 to date and discuss future plans, present the new board members, and most importantly take questions from and engage with members.

More details on this will follow including a videoconferencing link.

Q3 2024 Funding Announcement

Tue, 27 Aug 2024 08:30:00 +0800

Clojurists Together is excited to announce that we will be funding 7 projects in Q3 2024 for a total of $35K USD (3 for $9K and 4 shorter or more experimental projects for $2K). To date in 2024, we have or are funding 30 projects or developers for a total of $258,000 USD. This includes the 8 long-term developers whose project work we are supporting for the year. Thanks to all our members for making this happen!

Based on your input on our last two surveys, we know that our members and larger Clojure community rely on this work on a regular (most on a daily) basis. If we are able to engage more companies or individual developer members, we could support even more important work - so please get the word out.

As usual, we received a LOT of great proposals - so the decision-making was not easy. However, proposals are returned to the pool for another 2 rounds for consideration. Here is a general overview of what each developer plans to work on. We’re looking forward to their regular updates as the projects progress!

$9K Projects

Clojure Goes Fast: Oleksandr Yakushev
Malli: Ambrose Bonnaire-Sergeant
Scicloj: Daniel Slutsky

$2K Projects

Clj-nix, nixpkgs: Jose Luis Lafuente
Jank: Jeaye Wilkerson
Kushi: Jeremiah Coyle
Standard Clojure Style: Chris Oakman

$9K Projects

Clojure Goes Fast: Oleksandr Yakushev

I plan to spend these three months improving different tools under the Clojure Goes Fast umbrella.

For clj-async-profiler, the most accurate performance profiler for Clojure, I want to create a brand new web application that will allow users to host and share the generated flamegraphs. At the moment, even though flamegraphs are just self-contained HTML files, sending them to somebody is a chore. The new service can make this much easier and offer extra features like saving and sharing dynamic transforms on the fly. Additionally, I’d like to focus on the UI side of clj-async-profiler - add new dynamic transforms, improve aesthetics and the UX.

For clj-java-decompiler, I have some ideas to expand its preprocessing abilities to present clearer results to the user. I also want to eventually integrate it more tightly with established Clojure IDEs like CIDER and Calva, which requires some groundwork.

Another focus of mine is populating the Clojure Goes Fast knowledge base (https://clojure-goes-fast.com/kb/) with more articles. I have several topics I want to cover in the knowledge base regarding different types of benchmarking and some fresh ones, and some are written as blog posts and require adapting and bringing the information up to date.

Malli (Constraints and Humanization): Ambrose Bonnaire-Sergeant

This project aims to drastically improve the expressivity of Malli schemas to help address current user feedback and enable future extensions.
The basic idea is to add a constraint language to each schema to express fine-grained invariants and then make this constraint language compatible with validators/explainers/generators/etc so that Malli users can write high-level, precise schemas without resorting to partial workarounds.
A real-world frequent user request on #malli Clojurians is the ability for Malli :map schemas to express constraints about keysets, such as two keys being both present or both absent. Specs/keys supports this using a limited constraint language consisting of (or (and ..)).

It is undesirable to work around this using :fn and :and because it breaks many features of Malli, usually generators and error messages. A better solution would be to support this directly by Malli for maximum compatibility. Unfortunately, this is usually the best and only suggestion, even though it introduces other problems.

I have prototyped this project here: https://github.com/frenchy64/malli/pull/12 I will collaborate with the Malli maintainers to extract and redevelop parts of the prototype. By the end of the project, I hope to have merged support for constraints in Malli along with documentation for its use.

Scicloj: Daniel Slutsky

Our current main community-oriented goal is making the existing data-science stack easy to use through the maturing of the Noj library, mentioned below. In particular, we are working on example-based documentation, easy setup, and recommended workflows for common tasks.

All these, and the tools to support them, grow organically, driven by real-world use-cases.

Here is the current plan for the coming quarter. While the plan focuses on my tasks, many of these tasks are done in collaboration with others. The plan and priorities are frequently updated through discussions at the Scicloj group. Daniel has also provided us a YouTube video explaining more about Scicloj and the project - thanks for this Daniel - it is always fun to hear directly from the source!

Stabilize the Noj v2 project:

https://scicloj.github.io/noj Noj is an entry point for the main data and science libraries. Some parts are under active development and will be stabilized as a group effort in the coming quarter. Specifically, stabilization will involve the following main tasks:

Help with the documentation effort of Fastmath (math & stats) version 3.
Help develop current branches of Metamorph.ml (machine learning) and scicloj.ml.tribuo.
Help with issues in Tablecloth (dataset processing).
Stabilize and extend the API of Hanamicloth (data visualisation).

Improve the Noj documentation:

The goal of the Noj documentation is to introduce the main libraries and explain how they can be composed in typical use cases.

Coordinate the Scicloj open-source mentoring program:

https://scicloj.github.io/docs/community/groups/open-source-mentoring/

Meet all people who apply to the program.
Coordinate the assignment of projects and mentors.
Take part in mentoring most participants.
** Between Aug 10th to Aug 27th:**
21 people have applied and started meeting

Run dev groups and study groups:

https://scicloj.github.io/docs/community/groups/ In the coming quarter, the following will be most active:

real-world-data – a space to discuss data and science projects at work.
jointprob (restarting these days) – studying probability & statistics together with other tech communities.
visual-tools – collaborations of tool-makers and discussion of literate programming, data visualization, and UI design.
data-recur – recurring updates & discussions around building the emerging data stack.

Work on tooling for data & science:

Kindly - a simple data-visualization standard to support compatibility across different tools.
Clay - a notebook tool for interactive data exploration and literate programming.

Work on additional libraries:

Stabilize cmdstan-clj – a Clojure bridge to the Stan probabilistic programming language.
Initiate the development of a grammar-of-graphics library (ggplot-inspired), continuing our experience with Hanamicloth.

Maintain the Scicloj website:

https://scicloj.github.io/

$2K Projects

Clj-nix, nixpkgs: Jose Luis Lafuente

I plan to add an alternative builder for Nix that uses Babashka/SCI instead of Bash. It provides a way for constructing complex Nix derivations using Babashka/SCI entirely, eliminating the need to write any Bash code. My plan is to initially develop the builder under the clj-nix project, but if it gains enough traction I’d consider extracting the new builder to its own project, or even upstreaming it to nixpkgs.

I also plan to add a Babashka writer to nixpkgs. Nixpkgs supports creating self-contained scripts, called “nix writers.” Traditionally written in Bash, recent versions of nixpkgs include the ability to write these scripts in Python, Ruby, or Rust. I propose adding a new writer to support Babashka.

Jank: Jeaye Wilkerson

Jank feels like Clojure now, with 92% syntax parity and nearly 40% clojure.core parity. But it only feels like Clojure to me because none of you are using it yet.

My top priority is to change that.

I’ll be working on building out jank’s nREPL server, which involves implementing bencode support, clojure.test, improving native interop, supporting pre-compiled binary modules, and ultimately adding AOT compilation support.

This is a great deal of work, with many side quests along the way, but I’m aiming to have the nREPL server working from my editor by the end of the year.

Kushi: Jeremiah Coyle

I’ll continue development of Kushi, a foundation for building web UI with ClojureScript. Work during the Q3 funding cycle will focus on finishing the new css transpilation pipeline, significant build system performance upgrades, and implementing a reimagined theming system.

Standard Clojure Style: Chris Oakman

I’ll be developing Standard Clojure Style which is a “no config, runs everywhere, follows simple rules” formatter for Clojure code.
More information about the genesis of the project can be found on Issue #1: https://github.com/oakmac/standard-clojure-style-js/issues/1

2024 Annual Members' Meeting

Tue, 30 Jul 2024 14:00:00 +1200

Annual Members' Meeting

Our 4th annual convening is fast-approaching - so we want to give you advance notice of the date. We know you are busy, but if you could reserve an hour to meet, we would value both your participation and input. Please hold the following date and time on your schedules (certainly not a complete list - but enough to check your time). We’ll be sending out more information and an agenda in the coming month.

Auckland Wed., Oct 30, 6 am
Chicago Tues., Oct 29. 12 pm (noon)
New York, Tues., Oct 29, 1 pm
São Paulo, Brazil, Tues., Oct 29, 2 pm
London, Tues. Oct 29, 5 pm
Amsterdam, Barcelona, Belgrade, Berlin, Paris Tues., Oct. 29, 6 pm

May & June 2024 Long-Term Project Updates

Mon, 22 Jul 2024 14:00:00 +1200

A huge thank you to our 2024 long-term developers for their amazing work in May and June. Check out their latest project updates!

Bozhidar Batsov

This period was quite busy and productive for CIDER and friends. The highlights are 3 (!!!) CIDER releases and a couple of nREPL releases:

CIDER 1.14 (“Verona”)
CIDER 1.15 (“Cogne”)
CIDER 1.15.1 (small bug-fix release)
nREPL 1.1.2 (small bug-fix release)
nREPL 1.2.0

CIDER 1.14 is our most ambitious release since CIDER 1.8 (“Geneva”), which was released last autumn.

The single most notable user-visible change of this release is that CIDER is now more robust when evaluating and displaying large values. CIDER will no longer hang when C-x C-eing a big value in a source buffer or stepping over such a value with CIDER debugger.

I’m guessing that many people will also appreciate the improvements we’ve made to flex completion (which is finally fully compliant with the Emacs completion API), the inspector and to the cider-cheatsheet functionality which was mostly redesigned.

nREPL 1.2 restores the ability to interrupt evaluation on JDK 20+ (see https://github.com/nrepl/nrepl/pull/318 for details) and CIDER 1.15 implements support for nREPL 1.2.

More interesting work is in progress, so I hope I’ll have another exciting report for all of you in a couple of months!

Michiel Borkent

Updates In this post I’ll give updates about open source I worked on during May and June 2024. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all.

Current top tier sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which aren’t listed above, please get in touch.

On to the projects that I’ve been working on!

Updates

Here are updates about the projects/libraries I’ve worked on in May and June.

html: Html generation library inspired by squint’s html tag
- A NEW library for html generation that is both safe, performant, generates easy to understand code and works the same across CLJ and CLJS.
babashka: native, fast starting Clojure interpreter for scripting. Released v1.3.191 with the following changes: \
- Fix #1688: use-fixtures should add metadata to *ns*
- Fix #1692: Add support for ITransientSet and org.flatland/ordered-set
- Bump org.flatland/ordered to 1.15.12.
- Partially Fix #1695: --repl arg handling should consume only one arg (itself) (@bobisageek)
- Partially Fix #1695: make *command-line-args* value available in the REPL (@bobisageek)
- Fix #1686: do not fetch dependencies/invoke java for version, help, and describe options (@bobisageek)
- #1696: add clojure.lang.DynamicClassLoader constructors (@bobisageek)
- #1696: add clojure.core/*source-path* (points to the same sci var as *file*) (@bobisageek)
- #1696: add clojure.main/with-read-known (@bobisageek)
- #1696: add clojure.core.server/repl-read (@bobisageek)
- #1696: make the cognitect-labs/transcriptor library work (@bobisageek)
- #1700: catch exceptions from resolving symbolic links during bb.edn lookup (@bobisageek)
- Support java.nio.channels.ByteChannel + several other related interop
- Bump nrepl/bencode to 1.2.0
- Bump babashka/fs
- Bump org.babashka/http-client to 0.4.18
clj-kondo: static analyzer and linter for Clojure code that sparks joy. \
- Fix #2335: read causes side effect, thus not an unused value
- Fix #2336: do and doto type checking (@yuhan0)
- Fix #2322: report locations for more reader errors (@yuhan0)
- Imports were copied to .clj-kondo/imports but weren’t pick up correctly. Thanks @frenchy64 for reporting the bug.
- #2333: Add location to invalid literal syntax errors
- #2323: New linter :redundant-str-call which detects unnecessary str calls. Off by default.
- #2302: New linter: :equals-expected-position to enforce expected value to be in first (or last) position. See docs
- #1035: Support SARIF output with --config {:output {:format :sarif}}
- #2307: import configs to intermediate dir
- #2309: Report unused for expression
- #2315: Fix regression with unused JavaScript namespace
- #2304: Report unused value in defn body
- #2227: Allow :flds to be used in keys destructuring for ClojureDart
- #2316: Handle ignore hint on protocol method
- #2322: Add location to warning about invalid unicode character
- #2319: Support :discouraged-var on global JS values, like js/fetch
squint: CLJS syntax to JS compiler
- #536: HTML is not escaped in dynamic expression
- #537: Fix not: wrap argument in parens
- Return interop expression in function body
- Prefer value from props map over explicit value
- #html improvements, support :& for spreading props
- #492: defclass static methods and fields
- #526: Fix export of class name with dashes
- #517: Preserve state over REPL evals
- #513: Fix shuffle core function random distribution and performances
- #517: Fix re-definition of class with defclass in REPL
- #522: fix nil #html rendering issue
neil: A CLI to add common aliases and features to deps.edn-based projects.
Released version 0.3.65 with the following changes:
- #209: add newlines between dependencies
- #185: throw on non-existing library
- Bump babashka.cli
- Fetch latest stable slipset/deps-deploy, instead of hard-coding (@vedang)
- Several emacs package improvements (@agzam)
cherry: Experimental ClojureScript to ES6 module compiler
- Fix #130: fix predefined :aliases for cherry.embed
- Support IDeref, ISwap, IReset in deftype
clojure-mode: Clojure/Script mode for CodeMirror 6.
- Fix #54: support slurping from within string literal
pottery: A clojure library to interact with gettext and PO/POT files
- Contributed a few improvements to dealing with reader conditionals
nbb: Scripting in Clojure on Node.js using SCI
- Fix cljs.pprint/print-table + with-out-str
- Fixed cljs.test/testing macro to display strings correctly on test failure (@jaidetree)
CLI: Turn Clojure functions into CLIs! \
- Fix #98: internal options should not interfere with :restrict
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Upgrade/sync with clojure CLI v1.11.3.1463

Other projects

There are many other projects I’m involved with but that had little to no activity in the past month. Check out the Other Projects section (more details) of my blog here to see a full list.

Published 30-06-2024.

Toby Crawley

Commit Logs: clojars-web, infrastructure

June 2024

Commit Logs: clojars-web, infrastructure

Thomas Heller

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (e.g. Clojurians Slack).

Current shadow-cljs version: 2.28.10 Changelog

Notable Updates

Reworked some of the shadow-grove internals and adjusted the shadow-cljs UI accordingly. Fixing some old bugs in the process.
Updated some Grove Architecture docs: KV, Big Picture, defc deep dive and impl notes

Kira McLean

This is a summary of the open source work I’ve spent my time on throughout May and June, 2024. There were lots of small bug fixes and reports, driven by work on the Clojure Data Cookbook. This work was also the impetus for my initial release of tcutils, a library of utility functions for working with tablecloth datasets. I also had the wonderful opportunity to attend PyData London in June and found it really insightful and inspiring. Read on for more details.

Sponsors

If you find my work valuable, please share it with others and consider supporting it financially. There are details about how to do that on my GitHub sponsors page. On to the updates!

Ecosystem issue reports and bug fixes

Working on the cookbook these last couple of months turned up a few small issues in ecosystem libraries. The other developers of Clojure’s data science tools are such a pleasure to work with, it’s so rare and nice to have a distributed team of people capable of getting cool things built asynchronously. Here are some details of a few particular issues that came up:

Small problem loading .xls/.xlsx files as datasets if they had a number as a column name: discussed here, reported here, and graciously fixed by Chris Nuernberger.
Unexpected behaviour when comparing certain numeric types in dtype-next: [discussed here](https://clojurians.zulipchat.com/#narrow/stream/236259-tech.2Eml.2Edataset.2Edev/topic/numeric.20datatypes/near/438617694%5D(https://clojurians.zulipchat.com/%23narrow/stream/236259-tech.2Eml.2Edataset.2Edev/topic/numeric.20datatypes/near/438617694), reported here, and again fixed by Chris. This one sadly had some unintended consequences that generateme found and reported here.
Many improvements to Clay by Daniel Slutsky, especially a couple of ones that make the quarto publications it produces much nicer: fixing too-wide tables in quarto pages and supporting limiting the number of table rows that get displayed.
Some good discussions about how best to incorporate the myriad of dependencies required to use Java machine learning libraries in Clojure libs, including sorting out what to do about transitive dependencies in our tribuo wrapper, led by Carsten Behring.

Initial release of tcutils

In my explorations of other languages' tools for working data I often come across nice utility functions that are super simple but have a big impact on the ergonomics of using the tools. I wanted to start bringing some of these convenience utilities to Clojure, so for now I’m putting them in tcutils. So far only a handful of helpers are implemented (lag, lead, cumsum, and clean-column-names). The goal is to eventually fill out more utilities that save people from having to dig into the documentation of half a dozen different libraries to figure out how to implement things like these. The goal is not to achieve feature parity or to exactly copy similar libraries, like pandas or dplyr, but rather to take inspiration from them and make our tools easier to use for people who are used to these conveniences.

Progress on Clojure Data Cookbook

I spent a lot of time on the Clojure Data Cookbook over these last two months. Notable progress includes:

The introductory chapters bear some resemblance now to the final form they’ll take.
The overall structure of the book is much more clear now.
I started the example analysis that will serve as the high-level introductory section of the book.
The publishing and deployment process is finally working.

It’s still very much in progress, but in the interest of transparency the work-in-progress version is available online now. It will continue to evolve and change as I fill out more and more of the chapters, but there’s enough of it available now to hopefully give a sense of the style and tone I’m going for. I also finally have the publishing workflow set up and it’s generating a nice-looking Quarto book, thanks to all of Daniel Slutsky’s amazing work on Clay and Quarto integration recently.

Progress on high-level goals

The high-level goal of my work in general remains to steward Clojure’s data science ecosystem to a state of maturity and flourishing so that data practitioners can use it to get real work done. Toward this end, I set up a project board to track progress toward what I see as the main components of this project.

Over the last couple of months, beginning with a prototype demoed at my London Clojurians talk in April, Daniel Slutsky has made tremendous progress on our goal of implementing a grammar of graphics in Clojure in the new hanamicloth library. The near-term goal is to stabilize the API of this library enough that it can be used to provide a user-friendly way to accomplish all of the simple data visualization tasks that are currently possible with our other tools. The long term goal is to take the lessons we learn from this library and build a JVM-only grammar of graphics library for doing data visualization “right” in Clojure.

The development and surrounding discussions of hanamicloth have also made me realize it would be useful to write an overview of the current state of dataviz options for Clojure and why we’re working on building something new. That’s on my list for the coming months, but lower priority than actual development work.

Impressions from PyData London

I got to attend PyData London this year thanks to a client of mine who was sponsoring the conference. I learned a lot and found the talks very interesting. My overall impression is that data science is maturing as a discipline, with more polished methods and robust theory backing up different approaches to data-related problems. With this maturation, though, comes higher expectations for production-ready, professional quality results. Most of the talks focused on high-level concerns like observability, scalability, and long-term stewardship of large open-source projects.

There are a lot of reasons why Python is just not ideal for building highly available, high-performance systems, and I really believe this is a good time to be building alternative tools for data science. Python is obviously entrenched as the current default language for working with data, but it is difficult and slow to write code that can take full advantage of modern hardware (because of the infamous global interpreter lock, reference counting, slow I/O, among other reasons). And to be fair, the Python community knows this. It’s why virtually all of the libraries that do the heavy lifting for data science in Python are actually implemented in C (numpy, pandas) or Rust (Polars, Pydantic), or are wrappers around C++ (PyTorch, TensorFlow, matplotlib) or Java (PySpark, Pydoop, confluent-kafka) libraries.

I think this provides a lot of insights into what data practitioners want. It’s clear that users want approachable, simple, human-readable interfaces for all of these tools, and that any new tool needs to interoperate with the rest of the ones currently in use. People are also tired of churn and are craving stability. I think Clojure has a lot to offer in all of these areas and is well placed to become more widely adopted for data science.

Ongoing work

My focus over the next two months will remain on the cookbook. My main goal is to finish the introductory chapter with the housing price analysis and to continue putting together the data import section with instructions and examples for all file formats that can reasonably be supported easily at this time.

I’ll continue to support and contribute to all of the ecosystem libraries I come across in my writings and analysis work in hopes of smoothing out all the rough edges I find.

Thanks for reading. I always love hearing from people who are interested in any of the things I’m working on. If that’s you, don’t hesitate to be in touch :)

Nikita Prokopov

Hi, I’m Nikitonsky and this is my open-source update for the past two months. Some good work was done on Humble UI (finally!), DataScript and new project — AlleKinos.de.

New project: AlleKinos.de, a no-nonsense movie showtimes site for the entire Germany:

A simple view for all movie screenings in Germany, inspired by Bret Victor’s Magic Ink
Developed in Clojure, data stored in DataScript, hosted on application.garden
Includes many many small cities (up to 671 now!),
And all the cinemas that were reported missing before.

HumbleUI, Clojure Desktop UI framework:

A long-standing vdom branch that was dragging from January is finally merged!
All examples have been ported to the new style
Still lots of issues and design ideas to look at, but now I’ll be going through them in the main branch

DataScript, immutable database and Datalog query engine for Clojure, ClojureScript, and JS:

fixed some OR queries broken in 1.6.4 468, closes 469)
Remove duplicate code 471
Document “partial db” during transaction 366
Stable sorting of sequences of various types 470
Correctly restore :max-tx from storage
Fixed tempid/upsert resolution when multiple tempids are added first (closes 472
Allow upsert by implicit tuple when only tuple components are specified 473
Allow lookup-refs inside tuples used for lookup-refs 452
Code cleanup and formatting for the entire codebase

clj-reload, a smarter way to reload Clojure code:

Disabled parallel init/reload via lock 9
:only with regexp only reloads changed + new matching
added find-namespaces
clj-reload support has been merged into CIDER 1.14
Now possible to initialize without passing :dirs option, will use system classpath in that case

Clojure Sublimed, Clojure support for Sublime Text 4:

Fixed Socket REPL not working on Windows 95
Fixed a bug when Clojure Sublimed would not work right after first install 109

Sublime Executor, Sublime Text plugin to run any executable from your working dir:

Added executor_show_panel_on_output option

Blogging:

Going to the cinema is a data visualization problem
Local, First, Forever: what if your CRDT’s syncing engine was Dropbox?

Talks:

Clj-reload at Clojure Berlin (a bit rushed).
Same talk, but re-recorded offline, a little more deep and less rushed. I recommend this version.

Love,
Niki

Tommi Reiman

Started my 3 month sabbatical in June with a road-trip with the kids, a welcome reset! Now back to home, learning and doing.
Refreshed my knowledge of the latest TypeScript, Zod and XState with a goal to pull some of the good things to Clojure (into Malli + a fully Xstate-compatible FSM-library). Also working on a template-project with monorepo + malli + reitit, using Java21 and Virtual Threads.

Library Releases

reitit 0.7.1 (active)

Fixing regression bugs from 0.7.0 + latest features via dependent libraries. Changelog here.

malli 0.16.2 (active)

Welcome Experimental Simplified Function Schemas!

[:-> :any] ; [:=> :cat :any]
[:-> :int :any] ; [:=> [:cat :int] :any]
[:-> [:cat :int] :any]  ; [:=> [:cat [:cat :int]] :any]
[:-> a b c d :any] ; [:=> [:cat a b c d] :any]

;; guard property
[:-> {:guard (fn [[[arg] ret]] ...)} :string :boolean]
; [:=> [:cat :string] :boolean [:fn (fn [[[arg] ret]] ...)]]

Also, small fixes and additions. Changelog here.

There is a big bunch of WIP work from myself and contributors waiting to be finished.

jsonista 0.3.9 (stable)

:do-not-fail-on-empty-beans option + updated dependencies, Changelog here

ring-http-response 0.9.4 (stable)

Teapots welcome! Changelog here.

spec-tools 0.10.7 (inactive)

Small fixes and improvements, Changelog here. If you are a user of spec-tools and want to help, feel free to ping me on Clojurians Slack, happy to take a new contributor here.

Something Else

Old abandoned Soviet-era sanatorium in Latvia.

Peter Taoussanis

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open source work! I realise that it’s a tough time for a lot of folks and businesses lately, and that sponsorships aren’t always easy 🙏

2024 May - Jun

Hi folks! 👋

The last couple months have been light on big-ticket releases. Have been focused on maintenance, support, and groundwork for future releases. Output included:

Nippy and Carmine security releases

If you haven’t yet, please do try update to the latest versions of Nippy and/or Carmine when possible:

Nippy v3.4.2 released 2024-05-26
Carmine v3.4.1 released 2024-05-30

These include a fix to address a security vulnerability described in more detail in Nippy’s release notes.

In short: Carmine uses Nippy for its serialization, and Nippy uses a Java compression library for its compression. Earlier releases of that Java library may be vulnerable when decompressing malicious data directly crafted by an attacker. The attack is believed to require arbitrary control of the data provided to Nippy for thawing.

Relevant posts were made to the Clojure subreddit, Clojurians Slack, and my X account.

Telemere

Work has continued on Telemere, my new structured logging and telemetry library for Clojure/Script.

There were numerous minor beta releases to address various issues that came up, and to polish sharp edges and documentation, etc.

Instead of detailing all that here, I’ll just point to the current release - v1.0.0-beta14. The latest beta release will always include a summary of all major recent changes.

I’m aiming to try out RC1 around the end of August, but won’t needlessly rush. I’d like the API to be completely stable after v1 final is out, so I’d rather go a bit slower now to get things right.

Big thanks to early adopters and testers for all the valuable feedback so far! 🙏

Carmine

Work has continued on Carmine v4. It’s quite an undertaking, but I’ve recently updated and merged the first parts of the new v4 core into mainline.

The current plan is for all the new stuff to live in a parallel taoensso.carmine-v4 namespace. This’ll make it easier for me to roll out the new work in stages, and get feedback from early adopters without negatively impacting existing users.

There’ll be a lot to say on Carmine v4, but that’ll come later.

Upcoming work

My current roadmap can always be found here, and it’s now also possible to vote to help guide my priorities.

Current objectives for July-August include:

Continued efforts on Telemere.
Hopefully release the final stable version of Tempel - my new data security framework for Clojure. Before the final release I’m planning to investigate support for MFA, extend the docs re: use with OpenID, OWASP, and make a few other last improvements. Originally had this planned for earlier, but rescheduled so that I could prioritise the Nippy security topic.

Cheers!
- Peter Taoussanis

June & July 2024 Short-Term Project Updates

Sat, 20 Jul 2024 08:30:00 +0800

We’ve got several updates to share from our Q2 2024 project developers. Check out the latest in their June and July Reports following the project list below.

clj-merge tool: Kurt Harriger
This project focuses on developing a git diff and merge tool for edn and clojure code with the aim of creating a git mergetool that can be used as a replacement for git’s default merge tool for clj(s) and edn files.

Compojure-api: Ambrose Bonnaire-Sergeant
This project will deploy the first new releases since 2019 (and include compojure-api 1.x, 2.0.0-alpha branch, ring-swagger), compojure-api/reitet migration tools, and Swagger 3.0.

Enjure: Janet A. Carr
This project focuses on MVP for the Enjure CLI tool and providing the ability to create new projects and view/controller templates as well as delete templates.

Jank: Jeaye Wilkerson
Jank’s library parity with Clojure.core is around 20%. The next step is to fill out the language to make it feel more like Clojure - including Lazy sequences, Loop/recur, Destructuring, Symbol interning, and for and doseq macros.

Lost in Lambduhhs Podcast: L. Jordan Miller
Rejuvenate and streamline production of the Lost In Lambduhhs Podcast, where the audience gets the opportunity to “meet the person behind the Github” - illuminating the personal narratives and insights of tech luminaries, giving them a platform to share their perspectives while promoting their library or tool.

Clj-merge: Kurt Harriger

Q2 2024 Report No. 2. Published July 1, 2024

Introduction

This tool aims to reduce unnecessary conflicts due to whitespace and syntax peculiarities by using a more semantic approach to diffing and merging. I’m grateful for the support from ClojuristsTogether and the invaluable feedback and support from the Clojure community.

Recent Progress

This month, I focused on the following improvements:

Bug Fixes: Several bugs were fixed to enhance the stability of the tool.
CI/CD Pipeline: A CI/CD pipeline was added to streamline the installation process and prevent additional regressions.
Error Reporting: Simplified error reporting to make it easier for users to provide useful feedback when the tool does not work as expected.
Due to an exceptionally busy schedule, progress on diff visualization and project promotion was limited.

Milestones Overview

The project was structured around several key milestones:

Development of the MVP - Mostly complete
Enhancement of diff handling and presentation - Ongoing
Community engagement and feedback integration - Ongoing
Performance optimization and cross-platform compatibility - Done

Milestone Progress

Development of the MVP
- Goals: To create a minimal viable product using editscript and rewrite-clj.
- Recent Updates: Bug fixes were implemented to enhance the stability of the tool.
- Status: Mostly Complete. From a technical perspective I have been able to test the feasibility of the implementation and learned a lot. Its hard to say when this is “done,” I don’t quite feel ready to push the adoption until more work has been done on the diff visualization.
Enhancement of Diff Handling and Presentation
- Goals: To improve the readability and utility of diffs for developers.
- Recent Updates: Limited progress on diff visualization due to time constraints.
- Status: Much more work still needs to be done here.
Community Engagement and Feedback Integration
- Goals: To actively engage with the community to gather detailed feedback and real-world merge conflict examples.
- Recent Updates: Simplified error reporting to facilitate better feedback.
- Next Steps: Increase efforts to engage the community and aim to present at a Clojure meetup in the near future.
Performance Optimization and Cross-Platform Compatibility
- Goals: Simplify the installation process.
- Recent Updates: A CI/CD pipeline was added to streamline the installation process.
- Status: Done

Conclusion

Thank you for your support and contributions to the clj-mergetool project.

Compojure-api: Ambrose Bonnaire-Sergeant

Q2 2024 Report No. 3. Published July 8, 2024

Last month I successfully added support for compojure-api 1.x coercions in the 2.x branch. This is one of the last steps towards backwards-compatibility of 1.x code using the 2.x branch. I did not make any progress on this front this month, but the remaining steps are starting to crystallize, which I will talk a bit about here.

Implementation wise, a 1.x coercion is detected with fn?, and implies the Schema backend (Spec support was addedin 2.x). Such a coercion is a nested function with the shape request->field->schema->coercer, often often implemented like (constantly nil) or (constantly {:body matcher}).

Several insights during this 3-month project made backwards-compatibility particularly clean.

Once I grokked the main differences between 1.x and 2.x coercions at the end of month 2, I realized that my efforts to restore support for ring-middleware-format was misguided. I could instead translate 1.x coercions to muuntaja’s expected format.

There are two steps to this. The first was to add support for “legacy” coercions in 2.x’s coercion abstraction. This involved changing the coerce-request implementation in compojure.api.coercion.schema.

The second step is to translate ring-middleware-format’s :format options to muuntaja’s :formats. I have only done this for the default options, and currently any custom :format extensions do not work.

One wrinkle that is difficult to reconcile in all cases is that 2.x dropped implicit support for several coercion formats such as yaml. In order to maintain backwards compatibility with 1.x coercions, we want to ensure that yaml formats are supported by default for legacy coercions.

I have not completely solved this problem, but I identified that coercions are usually configured in terms of the api-defaults var, which is a map with containing :format in 1.x and :formats in 2.x. In both branches, I introduced a breaking change, renaming api-default to api-defaults-v1 and api-defaults-v2 using :format and :formats respectively. This might help decide whether to include yaml coercion by default, but requires more thought.

Finally, I removed any attempt to add ring-middleware-format support in the 2.x branch since I realized it was unnecessary.

recompojure

As part of this 3-month project, I am releasing a recompojure, which is a library providing compojure-style macros that expand to reitit.

It does not have a stable release yet, but there are some interesting problems to solve.

I worked on recompojure for the first month of this project, but stopped after I ported it out of a corporate repo I prototyped it in. I realized that compojure-api has a different set of features than reitit, and decided that my time would be better served working on compojure-api itself.

One big difference between reitit and compojure-api is reitit accepts a local configuration (opts) map which compojure-api is extended using global state. To preserve this local configuration style, recompojure is structured as a macro-generating-macro that is passed a top-level options map. An additional subtlety is that this options map is needed at compile-time when compojure-api does most of its work.

For example, the load-api call here defines all the compojure-api macros such as GET, POST, context, etc., but their extensions can (eventually) be centralized in the options var. This attempts to address a common concern using compojure-api where care must be taken to ensure extension are loaded before any routing macros are expanded—this style should centralize extensions such that they are deterministic without further safe guards.

(ns com.recompojure.compojure-api1
  "Exposes the API of compojure.api.core v1.1.13 but compiling to reitit."
  (:require [com.recompojure.compojure-api1.impl :as impl]
            [clojure.set :as set]))

(def ^:private options {:impl :compojure-api1})

(impl/load-api `options)

From here, I would like to add compojure-api 2.x support, and fully take advantage of the implicit options map as described. The next big feature would be to reconcile compojure-api and reitit’s middleware support so that compojure-api-style applications can easily be translated to reitit via recompojure. In particular, most compojure-api app use the api function to create an app, but recompojure does not yet support translating this to reitit.

Project Summary

This 3-month project had two main focuses.

The first half concentrated on performance of the 2.x branch of compojure-api and ensuring stable versions of security fixes were deployed.

My main goal for the second half of this 3-month project was to ease future maintenance of compojure-api by retiring the 1.x branch. That way, features need only be developed in the 2.x branch and can still be enjoyed by 1.x users.

This was much more challenging and onerous than I anticipated, and I would not have been able to invest time in this if Clojurists Together had not funded the project. My main activity was attempting to understand and compare two versions of the same project and reverse-engineer the evolution of the project.

I’d like to thank Clojurists Together for selecting this project for funding.

Enjure: Janet A. Carr

Q2 2024 Report. Published June 12, 2024

Progress has been good. I regularly stream Enjure to my audience on Twitch which seem to be bootstrapping Enjure’s Github stars.

Despite the progress, I intentionally expanded the scope of the project by implementing an HTTP router for Enjure. I’m not entirely sure that this was a wise decision, but it adheres to Enjure’s guiding philosophy. Enjure’s HTTP router is implemented with a Radix tree and supports path parameters, in pure Clojure. I’m hoping to come up with a scheme for query, body, path, and form coercion soon, but I haven’t decided on a scheme I like. The router lives in a dynamic var managed by Enjure and is updated by macros for defining pages and controllers.

Enjure has several macros enforcing a similar convention to define HTTP resources. The purpose of which brings together a resource’s routes, contract, coercion and handling expressions to a single namespace. Often Clojure web applications are structured with several libraries. For example, Consider an application with Reitit with ring, next.jdbc with postgreSQL, The application will likely have its routes in one namespace, it’s handlers in another namespace, its business logic in another namespace and data modification language (DML) in another namespace; Necessitating opening several source files to accomplish a small task. Rarely do the Routes, contracts, and handlers change. If they do, it’s from minute changes. Bringing these together cuts down on the cyclomatic complexity of developing web Applications in Clojure. Thanks to homoiconicity, I can create constructs to help with Exactly this:

;; Example from Enjure repo
(defpage user "/users/:user-id"
  [req]
  (let [{:keys [path-params]} req
        {:keys [user-id]} path-params]
    (format "Hello, %s
" user-id)))

This “page” construct is simply a function var under the hood, but also manages the routing-table Var. There’s no middleware required to update the routing table upon REPL reload. Simply evaluating The buffer/namespace will change the routing table. defpage expects a string as its return value as it’s largely tied to the content-type text/html. In the future I hope to have other, similar view constructs to support other popular application mime types.

Similarly, there are actions, changes, and removals that correspond to POST, PUT, and DELETE HTTP methods, respectively. Since Enjure places a high emphasis on convention, I’ll only show a Simple example of a Sign In action for a user:

(defaction signin "/signin"
  [req]
  (let [{:keys [email password]} (:form-params req)]
    (if (check-db email password)
      (redirect pages/home :see-other) ;; redirects to whatever route pages/home var has.
      (pages/siginin req) ;; this is a page var to render
  )))

Since resources in Enjure are just function vars, they can be called directly, and also reverse-routed to using some of the response macros. In the above example, if the signing check passes, redirect Redirects to whatever route pages/home has declared. (Reverse-routing is largely for convenience, and Not mandatory, the redirect macro supports redirecting to static paths/URLs, Enjure resources like pages, and Values from functions).

Ideally, resources would interact with the database through a data model supported by the framework. My ideas for this are still experimental and can be found in the repository under the internal “frm” namespace. Currently, it’s some simple templating of basic queries by querying the information_schema in Postgres, and interning the query functions as vars. These are queries I’ve seen regularly over the years, and I’m sure that, once implemented, will give developers a boost in productivity. Plus, there’s the added benefit of being decoupled from whatever mechanism I choose for supporting migrations/entities in Enjure (still A TBD). However, this model does not alienate developers who opt to create more complex queries as those are supported as well with next.jdbc.

Another idea I’ve been experimenting with is something I call the ReactiveRecord. ReactiveRecord uses Software transactional memory to synchronize with the database, providing an in-memory DB representation. I think given the functional interface provided by FRM above and information schema data. It might be interesting, but I do believe this kind of transacting might be faux-pas or even dangerous, so more thought is needed here on my part.

All of this will ideally be controlled with the Enjure CLI. Enjure puts a heavy emphasis on reducing developer friction. Given a base installation of Clojure, installing Enjure should allow for the creation and management of Enjure projects very easily. I’ll admit this is an area I’ve been slacking on a bit since I wanted to finished with other core components first. As of writing this, the Enjure CLI has two basic commands: Notes and help. Notes search a project for comments containing NOTES, FIXME, TODO, and HACK. Help just prints out the help dialog. Soon enough Enjure CLI will support creating and deleting resources, migrations, Entities, dependencies, etc., as well as creating new projects. The Enjure CLI can already be installed to a user’s path as a CLI utility written entirely in Clojure.

Finally, documentation of the project has become my lowest priority and definitely at risk. However, I’m not too concerned about the documentation faltering. In some sense, I’m a technical writer thanks to my blog, so I believe writing documentation for Enjure won’t be as challenging as the rest of the project.

Jank: Jeaye Wilkerson

Q2 2024 Report 3. Published June 30, 2024

Welcome back to another jank development update! For the past month, I’ve been pushing jank closer to production readiness primarily by working on multimethods and by debugging issues with Clang 19 (currently unreleased). Much love to Clojurists Together and all of my Github sponsors for their support this quarter.

Multimethods

I thought, going into this month, that I had a good idea of how multimethods work in Clojure. I figured we define a dispatch function with defmulti:

(defmulti sauce-suggestion ::noodle-type)

Then we define our catch-all method for handling types:

(defmethod sauce-suggestion :default [noodle]
  (println "You can't go wrong with some butter and garlic."))

Then we define some specializations for certain values which come out of our dispatch function.

(defmethod sauce-suggestion ::shell [noodle]
  (println "Cheeeeeeeese!"))

(defmethod sauce-suggestion ::flate-white-rice [noodle]
  (println "Hor fun gravy."))

Then, when you call the sauce-suggestion function, first the dispatch function is called and then the correct method is looked up and called.

(sauce-suggestion {::noodle-type ::shell})
Cheeeeeeeese!

(sauce-suggestion {::noodle-type ::spaghetti})
You can't go wrong with some butter and garlic.

This is as much as I knew. But wait, there’s more!

Hierarchies

It turns out that multimethods match dispatch values based on a couple of different hierarchies, too. If you’re matching actual class types, like String, you could have a method which is parameterized on Object and it will be a catch-all. So this would allow you to match on everything which inherits from IRenderable, for example, and then use that interface to render the object. I wasn’t concerned about this, since jank’s object model isn’t based on inheritance. I figured I could leave this whole feature out of multimethods.

However, it turns out that Clojure supports another form of hierarchies! Even crazier, we have full control over those hierarchies at run-time and we can build as many as we want. Check this out.

; We can classify spaghetti and penne as Italian.
; They will both be considered children of ::italian.
(derive ::spaghetti ::italian)
(derive ::penne ::italian)

; Then we can define a method based on the parent.
(defmethod sauce-suggestion ::italian [noodle]
  (println "Sugo al pomodoro."))

; This allows us to match multiple dispatch values in a
; deterministic and intuitive way.
(sauce-suggestion {::noodle-type ::penne})
Sugo al pomodoro.

There are a handful of related core functions for working with these hierarchies. jank now implements all of them.

make-hierarchy
isa?
parents
ancestors
descendents
derive
underive

As I was implementing multimethods, I needed a few more core functions, so those were all implemented as well:

hash-set
disj
defmulti
alter-var-root
bound?
thread-bound?

Notably, this includes bound?, which required me to actually create a dedicated unbound var object so I could distinguish between unbound vars and vars holding nil.

Clang/LLVM 19

Most of my time this past month was not spent developing new features for jank, which is why I only have multimethods and 13 new functions to report. Instead, my time was spent trying to get jank ported over to the latest Clang/LLVM version, which will allow us to leave Cling behind. jank uses these for JIT compiling C++ code and upgrading to the upstream Clang will unlock huge performance wins, make compiling jank easier, and will allow for jank to follow the bleeding edge of the native JIT space. However, before we get there, we have a couple of bugs to get past.

Extern templates

The first bug, which was causing JIT linking issues, I reduced down to a simple test case involving an extern template which is linked either in the current process or in a loaded shared library. Clang will be unable to resolve the address of the definition of that function. As it happens, the fmt library uses this pattern to provide some optimized versions of certain templates. However, we can fortunately work around this, since fmt wraps those definitions in a FMT_HEADER_ONLY preprocessor flag. The relevant fmt source is here.

The process of narrowing this down from the entire jank runtime is cumbersome, ruling out chunks of code at a time while still trying to keep things compiling and correct.

Optimization crash

This is the blocking bug preventing jank from switching to Clang. It only happens in release builds, which also makes it harder to debug. This month, I traced the bug down from a crash in jank all the way to a minimal test case involving assignments with an implicit constructor. However, when testing whether or not the bug existed in Clang 18, I found that it indeed did not. This meant that it’s since been introduced in the yet unreleased Clang 19. So I bisected around 1300 commits, each time requiring a fresh Clang/LLVM compilation and taking ~30m. It was an entire day of all 32 cores on my machine being busy compiling, but fortunately I could script all of the hard work just using some bash. Bisecting allowed me to find the commit which introduced the issue. This has yet to be fixed and I don’t have the expertise to know what’s wrong with that commit, but I’ve provided a test case, pinged the relevant people, and now I’m hoping the real experts can come in for the save.

Clang status

Aside form those two issues, only one of them being a blocker, the port to Clang is ready. In debug builds (which avoid the second bug), jank can pass its full test suite using Clang 19. Even better, some early benchmarking has shown that Clang 19 is more than twice as fast as Cling when it comes to JIT compiling large amounts of generated C++ code (such as all of clojure.core). That will mean faster startup times and shorter REPL iteration loops.

What’s next?

Implementing multimethods identified a couple of issues related to certain sequence types in jank which I’m still investigating. Once those are sorted, I’ll continue working through the requirements to implement clojure.test, which is why I was implementing multimethods in the first place. From there, I can start testing my jank code using more jank code and the dogfooding cycle can really begin. Stay tuned, folks!

Lost in Lambduhhs Podcast: L. Jordan Miller

Q2 2024 Report 2. Published June 27, 2024.

I have made continued progress on my new podcast series, thanks to the support from Clojurists Together. Here are the key milestones I’ve achieved since my last update and my plans moving forward:

Theme Music and Audio Engineering

Created Theme Music and Audio Engineering Template: Developed the theme music and an audio engineering template to ensure a consistent and professional sound for each episode.

Riverside.fm Proficiency

Learned Riverside.fm Editing Software: Gained proficiency in using Riverside.fm’s editing software and created a workflow for efficiently editing audio.

Episode Releases

Released Two Episodes:
- David Nolan
- Arne Brasseur

Guest Coordination and Diversity Efforts

Gender Diversity Challenge: I am striving to ensure gender diversity in my episodes, which has been challenging.
Reached Out to Prospective Guests: Contacted three prospective guests, with two having returned my communications.

Recent Challenges

Scheduling Conflicts: Faced scheduling conflicts due to a death in my family followed by getting sick with strep throat. I am now on day 8 of recovering from the sickness and have recordings scheduled for next week.

Next Steps

Continue Outreach: Continue to reach out to schedule recordings, ensuring a diverse lineup of guests.
Timely Editing and Release: Edit and release episodes in a timely manner, promoting on Clojurians Slack, Clojure Weekly updates, LinkedIn, and Twitter.
Expand Promotion Channels: Create a Mastodon account to help promote the podcast.

Conclusion

Despite recent challenges, I am on track with my project timeline and excited about the content I am creating. I will continue to provide updates as I progress further.

Call for Proposals. June 2024 Member Survey

Fri, 12 Jul 2024 08:30:00 +0800

Happy July! It’s that time again.

Clojurists Together is pleased to announce that we are opening our Q3 2024 funding round for Clojure Open Source Projects. Applications will be accepted through the 26th of July 2024 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.

We will be awarding up to $44,000 USD for a total of 6-8 projects. The $2k funding tier is for experimental projects or smaller proposals, whereas the $9k tier is for those that are more established. Projects generally run 3 months, however, the $9K projects can run between 3 and 12 months as needed. We expect projects to start on Sept. 1, 2024.

We surveyed our members again in June to find out what types of initiatives they would like us to focus on for this round of funding. Their responses are summarized below. In particular, it was great to see members' feedback relating to how often they used or referred to developers' work we have funded. Also noted that several of you plan to attend Heart of Clojure in Belgium in Sept. and Clojure/Conj in the US in October. Check this out!

If you are working on a Clojure open source project or have a new one in mind, especially one mentioned as a focus area for our members, consider applying. Or if you know someone that might be interested, please pass this information along. Let’s get the word out! If you have questions, please contact Kathy Davis at kdavis@clojuriststogether.org.

Our Members Speak: Feedback from the June 2024 Survey.

What other information would you like to know about Clojurists Together and the work we fund?

Your updates have been great. The current amount of information is good.
A roadmap of where clojurists together wants to go/grow to.
It’d be great to learn about your decision making-process (which is so fruitful)!
I’d like to know more about your approach to supporting new contributors and people from underrepresented groups.

What areas of the Clojure and ClojureScript ecosystem need support?

Although this doesn’t affect me personally, it is always good to make it easier for newcomers, so may some articles/documentation aimed at them, and maybe support for things like Kit Framework so they can get going quickly. (4 comments)
A better test framework than clojure.test but ideally mostly compatible with current tooling. The implementation of clojure.test is borderline unreadable.
AI copilots specific to clojure libraries
Cloud deployment patterns & tooling
JVM/Clojure runtime has seen catch up with the JDK platform, but ClojureScript runtime seems to be a bit “stuck”, which makes me worried.
Clojure Editor integrations
ClojureDart, auth libs for web apps
Fairly bare-to-the-metal visualization. I’m still using Oz (vega, vega-lite), but it is not maintained. I am not that much interested in hanami, which is its own metalanguage on top of vega-lite, and I think cloj-viz wants to build on top of hanami again. At least oz I can debug by looking at vega/vega-lite code.
3rd Party Libraries, some of which have merges for fixes but no releases!
Structural editing
I’d love access to ClojureScript debugging within Emacs
Data-science
Making simple things easy, like Rails does.
Calva support for simultaneous clojure+clojurescript from the same workspace
Test tooling
I was recently looking at test.check and clojure.spec.alpha and was having some trouble figuring out how (if at all) the two are related? Maybe some unification of these two concepts?
The usual issues that crop up every year, like getting newcomers, error messages, and community engagement. Core team output feels stagnant; nothing in 1.12 feels worthy of a major release. Plus, it seems like Clojure is falling behind in just keeping up with changes to Java.
Marketing. Rich’s seminal talks were a fantastic advert for Clojure, but the tech market is fickle and nothing has really stepped in to replace these to attract companies in a position to create jobs.
Library maintenance
Documentation is still horrible for most libraries in the ecosystem.

What areas of the Clojure and ClojureScript ecosystem are strong?

Core language itself
Stability has been great (4).
Expertise is strong - but especially on Slack, where it is quickly swept under the tide of time. Slack has some very patient people with great advice. The design work that went into the language is showing it’s benefit.
Good community, good tools and libraries developed by talented and experienced people, with a preference towards stability and backwards compatibility. Community is strong and welcoming. Documentation is there (though often in not always obvious places).
Babashka and it’s ecosystem
The libraries and general “can get things done with the language” abilities are super-strong.
Web development
Interactive developer tooling

Are there any particular libraries, tools, or projects that are important to you that you would like to see supported?

(Number of mentions in parentheses):

Cider (8)
Malli (6)
Shadow-cljs (5)
Clj-kondo (5)
Calva (4)
Reiti (4)
Ring (3)
Babashka, Biff, buddy, cljfmt, clj-reload, Clojure-lsp, ClojureDart, Donut, Flowstorm, Re-frame (each 2)
Async, badspreadsheet, Carmine cluster support, Clay, Clojure-spec, Clojure-ts mode, Cloverage, Conjure, Data Analysis processing framework, Datalevin, DataScript, Datasplash, Dtype-next, eMac, Fastmath, Fulcro, Hanami, Hanamicloth, HoneySQL, HTMX projects, Humble UI, Jank, Kindly, Langohr, Leinigen, libpython-clj, Metamorph.mi, nbb, Neanderthal, Neovim, next.jdbc, Noj, Parinfer, Pedestal, Polylith, Portal, Regeant, Reframe, ring-jetty9-adapter, SciCloj, Scittle, Spandex, Tablecloth, Tech.ml.dataset, uix, VIM integrations, All things Borkdude, Taoensso & Weavejester’s projects (each 1)
I am very impressed by ClojureScript. With that said, I have been reading about unpoly and htmx of late. I’m not sure if it is a fad or not at this point, but it would be interesting to highlight if we have any special advantages or integrations between Clojure and these frameworks. I especially like the “hypermedia first” narrative that htmx is pushing.
The data-science thing. Datascript’s core insofar as it is reused in Datalevin. Datalevin might not be looking for funding, but it is(?) the obvious heir to the Datomic popular revolution (FOSS triple-store replacing SQL+Lucene without time-travel) and thus has the potential to bring lots of attention as the SQL ball-and-chain is finally clipped from developers' ankles.
Mac version (M1+ apple). It’s a great base for high-performance computing
Some level of ClojureScript debugging support that could also work when developing for nbb via nrepl
I would like the bi-quarterly updates to include a one line description of what the project is and a link to its website, before describing all that work that was done - to set the scene. Don’t assume we know (and remember) all the cool Clojure projects.

What would you like to be different in the Clojure community in the next 12 months?

Better AI / ML story
Maturing of the data-science stack
Coordinate more around certain standards like biff.
For 3rd party libraries that have commits, but no releases, or even open pull releases to fix issues are released!
kotlin interop, scala interop
Get rid of the perceived lack of adoption, bring companies before the curtain who use Clojure.
Helping innovation like squintjs/cherry, or something similar, to strengthen the ClojureScript runtime story.
CT has funded people to be present on Slack and share expertise. A live answer is very nice, but the goodness will diminish as soon as funding stops, and completely vanish if Slack ceases to renew the free enterprise status. In a word, when the music stops there will not even be records to replay. What is a potential solution?
I notice many of the questions recur, over and over and over again. They are literally FAQs. Could CT encourage contributing to a FAQ?
ClojureDart will be big: very big. As a toy, it is already impressive. My app came out super on mobile phones & tolerable as a website, totally bypassing the self-inflicted agonies of Javascript. CLJD is still missing a few key things - or maybe just multimethods - that a lot of Clojure software depends on. Soon as that obstacle is past, I predict a tsunami of interest in CLJD-adapted CLJC of many Clojure libraries. Clojurists Together may have a part in adapting long-stable libraries, in service of possibly really putting Clojure ‘on the map’, leapfrogging the labor quagmire of JS/CLJS while reusing tons of software already written for the JVM/JS hosts!"
The Clojure community is already pretty great. I think we must just continue to be a friendly community and continue to help each other and newcomers on Slack and AskClojure. Efforts like Clojurists Together is a wonderful way to support developers that work on important open source tools and libraries. Keep up the good work!
Attracting newcomers & find out what bumps are in onboarding . More advocacy and uptake of the language, I sense a lull not only due to the economy, but also due to Rich’s retirement. How can we grow the Clojure userbase?
Maybe more focus on getting started quickly for new Clojure projects? I am not sure exactly how, but maybe docker images or nix integrations that are just dead simple. I don’t honestly have the answers here, but I think that a lot of people just dismiss Clojure because it has somewhat of a learning and setup cost. I think if you can just get it in front of people quickly then you can quickly impress them with language feature/design choices, but you have to get them to look at it. Getting started was a little easier then we could slowly grow our ranks a little more.
I’m personally not a fan of the community going to deps. Kind of feels like if the Java community moved back to ant.
Better transparency over the current state of Clojure libraries. Are they being actively maintained? Do they have stale dependencies that might have security issues?

April and May 2024 Short-Term Project Updates

Mon, 03 Jun 2024 08:30:00 +0800

We’ve got several updates to share from our Q1 and Q2 project developers. Check out the latest in their April and May reports.

clj-merge tool: Kurt Harriger
Compojure-api: Ambrose Bonnaire-Sergeant
Instaparse: Mark Engelberg
Jank: Jeaye Wilkerson
Plexus: John Collins
Lost in Lambduhhs Podcast: L. Jordan Miller
Scicloj: Daniel Slutsky

Clj-merge: Kurt Harriger

Q2 2024 Report No. 1. Published May 15, 2024

Introduction

Milestones Overview

The project was structured around several key milestones:

Development of the MVP.
Enhancement of diff handling and presentation.
Community engagement and feedback integration.
Performance optimization and cross-platform compatibility.

Milestone Progress

Development of the MVP
- Goal: To create a minimal viable product using editscript and rewrite-clj.
- Progress: The MVP was successfully developed and demonstrated its capability in resolving basic merge conflicts. Initially, extensive diffs suggested a complete rewrite of editscript might be necessary. However, implementing isomorphic translations between rewrite-clj node representations proved to be a sufficient workaround for now.
- Next Steps: The focus will now shift towards refining this MVP, enhancing its error handling, and improving the user feedback system to make the tool more robust.
Enhancement of Diff Handling and Presentation
- Goal: To improve the readability and utility of diffs for developers.
- Progress: The generated diffs are more machine-readable than human-readable, early use of the tool has underscored the importance of easily interpretable diffs emphasizing the need for better visualization.
- Next Steps: I plan to continue working on improving the presentation of diffs, making them easier to understand and act upon.
Community Engagement and Feedback Integration
- Goal: To actively engage with the community to gather detailed feedback and real-world merge conflict examples.
- Progress: Some feedback and bug reports have been received, such as an “index out of range” error; however, collecting comprehensive examples has proved challenging.
- Next Steps: I aim to increase efforts to engage the community and hope to present at one of the clojure meetups in the near future.
Performance optimization and cross-platform compatibility
- Goal: Simplify the installation process
- Progress: The project has been successfully compiled with GraalVM for fast startup. However, these are built during the install process and require GraalVM to be available at install.
- Next Steps: CICD process to publish the binaries for download.

Future Vision and Calls to Action

Moving forward, enhancing diff visualization will be my primary focus. A more intuitive representation of changes will not only improve the tool’s usability but also its adoption. I encourage everyone in the Clojure community to try clj-mergetool, especially in challenging merge scenarios, and share any issues or feedback. Your contributions are crucial for refining the tool and expanding its capabilities.

Thank you for your continued support and contributions to the clj-mergetool project.

Compojure-api: Ambrose Bonnaire-Sergeant

Q2 2024 Report No. 1 & 2. Published April 30 & June 7, 2024

Report 1: April 2024

ring-swagger

I have released ring-swagger 1.0.0, compojure-api 1.1.14 and 2.0.0-alpha33 which all include a critical fix to prevent this memory leak.

Rajkumar Natarajan proposed OpenAPI3 support and I have been reviewing it.

1.0.0 (30.4.2024)

Fix memory leaks via multimethods caching default dispatch values: https://github.com/metosin/compojure-api/issues/454

compojure-api

My two main focuses with compojure-api have been to make 2.x backwards compatible with 1.x and implement performance improvements.

I have drafted some further performance ideas as issues and the remaining tasks for 1.x compatilibity are here.

2.0.0-alpha33 (2024-04-30)

Throw an error on malformed :{body,query,headers}, in particular if anything other than 2 elements was provided
Disable check with -Dcompojure.api.meta.allow-bad-{body,query,headers}=true
50% reduction in the number of times :{return,body,query,responses,headers,coercion,{body,form,header,query,path}-params} schemas/arguments are evaluated/expanded
saves 1 evaluation per schema for static contexts
- saves 1 evaluation per schema, per request, for dynamic contexts
Fix: Merge :{form,multipart}-params :info :public :parameters :formData field at runtime
Add :outer-lets field to restructure-param result which wraps entire resulting form
Remove static-context macro and replace with equivalent expansion without relying on compojure internals.
Upgrade to ring-swagger 1.0.0 to fix memory leaks

2.0.0-alpha32 (2024-04-20)

Fix empty spec response coercion. #413
Add back defapi (and deprecate it)
Remove potemkin #445
Add back compojure.api.routes/create
Add back middleware (and deprecate it)
Make context :dynamic by default
Add :static true option to context
Add static context optimization coach
- -Dcompojure.api.meta.static-context-coach=print to print hints
- -Dcompojure.api.meta.static-context-coach=assert to assert hints
port unit tests from midje to clojure.test

Report 2: May 2024

compojure-api

This month I concentrated on making compojure-api 2.x backwards compatible with 1.x. I approached this by both backporting features to the 1.x branch and reestablishing 1.x features in the 2.x branch. My hope is when feature-parity is achieved, I can release a stable 2.x and retire the 1.x branch.

This proved to be challenging and resulted in many false starts. The main success this month was adding support for 1.x coercions in 2.x.

My initial conceptualization of the problem was that the move from ring-middleware-format to muuntaja in 2.x was the main breaking change, and backwards compatbility would involve restoring ring-middleware-format support in the 2.x branch. I am reexaminining this assumption, as I realized I conflated 1.x coercions with ring-middleware-format after successfully adding 1.x coercions in 2.x, however this assumption directed most of my development this month.

I initially copied the 1.x test suite to the 2.x branch and attempted to directly change the 2.x branch until the tests pass. This proved overwhelming and highlighted that I did not deeply understand compojure-api’s internals. I abandoned this approach.

To better understand the changes from 1.x to 2.x, I created a PR to compare the 1.x and 2.x branches. Using this PR, I backported many of the changes made in 2.x to 1.x until the major refactoring around coercions was the main difference.

From there, I attempted to backport 2.x coercions into 1.x. This proved very difficult to reason about since the code paths around coercion completely changed in 2.x.

It was a useful exercise, however, and I realized that 1.x coercions could unintrusively be added to 2.x, which was a key stumbling block in my initial attempts at having the 1.x test suite pass in the 2.x branch.

Next month I’m planning to continue on backwards compatibility. I think I may not need to add ring-middleware-format support which addresses a user concern, so I will probably back out any ring-middleware-format related changes I added in 2.x.

#472: I found and fixed a potential memory leak in compojure-api 2.x
Upgraded to spec-tools 0.10.6 and compensated for upstream changes
Fixed outdated docstring around 2.x coercions that described 1.x coercions

Instaparse: Mark Engelberg

Q1 2024 Report 2. Published May 31, 2024

Thanks to funding from Clojurists Together, I have continued to review instaparse pull requests that have been submitted over the past couple of years.

The most interesting and useful issue, which had languished among the pull requests for over two years, was a suggestion to incorporate namespaced non-terminals, so I am pleased to report that this feature has now been implemented, tested, documented, and deployed in instaparse version 1.5.0. The pull request wasn’t quite usable out of the box, as it relied on a feature unique to Clojure 1.11, and I always strive for instaparse to be backwards compatible to Clojure 1.5. But it provided a great starting point for implementation. I think the community will find this feature to be useful.

For the final third of my Clojurists Together time, I have my eye on a bug with negative lookahead that was discovered shortly after instaparse’s initial release. It’s something I have always wanted to fix, but have never had the time to solve it as the problem is quite subtle, and any fix will require in-depth testing since it could have wider ramifications.

Jank: Jeaye Wilkerson

Q2 2024 Reports 1&2. Published April 30 & May 31, 2024

Report 1: April 30, 2024

This quarter, I’m being funded by Clojurists Together to build out jank’s lazy sequences, special loop* form, destructuring, and support for the for and doseq macros. Going into this quarter, I had only a rough idea of how Clojure’s lazy sequences were implemented. Now, a month in, I’m ready to report some impressive progress!

Lazy sequences

There are three primary types of lazy sequences in Clojure. I was planning on explaining all of this, but, even better, I can shine the spotlight on Bruno Bonacci’s blog, since he’s covered all three of them very clearly. In short, we have:

Per-element lazy sequences
Chunked lazy sequences
Buffered lazy sequences

This month, I have implemented per-element lazy sequences, along with partial support for chunked lazy sequences. Chunked lazy sequences will be finished next month. By implementing even per-element lazy sequences, so many new opportunities open up. I’ll show what I mean by that later in this post, so don’t go anywhere!

Loop

Prior to this month, jank supported function-level recur. As part of this month’s work, I also implemented loop* and its related recur. When we look at how Clojure JVM implements loop*, it has two different scenarios:

Expression loops
Statement loops

If a loop is in a statement position, Clojure JVM will code-generate labels with goto jumps and local mutations. If the loop is an expression, Clojure JVM generates a function around the loop and then immediately calls that. There is potentially a performance win of not generating the function wrapper and calling it right away, but note that this particular idiom is commonly identified and elided by optimizing compilers. It even has its own acronym: IIFE. (see this also)

jank, for now anyway, simplifies this by always using the IIFE. It does it in a more janky way, though, which is interesting enough that I’ll share it with you all. Let’s take an example loop* (note that the special form of loop is actually loop*, same as in Clojure; loop is a macro which provides destructuring on top of loop* – now you know):

(loop* [x 0]
  (when (< x 10)
    (println x)
    (recur (inc x))))

Given this, jank will replace the loop* with a fn* and just use function recursion. Initial loop values just get lifted into parameters. The jank compiler will transform the above code into the following:

((fn* [x]
   (when (< x 10)
     (println x)
     (recur (inc x)))) 0)

jank code-generates function recursion into a while(true) loop with mutation on some locals for each iteration, similar to Clojure.

However, loop* is tricky, since it can also do anything let* can do. For example (also note: no recursion):

(loop* [a 1
        b (* 2 a)]
  (println a b))

Since we’re using a in the binding for b, we can’t know b until we’ve calculated a, and doing so can involve any arbitrary expression. Agh! This can’t work if we just dump those into the positional parameters of the IIFE. So jank gets around this by actually just wrapping it in a let*. 🙃

(let* [a 1
       b (* 2 a)]
  ((fn* [a b]
    (println a b)) a b))

This could be done in a macro, but since it’s a language-level feature, the compiler does it for us. This means you can still use loop* even if you’re running without clojure.core. As mentioned, this is potentially slower, in the scenario of the loop being in statement position. We can return to this when the performance of loops is the most important thing to tackle. Right now, parity with Clojure and getting jank onto your machine are most important.

Destructuring

Clojure supports all kinds of fancy destructuring of sequences, maps, and keyword arguments. We use destructuring in let, defn, and loop, primarily. One interesting thing about this destructuring is that there’s no compiler support for it at all; it’s not a language-level feature. It’s a library feature, done entirely in macros. The amazing thing about it is that, as long as we support all of the core functions required, we can support destructuring. The actual destructure function is huge, but you can see it in Clojure’s source here.

This month, I implemented all of the missing functions required for the destructure function to be ported over to jank. Largely, once all those functions were implemented, the port just meant updating Java interop in a few places to be C++ interop. Now jank supports all of the fancy destructuring Clojure does, in all the same places. This helps demonstrate how much closer jank is to being a complete Clojure dialect, since complex functions like this can almost just work.

New clojure.core functions

So, to support lazy sequences and destructuring, I needed to add several new core functions. While adding those, I tended toward implementing any similar or surrounding functions as well. I got a little carried away, to be honest. Let’s take a look at the new functions jank now supports.


`take` (no transducer)	`cycle`
`take-while` (no transducer)	`repeat`
`drop` (no transducer)	`seq?`
`filter` (no transducer)	`concat`
`identity`	`->`
`constantly`	`->>`
`into` (no transducer)	`cond->`
`mapv`	`zipmap`
`filterv`	`last`
`reduce`	`butlast`
`nthrest`	`map?`
`nthnext`	`key`
`partition`	`val`
`partition-all`	`dissoc`
`partition-by`	`ident?`
`dorun`	`simple-ident?`
`doall`	`qualified-ident?`
`when-let`	`boolean`
`when-some`	`nth`
`when-first`	`loop`
`split-at`	`peek`
`split-with`	`pop`
`drop-last`	`for`
`take-last`	`chunk-buffer`
`chunk-append`	`destructure`

That’s 52 new functions/macros! That alone amounts to around 10% of all the functions in clojure.core jank will be implementing. A few of these will need some updates once jank fully supports chunked lazy sequences and transducers, but they’re all very usable today. You may also note that for is in there, which was one of the goals this quarter.

Migration from Cling to Clang

jank is much closer to running on Clang’s JIT compiler than it was a month ago. Some recent patches have landed which partially address a blocking bug with pre-compiled header handling in Clang’s internal C++ JIT compiler. I have identified another small reproduction case for what I hope to be the rest of the issues. Part of my work this month involved getting jank running on LLVM 19 and updating filling out the related CMake system to be able to flexibly bring in LLVM on any system.

Once jank moves away from Cling in favor of Clang, building and distributing jank will be significantly easier. Developers won’t need to compile a custom Cling/Clang/LLVM stack. On top of that, Clang’s JIT compiler has recently landed support for loading C++20 modules, which can serve as an less-portable equivalent to JVM’s class files, allowing jank to load pre-compiled modules very quickly. This will drastically optimize jank’s startup time, but will require some work to get going. I’ll keep you updated!

What’s next?

I’m well ahead of schedule, for the quarter, but I need to finish up chunked sequences and doseq. I’ll have time after that and I’d like to get atoms working, since most Clojure programs have some form of state. From there, I can look into strengthening native interop and making jank more easily distributable, but let’s not get ahead of ourselves.

Report 2: May 31, 2024

Hey folks! I’ve been building on last month’s addition of lazy sequences, loop*, destructuring, and more. This month, I’ve worked on rounding out lazy sequences, adding more mutability, better meta support, and some big project updates.

Chunked sequences

I’ve expanded the lazy sequence support added last month to include chunked sequences, which pre-load elements in chunks to aid in throughput. At this point, only clojure.core/range returns a chunked sequence, but all of the existing clojure.core functions which should have support for them do.

If you recall from last month, there is a third lazy sequence type: buffered sequences. I won’t be implementing those until they’re needed, as I’d never even heard of them before researching more into the lazy sequences in Clojure.

Initial quarter goals accomplished

Wrapping up the lazy sequence work, minus buffered sequences, actually checked off all the boxes for my original goals this quarter. There’s a bottomless well of new tasks, though, so I’ve moved onto some others. So, how do I decide what to work on next?

My goal is for you all to be writing jank programs. The most important tasks are the ones which bring me closer to that goal. Let’s take a look at what those have been so far.

Volatiles, atoms, and reduced

Most programs have some of mutation and we generally handle that with volatiles and atoms in Clojure. jank already supported transients for most data structures, but we didn’t have a way to hold mutable boxes to immutable values. Volatiles are also essential for many transducers, which I’ll mention a bit later. This month, both volatiles and atoms have been implemented.

Implementing atoms involved a fair amount of research, since lockless programming with atomics is not nearly as straightforward as one might expect.

As part of implementing atoms, I also added support for the @ reader macro and the overall derefable behavior. This same behavior will be used for delays, futures, and others going forward.

Meta handling for defs

Last quarter, I added support for meta hints, but I didn’t actually use that metadata in many places. Now, with defs, I’ve added support for the optional meta map and doc string and I also read the meta from the defined symbol. This isn’t a huge win, but it does mean that jank can start using doc strings normally, and that we can do things like associate more function meta to the var in a defn, which can improve error reporting.

Monorepo

There will be many jank projects and I’ve known for a while that I want them all to be in one git monorepo. This makes code sharing, searching, refactoring, and browsing simpler. It gives contributors one place to go in order to get started and one place for all of the issues and discussions. It’s not my intention to convince you of anything, if you’re not a fan of monorepos, but jank is now using one.

This started by bringing in lein-jank, which was initially created by Saket Patel. From there, I’ve added a couple of more projects, which I’ll cover later in this update.

New clojure.core functions

Following last month’s theme, which saw 52 new Clojure functions, I have excellent news. We actually beat that this month, adding 56 new Clojure functions! However, I only added 23 of those and the other 33 were added by madstap (Aleksander Madland Stapnes). He did this while also adding the transducer arity into pretty much every existing sequence function. I added volatiles to support him in writing those transducers.


`dotimes`	`chunk`
`chunk-first`	`chunk-next`
`chunk-rest`	`chunk-cons`
`chunked-seq?`	`volatile!`
`vswap!`	`vreset!`
`volatile?`	`deref`
`reduced`	`reduced?`
`ensure-reduced`	`unreduced`
`identical?`	`atom`
`swap!`	`reset!`
`swap-vals!`	`reset-vals!`
`compare-and-set!`	`keep`
`completing`	`transduce`
`run!`	`comp`
`repeatedly`	`tree-seq`
`flatten`	`cat`
`interpose`	`juxt`
`partial`	`doto`
`map-indexed`	`keep-indexed`
`frequencies`	`reductions`
`distinct`	`distinct?`
`dedupe`	`fnil`
`every-pred`	`some-fn`
`group-by`	`not-empty`
`get-in`	`assoc-in`
`update-in`	`update`
`cond->>`	`as->`
`some->`	`some->>`

New projects

At this point, I was thinking that jank actually has pretty darn good Clojure parity, both in terms of syntax and essential core functions. So how can I take the best steps toward getting jank onto your computer?

Well, I think the most important thing is for me to start writing some actual projects in jank. Doing this will require improving the tooling and will help identify issues with the existing functionality. The project I’ve chosen is jank’s nREPL server. By the end of the project, we’ll not only have more confidence in jank, we’ll all be able to connect our editors to running jank programs!

nREPL server

nREPL has some docs on building new servers, so I’ve taken those as a starting point. However, let’s be clear, there are going to be a lot of steps along the way. jank is not currently ready for me to just build this server today and have it all work. I need a goal to work toward, though, and every quest I go on is bringing me one step closer to completing this nREPL server in jank. Let’s take a look at some of the things I know I’ll need for this.

Module system

jank’s module system was implemented two quarters ago, but since there are no real jank projects, it hasn’t seen much battle testing. To start with, I will need to work through some issues with this. Already I’ve found (and fixed) a couple of bugs related to module writing and reading while getting started on the nREPL server. Further improvements will be needed around how modules are cached and timestamped for iterative compilation.

Native interop

Next, jank’s native interop support will need to be expanded. I’ve started on that this month by making it possible to now write C++ sources alongside your jank sources and actually require them from jank! As you may know, jank allows for inline C++ code within the special native/raw form, but by compiling entire C++ files alongside your jank code, it’s now much easier to offload certain aspects of your jank programs to C++ without worrying about writing too much C++ as inline jank strings.

jank’s native interop support can be further improved by declaratively noting include paths, implicit includes, link paths, and linked libraries as part of the project. This will likely end up necessary for the nREPL server.

AOT compilation

Also required for the nREPL server, I’ll need to design and implement jank’s AOT compilation system. This will involve compiling all jank sources and C++ sources together and can allow for direct linking, whole-program link time optimizations (LTO), and even static runtimes (no interactivity, but smaller binaries).

Distribution

Finally, both jank and the nREPL server will need distribution mechanisms for Linux and macOS. For jank, that may mean AppImages or perhaps more integrated binaries. Either way, I want this to be easy for you all to use and I’m following Rust/Cargo as my overall inspiration.

I hope I’ve succeeded in showing how much work still remains for this nREPL server to be built and shipped out. This will take me several months, I’d estimate. However, I think having this sort of goal in mind is very powerful and I’m excited that jank is far enough along to where I can actually be doing this.

nREPL server progress

Since I have C++ sources working alongside jank source now, I can use boost::asio to spin up an async TCP server. The data sent over the wire for nREPL servers is encoded with bencode, so I started on a jank.data.bencode project and I have the decoding portion of that working. From there, I wanted to write my tests in jank using clojure.test, but I haven’t implemented clojure.test yet, so I looked into doing that. It looks like clojure.test will require me to implement multimethods in jank, which don’t yet exist. On top of that, I’ll need to implement clojure.template, which requires clojure.walk, none of which have been started.

I’ll continue on with this depth-first search, implementing as needed, and then unwind all the way back up to making more progress on the nREPL server. Getting clojure.test working will be a huge step toward being able to dogfood more, so I don’t want to cut any corners there. Once I can test my decode implementation for bencode, I’ll write the encoding (which is easier) and then I’ll be back onto implementing the nREPL server functionality.

Hang tight, folks! We’ve come a long way, and there is still so much work to do, but the wheels are rolling and jank is actually becoming a usable Clojure dialect. Your interest, support, questions, and encouragement are all the inspiration which keeps me going.

Plexus: John Collins

Q2 2024 Report 1. Published May 15, 2024

1. Much better Loft Algorithm.

The previous loft algorithm simply mapped vertices between one-to-one between cross sections. This meant that lofted cross-sections had to have the same number of vertices. The new loft algorithm is much more general and now supports many-to-one and one-to-many vertex mappings. Loft is a very important operation that is not available in many programmatic CAD tools, so I’m excited to have support for this.

I go over this a bit more in a blog post: http://www.cartesiantheatrics.com/2024/04/09/perfect-loft.html

2. Text rendering Support

I wrote a first-cut at support for text rendering in companion library to plexus called clj-manifold3d. There is not now a simple function called text that takes a .ttf font file, a string, and a few other parameters and renders the string to a 2D cross section that can be extruded like any other cross section. This is done in the c++ by interpolating freetype2 glyphs.

Aside from built-in support for textures, this is the last major feature that clj-manifold lacked compared to OpenSCAD.

3. N Slices

There is now a highly efficient algorithm to slice a manifold into N evenly spaced 2D cross sections. This is a primitive that can be used to implement custom slicers. In the future, I will likely be writing a slicer that gives a high level of control over the G-code generated.

4. Three Point Arcs

You can now create arcs given three points. This lets you draw circles or arcs in a similar way that is often done in graphical CAD systems. It is useful for many complex polygon constructions.

This is totally unfinished and unproven, but I have been experimenting heavily with a somewhat unique way doing custom texturing of manifolds. It works by creating a set of primitives that make it easy to “draw on” arbitrary 3D manifolds as if you’re drawing on a 2D plane. I’m hoping achieve something more fine-tunnable than common texturing methods (like UV mapping) and that could integrate seamlessly with Plexus’s abstractions. It has proven to be challenging unclear how well it’s going to work out.

While continuing to tinker with this approach, I’ll likely add support for more standard texturing.

6. Example projects

I improved and updated example projects that demonstrate using plexus for real-world problems. These are:

I will try more examples in the future.

7. Better support for 2D affine transforms

2D affine transforms (3x2 matrices) are now fully supported. They support the same API as 2D cross sections. Having affine transforms as independent objects is a big advantage over OpenSCAD.

8. Tests, Docs, Code Cleanup

Documentation is still sorely lacking, but README’s have been improved. There are more tests now and somewhat better API documentation in the code. There are also now github action pipelines in an effort to bring a bit more transparency and professionalism to the dev process.

Lost in Lambduhhs Podcast: L. Jordan Miller

Q2 2024 Report 1. Published May 15, 2024.

Progress Overview

I have made significant progress on my new podcast series, thanks to the support from Clojurists Together. Here are the key milestones I’ve achieved so far and my plans moving forward:

Platform Subscription

Subscribed to Riverside.fm as my podcasting platform to ensure high-quality audio recordings and ease of use for my guests.

Guest Coordination

First Four Guests Identified and Scheduled:
- David Nolan - Recorded on Monday, May 13.
- Arne Brasseur - Scheduled to record on Wednesday, May 15.
- Recia Roopnarine - Scheduled to record on Wednesday, May 21.
- Raf Dittwald - Scheduled to record on Wednesday, May 21.

Recordings and Editing

Completed Recording:
- My first session with David Nolan was successfully recorded.
Current Task:
- I am currently editing and post-processing the interview with David Nolan.
Upcoming Recordings:
- Recording with Arne Brasseur on May 15.
- Recording with Recia Roopnarine and Raf Dittwald on May 21.

Release Schedule

Planned Release:
- I plan to release the episode featuring David Nolan within the next week.

Next Steps

Complete the editing phase for the first episode.
Prepare and test all technical setups for the upcoming recordings.
Begin outreach for additional guests to feature in future episodes.

Conclusion

I am on track with my project timeline and excited about the content I am creating. I will continue to provide updates as I progress further.

Scicloj: Daniel Slutsky

Q1 2024 Report 3. Published April 30, 2024

April 2024 was the last of three months on the Clojurists Together project titled “Scicloj Community Building and Infrastructure”.

Scicloj is an open-source group developing Clojure tools and libraries for data and science. As a community organizer at Scicloj, my current role is to help make the emerging Scicloj stack easier and more accessible for broad groups of Clojurians. I collaborate with a few Scicloj members on this.

While this is the last update under the Clojurists Together 2024 Q1 support, the project will, of course, continue.

Below are the sub-projects that were addressed during April 2024. They are listed by their proposed priorities for the coming month.

The new real-world-data group is ranked highest for its impact on community growth. This means the following. Assuming this group will (hopefully) grow well and demand attention, the goals of other projects will receive less attention and will be delayed. However, some of them (e.g., required extensions or bugfixes to libraries) will receive more attention if the real-world-data group requires them.

The real-world-data group

The real-world-data group is a space for Clojure data and science practitioners to bring their data projects, share experiences, and evolve common practices.

April summary

had a few one-on-one meetings with group members, discussing their goals, and helping out with the technical path
had the second and third group meetings, which included new presentations, follow-ups on personal projects, hands-on parts, and discussions
kept working on introductory materials to support the group

May goals

have more one-on-one meetings, three more group meetings, and ad-hoc small topical meetings
help the participants take on active paths that connect their interests with community goals

Noj

The Noj project bundles a few recommended libraries for data and science and adds convenience layers and documentation for using them together.

April summary

collaborated with Kira McLean on a draft for a new data-visualization API, combining Tablecloth, Hanami, and statistical functions
updated documentation: added a tutorial for visualizing correlation matrices (WIP); started working on an additional machine-learning tutorial
updated the implementation to reuse existing functions of other libraries

May goals

implement the new data-visualization API (still in experimental stage)
improve documentation

translating books

In this project, we are renewing previous efforts to systematically review data science books in other programming languages and convert them to Clojure.
The goal is twofold: figuring out what common data science needs are still missing in the Clojure stack and creating well-polished documentation of this stack. It is also an opportunity for Clojurians to get involved in the data science community and learn from books they are curious about.

April summary

created a list of books (to be announced soon in a tidy repo) in a discussion with community members, exploring content and licenses
explored a Clay+Quarto workflow for a couple of the books, and created draft repos for them
started exploring certain books with community members who may take them on as their long-term projects

May goals

focus on Modern Statistics with R by Måns Thulin
keep exploring other books with community members

visual-tools group

This group’s goal is to create collaborations in learning and building Clojure tools for data visualization, literate programming, and UI design.

April summary

had the third ggplot study session
had a meetup about badspreadsheet and HTMX with Adam James
coordinated collaborations with a few group members who are working on HTMX-based dashboards (TBA)
kept exploring options for grammar-of-graphics implementations (documented in the Scrapbook)

May goals

keep the collaborations around HTMX-based layers
continue the grammar-of-graphics study sessions
clarify a proposal and a proof-of-concept for the long-term grammar-of-graphics project

Clojure Data Scrapbook

The Clojure Data Scrapbook is intended to be a community-driven collection of tutorials around data and science in Clojure.

April summary

continued the “exploring ggplot” tutorials
started tutorials (WIP): processing JSON files, analyzing transportation networks
adapted old tutorials to ecosystem updates

May goals

encourage and help community contributions to the scrapbook
keep adding content to support other projects

Clay

Clay is a minimalistic namespace-as-a-notebook tool for literate programming and data visualization.

April summary

added an experimental version of test generation for the purpose of testable docs / literate testing
minor bugixes and extensions
5 minor releases of Clay, 2 minor releases of the clay.el Emacs package

May goals

start working on additional visualizations, mostly Emmy.viewers integration
explore the extraction of the HTML and Markdown generation layer as a separate library
keep evolving by user needs

Kindly

Kindly is a proposed standard for requesting data visualizations in Clojure.

April summary

added the meta-kind kind/fn for user-defined display
added the meta-kind kind/test-last (with kindly/check syntactic sugar) for test generation
updated documentation (the Kindly-noted project)
updated kind-clerk (Clerk adapter): plotly support

May goals

start working on Kindly support with the creators of new HTMX-based visual-tools
explore the option of a standalone Kindly implementation that is reusable in different tools (an alternative to the current approach of tool-specific implementations)

cmdstan-clj

Cmdstan-clj is a draft library for interop with Stan (probabilistic modeling through Bayesian statistics).

April summary

gave a presentation of the library and the topic of Bayesian Statistics at the real-world-data group
maintenance: adapted the library to related ecosystem changes

May goals

practice usage with community members and keep developing by need

ClojisR

ClojisR is a bridge between Clojure and the R language for statistical computing. During this Month, @generateme released the first non-beta version of the library and announced it as stable after 4.5 years of usage.

April summary

My role in the release was mostly migrating the old documentation to use our current literate programming workflow with Clay, test-generation, and Quarto.

May goals

Migrate the clojisr-examples project to the current workflow.

The Scicloj website

April summary

Maintenance and updates

May goals

minor updates reflecting current projects and events

Your feedback would help

Scicloj is in transition. On the one hand, quite a few of the core members have been very active recently, developing the emerging stack of libraries. At the same time, new friends are joining, and soon, more people will enjoy the Clojure for common data and science needs.

If you have any thoughts about the current directions, or if you wish to discuss how the evolving platform may fit your needs, please reach out.

March & April 2024 Long-Term Project Updates

Wed, 08 May 2024 14:00:00 +1200

Our 2024 long-term developers report on an incredible body of work for March and April. A heartfelt thanks to all!

Bozhidar Batsov: CIDER
Michiel Borkent: squint, neil, clj-kondo,nbb, CLI, and more
Toby Crawley: clojars-web
Thomas Heller: shadow-cljs
Kira McLean: Scicloj Libraries and more
Nikita Prokopov: Datascript, Clj-reload, Clojure Sublimed, and more
Tommi Reiman: Reitit 7.0. Malli
Peter Taoussanis: http-kit, Nippy, Telemere, and more

Bozhidar Batsov

The biggest news in the past couple of months is that CIDER now supports clj-reload, as an alternative of clojure.tools.namespace! You can find the relevant PR here.

Some other noteworthy changes:

Introduced support for global CLI aliases (more details)
Many small improvements to the Inspector (see Orchard’s changelog, e.g. this section)
Dropped support for Clojure 1.9 (it’s barely used these days and dropping it allows us to simplify the codebase and provide a better user experience)
The inspector and code reloading now have dedicated pages in the CIDER’s docs:
- https://docs.cider.mx/cider/debugging/inspector.html
- https://docs.cider.mx/cider/usage/code_reloading.html

Interested people should check out the recent changes in cider-nrepl and orchard, as that’s where the bulk of the work has happened.

We’ve yet to release a new version of CIDER, but I’m expecting this will happen before the end of May.

P.S. We might be close to a solution for the broken interrupt functionality in nREPL on newer JDKs (20+). See this for details.

Michiel Borkent

Updates In this post I’ll give updates about open source I worked on during March and April 2024. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all.

Current top tier sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch.

On to the projects that I’ve been working on!

Updates

Here are updates about the projects/libraries I’ve worked on last month.

squint: CLJS syntax to JS compiler
- #509: Optimization: use arrow fn for implicit IIFE when possible
- Optimization: emit const in let expressions, which esbuild optimizes better
- Don’t wrap arrow function in parens, see this issue
- Fix #499: add support for emitting arrow functions with ^:=> metadata
- Fix #505: Support :rename in :require
- Fix #490: render css maps in html mode
- Fix #502: allow method names in defclass to override squint built-ins
- Fix #496: don’t wrap strings in another set of quotes
- Fix rendering of attribute expressions in HTML (should be wrapped in quotes)
- Compile destructured function args to JS destructuring when annotated with ^:js. This benefits working with vitest and playwright.
- #481: BREAKING, squint no longer automatically copies all non-compiled files to the :output-dir. This behavior is now explicit with :copy-resources, see docs.
- Add new #html reader for producing HTML literals using hiccup. See docs and playground example.
- #483: Fix operator precedence problem
neil: A CLI to add common aliases and features to deps.edn-based projects.
Released version 0.3.65 with the following changes:
- #209: add newlines between dependencies
- #185: throw on non-existing library
- Bump babashka.cli
- Fetch latest stable slipset/deps-deploy, instead of hard-coding (@vedang)
- Several emacs package improvements (@agzam)
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
Released 2024.03.13
- Fix memory usage regression introduced in 2024.03.05
- #2299: Add documentation for :java-static-field-call.
- #1732: new linter: :shadowed-fn-param which warns on using the same parameter name twice, as in (fn [x x])
- #2276: New Clojure 1.12 array notation (String*) may occur outside of metadata
- #2278: bigint in CLJS is a known symbol in extend-type
- #2288: fix static method analysis and suppressing :java-static-field-call locally
- #2293: fix false positive static field call for (Thread/interrupted)
- #2296: publish multi-arch Docker images (including linux aarch64)
- #2295: lint case test symbols in list
  Unreleased changed:
- #1035: Support SARIF output with --config {:output {:format :sarif}}
- #2309: report unused for expression
- #2135: fix regression with unused JavaScript namespace
- #2302: New linter: :equals-expected-position to enforce expected value to be in first (or last) position. See docs
- #2304: Report unused value in defn body
CLI: Turn Clojure functions into CLIs!
Released version 0.8.58-59
- Fix #96: prevent false defaults from being removed/ignored
- Fix #91: keyword options and hyphen options should not mix
- Fix #89: long option never represents alias
rewrite-edn: Utility lib on top of rewrite-clj with common operations to update EDN while preserving whitespace and comments
Released 0.4.8 with the following update:
- Add newline after adding new element to top level map with assoc-in
nbb: Scripting in Clojure on Node.js using SCI
- nbb bundle JS output will ignore nbb.edn
- #351: Update bun docs/example.
- Add cljs.core/exists?
clojure-mode: Clojure/Script mode for CodeMirror 6.
- Fix #49: bug with hitting backspace after line comment Test it in the squint playground.
instaparse-bb: Use instaparse from babashka
- Serialize regexes in parse results
scittle: Execute Clojure(Script) directly from browser script tags via SCI
Released v0.6.17
- #77: make dependency on browser (js/document) optional so scittle can run in webworkers, Node.js, etc.
- #69: executing script tag with src + whitespace doesn’t work
- #72: add clojure 1.11 functions like update-vals
- #75: Support reader conditionals in source code
cherry: Experimental ClojureScript to ES6 module compiler
- #127: fix duplicate cherry-cljs property in package.json which caused issues with some bundlers
- Bump squint common compiler code
clerk
- #646 Fix parsing + location issue which fixes compatibility with honey.sql
http-client: babashka’s http-client
Released 0.4.17-19
- #55: allow :body be java.net.http.HttpRequest$BodyPublisher
- Support a Clojure function as :client option, mostly useful for testing
- #49: add ::oauth-token interceptor
- #52: document :throw option
bbin: Install any Babashka script or project with one command
These fixes have been made by @rads:
- Fix #62: bbin ls is unnecessarily slow
- Fix #72: bbin install [LOCAL-FILE] should not be restricted to files with the .clj extension
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Fix #626: add cljs.core/exists?
- Fix #919: :js-libs + refer + rename clashes with core var
- Fix #906: merge-opts loses :features or previous context
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Fix Windows issue related to relative paths (which took me all day, argh!)
fs - File system utility library for Clojure
- #122: fs/copy-tree: fix copying read-only directories with children (@sohalt)
- #127: Inconsistent documentation for the :posix-file-permissions options (@teodorlu)
babashka: native, fast starting Clojure interpreter for scripting.
- Fix #1679: bump timbre and fix wrapping timbre/log!
- Add java.util.concurrent.CountDownLatch
- Add java.lang.ThreadLocal
- Bump versions of included libraries

Other projects

There are many other projects I’m involved with but that had little to no activity in the past month. Check out the Other Projects section (more details) of my blog here to see a full list.

Published: 2024-04-30 Tagged: clojure oss updates

Toby Crawley

April 2024

Commit Logs: clojars-web

Mostly maintenance work this month related to error handling and tighening error boundaries.

March 2024

Commit Logs: clojars-web, infrastructure

Upgrade from Amazon Linux 2 to Amazon Linux 2023
Updates to error handling and reporting to allow more to be reported
Upgrades to address CVEs

Thomas Heller

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (e.g. Clojurians Slack).

Current shadow-cljs version: 2.28.4 Changelog

Notable Updates

Introduced the shadow-cljs Browser Extension
Worked on some additional devtools for shadow-grove, which will also end up as a browser extension at some point. Similar in spirit as the react/vue developer tools.

Kira McLean

This is a summary of the open source work I’ve spent my time on throughout March and April, 2024. Overall it was a really insightful couple of months for me, with lots of productive discussions and meetings happening among key contributors to Clojure’s data science ecosystem and great progress toward some of our most ambitious goals.

Sponsors

If you find my work valuable, please share it with others and consider supporting it financially. There are details about how to do that on my GitHub sponsors page. On to the updates!

Grammar of graphics in Clojure

With help from Daniel Slutsky and others in the community, I started some concrete work on implementing a grammar of graphics in Clojure. I’m convinced this is the correct long-term solution for dataviz in Clojure, but it is a big project that will take time, including a lot of hammock time. It’s still useful to play around with proofs of concept whilst thinking through problems, though, and in the interest of transparency I’m making all of those experiments public.

The discussions around this development are all also happening in public. There were two visual tools meetups focused on this over the last two months (link 1, link 2). And at the London Clojurians talk I just gave today I demonstrated an example of one proposed implementation of a grammar-of-graphics-like API on top of hanami implemented by Daniel.

There are more meetups planned for the coming months and work in this area for the foreseeable future will look like researching and understanding the fundamentals of the grammar of graphics in order to design a simple implementation in Clojure.

Clojure’s ML and statistics tools

I spent a lot of time these last couple of months documenting and testing out Clojure’s current ML tools, leading to many great conversations and one blog post that generated many more interesting discussions. The takeaway is that the tools themselves in this area are all quite mature and stable, but there are still ongoing discussions around how to best accommodate the different ways that people want to work with them. The overall goal in this area of my work is to stabilize the solutions so we can start advocating for specific ways of using them.

Below are some key takeaways from my research into all this stuff. Note none of these are my decisions to make alone, but represent my current opinions and what I will be advocating for within the community:

Smile will be slowly sunsetted from the ecosystem. The switch to GPL licensing was made in bad faith and many of the common models don’t work on Apple chips. Given the abundance of suitable alternatives, the easiest option is to move away from depending on it.
A greater distinction between statistical modelling and machine learning workflows will be helpful. Right now there are many uses of the various models that are available in Clojure, and the wrappers and tools surrounding them are usually designed with a specific type of user in mind. For example machine learning people almost always have separate training and testing datasets, whereas statisticians “train” their models on an entire dataset. The highest-level APIs for these different usages (among others) look quite different, and we would benefit from having APIs that are ergonomic and familiar to our target users of various backgrounds.
We should agree on standards for accomplishing certain very common and basic tasks and propose a recommended usage for users. For example, there are almost a dozen ways to do linear regression in Clojure and it’s not obvious which is “the best” way to someone not deeply familiar with the ecosystem.
Everything should work with tablecloth datasets and expect them as inputs. This is mostly the case already, but there is still some progress to be made.

Foundations of Clojure’s data science stack

I continue to work on guides and tutorials for the parts of Clojure’s data science stack that I feel are ready for prime time, mainly tablecloth and all of the amazing underlying libraries it leverages. Every once in a while this turns up surprises, for example this month I was surprised at how column header processing is handled for nippy files specifically. I also fixed one bug in tablecloth itself, which I discovered in the process of writing a tutorial earlier in March. I have a pile of in-progress guides focusing on some more in-depth topics from developing the London Clojurians talk that I’m going to tidy up and publish in the coming months.

The overarching goal in this area is to create a unified data science stack with libraries for processing, modelling, and visualization that all interoperate seamlessly and work with tablecloth datasets, like the tidyverse in R. Part of achieving that is making sure that tablecloth is rock solid, which just takes a lot of poking and prodding.

London Clojurians talk

This talk was a big inspiration for diving deep into Clojure’s data science ecosystem. I experimented with a ton of different datasets for the workshop and discovered tons of potential areas for future development. Trying to put together a polished data workflow really exposed many of the key areas I think we should be focusing on and gave me a lot of inspiration for future work. I spent a ton of time exploring all of the possible ways to demonstrate a broad sample of data science tools and learned a lot along the way.

The resources from the talk are all available in this repo and the video will be posted soon.

Summary of future work

I mentioned a few areas of focus above, below is a summary of the ongoing work as I see it. A framework for organizing this work is starting to emerge, and I’ve been thinking about in terms of four key areas:

Visualisation

Priority here is to release a stable dataviz API using the tools and wrappers we currently have so that we can start releasing guides and tutorials that follow a consistent style.
The long-term goal is to develop a robust, flexible, and stable data visualization library in Clojure itself based on the grammar of graphics.

Machine learning

Priority is to decide which APIs we will commit to supporting in the long term and stabilize the “glue” libraries that provide the high-level APIs for data-first users.
Long term goal is to support the full spectrum of libraries and models that are in everyday use by data science professionals.

Statistics

Priority is to document the current options for accomplishing basic statistical modelling tasks, including Clojure libraries we do have, Java libs, and Python interop.
Long term goal is to have tablecloth-compatible stats libraries implemented in pure Clojure.

Foundations

Priority is to build a tidyverse for Clojure. This includes battle-testing tablecloth, fully documenting its capabilities, and fixing remaining, small, sharp edges.

Going forward

My overarching goal (personally) is still to write a canonical resource for working with Clojure’s data science stack (the Clojure Data Cookbook), and I’m still working on finding the right balance of documenting “work-in-progress” tools and libraries vs. delaying progress until I feel they are more “ready”. Until now I’ve let the absence of stable or ideal APIs in certain areas hinder development of this book, but I’m starting to feel very confident in my understanding of the current direction of the ecosystem, enough so that I would feel good about releasing something a little bit more formal than a tutorial or guide and recommending usages with the caveat that development is ongoing in some areas. And while it will take a while to get where we want to go, I feel like I can finally see the path to getting there. It just takes a lot of work and lot of collaboration, but with your support we’ll make it happen! Thanks for reading.

Nikita Prokopov

Hello hello hello, I hope you like some open-source, because I have some for ya. This past two months have been busy!

DataScript:

Implement “constant substitution” optimization for queries #462
Fixed :max-eid for dangling entities during reader-based serialization #463
Fixed tempid in unique refs #464
Pass through BigInteger/BigDeciman to freeze-fn in serializable #465, #466

Humble UI:

Migration to VDOM continues. Ported stack, redid button
Redid state sharing approach between behavior components (e.g. clickable) and visual ones (e.g. button-look)
New frame & event pace graphs
New canvas example (drawing, mouse lag graph)

Skija:

Surface and PictureRecorder cache returned Canvas object and invalidate it when owner is closed #66

clj-reload, a smarter way to reload Clojure code:

Added unload
Fixed issues when adding/removing keeps
Speed up topo-sort #5
Do not report self-reference as a cycle #6
Parse record ctor syntax #7
Added :files option #8

Clojure Sublimed, Clojure development environment for Sublime Text:

Socket REPL: Watches (just like in original LightTable!)
Added transform argument to clojure_sublimed_eval. It lets you implement stuff like print to buffer, eval test under cursor, macroexpand etc #101 #102
Added expand argument to clojure_sublimed_eval
Added output.repl panel and Toggle Output Panel command for raw nREPL #104
Raw nREPL: Support colored output in output console #99
Display failed tests report as red
Fixed Reconnect command
Add on_finish_callback to eval #105
Added print_quota as a setting and as an argument to cs_conn.eval

New library: sane-math

Write mathematical expression in Clojure in infix notation
Part April Fools’ joke, part serious
Supports +, −, *, /, unary minus, ** and parentheses

Blogging:

Best, Niki

Tommi Reiman

Finally! Reitit 0.7.0 is out. It has been over a year in the making, spanning multiple libraries: reitit, malli, schema-tools, [spec-tools](https://github.com/metosin/spec-tools and ring-swagger-ui. Big thanks to everyone involved. There is a lot of draft work that has been queued and can now be worked on. New releases should come more frequently in the future.

Reitit 0.7.0 (all 8 alphas flattened)

0.7.0 (2024-04-30)

The OpenAPI3 release, Year in the making - the changes span over multiple repositories!

Openapi3 support, see the docs
- Fetch OpenAPI content types from Muuntaja #636
- OpenAPI 3 parameter descriptions get populated from malli/spec/schema descriptions. #612
- Generate correct OpenAPI $ref schemas for malli var and ref schemas #673
- new syntax for :request and :response per-content-type coercions. See coercion.md. #627
- #84
Handlers can be vars #585
Fix swagger generation when unsupported coercions are present #671
BREAKING: require Clojure 1.11, drop support for Clojure 1.10
BREAKING: compile-request-coercers returns a map with :data and :coerce instead of plain :coerce function
BREAKING: Parameter and Response schemas are merged into the route data vector - so they can be properly merged into the compiled result, fixes #422 - merging multiple schemas together works with Malli and Schema, partially with data-spec but not with spec.
Fixed some module dependencies so Cljdoc can properly analyze all the modules
Fix reading fragment string on Html5History initialization
Add fragment string parameter to reitit-frontend functions (#604)
Frontend: provide easy way to update current query params. #600
Updated dependencies:

[metosin/malli "0.16.1"] is available but we use "0.10.1"
[metosin/muuntaja "0.6.10"] is available but we use "0.6.8"
[metosin/spec-tools "0.10.6"] is available but we use "0.10.5"
[metosin/schema-tools "0.13.1"] is available but we use "0.13.0"
[metosin/jsonista "0.3.8"] is available but we use "0.3.7"
[com.fasterxml.jackson.core/jackson-core "2.17.0"] is available but we use "2.14.2"
[com.fasterxml.jackson.core/jackson-databind "2.17.0"] is available but we use "2.14.2"
[ring/ring-core "1.12.1"] is available but we use "1.9.6"
[metosin/ring-swagger-ui "5.9.0"] is available but we use "4.15.5"

Malli

0.16.1 (2024-04-30)

Enabled Java8 tests back, no need to limit the version.

0.16.0 (2024-04-20)

BREAKING: minimum Java-version is now Java11
allow changing prefix of json-schema $refs via option :malli.json-schema/definitions-path #1045
Inline refs in non-:body swagger parameters #1044
Fix flaky test #1040
Utility to update entry properties: mu/update-entry-properties #1037
Fix actions cache #1036
Only humanize one of :min / :max when different #1032
Distinguish between symbols and strings in humanize #1031
Fix :map-of :min and unreachable generator, explain such-that failures #1029

0.15.0 (2024-03-23)

:=> takes optional 3rd child, the guard schema validating vector of arguments and return value [args ret]. See Function Guards for more details. Fixes #764 and #764.

;; function of arg:int -> ret:int, where arg < ret
[:=> 
 [:cat :int] 
 :int 
 [:fn (fn [[[arg] ret]] (< arg ret))]]

BREAKING: malli.generator/function-checker returns explanations under new keys:
- ::mg/explain-input -> ::m/explain-input
- ::mg/explain-output -> ::m/explain-output
- new ::m/explain-guard to return guard explanation, if any
m/explain for :=> returns also errors for args, return and guard if they exist
FIX m/deref-recursive doesn’t play nice with :merge schema #997 via #999
FIX nested :repeat sequence schema’s doesn’t seem to work #761 via #1024
FIX Invalid Swagger JSON with [:or :nil] alternatives #1006 via #1023
FIX (explain :tuple []) #1022
Enforce entry specs in open map destructurings #1021
FIX goog/mixin was deprecated and is now removed #1016
Updated dependencies:

borkdude/edamame 1.3.23 -> 1.4.25

Something else

Back at Greece, to relax and to Open Source.

Peter Taoussanis

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open source work!

Hi folks! 🦎

It’s been a very productive couple months! Have been able to continue full-time on open source. Output included:

http-kit v2.8.0

http-kit v2.8.0 final is now on Clojars 👍

http-kit is a simple, high-performance event-driven HTTP client+server for Clojure.

This is the first major stable http-kit release since 2023-06-30, and includes work from 10 contributors. Big thanks to everyone involved! 🙏

Some highlights include:

Performance improvements, incl. auto JVM 21+ virtual threads when available.
Support for the latest Ring async and WebSocket APIs.
A comprehensive new benchmark suite for http-kit server and client.
>15 fixes and numerous other improvements

Nippy v3.4.0

Nippy v3.4.0 final is now on Clojars 👍

Nippy is a fast and mature binary serialization library for Clojure.

This is the first major stable Nippy release since 2023-10-11, and includes:

Faster, more accurate freezable? util (checks if arg is serializable)
Zstandard compression support
Support for serializing next.JDBC results (this was previously broken)

Telemere v1.0.0 first public pre-releases

My main focus during this period has been has been Telemere.

Telemere is a major new library (and along with Tempel, my first all-new library in 7+ years). It’s a structured telemetry library for Clojure/Script, and a highly-polished modern rewrite of Timbre without any of the historical constraints.

It offers a superset of the functionality found in traditional and structured logging, and out-the-box support for SLF4J, OpenTelemetry, clojure.tools.logging, etc.

The latest release can be found here (currently beta5).

Folks happy with Timbre have zero pressure to update, I’ll continue to support Timbre as usual. But Telemere offers a lot of new features and improvements (see README), and migration is often pretty easy.

Will note that based on Clojure survey feedback, I’ve been putting a lot more emphasis lately on beginner-oriented support. For Telemere this includes the most comprehensive wiki and API docs I’ve yet included with a library.

Please do let me know if this stuff is helpful, since it adds a lot to the development effort! 🙏

There’s also a new Telemere Slack channel and short demo video.

Telemere’s a small library, but it’s been a lot of work getting the details just right. I’m happy with the results, and excited for folks to try it out.

Telemere is in many ways represents the refinement and culmination of ideas brewing over 12+ years in Timbre, Tufte, Truss, etc.

Ultimately the hope is for it to help enable Clojure/Script systems that are observable, robust, and debuggable. The wiki intro is probably a good place to start if you’re interested in hearing more.

London Clojurians talk

This was actually recorded back in February, but I have folks still occasionally mentioning that they’d missed it earlier - so I’ll share a reminder here.

The talk is available on YouTube, and is titled Some Controversial Truths: _challenging some commonly-held ideas about Clojure, software engineering, and startups; and sharing the 1 secret that will solve all your problems.

Big thanks to Bruno Bonacci for hosting!

Interview with Daniel Compton

Likewise for folks that missed it earlier - Daniel Compton recently posted a chat we had about my open source work. Big thanks to Daniel for hosting!

Upcoming work

My current roadmap can always be found here.

Current objectives for May-June include:

Release the final stable version of Tempel - my new data security framework for Clojure. Before the final release I’m planning to add support for MFA, extend the docs re: use with OpenID, OWASP, and make a few other last improvements.
Continued efforts on Telemere. I’m currently working on porting handlers over from Timbre, improving the documentation, and helping out folks on the Slack channel.
(If time allows) I’d also like to update Tufte to use the new engine that was written for Telemere. The two already work well together, but this’ll be especially true after they share the same engine (and so filtering and handler API).

- Peter Taoussanis

March 2024 Short-Term Project Updates

Wed, 17 Apr 2024 08:30:00 +0800

We’ve got a lot of great work to report on - all projects funded in Q1 2024. Thanks to all!

clojure-lsp: Eric Dallo
Instaparse: Mark Engelberg
Jank: Jeaye Wilkerson
Scicloj: Daniel Slutsky
SiteFox: Chris McCormick
UnifyBio: Benjamin Kamphaus
Wolframite: Thomas Clark

clojure-lsp: Eric Dallo

Q1 2024 Funding. Reports 2 & 3. Published March 1 and April 1, 2024

clojure-lsp

The main highlight from my work in February is the new linter different-aliases helps guarantee consistency across alias in your codebase!

In April I spent some time fixing and improving clojure-lsp for Calva, but most of the time working on the IntelliJ support for LSP and REPL, improving both clojure-lsp-intellij and clojure-repl-intellij.

2024.03.01-11.37.51

General

Bump clj-kondo to 2024.02.13-20240228.191822-15.
Add :clojure-lsp/different-aliases linter. #1770
Fix unused-public-var false positives for definterface methods. #1762
Fix rename of records when usage is using an alias. #1756

Editor

Fix documentation resolve not working for clients without hover markdown support.
Added setting to allow requires and imports to be added within the current comment form during code action and completion: :add-missing :add-to-rcf #1316
Fix suppress-diagnostics not working on top-level forms when preceded by comment. #1678
Fix add missing import feature on some corner cases for java imports. #1754
Fix semantic tokens and other analysis not being applied for project files at root. #1759
Add support for adding missing requires and completion results referring to JS libraries which already have an alias in the project #1587

2024.03.31-19.10.13

Editor

Adding require command fails for requires without alias. #1791
Add require command without alias now add requires with brackets.
Project tree feature now support keyword definitions like re-frame sub/reg.#1789
Support textDocument/foldingRange LSP feature. #1602
Improve textDocument/documentSymbol considering keyword definitions and returning flatten elements.
Fix Add require/import usages count in code actions. #1794.

2024.03.13-13.11.00

General

Bump clj-kondo to 2024.03.13 fixing high memory usage issue.
Editor
Fix workspace/didChangeConfiguration exception causing noise on logs. #1784

clojure-lsp-intellij

1.14.8 - 1.14.10

Fix exception when starting server related to previous version.
Fix some exceptions that can rarely occurr after startup.
Bump clojure-lsp to 2024.02.01-11.01.59.

There was a major change to how the plugin starts clojure-lsp, now it starts a clojure-lsp process under the hood (like all other editors) instead of using clojure-lsp as a JVM deps, this fixed a lot of macos bugs.
Also this adds support for “find implementations” of defmultis and protocols, something that it was never possible in any other IntelliJ plugin.

2.0.0 - 2.3.2

Use clojure-lsp externally instead of built-in since causes PATH issues sometimes. Fixes #25 and #26
Fix multiple code lens for the same line. #29
Fix os type for macos non aarch64 when downloading clojure-lsp server.
Fix references for different URIs when finding references.
Fix only noisy codelens exception. #33
Support “Find implementations” of defmultis/defprotocols. #31
Fix commands, code actions not being applied after 2.0.0.
Improve “find declaration or usages” to show popup for references.
Improve Find references/implementations to go directly to the usage if only one is found. #39
Wait to check for client initialized to minor cpu usage improvmenet.
Support multiple projects opened with the plugin. #37
Fix Stackoverflow exception when renaming. #32
Add common shortcuts to DragForward and DragBackward.
Fix race condition NPE when intellij starts slowly.

clojure-repl-intellij

Although this is not related with clojure-lsp, it’s a critical library for IntelliJ usage since without it, there is no REPL usage using only LSP. I spent considerable time adding the missing feature to make this plugin good enough for a stable release.
Now the plugin has test support!

0.1.7 - master

Use cider-nrepl middleware to support more features.
Add test support. #46
Fix freeze on evaluation. #48
Improve success test report message UI.
Support multiple opened projects. #51
Fix eval not using same session as load-file. #52

Instaparse: Mark Engelberg

Q1 2024 Funding. Report 1. Published March 30, 2024.

Thanks to funding from Clojurists Together, I have been able to review Instaparse pull requests that have been submitted over the past couple of years. I began by incorporating some “low-hanging fruit” pull requests, which addressed some quality-of-life issues raised by users with minimal changes to the code. Although these were small changes and code was contributed by other users, I needed to test the code and make sure the changes were adequately documented.

I also engaged with users who submitted issues where I needed more explanation or input to carefully consider their proposals. In some cases, I spent time evaluating pull requests but eventually decided not to incorporate that pull request. A good example of this was tonsky’s proposal to change the way that parsers and error messages print at the REPL. His proposal was logical but would be a breaking change, which posed a dilemma. After collecting information from him, I consulted with other Clojurists who are involved with instaparse as well as pretty printing and REPLs. I came to the conclusion that it was better to leave as-is.

The most interesting issue I began looking at was a suggestion to incorporate namespaced non-terminals. This is an excellent suggestion because namespaced keywords have taken on much more importance in Clojure since the time instaparse was initially released, due to their critical role in Datomic and Spec. This will be my next area of focus.

I had hoped to complete more work on namespaced keywords, but I spent most of March ill with covid (my first time getting covid), which delayed my work on this more substantive issue. So, rather than wait for the completion of that work, I deployed a new release with the pull requests I had incorporated so far (actually two releases in quick succession: 1.4.13 and 1.4.14) and I look forward to making progress on namespaced keywords in the coming weeks.

Jank: Jeaye Wilkerson

Q1 2024 Funding. Report 2. Published March 30, 2024.

Oh, hey folks. I was just wrapping up this macro I was writing. One moment.

(defmacro if-some [bindings then else]
  (assert-macro-args (vector? bindings)
                     "a vector for its binding"
                     (= 2 (count bindings))
                     "exactly 2 forms in binding vector")
  (let [form (get bindings 0)
        pred (get bindings 1)]
    `(let [temp# ~pred]
       (if (nil? temp#)
         ~else
         (let [~form temp#]
           ~then)))))

“Does all of that work in jank?" I hear you asking yourself. Yes! Indeed it does. Since my last update, which added dynamic bindings, meta hints, and initial reader macros, I’ve finished up syntax quoting support, including gensym support, unquoting, and unquote splicing. We might as well see all of this working in jank’s REPL CLI.

❯ jank repl
> (defmacro if-some [bindings then else]
    (assert-macro-args (vector? bindings)
                       "a vector for its binding"
                       (= 2 (count bindings))
                       "exactly 2 forms in binding vector")
    (let [form (get bindings 0)
          pred (get bindings 1)]
      `(let [temp# ~pred]
         (if (nil? temp#)
           ~else
           (let [~form temp#]
             ~then)))))
#'clojure.core/if-some
> (if-some [x 123]
    (str "some " x)
    "none")
"some 123"
> (if-some [x nil]
    (str "some " x)
    "none")
"none"
>

New interpolation syntax

Some of the early feedback I had for jank’s inline C++ support is that the interpolation syntax we use is different from what ClojureScript uses. Turns out there’s no reason to be different, aside from jank needing some more work, so jank has been improved to support the new ~{} syntax. If you’re not familiar, inline C++ in jank looks like this:

(defn sleep [ms]
  (let [ms (int ms)]
    ; A special ~{ } syntax can be used from inline C++ to interpolate
    ; back into jank code.
    (native/raw "auto const duration(std::chrono::milliseconds(~{ ms }->data));
                 std::this_thread::sleep_for(duration);")))

New logo

I’m wonderfully pleased to announce that jank now has a logo! The logo was designed by jaide, who was graciously patient with me and a joy to work with through the various iterations. With this logo, we’re capturing C++ on one side, Lisp on the other, and yet a functional core.

Transients

Back to code. In truth, there’s more work going on. A lovely man named Saket has been helping me fill out jank’s transient functionality, which now includes array maps, vectors, and sets, as well as the corresponding clojure.core functions. This is not the first time I’ve brought up Saket, since he also implemented the initial lein-jank plugin. Let’s take a look at that.

lein-jank

This plugin isn’t ready for prime time yet, but it’s a good proof of concept that jank can work with leiningen’s classpaths and it’s a good testing ground for multi-file projects. jank will be adding AOT compilation soon and this lein-jank plugin will be the first place new features will land. As a brief demonstration of where it is today, take a look at this session.

❯ cat project.clj
(defproject findenv "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.11.1"]]
  :plugins [[lein-jank "0.0.1-SNAPSHOT"]]
  :jank {:main findenv.core})

❯ cat src/findenv/core.jank
(ns findenv.core)

(defn -main [& args]
  (let [env-var (first args)
        ; Call through into native land to look up the var.
        env-val (or (native/raw "auto const str(runtime::detail::to_string(~{ env-var }));
                                 __value = make_box(std::getenv(str.c_str()));")
                    "var not found")]
    (println env-val)))

❯ export FINDME="found me!"

❯ lein jank run FINDME
found me!

❯ lein jank run YOUWONTFINDME
var not found

❯ lein jank run LC_ALL
en_US.UTF-8

Migration from Cling to clang-repl

Lastly, I’ve been working on migrating jank to use the upstream LLVM version of Cling, called clang-repl. The key benefit here is that we’d no longer need to compile our own Cling/Clang/LLVM stack in order to build jank and we can distribute jank to use each distro’s normal LLVM package, rather than its own. On top of that, future work is happening more on clang-repl than on Cling, so it has recent support for loading pre-compiled C++20 modules, for example. That would greatly improve jank’s startup performance, since Cling doesn’t allow us to load pre-compiled modules at this point.

Work here is ongoing and there are some bugs that I have identified in clang-repl which need to be fixed before jank can fully make the switch. I’ll keep you all updated!

Scicloj: Daniel Slutsky

Q 1 2024 Funding. Report 2. Published March 31, 2024.

March 2024 was the second of three months on the Clojurists Together project titled “Scicloj Community Building and Infrastructure”. Scicloj is an open-source group developing Clojure tools and libraries for data and science.

As a community organizer at Scicloj, my current role is to help make the emerging Scicloj stack easier and more accessible for broad groups of Clojurians. I collaborate with a few Scicloj members on this.

In March 2024, this has been mostly about the following projects. The projects are listed by their proposed priorities for the coming month.

The real-world-data group

The real-world-data group is a space for Clojure data and science practitioners to bring their data projects, share experiences, and evolve common practices.

March summary

had quite a few one-on-one meetings with group members, discussing their goals, interests, and needs
had the first group meeting, including personal introductions, talks by Kyle Passarelli and by Adham Omran, a hands-on part, and discussions
started creating introductory materials to support the group (see the Scrapbook section)

April goals

have more one-on-one meetings, two more group meetings, and ad-hoc small topical meetings
help the participants take on active paths that connect their interests with community goals

Noj

The Noj project bundles a few recommended libraries for data and science and adds convenience layers and documentation for using them together.

March summary

reorganized the docs and clarified the status of different parts
moved some parts of the experimental functionality to other libraries

April goals

start stabilizing important parts of the experimental API (noj.vis.*, noj.stats)
improve documentation

Clojure Data Scrapbook

The Clojure Data Scrapbook is intended to be a community-driven collection of tutorials around data and science in Clojure.

March summary

created a simple contribution guide
content updates:
- added the Chicago bike trips tutorial
- added the noj-getting-started notebook & video
- added the exploring Observable draft, exploring Observable interop
- added a few updates to the exploring ggplot book
- kept working on the Seattle parks & neighborhoods tutorial

April goals

encourage and help community contributions to the scrapbook
keep adding content to support other projects

Clay

Clay is a minimalistic namespace-as-a-notebook tool for literate programming and data visualization.

March summary

user support
bugfixes, extensions, and performance improvements
7 minor releases
shifted from Alpha to Beta stage

April goals

support user needs, especially in study groups
explore adding emmy-viewers support

Kindly

Kindly is a proposed standard for requesting data visualizations in Clojure.

April goals

discuss Kindly integration with visual tool authors

visual-tools group

This group’s goal is to create collaborations in learning and building Clojure tools for data visualization, literate programming, and UI design.

March summary

had one meeting - the second ggplot study session
supported some related explorations of grammar-of-graphics in Clojure (see the exploring ggplot book), especially connecting Clojure specs to ggplotly

April goals

continue the grammar-of-graphics exploration
have at least one more study session

cmdstan-clj

Cmdstan-clj is a draft library for interop with Stan (probabilistic modeling through Bayesian statistics).

April goals

practice usage with community members and keep developing by need

Your feedback would help

If you have any thoughts about the current directions, or if you wish to discuss how the evolving platform may fit your needs, please reach out.

SiteFox: Chris McCormick

Q1 2024 Funding. Report 2. Published March 30, 2024.

Hello! The second half of my Clojurists Together funded work on Sitefox is complete. I made around 30 commits to the project for a total of 80 since the start of the year and this is a summary of the progress I’ve made.

My goal with the Clojurists Together funding has been to make it safer and easier for other people to get started building sites and apps on Sitefox. There were two components to this: a) improving documentation and setup tooling; b) improving security and stability.

E2e testing

I continued work on e2e tests for Sitefox. I did this to lay the groundwork for other improvements and get confidence that my changes aren’t breaking any major functionality. I made three main improvements to the tests:

I started by finshing off the AJAX fetch request test which includes CSRF testing.
I created a new set of CI rules to run the tests using Postgres, in addition to Sqlite.
I got basic testing in place against shadow-cljs in dev and compiled release modes.

These tests enabled me to replace the CSRF protection module, make changes to the database layer, and upgrade dependencies knowing the main functions of the framework were still working.

Dependency upgrades

Once I had finished the AJAX request CSRF tests I was able to finish replacing the csurf module. I chose csrf-csrf as the replacement and with a few tweaks I was able to verify it as a drop-in replacement. I also upgraded nbb and the Express webserver module which was flagged by GitHub security infrastructure as vulnerable.

Database layer changes

Sitefox wraps the Keyv key-value database layer and it features functions for filtering data based on the result of a callback. Previously this would load all of the rows of the table into memory before running the filter, but I updated it to do this sequentially in batches instead. I also tweaked the way values are deserialized to use the underlying library’s method, and removed some legacy cruft to do with the way objects were returned. I used the database tests to verify that none of these changes impacted typical database use-cases.

Other misc. updates

Various other updates I made to Sitefox included: adding to the auth layer the ability to dynamically redirect on sign-out, inlining the npm “create” scripts so they are part of the main monorepo, and general code tidying and linter fixes.

Presentations

Near the end of February I gave a talk about Sitefox to the London Clojurians meetup group. This was useful as it helped me distill the core ideas behind Sitefox and get feedback from the community.

Finally, one of my goals was to create a “getting started” tutorial. I wrote the tutorial and shot a simple YouTube video, but then discovered the sound had some issues. I will re-record this video with better sound and upload it, as well as publishing the text version of the tutorial to help people get started with Sitefox.

What’s next

Now that the funding period is complete I intend to continue Sitefox maintenance and updates. I have started by cutting a release (v0.0.19) with all of the changes made during the Q1 2024 Clojurists Together funding period.

One thing I am particularly interested in is building an RPC layer as an alternative to cumbersome REST or GraphQL communications. I hope this will make ClojureScript client-server code more natural to write and reason about without hiding away fundamental information about which computer the code is running on. Hopefully more on that later.

I’m very grateful to have received this support from Clojurists Together. Of course the funding itself is helpful but the most important thing for me was that it showed others are interested in this work and find it valuable and worth working on.

Thanks again for your interest and your support!

UnifyBio: Benjamin Kamphaus

Q1 2024 Funding. Report 2. Published March 31, 2024.

Since the last update, most of my development effort has been split into three areas:

Data-driven validations (essentially resulting in specs applied to imported data, as well as other constraints)
Data lifecycle management (retractions work, but diff/merge still in progress)
Example dataset for quickstart, and full tutorial (I have tiput together he example, support docs still in progress)

I haven’t completely wrapped these yet as of Mar 31, but I am very close on the first and last bullet. I will try to update Clojurists Together and the larger data sci/engineering and datomic communities when these things are all available.

Some of my time was spent figuring out what a sustainable long-term solution would be for continuing to develop the core of UnifyBio and to ensure it sees actual use in the life sciences. I had some discussions with different orgs and ended up accepting a full-time position at the Rare Cancer Research Foundation (just started at the end of this quarter), where I’ll have support to further develop UnifyBio. This means the project will probably be moved to the RCRF repo, and there’s a possibility it might be re-branded, or that the UnifyBio name and site might be brought under RCRF’s umbrella. UnifyBio will remain open source, regardless of where it lives. I’ll update Clojurists Together when I have this information, so the project can be pointed to.

IMO this is an ideal place to be positioned coming out of this quarter where I’ve been working on the project as an independent, supported by a mix of client work and funding like the small grant provided to me by Clojurists Together. This change does mean I’ll be spending more time on bio specific applications and not as much work focused on making Unify a generically useful tool for Clojure data science, but this won’t be a 100% shift, as general use will continue to be helpful for the health of the open source data commons ecosystem I’ll be building with RCRF.

I want to thank Clojurists Together again for helping me bridge a time of uncertainty in this interim period while I was working on UnifyBio as a solo dev, and didn’t yet have longer term support from a sponsor or employer.

Wolframite: Thomas Clark

Q1 2024 Funding. Report 1. Published April 15, 2024.

Overview
Code organization
User experience
Documentation
Preparation

Overview

Well, 1 and a half months, much confusion and 1 baby later, we have officially sunk our teeth into the wolfram<->clojure bridge. Wolframite, as newly christened by Pawel, is the continuation of Clojuratica: a geat project, pioneered by great people over more than 15 years. As such, the main task for this part of the funding was simply to get to grips with what’s going on underneath before we can prepare it for posterity. A summary of the work so far follows below.

Code organization

A big part of the work was debugging and merging all of the great things that Pawel and others contributed with the current system. As such, main is now up to date and stable. Examples of incorporated work are making sure that we don’t rely on macros or dynamic vars and that options are passed explicitly. The API has been cleaned up, seprating core functionality from tools etc. and functions and namespaces have been renamed to enforce a standard across the codebase.

User experience

For the user, we have particularly worked on the initialization experience. This has involved fixing bugs that prevented the use of wolframengine on linux, type mismatches, reordering engine priorities (Wolfram has different flavours of installation) and having clearer error messages (e.g. when executables and licences are missing). As well as basic streamlining (removing the need for flags etc.), we have ensured a more robust jlink detection, un-lazy interning and significantly faster symbol loading. We have also, with thanks to Daniel Slutsky, integrated support for ’clay’ and the ’kindly’ system, with a plan for allowing users to specify their own clojure<->wolfram aliases.

Documentation

As well as updating the key, user-facing docs, we have also built a series of troubleshooting tips and development documentation that will no doubt grow before (and after) release. This was further complemented with ongoing internal commenting within the source code. Additionally, we have a new demo notebook that illustrates clay and kindly, and two example physics namespaces that demonstrate the bridge for a couple of real-world problems.

Preparation

Finally, an important part of this early stage has simply been the necessary preparation for the second half, where the lion’s share of our contribution is expected to be felt (particularly now that no more deliveries of small people are expected :) ). Such preparation has largely focused on learning and documenting the internal code structure, opening channels with the official Wolfram team and opening issues: both existing bugs and enhancements highlighted by test use cases.

In the short term, we plan to release wolframite-1.0.0-alpha very soon so that the next stage of development can benefit from community feedback. This should happen as soon as we finalize some “getting-started” materials. These will be aimed at two target groups: Clojure developers interested in data science, and Mathematica / Wolfram users who would benefit from using the algorithms from Clojure (a real programming language!).

Q2 2024 Funding Announcement

Mon, 01 Apr 2024 08:30:00 +0800

Clojurists Together is excited to announce that we will be funding 7 projects in Q2 2024 for a total of $35K USD (3 for $9K and 4 shorter or more experimental projects for $2K). To date in 2024, we are funding 25 projects or developers for a total of $223,000 USD. This includes the 8 long-term developers whose project work we are supporting for the year. We expect to be able to fund another 7 projects this year for a grand total of $258,000. Thanks to all our members for making this happen!

Based on our recent survey results we know that our members and larger Clojure community rely on this work on a regular (most on a daily) basis. If we are able to engage more companies or individual developer members, we could support even more important work - so please get the word out.

As usual, we received a LOT of great proposals - so the decision-making was not easy. However, proposals are returned to the pool for another 2 rounds for consideration. We’re looking forward to developer updates over the next 3-6 months! Here is a general overview of what each developer plans to work on.

$9K Projects

Clj-kondo, Babashka, Squint/Cherry: Michiel Borkent
Compojure-api: Ambrose Bonnaire-Sergeant
Jank: Jeaye Wilkerson

$2K Projects

Clj-merge tool: Kurt Harriger
Enjure: Janet A. Carr
Lost in Lambduhhs Podcast: L. Jordan Miller
Plexus: John Collins

Clj-kondo, Babashka, Squint/Cherry: Michiel Borkent

Work for Q2 2024 project will include:
Clj-kondo: support Clojure 1.12, other Clojure dialects, most wanted open tickets
Babashka: Support new Clojure 1.12 (interop) features, better error messages
Squint / cherry: source map support, better nREPL support, better CLJS compatibility

Compojure API: Ambrose Bonnaire-Sergeant

compojure-api was a popular and actively maintained library to use for web projects around 2014-2018. While its creators have moved on to reitit, there are likely many existing/legacy commercial projects that rely on compojure-api. Lack of support for “old” or “abandoned” libraries is a common pain point for Clojure users, and a common complaint about Clojure in the annual surveys. My focus for this project:

Deploy first releases since 2019
Since 2019 compojure-api (and ring-swagger, a sister project) have not seen releases since 2019, as of the time of writing. There are several issues that warrant new releases.

compojure-api 1.x
– vulnerable dependencies
compojure-api 2.0.0-alpha* branch – release stable 2.0.0
– finalize breaking changes from 1.x => 2.x
ring-swagger
– include critical memory leak fix https://github.com/metosin/ring-swagger/pull/148
– compojure-api will need to bump its ring-swagger version https://github.com/metosin/compojure-api/issues/454

House cleaning

Review documentation, README’s, templates, and wikis for outdated information that have gone stale over the last 5 years.
Review, update and add tests to example projects.
Update CI, linting, and similar tooling that might be applicable.
Triage open issues on compojure-api and ring-swagger. Review open PRs.
Update tutorial https://github.com/metosin/compojure-api/wiki/Tutorial - don’t assume knowledge of compojure.

compojure-api => reitit migration tools
I believe many compojure-api users now use reitit for new projects (as recommended in the compojure-api README), but also have old projects that they wish they could convert to reitit. There are significant performance benefits to using reitit but not all compojure-api projects can be ported since compojure routing is more dynamic than reitit. Even if possible, manually migrating from compojure-api to reitit is error prone and difficult to do incrementally. I would like to build tools to aid converting an existing compojure-api project to reitit.

Swagger 3.0
I would like to investigate what is necessary for supporting Swagger/OpenAPI 3.0 and implement it if time permits.

Jank: Jeaye Wilkerson

At this point, jank has over 80% syntax parity with Clojure. Library parity with clojure.core is around 20%. The next step is to fill out the language to make it feel more like Clojure. There are just a few things remaining which show up in every Clojure program which I will address in Q2 2024 project:
Lazy sequences
Once we have these, we can implement all sorts of core function goodies, lazy like a cat.

Loop/recur
jank only has function-level recur right now, but loop is even more common.

Destructuring: This one’s actually done at a macro level, but right now let, defn, and friends don’t support any destructuring.

Symbol interning
This is a smaller one to tackle, but it’s important for reaching parity. Clojure allocates all symbols separately right now, rather than interning them (though keywords and vars are interned).

Bonus for and doseq magic
If there’s time, I’ll implement all of the craziness that go into the for and doseq macros. All of this will get me where I want to be to start focusing on tooling, distribution, error handling, more robust interop, and overall usability. clojure.core bits will fill in over time and after this quarter we’ll have even more of the essentials in there.

Clj-merge tool: Kurt Harriger

Clojure syntax and style tend to create unnecessary merge conflicts due to bunching of ))) on single line for non-local changes. Manual resolution is often not performed by same person that wrote it and may not be well understood or (re)tested after merge resulting in errors such as moving a form in or out of a else or block changing the code behavior. My project will focus on developing a git diff and merge tool for edn and clojure code with the aim of creating a git mergetool that can be used as a replacement for git’s default merge tool for clj(s) and edn files.

Git’s line based merge algorithms can result in frequent and unnecessary conflicts due changes in whitespace and indentation.

What will clj mergetool do differently?
clj mergetool diffs the data structures rather then the lines of text, as a result conflicts resulting from whitespace and indentation changes are far less likely. One such structural diff/patch implementation used successfully in practice is editscript.

However, these structural edits do not preserve whitespace and a single line of code of output even reformatted is not good enough for source code. However, building on rewrite-clj and the associated zipper structure I believe it is possible to preserve essential whitespace when applying structural changes.

Enjure: Janet A. Carr

Since this is an experimental project, the focus should be on what might constitute a ‘minimum-viable-project’(MVP) to demonstrate the value the Enjure aims to deliver, in accordance with the guiding principles.

The first guiding principle “Easy to get going, easy to keep going” alludes to my starting: point: The Enjure CLI tooling, since it’ll be the first experience all developers will have with it. Largely, I think the Enjure CLI should be able to create new projects and (view/controller) templates as well as delete templates. Migrations are a much bigger task I imagine, and probably outside the scope of an MVP.

Naturally, This implies creating a basic view and controller system. Hardly a compelling idea, but the guiding philosophy of “A holistic approach” gives us a hint as to how it should function. Essentially, each constituent component of the system should have a defined functional interface such that other components can interact with the system in a preordained manner. For example, consider the Enjure CLI, it should be entirely possible for the Enjure CLI to be a ‘view’ unto itself, AND should be easy for a developer to use the same functional interface the CLI might use to create a GUI to manage the Enjure project.

Lost in Lambduhhs Podcast: L. Jordan Miller

This proposal sets forth a strategic plan to rejuvenate the “Lost In Lambduhhs Podcast,” an interview-style technology show for engineers and people working in tech. Through free-form conversational style questions the audience gets the opportunity to “meet the person behind the Github”.

The goal of each episode is to illuminate the personal narratives and insights of tech luminaries, giving them a platform to share their perspectives while promoting their library or tool. Following a hiatus necessitated by the extensive demands of editing and production, the ambition is to leverage the learnings from the initial seasons, alongside the latest advancements in SaaS platforms and generative AI tools.

My strategy aims to streamline my production process, elevate content quality, and achieve consistent episode releases. “Lost in Lambduhhs” has already cultivated a loyal audience by uncovering the human stories beneath technological breakthroughs. Now, with advancements in technology and renewed funding, I am excited for the opportunity to refine my production strategy, rendering the crafting of compelling content both more efficient and sustainable.

Plexus: John Collins

I will be developing a solid modelling library called Plexus, as well as dependent libraries that bring the full power of Manifold (a state-of-the-art CSG modelling library written in c++) to the Java and, most importantly, Clojure ecosystems. Plexus is an effort to define a declarative data model for solid modeling on top of a robust CSG foundation and combine that with the unmatched interactive development experience that Clojure provides.

The library is usable today. The goal of this work will be to (1) smooth out rough edges and make plexus an approachable, hardened, well-document, well-presented, and well-tested library suitable for consumption by non-experts and (2) extend the functionality to make it more powerful (and possibly more extensible) than it is today.

Here is a list of some of the tasks I hope to accomplish in rough order of priority:

Clj-docs for Plexus
Extesive tests
Tutorials, including video tutorials.
Improved error handling and schema validation.
Examples gallery (mostly collected from things I’ve already built with it).
Substantial improvement to the Loft algorithm to make it more general and potentially replace a lot of union operations.
Addition of text support to Manifold.
Three-point arcs.
Bezier curves.
Support for more Manifold operations (SmoothOut, etc.)
(Aspirational/experimental) Topology Projections, allowing the user to navigate and “draw” on the surface of arbitrary manifolds.
ClojureScript Support (via. emscripten build of Manifold)

January & February 2024 Long-Term Project Updates

Mon, 11 Mar 2024 14:00:00 +1200

We’re excited to post the first reports of the year from our 2024 long-term developers. There is a lot of great work to catch-up on, so dive in!

Bozhidar Batsov: CIDER, Clojure-mode, clojure ts-mode
Michiel Borkent: clj-kondo, babashka, SCI, squint, nbb, CLI, and more
Toby Crawley: clojars
Thomas Heller: shadow-cljs
Kira McLean: Scicloj Libraries
Nikita Prokopov: Humble UI, Clj-reload, Datascript, and more
Tommi Reiman: Malli
Peter Taoussanis: Telemere, Tempel, and more

Bozhidar Batsov

Another busy couple of months with quite a few achievements, both big and small. This time around I even managed to write a few articles about the bigger achievements! Here are the highlights for this period:

CIDER now features preliminary support for clojure-ts-mode (see https://metaredux.com/posts/2024/02/19/cider-preliminary-support-for-clojure-ts-mode.html for more details)
clojure-mode has full support for “tonsky”/fixed indentation (see https://metaredux.com/posts/2024/02/19/configuring-fixed-tonsky-indentation-in-clojure-mode.html)
nREPL 1.1.1 is out with improved code completion functionality (see https://metaredux.com/posts/2024/02/20/nrepl-1-1-1-improved-completion-with-compliment-lite.html)
clojure-ts-mode 0.2.1 and 0.2.2 were released (see https://github.com/clojure-emacs/clojure-ts-mode/releases/tag/v0.2.1)
More improvements are in the pipeline on clojure-ts-mode’s front
A new stable CIDER release is likely around the corner

On top of this I wrote an article about the positive impact that community-contributed funding has had on CIDER and friends. Thanks to everyone for their continued support!

P.S. Some of you might be interested to hear that in this period I’ve also become of Flycheck’s maintainers. I’ve spent quite a bit of time working on Flycheck, and I see it very connected to the rest of my projects (e.g. there’s flycheck-elgot and flycheck-clj-kondo which many Clojure programmers user)

Michiel Borkent

In this post I’ll give updates about open source I worked on during January and February 2024. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Like you can read on Bozhidar Batsov’s blog these aren’t the easiest times for Open Source sponsored software. I have no reason to complain, but I did see a similar drop in sponsoring in the last year. I’m thankful for those who sponsored my projects in the past and even more for those who keep doing so! Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all.

Current top tier sponsors:

Additional sponsor info: If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!
Clojurists Together
Github Sponsors
The Babaska or Clj-kondo OpenCollective
Ko-fi
Patreon
If you’re used to sponsoring through some other means which isn’t listed above, please get in touch. On to the projects that I’ve been working on!

Updates

Here are updates about the projects/libraries I’ve worked on last two months.

clj-kondo: static analyzer and linter for Clojure code that sparks joy. Released 2024.02.12
- #2276: New Clojure 1.12 array notation (String*) may occur outside of metadata
- #2278: bigint in CLJS is a known symbol in extend-type
- #2288: fix static method analysis and suppressing :java-static-field-call locally
- #2293: fix false positive static field call for (Thread/interrupted)
- #2093: publish multi-arch Docker images (including linux aarch64)
- #2274: Support clojure 1.12 new type hint notations
- #2260: calling static field as function should warn, e.g. (System/err)
- #1917: detect string being called as function
- #1923: Lint invalid fn name
- #2256: enable assert in hooks
- #2253: add support for datomic-type-extensions to datalog syntax checking
- #2255: support :exclude-files in combination with linting from stdin + provided --filename argument
- #2246: preserve metadata on symbol when going through :macroexpand hook
- #2254: lint files in absence of config dir
- #2251: support suppressing :unused-value using :config-in-call
- #2266: suppress :not-a-function linter in reader tag
- #2259: ns-map unmaps var defined prior in namespace
- #2272: Report var usage in if/when condition as always truthy, e.g. (when #'some-var 1)
squint: CLJS syntax to JS compiler
- #472: Use consistent alias
- #474: fix JSX fragment
- #475: don’t crash watcher on deleting file
- Add simple-benchmark
- #468: Keywords in JSX should render with hyphens
- #466: Fix doseq expression with set! in function return position
- #462: Add "exports" field to package.json
- #460: escape < and > in JSX strings
- #458: don’t emit null in statement position
- #455: don’t export non-public vars
- Fix infix operator in return position
- Allow playground to use JSX in non-REPL mode
- Add transducer arity to all existing core functions
babashka: native, fast starting Clojure interpreter for scripting. Two releases in the past two months with the following changes:
- #1660: add :deps-root as part of hash to avoid caching issue with deps.clj
- #1632: fix (.readPassword (System/console)) by upgrading GraalVM to 21.0.2
- #1661: follow symlink when reading adjacent bb.edn
- #1665: read-string should use non-indexing reader for compatibilty with Clojure
- Bump edamame to 1.4.24
- Bump http-client to 0.4.16
- Bump babashka.cli to 0.8.57
- Uberjar task: support reader conditional in .cljc file
- Support reader conditional in .cljc file when creating uberjar
- Add more javax.net.ssl classes
- #1675: add hash-unordered-coll
- #1658: fix command line parsing for scripts that parse --version or version etc
- Add clojure.reflect/reflect
- Add java.util.ScheduledFuture, java.time.temporal.WeekFields
- Support Runnable to be used without import
- Allow catch to be used as var name
- #1646: command-line-args are dropped when file exists with same name
- #1645: Support for clojure.lang.LongRange
- #1652: allow bb.edn to be empty
- #1586: warn when config file doesn’t exist and --debug is enabled
- #1410: better error message when exec fn doesn’t exist
- Bump babashka.cli to 0.8.55 which contains subcommand improvements
- Bump deps.clj to 1.11.1.1435
- Bump babashka.fs to 0.5.20
- Compatibility with plumbing.core
- Compatibility with shadow.css by improving tools.reader compatibility
- #1647: Allow capturing env vars at build time (only relevant for building bb)
process: Clojure library for shelling out / spawning sub-processes
- #123: exec now converts :env and :extra-env keywords (@lread)
- #140: accept java.nio.file.Path as :dir argument
- #148: accept Path in :out, :err and :in
- Support :out :bytes (@hansbugge)
babashka.json: babashka JSON library/adapter
- Released version 0.1.6 which fixes :key-fn + read behavior for cheshire
tools-deps-native and tools.bbuild: use tools.deps directly from babashka
- Upgraded the underlying tools.build version to the latest version used in tools.build (the very latest wasn’t compatible with tools.build!)
edamame: Configurable EDN/Clojure parser with location metadata
- Support new ^[String] metadata notation which desugars into ^{:param-tags [String]}
- Add :map and :set options to coerce map/set literals into customizable data structures, for example, an ordered collections to preserve key order.
nbb: Scripting in Clojure on Node.js using SCI
- Add cljs.test/run-test macro
- Add cljs.core/Atom
- Add promesa promesify
http-client: babashka’s http-client
- #45: query param values are double encoded
CLI: Turn Clojure functions into CLIs!
- Fix #82: prefer alias over composite option
- Add :opts to :error-fn input
- Fix command line args for test runner --dirs, --only, etc
- Fix --no-option (--no prefix) in combination with subcommands
- Prioritize :exec-args over spec :defaults
- dispatch improvements (@Sohalt, @borkdude):
  - The :cmds order of entries in the table doesn’t matter
  - Support parsing intermediate options: foo --opt1=never bar --opt2=always
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Bump edamame
- Add hash-ordered-coll
- read-string should use non-indexing reader

Other projects

There are many other projects I’m involved with but that had little to no activity in the past month. Check out the Other Projects section (more details) of my blog here to see a full list.
Published: 2024-02-29
Tagged: clojure oss updates

Toby Crawley

January 2024

Commit Logs: clojars-web, infrastructure

I upgraded the PostgreSQL database from v12.1 to v15.5.

February 2024

Commit Logs: clojars-web

This month was a smattering of small changes/fixes:

Thomas Heller

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (e.g. Clojurians Slack).

Current shadow-cljs version: 2.27.5 Changelog

Notable Updates:

Tweaked watch recompile logic to also account for indirect var usages via macros. The usual recompile logic compiles a changed namespace, and then everything which directly required it. This is sometimes insufficient since macros can insert references to other namespaces, without the namespace using the macro having direct knowledge (or require) of that ns. Now all direct accessed vars (after analysis) are collected and used for this logic, making it much more accurate.
Added limited support for npm modules using import() in their code. This is still fairly limited in support, and does not perform actual code splitting as webpack might, but it made some npm modules usable again that would previously just crash.
Worked a lot on shadow-grove. Spent way too much time benchmarking, but I feel confident now that performance is quite good and potentially the fastest CLJS react-equivalent available. Also updated the playground, which I plan on using as the basis for documentation. Still a couple of things to work out, but overall in good shape.

Kira McLean

This is a summary of the work I did on open source projects in January and February 2024. It was published as a blog post on my website here.

Clojure Tidy Tuesdays

The main thing I spent my time working on over the past couple of months was a collection of tutorials and guides for working with data in Clojure. The R for Data Science online learning community publishes toy datasets every week for “Tidy Tuesdays” with a question to answer or example article to reproduce. I’ve been going through them in Clojure, and it’s proven a great tool for uncovering areas for future development in the Clojure data science ecosystem.

Other Work

The explorations with the Tidy Tuesday data have been revealing areas where I think we could benefit from more ergonomic ways to work with tablecloth datasets. I started two little projects each with a couple of little wrappers around existing functions to make them easier to use with tablecloth datasets. So far I’m calling them tcstats (for statistical operations on datasets) and tcutils (with miscellaneous dataset manipulation tools that aren’t built-in to tablecloth directly).

I am also still working on the Clojure Data Cookbook. I nudged it forward ever so slightly these last couple of months, and I plan to finish it despite the remaining holes in Clojure’s data science stack. I would love to also fill these in eventually, but the Cookbook will be a living document that can easily evolve and be updated as new tools and libraries are developed.

Lastly, one of the main missing pieces I’m discovering we really need to work on in Clojure’s data science ecosystem is a robust yet flexible graphics library. There are a few great solutions that already exist, but they take different approaches to graphing that can make them a bit clumsy to work with when it comes time to build more complex visualisations. My dream is to implement a proper grammar of graphics in Clojure, giving the Clojure data ecosystem a “profressional quality” graphics library, so to speak. Anyway.. there is still tons of work to do here so I’m grateful for the ongoing funding that will allow me to continue to focus a large amount of time on it for the foreseeable future.

Nikita Prokopov

Hello guys and gals, Nikitonsky here with some Winter 2024 updates.

New library! Clj-reload is a smarter way to reload Clojure code during development:
Main goal was to replace and improve over tools.namespace:

Do not reload everything on first repl/refresh
Allow users to register hooks on namespace unload
Support in-ns and standalone require and use
Not reload namespaces that were never loaded before
Keep defonce values/protocols/types between reload

And it worked! Humble UI and my website are already migrated to it, and it feels fantastic to being able to use defonce again, without creating a separate namespace just to hold that one value.

Filipe Silva is working on CIDER integration, so I hope we’ll see more adoption soon.

If you’ve been using tools.namespace, give clj-reload a try. You might like it better. If you haven’t, it’s time to reconsider your REPL workflow. We have some convincing points in the README.

Oh, and DO check out our new logo. I’m pretty happy with how it turned out.

Humble UI:

Implemented tricky lazy-loading system
Improved deftype+ stacktraces
Migrated to VDom:
- gap
- label
- image
- svg
- padding
- rect, rounded-rect
- clip, clip-rrect
- halign, valign, center
- vscroll, vscrollbar
- column, row
- hoverable, clickable
- button, toggle-button (new!)
- slider
Migrated to clj-reload
Jakub Dundalek managed to run HumbleUI app from GraalVM native image

JWM:

macOS: fix fullscreen. Yes, I had to fix something that I didn’t touch for a year and it broke anyways.

Humble Deck:

Now supports multiple decks

humble-starter:

Simplest possible project to draw a window on a screen

DataScript:

Query: shortcircuit clause resolution when result is guaranteed to be empty #459 via @galdre

Clojure Sublimed:

Detect namespace from in-ns forms

Sublime Executor:

Support colored output (I can finally see colored diffs in failing tests)

Blogging:

JavaScript Bloat in 2024 (funny side note: other people now translate my articles to Russian because I write in English. How the table have turned!)
New Library: clj-reload
In Loving Memory of Square Checkbox

Talks:

Desktop GUI Made Easy

Onward and upward!

Tommi Reiman

Worked on a big new release of Malli and wrote a blog post about it.

Reitit should be now feature-complete for OpenAPI, will cut out release soon.

Helped users to use and adopt the libs.

0.14.0 (2024-01-16)

Better development-time tooling
- malli.dev/start! captures all malli-thrown exceptions, see [README](README.md#development-mode for details
- does not log individual re-instrumentation of function vars
- BREAKING: changes in malli.dev.virhe and malli.pretty extension apis, wee #980 for details
New m/deref-recursive to recursive deref all schemas (not :refs)
FIX: Malli generates incorrect clj-kondo spec for :fn schemas #836 via #987
Support for Var references #985, see [guide](README.md#var-registry for details.
BREAKING: m/coerce and m/coercer throw ::m/coercion instead of ::m/invalid-input
New Guide for Reusable Schemas
Less printing of Var instumentation
BREAKING: qualified symbols are valid reference types #984
Fixing mt/strip-extra-keys-transformer for recursive map encoding #963
Support passing custom :type in into-schema opt for :map and :map-of #968
mu/path->in works with :orn, :catn and :altn.

Something else

Teppo the Dog enjoying the Sun at Näsijärvi.

Peter Taoussanis

Open source update

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open source work!

It’s been a productive start to the year! Have been focused almost entirely on open source. Output has included:

7x library releases

This includes http-kit v2.8.0-RC1 (tons of new stuff in here!), Tempel v1.0.0-RC1, Nippy v3.4.0-RC2, and Timbre v6.5.0.

See here for the full list, and also here for a new GitHub-hosted roadmap of my major upcoming open source work.

New Tempel explainer video

I recorded a short video to explain the new/upcoming Tempel data security framework.

This hopefully helps makes it clearer where Tempel can be useful.

The ultimate goal is to try make it feasible for more Clojure devs to incorporate data security in their apps, and/or at least get more Clojure devs thinking about ways to protect their users’ data.

It can be easier than you expect, and I detail one example pattern in the video.

BTW please let me know if there’s interest in me doing more of these kinds of videos in future.

London Clojurians Talk

On 20 Feb I gave an online talk at the London Clojurians Group. The talk’s now on YouTube.

Had a good time, was fun talking with folks there. A big thanks to Bruno Bonacci for organizing and hosting!

The talk was non-technical, titled:

Some controversial truths: challenging some commonly-held ideas about Clojure, software engineering, and startups; and sharing the 1 secret that will solve all your problems.

Part of the talk’s intention was to discuss some of the trade-offs that Clojure users/businesses should be aware of, but it looks like the Q&A after was unfortunately not recorded.

Please ping if there’s interest in me posting a write-up to summarize some of the key points discussed.

Interview with Daniel Compton

Had a really nice chat with Daniel Compton about my open source work and other projects. (Thanks Daniel!)

To avoid possible confusion re: discussed dates/timelines, please note that this was recorded at the end of last year (2023).

Lots of work On Telemere

Have been putting in a lot of work on the upcoming Telemere structured telemetry library for Clojure/Script.

Along with Tempel, this’ll be my first all-new Clojure library in 7+ years.

Very happy with how it’s coming along so far, and looking forward to sharing more closer to release (hopefully this April).

In some ways Telemere represents the culmination and refinement of many years of ideas from some of my other libraries - notably Timbre and Tufte.

I think the result is going to be really nice - and something possible only in Clojure.

Upcoming work

All major upcoming work is now documented live here. In addition to all the usual maintenance and support, my biggest objectives for this year are definitely Telemere and a majorCarmine update.

- Peter Taoussanis

Feb. 2024 Short-Term Project Updates

Mon, 04 Mar 2024 08:30:00 +0800

Our first round of reports is in from some of our Q1 2024 deveopers.

Benjamin Kamphaus: UnifyBio
Chris McCormack: Sitefox
Daniel Slutsky: Scicloj
Eric Dallo: clojure-lsp
Jeaye Wilkerson: Jank
VEMV: CIDER

Benjamin Kamphaus: UnifyBio

2024 Q1 Project Report 1. Published 15 February 2024.

Accomplished so far:

Completed lightweight schema definition and spec, an example of which can be found here
Users can now stand up a local system with the plain JSON datalog query service and schema browser (see image below) using docker compose
Very basic quickstart steps are now included in the updated README
Added the ability to retract a Unify managed dataset
Streamed on twitch for a few weeks but paused that, moving all Unify dev to YouTube (see more below).

For the short term, my goals are:

Prioritize dataset lifecycle management, dataset lifecycle scenario tests, tutorials
Delay work on additional backends and streaming processing until I hit a stable point re: ^ *View of the schema browser, now part of the local Unify system (adapted from alzabo by Mike Travers)

At this point, Unify is in a decent shape as an alpha for prototyping/experimental work. I’d hold on using it for production, though things are stabilizing pretty quickly.

Two ways to make use of Unify that I think would be straightforward for its current state:

For anyone already using Datomic, who wants to import data that is in tabular form, or can be turned into a table, they could have a go at adding Unify annotations to their existing schema and writing an import config
For anyone wanting to start working incrementally at data modeling for a new domain, Unify can provide a good interactive environment for vetting how data out in the world, e.g. in tables, might map on to your schema, and you can visualize the data model and connections between entities as you go with the schema browser.

Edges are sharp and documentation is still limited but more detailed tutorials are coming soon!

If anyone is interested in getting stated with using Unify for data integration, or just importing tables into their Datomic schema, but are a bit wary of jumping into this blind, I’m on the Clojurians Slack as:
@Ben Kamphaus

In the channels:
[#unify, #datomic, #data-science, #data-engineering]

Notes on Streaming

I started streaming dev on Unify with Twitch but have had some frustrations with the platform and gotten feedback that YouTube would be better for streaming also, not just collecting videos. It’s not worth going into too much detail on this, mainly I want to point people to the YouTube channel if they want to follow along as I get this aspect of the work going again.

Thanks to Clojurists Together and the Rare Cancer Research Foundation for supporting this work!

Chris McCormack: Sitefox

2024 Q1 Project Report 1. Published 15 February 2024.

Hello! The first half of my Clojurists Together funded work on Sitefox is complete. I made around 50 commits to the project since the start of the year and this is a quick summary of the progress I’ve made.

My broad goal with the Clojurists Together funding is to make it safer and easier for other people to get started and build sites and apps on Sitefox. There are two components to this:
a) improving documentation and setup tooling
b) improving security and stability

Updating dependencies

I started the process of updating dependencies with an npm audit. This command finds npm packages with known vulnerabilities. I updated the npm package nodemailer due to a vulnerability, and I also express, nbb, and react. I also updated Clojure deps Promsea, and js-interop. This was the first part of the dependency updates item.

The second part of the dependency updates item was to replace the deprecated csurf module. This Express module is responsible for securing POST requests against CSRF attacks. Express is the web server that Sitefox depends upon and they have decided to no longer provide this module themselves.

Replacing this module turned out to be a bigger task than I anticipated. I started by evaluating several libraries as replacement candidates. Next I created a branch to try out one of these replacements. At first it looked like the library was a good replacement, but it was only upon more rigorous testing that I realized it had serious flaws that made it unsuitable.

This experience made it clear to me that I needed comprehensive testing of the form submission and authentication flows in order to tell if a library was a good replacement and did not introduce any bugs or regressions. This led me to work on the second part of the work.

End-to-end testing

I spent the greater proportion of the commits after this working on end-to-end tests of basic Sitefox functionality including:

Tests for basic server functionality - does the web server run, render pages, and respond to requests?
Tests for the main authentication flows such as signing up, signing in, signing out, forgot password.
Tests for form submission and field validation, including CSRF protection.
Tests for CSRF protection on Ajax POSTs.

I managed to get all of these tests implemented and passing except for the final Ajax test which I am still working on. After that I got the tests running headless on every commit via a GitHub action. This will ensure that the most basic functionality Sitefox offers won’t be inadvertently broken when I make major changes in future. In particular I can ensure the CSRF protection continues to work after upgrading to a different CSRF library.

What is next

From my initial plan I have only managed to make progress on these two items. My goal for the remainder of Q1 is:

Finish the CSRF Ajax testing.
Finish replacing the csurf dependency with a well-tested alternative.
Update the key-value database module list and filtering code.
Move the npm create helpers into the main repo, and document them properly.
Tutorials showing how to get started building on top of Sitefox.

Given the progress of the first half of the quarter, I have tempered my goals a bit. If I can get these items done that will still provide a solid foundation for people wanting to get started with Sitefox and rely on it to build sites and apps.

You can see the board I am using to track progress here: https://github.com/users/chr15m/projects/13/views/1

Thanks for your interest and your support!

Daniel Slutsky: Scicloj

2024 Q1 Project Report 1. Published 29 February 2024.

February 2024 was the first of three months on the Clojurists Together project titled “Scicloj Community Building and Infrastructure”.

Scicloj is an open-source group developing Clojure tools and libraries for data and science.

As a community organizer at Scicloj, my current role is to help the emerging Scicloj stack become easier and more accessible for broad groups of Clojurians. This is done in collaboration with a few Scicloj members.

In February 2024, this has been about the following projects:

Clay

Clay is a namespace-as-a-notebook tool for literate programming and data visualization developed in collaboration with Timorthy Prately. It is used for documenting libraries and tutorials as well as an analysis tool for dynamic data exploration.

In February 2024, Clay got five new releases, mostly around the following:

improved compatibility of various visual elements with Quarto
improved support for making books
simplified live-reload experience
support for Observable visualizations
additional user-reported bugs and feature requests

Many thanks to generateme for the extensive testing and the numerous issues discovered.
In March 2024, the plan is mostly to continue user support and move from the alpha to the beta stage.

Noj

Noj is a project that collects a few recommended libraries for data and science in a bundle and adds some convenience layers for using them together.

During February 2024, we had some rethinking of this project’s scope and goals in discussion with Carsten Behring, who got involved in the project and has made some substantial contributions to its documentation.

My goal has been mostly to review Carsten’s work and add some documentation. For March 2024, the hope is to clarify the project’s goals and reorganize its relationships with other libraries accordingly.

Clojure Data Scrapbook

The Clojure Data Scrapbook is intended to be a community-driven collection of tutorials around data and science in Clojure.

In February 2024, I added a few tutorials and made some changes to the project structure. For March 2024, the main goal is to clarify the contribution workflow and encourage contributions.

Dev and study groups

visual-tools

In the visual-tools group, we began a new series of study sessions around ggplot2 and the grammar of graphics.

The intention is to implement a similar library in Clojure.

In February 2024, my attention has been around prototyping possible solutions, exploring ggplot and its internals, and creating a group of people who are interested in learning it. A few datavis-minded Clojurians have gathered a group and started thinking together, in meeting and over chat.

In March 2024, we will keep learning together. Hopefully, the ideas will be clarified, and some of the group members will start building something.

real-world-data

The real-world-data group will be a space for Clojure data and science practitioners to bring their own data projects, share experiences, and evolve common practices.

In February 2024, I restarted the group organization, mostly in one-on-one calls and chats with a few of the people who are planning to join.

In March 2024, we are expecting to have the first meeting.

Your feedback would help

Scicloj is in transition. On the one hand, quite a few of the core members have been very active recently, developing the emerging stack of libraries. At the same time, new friends are joining, and it seems like soon, more people will enjoy the Clojure for common data and science needs.

If you have any thoughts about the current directions, or if you wish to discuss how the evolving platform may fit your needs, please reach out.

Eric Dallo: clojure-lsp

2024 Q1 Project Report 1. Published 29 February 2024.

January 2024 Update:

clojure-lsp

The main highlight is the new custom project tree feature which shows project source-paths, dependencies, jars and namespaces!

2024.02.01-11.01.59

General
- Fix binary not wokring on some aarch64 linux. #1748
- Add new Project tree feature via the clojure/workspace/projectTree/nodes custom method. #1752
- Fix --log-path setting to work with listen/empty arg, starting clojure-lsp server and logging properly.
Editor
- Fix didChangeConfiguration throwing exception. #1749
- Fix rename of ns causing wrong ns names because of duplicate rename actions. #1751
- Fix range-formatting throwing exceptions when unbalanced parens are sent from client. #1758
- Fix rename functions need to clean up LSP state or restart in some clients implementing LSP method didRenameFiles. #1755
- Fix thread last all failed after comment form #_(...). #1745

Besides the clojure-lsp work, I worked too on some related projects that I think are important to improve clojure-lsp visibility and standardization as a tool, for example clojure-repl-intellij which without it make the use of clojure-lsp-intellij less valuable.

clojure-lsp-intellij

1.14.16 - 1.14.17

Bump clojure-lsp to 2024.02.01-11.01.59.
Add shortcuts to backward slurp and barf.
Add shortcut documentation to all features, check the features doc page.
Fix Rename feature not being available for some cases.

clojure-repl-intellij

Support for starting local repl besides the already available remote repl.

February 2024 Update

clojure-lsp

The main highlight is the new linter different-aliases helps guarantee consistency across alias in your codebase!

2024.03.01-11.37.51

General
- Bump clj-kondo to 2024.02.13-20240228.191822-15.
- Add :clojure-lsp/different-aliases linter. #1770
- Fix unused-public-var false positives for definterface methods. #1762
- Fix rename of records when usage is using an alias. #1756
Editor
- Fix documentation resolve not working for clients without hover markdown support.
- Added setting to allow requires and imports to be added within the current comment form during code action and completion: :add-missing :add-to-rcf #1316
- Fix suppress-diagnostics not working on top-level forms when preceded by comment. #1678
- Fix add missing import feature on some corner cases for java imports. #1754
- Fix semantic tokens and other analysis not being applied for project files at root. #1759
- Add support for adding missing requires and completion results referring to JS libraries which already have an alias in the project #1587

clojure-lsp-intellij

1.14.8 - 1.14.10

Fix exception when starting server related to previous version.
Fix some exceptions that can rarely occurr after startup.
Bump clojure-lsp to 2024.02.01-11.01.59.

Jeaye Wilkerson: Jank

2024 Q1 Project Report 1. Published 26 February 2024.

tl;dr I’m well ahead of schedule, so far this quarter! There’s a more detailed update here, with technical explanations: https://jank-lang.org/blog/2024-02-23-bindings/

Dynamic bindings

Dynamic bindings are implemented! I’m starting to use these within the compiler, as well, to track state. jank doesn’t have future yet, but everything is in place for binding conveyance. To go hand in hand with this, I tackled meta hints next, allowing us to do things like ^:dynamic on a var.

Meta hints

jank now supports hints in the form of ^:keyword, as well as ^{:keyword true}. Multiple hints can be specified, they can be nested, etc. Not many parts of jank are using these hints yet, since I didn’t go through all existing code to update usages, but we can do that iteratively.

What else?

Well, my quarter was booked for the following tasks:

🗹 Dynamic vars
🗹 Meta hints
☐ Syntax quoting
☐ Normalized interpolation syntax

The first two are done and the latter two remain, to be done in the next month. But is that all I did in two months? Just dynamic vars and meta hints? Nah.

Support for exceptions

I’ve added support for the special throw form, as well as for try/catch/finally. Previously, I was using inline C++ to throw exceptions, but the work on the dynamic vars gave me a good excuse to get proper exception support in there. I needed to ensure bindings were gracefully handled in exceptional scenarios!

My plan is to do a compiler deep dive, next post, going into how exceptions were implemented in jank. Stay tuned for that.

Escaped string literals

jank previously didn’t properly support strings like "foo \"bar\" spam", since they require mutation in order to unescape them. This is an interesting edge case, because all of the other tokens within jank’s lexer work based on memory mapped string views. String views allow jank’s lexer to run without any dynamic allocations at all. However, for escaped strings, we need to allocate a string, since we need to mutate it when unescaping. It’s straight-forward, but just something I hadn’t tackled yet.

Reader macros

Since I was improving the reader to support meta hints, I figured I’d add reader macro support. In jank, you can now use #_ to comment out forms. Also, you can use #{} to create sets. Finally, you can use #?(:jank foo) and #?@(:jank []) to conditionally read in jank code. The :default option is supported, too. Support for shorthand functions, regex values, and var quotes will be coming soon.

New core functions and macros

While implementing the above features, I also added support for the following vars in clojure.core:

assert
when-not
comment
zipmap
binding
with-redefs
drop (not lazy)
take-nth (not lazy)

Since jank doesn’t have lazy sequences yet, some of these functions are a little hacky. Lazy sequences come next quarter, though, as well as loop support!

Community involvement

jank received its first non-trivial code contributions this quarter, from a helpful man named Saket Patel. He’s working on a jank plugin for leiningen and it’s currently in a state where you can set up a multi-file jank project and use lein jank run to make magic happen. 😁 He’s also submitted some C++ improvements to aid in that quest and to help jank compile on Apple M1 hardware. I’ll have a more detailed demonstration of this in my next development update.

On top of that, in order to get him set up for contributing, I’ve done the following:

Added a Code of Conduct
Added a CLA, which is managed by a bot that will prompt you to sign upon submitting a PR with a large enough
Added automated code formatting and re-formatted the whole codebase, using clang-format. I don’t like the look of it, but at least it’s consistent

VEMV: CIDER

2024 Q1 Project Report 1. Published 7 February 2024.

January CT-sponsored work resulted in CIDER 1.13.0 (“Santiago”) and a subsequent 1.13.1 bugfix release.

Highlights have included:

all-new Timbre compatibility for cider-log-mode.
misc bugfixes, a couple of which were highly requested over the Clojurians Slack #cider channel.

There’s also been some WIP to improve our cljfmt integration.

Call for Proposals. February 2024 Member Survey

Tue, 13 Feb 2024 08:30:00 +0800

Call for Proposals.

Greetings All! It’s that time again.

Clojurists Together is pleased to announce that we are opening our Q2 2024 funding round for Clojure Open Source Projects. Applications will be accepted through the 4th of March 2024 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.

We surveyed our members in February to find out what types of initiatives they would like us to focus on for this round of funding. Their responses are summarized below. In particular, it was great to see members' feedback relating to how often they used or referred to developers' work we have funded. Check this out!

Our Members Speak: Feedback from the February 2024 Survey.

What areas of the Clojure and ClojureScript ecosystem need support?

Fractured build tooling. Deps feels like ant from java land still, every project a bit different with all the aliases. Lein was fine
A Clojure specific job platform would be great?
Development tools, AI/ML.
Data science/ML stack. Really don’t want to use python if I can help it.
Visualisation
Tooling like CIDER
Evangelism, Attracting more new users
In-person conferences in Europe
The ecosystem could use more beginner material and ergonomic tooling to help beginners get started.
Newcomer DX. Otherwise, the community will die out.
The React story has been good at first but React’s ecosystem is evolving and the ClojureScript counterparts aren’t really keeping up. There’s no common best practices for architecting SSR, code splitting etc.
Cljs build tools, type linters, DX
Documentation, Building and Test tooling-related areas
Better ways to build desktop applications.
Error messages, error messages, error messages.
I think the Google Closure Compiler is nearing the end of its life, so we should be supporting efforts that provide a more certain future for ClojureScript.
Malli schemas, datalog, electric, component

What areas of the Clojure and ClojureScript ecosystem are strong?

Too many to list! Clojure is just amazing - I just love coding in it.
Core language and Libs
Community. Response from and helpfulness of community members. The community is also very kind.
Stability, backwards compatibility, performance
Shadow-cljs works great, most development tooling is quite good
Clojurian Slack - https://clojure.org/api/cheatsheet
The overall API stability of the libraries - Babashka - ClojureScript and Shadow-cljs
IDE support, Linters, Data Analysis/Processing Frameworks Language expressively, ability to write clean code, REPL-oriented development

Are there any particular libraries, tools, or projects that are important to you that you would like to see supported?

(Number of mentions in parentheses):

Malli (8) and code quality tools generally, things that address the misconception that dynamic typing is malpractice relative to stat
Shadow-cljs (5)
Cider (5)
Babashka (4) and more libraries useable in this domain (e.g. writing Excel files)
Jank (4)
Clojure-lsp (3)
com.github.seancorfield/honeysql(3)
com.github.seancorfield/next.jdbc(3)
metosin/reiti(3)
Clj-kondo (2)
uix v2 (2)
Calva (2) for an improved developer experience (not the same as more features).
Tech.ml.dataset (2) is looking really good - Chris’s projects need to be included
Ring (4)
Re-frame(2)
Reagent(2)
Flowstorm (2)
Integrant (2)
Borkdude (2)
I still use lein for new projects because it is easy. It runs tests and the uberjar function is right there.
(1 each) Pathom and related, Asami, nt, uncomplicate libs, Data science stack, Core.typed, nbb, Clojure-ts-mode, Duct , Taoensso (tufte, timbre, sente), Weavejester (ragtime, crypto-password), Luminus/ring-undertow-adapter, com.fzakaria/slf4j-timbre, Conjure, ‘com.widdindustries/cljc.java-time, Datahike, Migratus, Hiccup, Oz, Scicloj
I would like a replacement for Oz to render vega/vega-lite, which isn’t maintained anymore, and https://github.com/scicloj/viz.clj exists, which looks promising. Don’t really care for the added layer of hanami in between-on top.
This Clojure Conj 2023 made me think that Clojure could rock really rock Data Science(2): https://www.youtube.com/watch?v=MguatDl5u2Q
I don’t mind using Java interop now and again, but I would like to avoid having to write extensive Java in Clojure syntax. Currently high on my list: anything bbatsov does (Cider, of course)
Nikita’s Humble UI is a big deal for me - I hope it will get desktop app development going in a bigger way with Clojure

What would you like to be different in the Clojure community in the next 12 months?

Comments from several members: Grow the size of the community. more outreach, community building, more conferences and meetups
Supporting new community contributors, thinking about how the tech sector layoffs will impact clj community (where are the jobs?)
I’d like to see even more newcomers and more support for those newcomers in the form of mentorship and up-to-date documentation, guides, and courses. I’d also like to see more outreach by the Clojure community into broader programming communities to help bring in more newcomers.
Succession planning. What happens when @whilo, @tonsky, or @taoensso move on from open source dev?
I think the community is doing well, especially since Nubank upped its support for Clojure devs, as well as the great work you do at Clojurists Together. There’s definitely increased motivation and focus on Clojure with a large number of devs whose tools I use regularly. More of this and I think the Clojure community will continue to be golden.
Do for clojure what typescript did for javascript and the userbase will get bigger
A strong competitor to CIDER in the emacs space
Consider tools / systems using capabilities of Java 21 (threads).
Optional type system, lsp-support
That people with design and UI skills help updating Clojure related websites to give a modern impression. Clojure related websites could be clojuredocs.org or planet.clojure.in but really anything with can be considered to be “the face of the Clojure community to the outside”. Just because Lisp is +70 years, doesn’t mean our websites and tools have to look and feel like something from back then.
I also hope to finde more blog post about solving problems with Clojure - both big and small. Blog posts inspire me to try new things and push the limits of what is possible with Clojure. I prefer blog posts over videos because they are easy to “scan” and search because of the text format and examples are easily copy-pasted.
I’d like a full visualisation stack in clojure that didn’t depend upon javascript
I’d like to see a foundation formed to tackle the things the core team is uninterested in.
A lighter weight polylith to organize code into components or modules

November and December 2023 Project Updates

Mon, 22 Jan 2024 08:30:00 +0800

There is a lot of work to report on folks! We're closing 2023 with two groups of updates:

the 6th and final reports from our 2023 long-term developers
final updates from Q3 2023 projects Jank and Quil

Thanks to all our 2023 developers for their incredible work throughout the year. We’re looking forward to an awesome 2024!

2023 Long-Term Developers:
Bozhidar Batsov: CIDER/REPL
Eric Dallo: Clojure-lsp, clojure-repl-intellij, clojure-lsp-intellij
Michiel Borkent: clj-kondo,babashka, squint, neil, CLI,clojure-mode, and more..
Nikita Prokopov: Humble UI, Clojure Sublimed, DataScript, Sublime Executor
Peter Stromberg: Calva, JavaScript REPL, Polylith
Peter Taoussanis: Carmine, Nippy, http-kit, Tempel, Telemere
Sean Corfield: clojure-doc.org, deps-new, honeySQL, expectations, next.jdbc, clj-Watson, org.clojure/java.data
Thomas Heller: Shadow-cljs
Toby Crawley: Clojars
Tommi Reiman: Malli, Reitit, Jsonista

Q3 2023 Updates:
Jeaye Wilkerson:Jank
Charles Comstock and Jack Rusher: Quil

Final Reports 2023 Long-Term Developers

Bozhidar Batsov

Happy New Year, everyone!

November and December were a bit slower than the previous couple of months, but we still made some nice progress. During this period we’ve continued the trend of refining the big changes introduced in CIDER 1.8. We’ve shipped 2 new releases - CIDER 1.11 and CIDER 1.12 - both of them feature mostly refinements to the Inspector functionality.

There’s currently a bit of work-in-progress to refine cider-log-mode that will likely land in the next feature release. The work to add clojure-ts-mode support in CIDER in in progress as well.

I also wrote an article on using clojure-lsp alongside CIDER and I plan to do a bit more work in that direction (e.g. expand CIDER’s documentation). And finally write some of the backlogged CIDER articles I have in my personal TODO list. :-)

Eric Dallo

During these 2 months I spent a considerable time doing mostly 2 things:

Working with @afucher in a new IntelliJ Clojure repl plugin, so people can really use clojure-lsp-intellij plugin with an option to repl support
Moving to a new apartment in another city :)

Even so, I can say I’m proud of the ongoing work on IntelliJ side related to clojure-lsp support, and I hope in a few weeks we should announce the new clojure-repl-intellij plugin and how to use it with clojure-lsp.

clojure-repl-intellij

It’s still pretty alpha and missing lots of REPL features, but this is how it’s looking for now:

clojure-lsp-intellij

clojure-lsp-intellij is way more stable, compatible with multiple intellij versions and other plugins like vim-intellij, also the main feature highlight is the new wizard to create new Clojure projects from Intellij itself:

0.13.1 - 0.14.1

Bump clojure-lsp to 2023.12.29-12.09.27.
Add wizzard to create multiple Clojure types of projects directly via Intellij.
Fix format for non clojure files. #28
Bump clojure-lsp to 2023.10.30-16.25.41-hotfix2 to fix settings merge during startup.
Fix exception during hover element.
Fix exception during find definition specific cases.
Fix support for older intellij.
Fix classpath lookup injecting user env on default classpath lookup commands.

clojure-lsp

The main highlights are performance improvements and fixes, there is a huge improvements in clojure-lsp API for the format task.

2023.12.29-12.09.27

General

Fix deep-merge of client settings with project settings.
Fix max-line-length on clean-ns feature not respecting some lines when contains a lot of refers. #1729
Bump cljfmt to 0.12.0.
Bump clj-kondo to 2023.12.15.

Editor

Fix edn tree visualization for keys with same name in the same level. #1558
Make clear when hover feature is in a calling and not in a specific symbol. #1281
Exclude keys that are already included in the function call from completion suggestions. #1720

API/CLI

Drastically improves performance of format task matching cljfmt, avoiding analyzing the project. #1723

Happy new year, and thank you all for this amazing journey!

Michiel Borkent

Happy new year!

First all, as this is the last day of 2023, I wish you all a happy new year. Hopefully many goods things may happen in the Clojure ecosystem. I’m grateful many of you have sponsored my work in 2023!

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible. Without you, the below projects would not be as mature or wouldn’t exist or be maintained at all. Top sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch. Thank you! On to the projects that I’ve been working on!

Advent of Code

It is Advent of Code time of year again. You can solve puzzles in an online squint or cherry playground here.

Change the /squint/ part of the url to /cherry/ to switch ClojureScript dialect versions. You can read more about the playground here.

November 2023 Updates

blog I’ve written two blog posts this month:
- Writing a Cloudflare worker with squint and bun
- Playing Advent of Code with Squint.
squint: CLJS syntax to JS compiler
Lots of stuff happened in November with squint! You could say that I’ve grown a little addicted to improving this project currently, driven by how users use it and also while developing the playground, a lot of potential improvements emerged. See blog for more detail
scittle-hoplon: a custom scittle distribution with Hoplon. I helped developing the SCI configuration for Hoplon.
gespensterfelder: a demo that Jack Rusher wrote using Three.js ported to squint.
neil: A CLI to add common aliases and features to deps.edn-based projects Version 0.2.63 released which adds mvn search and some bugfixes
CLI: Turn Clojure functions into CLIs!
- Small bugfix around priority of :exec-args and default
aoc-proxy: a Cloudflare worker that can be used to fetch Advent of Code puzzle input from the browser (see Advent of Code playground)
squint-macros: a couple of macros that stand-in for applied-science/js-interop and promesa to make CLJS projects compatible with squint and/or cherry.
clojure-mode: Clojure/Script mode for CodeMirror 6.
- Ported the eval-region extension to squint so you can use it straight from JS. This is used in the squint playground when you press Cmd-Enter after an expression.
sci.configs: A collection of ready to be used SCI configs.
- A helper macro was improved such that you can define macros that are usable in SCI
- The re-frame configuration now has support for re-frame.alpha. See playground.
babashka: native, fast starting Clojure interpreter for scripting. A new release: 1.3.186! See blog for more detail
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs \ Released version 0.8.41 See blog for more detail
cherry: Experimental ClojureScript to ES6 module compiler
- Released version 0.1.10 which catches up with the latest compiler improvements in squint
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- New :condition-always-true and :underscore-in-namespace linters + couple of bugfixes. Release expected in December.

December 2023 Updates

clj-kondo: static analyzer and linter for Clojure code that sparks joy. Released 2023.12.15
- #1990: Specify :min-clj-kondo-version in config.edn and warn when current version is too low (@snasphysicist)
- #1753: New linter :underscore-in-namespace (@cosineblast)
- #2207: New :condition-always-true linter, see docs
- #2235: New :multiple-async-in-deftest linter: warn on multiple async blocks in cljs.test/deftest, since only the first will run.
- #2013: Fix NPE and similar errors when linting an import with an illegal token (@cosineblast)
- #2215: Passthrough hook should not affect linting
- #2232: Bump analysis for clojure 1.12 (partitionv, etc)
- #2223: Do not consider classes created with deftype a var that is referred with :refer :all
- #2236: :line-length warnings cannot be :clj-kondo/ignored
- #2224: Give #'foo/foo and (var foo/foo) the same treatment with respect to private calls
- #2239: Fix printing of unresolved var when going through :macroexpand hook
quickblog: Light-weight static blog engine for Clojure and babashka v0.3.3 - v0.3.6 released
- Fix caching in watch mode
- #86: group archive page by year
- #85: don’t render discuss links when :discuss-link isn’t set
- #84: sort tags by post count
- #80: Generate an about.html when a template exists (@elken)
- #78: Allow configurable :page-suffix to omit .html from page links (@anderseknert)
- #76: Remove livejs script tag on render. (@jmglov)
- #75: Omit preview posts from index. (@jmglov)
- Support capitalization of tags
- #66: Unambigous ordering of posts, sorting by date (descending), post title, and then file name. (@UnwarySage)
squint: CLJS syntax to JS compiler
Lots of stuff happened in December with squint! Too many to mention here, just check the CHANGELOG.md
clojure-mode: Clojure/Script mode for CodeMirror 6.
- Improved the eval-region extension: when you evaluate #_(+ 1 2 3)| the expression (+ 1 2 3) is evaluated Test it in the squint playground.
fs - File system utility library for Clojure Released 0.5.20:
- #119: fs/delete-tree: add :force flag to delete read-only directories/files. Set the flag to true in fs/with-temp-dir (@jlesquembre)
- #102: add gzip and gunzip functions
- #113: fs/glob: enable :hidden (when not already set) when pattern starts with dot (@eval).
- #117: fix fs/match and fs/glob not finding files in root-folder (@eval).
cherry: Experimental ClojureScript to ES6 module compiler
- Released version 0.1.16 which catches up with the latest compiler improvements in squint and also adds the clojure.set namespace
http-server: serve static assets
- Released 0.1.12 with several new features
babashka: native, fast starting Clojure interpreter for scripting.
- Working towards a new release, planned for next month.

Other projects

These are (some of the) other projects I’m involved with but little to no activity happened in November and December. See final section of each report (“Other Projects”) for details.
[https://blog.michielborkent.nl/oss-updates-nov-2023.html]
[https://blog.michielborkent.nl/oss-updates-dec-2023.html]

Discuss this post here
Published: 1 and 31 December, 2023 \ Tagged: clojure oss updates

Nikita Prokopov

Last update of the passing year, so pour yourself a warm drink, cover yourself with a cozy wool blanket and let’s see what are we ending the year with.

Humble UI:

VDOM prototype implementation
Blog: Humble Chronicles: Managing State with VDOM

DataScript SQL Storage:

A bit embarassing to miss at first, but we now support connection pooling for SQL connections. To be frank, I became too lazy and soft from using Datomic and forgot how hard “real programmers” have it with SQL databases.

DataScript:

Migrated Conn to extend-clj atom (should be invisible for end users though).
Prevent explosion of redundant tuples during rule solving #456 #457, thx @RutledgePaulV
Fixed JS version bug caused by Conn rewrite

Clojure Sublimed:

We now support a connection per widnow, so you can have multiple REPLs at the same time as long as they are in separate windows.
We also now support (non-standard) .repl-port files for Socket REPL. Turned out, with multiple REPLs, you can’t just bind them all to port 5555 anymore.
Fixed status eval not clearing on disconnect
Fixed error when reporting warnings

Sublime Executor:

One execution per window, same as with Clojure Sublimed.
Added executor_clear_output command, with pair nicely e.g. right before reload namespaces or running test suite.
Ability to redirect output to a view

To sum the whole year up, these are the most notable things that happened:

DataScript got persistence! You can now save it on disk, like a real database. Immediately did that with Grumpy Website.
Made Clojure Sublimed a world-class tool for Clojure development.
Did tons of research on Humble UI with intermediate results all published. It’s now on direct train for getting component model in early 2024.
Published widely popular Unicode article
Released a few Clojure libraries:
Made a macOS app: Dark Mode Toggle. I use it almost every day myself, perfectly happy with effort/RoI ratio.
Left my day job and completely switched to open source/donation model.

Thanks Clojurists Together and its sponsors for funding this work. This is a dream job for me and I’m very thankful for a chance to be doing it. 2024 is going to be a open-source-as-a-full-time-job year, so even crazier!

Happy New Year!

Peter Stromberg

This summarizes my last two month of long term funding 2023. I can’t find words for how great this has been for me. Clojurists Together ROCKS! ❤️

Calva

The changes to Calva were mostly about fixing bugs. User support revealed quite a few places where Calva quality could be improved and was improved:

A strange situation where another VS Code extension stopped Calva’s nREPL client from working was fixed. Or, worked around rather, it is still unclear what the root cause is.
Instrumenting the REPL for utilities such as doc, and pprint, was failing.
- This also caused plain ClojureScript (i.e. not shadow-cljs) projects to sometimes fail to connect to our nREPL client.
Calva uses cljfmt for formatting. Mostly for performance reasons we have a separate, cljfmt.edn compliant, indenter for placing the cursor correctly when new lines are created. The indent configuration supports regular expressions, and we had bugs in this support.
We have been fighting lots of npm audit complaints. It’s a never ending struggle, but now Calva has a lot fewer dependencies, which improves the situation. (And, right now the report says 0 vulnerabilities detected.)
Word selection outside CLojure structural code (i.e. in line comments) was misbehaving.
It was discovered that Calva’s nREPL client was sending non-compliant eval messages. Most nREPL servers are resilient to this, but there showed up one that wasn’t (Squint). Fixing this we could also clean up a lot of code in Calva that compensated for the lacking compliance.
- This also prevented Calva from working with the Squint nREPL server.
The Calva API was upgraded with namespace utilities.
A glitch made the error message return late for failed evaluations in some situations.
A bug prevented the Project Type REPL Jack-in from populating on the first jack-in attempt (for some projects).
Connecting to a remote nREPL server sometimes didn’t work at all.
Manually breaking up line comments caused suprising, and sometimes rather messy reformatting of the code.
Connecting the shadow-cljs REPL failed for some projects
Glitches in including the doc string in hovers.
Duplicate definitions in hovers (both clojure-lsp and nREPL provides this)
Namespace alises shadowed local bindings in completions
Static definition lookup not working from project dependency files

Joyride

Clojure language support updates:

Add Clojure functions tap>, add-tap, and remove-tap
Conditional readers

Developer tooling:

Auto-create configuration and instructions for better clojure-lsp support for Joyride scripts
Fix nREPL server bug causing compliant eval op messages to fail (bug revealed when Calva started to send compliant eval messages)

Squint

I wanted to help test Squint and used it for solving some Advent of Code problems. Then I started instead to help fix some of the issues I reported as a result. Because Michiel Borkent is the way he is, helping with Squint development was more fun than solving AOC problems so I dropped out of AOC. My most significant contribution to Squint during this “sprint” was adding almost complete support for clojure.set.

Peter Taoussanis

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open source work!

Recent work

In November I released the first public alpha of Tempel, a new data security framework for Clojure - and my first all-new Clojure library in 7 (!) years.

Its main objective - to make it practical for more Clojure applications to use encryption and cryptographic best practices to protect user data and other sensitive info.

It offers a particularly high-level API focused on common tasks including logins, symmetric & asymmetric encryption, end-to-end encryption, signing, and key management.

For lots more info (incl. beginner-oriented documentation), see the Tempel GitHub page.

Since then, I’ve been mostly concentrating on Telemere - another all-new library focused on providing an idiomatic and flexible Clojure/Script API for structured telemetry. Support is planned for OpenTelemetry and others. Will share more info on this at release.

Upcoming work

My current roadmap includes:

Next http-kit beta mid January
First Tempel beta mid January
First Telemere alpha mid February

2023 recap

I’m happy to say that 2023 was a really productive year for my open source work. It was the first time I’ve had support from Clojurists Together - and their backing along with my usual contributors meant that I could put more time + effort into open source than I’ve been able to do in many years.

In particular, I took the opportunity to target some larger/hairier tasks that would have otherwise been infeasible. Some of that work has already borne fruit, some of it will bear fruit in the coming year.

Some notable results this year:

37 public library releases, incl. 1 all-new library and another to come soon.
Major improvements to my workflow for writing and maintaining documentation.
Updated and expanded documentation for most of my libraries (a few still TBD).
Several other cross-project improvements (unit tests, Graal support, cljdoc support, improved Cljs documentation, etc.).
Laid significant foundations for future upcoming work :-)

- Peter Taoussanis

Sean Corfield

In my previous Long-Term Funding update I said I would review and update of the “cookbooks” section and make another pass of “TBD” items in the “language” section.

`clojure-doc.org`

I reviewed and updated the cookbooks for Files and Directories, Mathematics, Middleware, Parsing XML in Clojure, and Strings, bringing them all up to Clojure 1.11 (and testing the examples – and fixing the broken ones).

For the Mathematics cookbook, that meant rewriting the content that previously used Java interop and/or math.numeric-tower to use the new-in-1.11 clojure.math namespace.

Several cookbooks got minor updates to take advantage of functions in clojure.core and clojure.string that have been added since Clojure 1.4, when most of the original material on clojure-doc was written.

I also went through all the Java documentation links and updated those to point to the Java 17 versions (they were mostly pointing at Java 7 previously!). These will get updated again once use of JDK 21 has become more widespread.

I’ve been slowly working my way through the “TBD” items in the various Language guides, including the Glossary, although some of them really need input from community members who have specialist knowledge in those areas. In particular, the Concurrency and Parallelism and Polymorphism guides still have a number of “TBD” items that I don’t feel qualified to write! Volunteers welcome!

Thank you to @adham-omran for a PR that added the Date and Time cookbook and to @samhedin for a PR that added a section about adding Java code to Clojure projects to the tools.build cookbook.

Finally, I made a logo and a favicon for the site with my very limited artistic “talents”!

To wrap up the year of work on clojure-doc.org, I consider the Clojurists Together funding to have been a massive success. The site has been completely overhauled at this point, bringing it up to date with Clojure 1.11 and removing all the outdated (and now-duplicated) material that was originally missing from the official Clojure documentation. In addition, by raising the profile of clojure-doc.org in the community, contributions have increased with two new cookbooks added via Pull Requests and several other sections of the site either getting PRs or being updated by me in response to extensive feedback from the community (mostly on Slack).

Keeping the site updated now feels like a tractable problem and I’m hoping to find time in 2024 and beyond to add more content to the site, especially when Clojure 1.12 is released and there are a lot of enhancements to Java interop!

`deps-new`

deps-new 0.6.0 was released with several documentation updates, a new :src-dirs option to make it easier to use deps-new as a library and use templates from the local file system, and a new :post-process-fn to make it possible to modify the generated project programmatically.

Expectations

No new release yet but several documentation updates for the clojure.test-compatible version of Expectations.

HoneySQL

HoneySQL 2.5.1103 was released with smarter quoting of entities, smarter handling of metadata in formatting, and new options to provide more control over both of those features.

`next.jdbc`

next.jdbc 1.3.909 brings improved compatibility with clojure.java.jdbc for insert-multi! and adds a :schema-opts option to provide more control over schema conventions for datafy/nav. There have also been several documentation updates, in particular around how to use next.jdbc/plan and next.jdbc.sql/find-by-keys. The build.clj has been updated to use the :pom-data option introduced in tools.build 0.9.6, as a better example for the community.

`clj-watson`

clj-watson is a great tool for checking your dependencies for known security vulnerabilities. It’s a wrapper around OWASP Dependency Check and NIST is requiring users of its NVD (National Vulnerability Database) to switch from using data feed downloads to a new API that requires a free key for access. The DependencyCheck library that clj-watson uses has been updated to use the new API, but it isn’t backward compatible so clj-watson needed changes to use the new version of the library – and to provide an easier way for users to specify their own NVD API key.

Although the clj-watson maintainer has moved on from Clojure, they’ve been receptive to my Pull Requests to update the documentation, update the library dependencies, add a new, optional properties file that users can provide to override defaults, as well as a new command line option to specify that file, if you don’t want it on the classpath, and to update the DependencyCheck library and provide documentation on how to obtain an NVD API key and how to use it with clj-watson.

A v5.0.0 release of clj-watson has been made, with all these changes, and is available as a git dependency. A Pull Request is pending with the README updates.

`org.clojure/java.data`

Finally, the java.data Contrib library has a new release, 1.1.103, which removes the dependency on org.clojure/tools.logging – which in turn means that next.jdbc no longer depends on tools.logging, reducing the chance of conflicts for users of either library.

Thomas Heller

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (e.g. Clojurians Slack).

Current shadow-cljs version: 2.26.2 Changelog

Toby Crawley

November 2023

Commit Logs: clojars-web, infrastructure

I rewrote the permissions system this month to support project-level scoping, allowing delegation of deploy rights to a user for a subset of projects under a group. This was released in December.

I also made improvements to the AMI release process.

December 2023

Commit Logs: clojars-web, infrastructure

This month I released the permissions system rewrite, updated the release logic to require a license in the POM for all releases, and made a few other minor improvements:

On the infrastructure front, I added disk space and SQS queue delay alarms so we can be better informed of when things go wrong.

Tommi Reiman

Many improvements are in the works, but no releases on libraries. My work spread over the following:

Working with Malli:

enchanced development mode, new extension apis & pretty printing everything possible (screenshots below)
little progress on the new effective type system
thinking about schemas and global identity, entities and values. Goal is to allow decomplecting maps/keys/values with using local data / schema properties
learning how to program with TypeScript Types

Drafting a Clojure specification for a 1:1 x-state compatible FSM implementation(xstate v5 released in december)

Why? have used FSMs for 10+ years with Clojure with great results, mostly copy-pasting the project-spesific engine from one project to another
We have already many great FSM libraries for Clojure, but all differ with design objectives. I’ll reach out to the library maintainers, e.g. could we have one new/great tool instead of many small ones? we have already depreceated tilakone.

organizing open source & stable libraries in general - getting new maintainters for some of the projects
reviewing and merging pull requests

Malli Development Mode

Coercion

Schema creation

Something else

Looking forward to 2024! Lot’s of interesting things in the OS pipeline and thanks to new long-term funding, will continue to work on them. Also, New year starts with crispy -20 (in Celcius).

Q3 2023 Project Reports

Charles Comstock and Jack Rusher: Quil

We had hoped to have a new release by the time we submitted this update, but we – by which I mean Charles – are down in the weeds trying to get all of the test infrastructure to work for every major platform in Github CI. The good news:

we have managed to migrate all of the testing away lein to deps.edn
tests all work properly from cider now
upgraded the Clojure test runner to Kaocha (thanks, plexus!)
moved browser testing for CLJS to Figwheel
Fixed some bugs around color processing (thanks, plexus!)
Foreign deps are better handled
we should have a new release either by the end of December or early in January 2024

Our plan is to continue the work a bit more in the new year to get everything clean and maintainable, then train some other devs in the community on the codebase.

Thanks for much for your help, Clojurists Together!
Published 27 December 2023

Jeaye Wilkerson: Jank

I’ve been quiet for the past couple of months, finishing up this work on jank’s module loading, class path handling, aliasing, and var referring. Along the way, I ran into some very interesting bugs and we’re in for a treat of technical detail in this holiday edition of jank development updates! A warm shout out to my Github sponsors and Clojurists Together for sponsoring this work.

Module loading progress

Ok, first and foremost, where is jank now with regard to module loading? I’m very pleased to say that everything I wanted to tackle this quarter has been finished and even more on top of that. There’s a PR up for the full changes here.

Let’s break this down by section.

Class paths

jank traverses a user-defined class path, which supports directories and JAR files, and can use that to find modules when you use require and friends. This is specifically designed to be compatible with the JVM, so once we hook in Leiningen or Clojure CLI, your existing dependency management should work just fine.

Necessary core functions

The following functions have all been implemented, which were required for module loading:

require
alias
use
refer
load

These take into account modules that are already loaded, flags for things like reloading, excluding, etc. For most use cases, they’re at functional parity with Clojure on the happy path. Error handling will improve once I have some better mechanisms for it.

Still, that’s not a very big list of functions, I know. How about this one?

compile
create-ns
find-ns
remove-ns
the-ns
ns-name
ns-map
ns-publics
var?
var-get
keys (note - not using a custom seq yet)
vals (note - not using a custom seq yet)
name
namespace
subs
gensym
concat
contains?
find
select-keys
map (note - not lazy yet, no transducers)
mapv (note - not lazy yet, no transducers)
mapcat (note - not lazy yet, no transducers)
filter (note - not lazy yet, no transducers)
complement
remove
set?
set
vector
doseq (note - not supporting fancy for features yet)
list*
apply
some
not-any?
not=
symbol
var?
cond
and
or
ns

All of these were needed by some of the above necessary functions, so I implemented them as much as possible. Most of them have complete functional parity with Clojure, but a few have interim implementations, especially since jank doesn’t yet have have an equivalent object type to Clojure JVM’s LazySeq. Still, jank feels, and looks, more and more like a proper Clojure every day.

(Bonus) Initial AOT compilation

You may have noticed, in that list, that compile has been implemented. This is an initial step toward AOT compilation and it compiles jank files into C++ files on the class path. Those can then be loaded in lieu of the jank files for a performance win. I also added a CMake job to jank’s build system to build the jank Clojure libs along with the compiler, so we can always have those pre-compiled and also always know they actually compile.

I’m currently working with the Cling developers to get support added to Cling for jank to pre-compile these C++ files into a closer equivalent to JVM class files. In my local testing, the startup time improvements by doing this were 10x. I’ll have more info on this once the work picks up.

(Bonus) CLI argument parsing

In order to support things like user-defined class paths, I’ve added a proper CLI arg parser to jank. You can see the current options in the help output here:

❯ ./build/jank -h
jank compiler
Usage: ./build/jank [OPTIONS] SUBCOMMAND

Options:
  -h,--help                   Print this help message and exit
  --class-path TEXT           A : separated list of directories, JAR files, and ZIP files to search for modules
  --output-dir TEXT           The base directory where compiled modules are written
  --profile                   Enable compiler and runtime profiling
  --profile-output TEXT       The file to write profile entries (will be overwritten)
  --gc-incremental            Enable incremental GC collection
  -O,--optimization INT:INT in [0 - 3]
                              The optimization level to use

Subcommands:
  run                         Load and run a file
  compile                     Compile a file and its dependencies
  repl                        Start up a terminal REPL and optional server

Each subcommand has its own help output, too. Speaking of subcommands, however, jank now has a repl subcommand which spins up a terminal REPL client with readline enabled for (single session) history and improved editing. This has been very handy for me as I’m testing out new things and was something that just came naturally after implementing the CLI argument parsing.

❯ ./build/jank repl
> (ns foo.bar)
nil
> *ns*
foo.bar
> (def wow "WOW!")
#'foo.bar/wow
> (def nice "NICE!")
#'foo.bar/nice
> (ns main)
nil
> *ns*
main
> (refer 'foo.bar :only '[wow])
nil
> wow
WOW!
> (alias 'fb 'foo.bar)
nil
> fb/nice
NICE!
> (ns omg.wow (:use [foo.bar :exclude [wow]]))
nil
> *ns*
omg.wow
> nice
NICE!
> (native/raw "*((char*)0) = 0;")
Segmentation fault (core dumped)

(Bonus) Maps, sets, keywords as functions

As part of implementing all of the new core functions this quarter, I also tackled these particular objects which behave as functions. Fortunately, because of the new object model design, these objects can have this behavior without the need for dynamic dispatch!

There will be bugs

jank is still pre-alpha software. I have an ever growing test suite, but no battle testing yet. As I develop more functionality, I find more issues and introduce more yet. That will remain the case until development can settle down and stable APIs can be decided. jank still isn’t ready to compile most Clojure programs, since it lacks support for some basic features like destructuring, lazy sequences, and even doc strings. While we’re talking about bugs, though, and since I’ve shown everything else I’ve built this quarter, let me tell you about such an interesting bug I found and how I fixed it.

Variadic argument matching bug

I fixed a few interesting bugs in the past couple of months, but this one was the most intriguing by far. So, the problem showed up in this case:

(defn ambiguous
  ([a]
   :fixed)
  ([a & args]
   :variadic))

(ambiguous :a) ; => should be :fixed

What jank was trying to do was call the variadic arity, with an empty seq for args, rather than to call the fixed arity. This is because both of them require one fixed argument first and the information I was storing for each function object was the required fixed args prior to variadic arg packing.

The equivalent function in Clojure JVM is RestFn.getRequiredArity, which returns the required fixed position arguments prior to the packed args. However, where Clojure JVM differs from jank is that Clojure uses dynamic dispatch to solve this ambiguity whereas jank does its own fixed vs variadic overload matching, for performance reasons.

To actually solve this problem, we need to know three things:

Is the function variadic?
Is there an ambiguous fixed overload?
How many fixed arguments are required before the packed args?

We cannot perform the correct call without all of this information. Also, function calls in a functional programming language like Clojure are on the hottest of hot code paths, so I can’t exactly add two more virtual functions to jank’s callable interface to get this data. In truth, even keeping one function but putting all of this data in a struct proved too much of an impact on the performance. Thus, we need to encode the data more compactly.

jank now packs all of this into a single byte. Questions 1 and 2 each get a high bit and question 3 gets the 6 remaining bits (of which it uses 4) to store the fixed arg count. So, this byte for our ambiguous function above would look like this:

1  1  0  0  0  0  0  1
^  ^  ^---------------
|  |  |
|  |  /* How many fixed arguments are required before the packed args? */
|  /* Is there an ambiguous overload? */
/* Is the function variadic? */

From there, when we use it, we disable the bit for question 2 and we switch on the rest. This allows us to do a O(1) jump on the combination of whether it’s variadic and the required fixed args. Finally, we only need the question 2 bit to disambiguate one branch of each switch, which is the branch equal to however many arguments we received.

object_ptr dynamic_call(object_ptr const source, object_ptr const a1)
{
  return visit_object
  (
    [=](auto const typed_source) -> object_ptr
    {
      using T = typename decltype(typed_source)::value_type;

      if constexpr(function_like<T> || std::is_base_of_v<callable, T>)
      {
        /* This is the whole byte, answering all three questions. */
        auto const arity_flags(typed_source->get_arity_flags());
        /* We strip out the bit for ambiguous checking and switch on it. */
        auto const mask(callable::extract_variadic_arity_mask(arity_flags));

        /* We're matching on variadic + required arg position. */
        switch(mask)
        {
          case callable::mask_variadic_arity(0):
            return typed_source->call(make_box<obj::native_array_sequence>(a1));
          case callable::mask_variadic_arity(1):
            /* Only in the case where the arg count == the required arity do we
               check the extra bit in the flags. */
            if(!callable::is_variadic_ambiguous(arity_flags))
            { return typed_source->call(a1, obj::nil::nil_const()); }
            /* We're falling through! */
          default:
            /* The default case is not variadic. */
            return typed_source->call(a1);
        }
      }
      else
      { /* ... redacted error handling ... */ }
    },
    source
  );
}

The special case, which needs to check the ambiguous flag, incurs a performance cost, due to the if. Every other case is unaffected. This was a challenge to wrap my head around at first, but after I wrote out all the things I need to know, as well as a test suite for each of the cases, I could work toward a solution which addressed everything.

What’s next?

Firstly, dynamic vars. Once those are implemented, I’ll need to go through all of the different parts of the compiler and runtime to start filling in vars. This will allow everything from improved error messages by tracking file/line/function to cyclical dependency checks on module loading.

Also, in order for jank to operate alongside other Clojure dialects, we’ll need to support reader conditionals on the :jank key. Currently, jank doesn’t support any reader macros, so getting that system going will open up the door to things like #() and #{} being supported.

Finally, I’ll be improving the interop interpolation syntax to be consistent with ClojureScript, adding meta hint support, and more. Stay tuned!
Published 27 December 2023

Q1 2024 Funding Announcement

Wed, 10 Jan 2024 08:30:00 +0800

Greetings as we start the new year! We’re excited to announce the projects we’ll be funding for Q1 2024. (8 projects $44K USD in total).

There was a groundswell of great project proposals - so making a decision was definitely not easy. The good news, however, is that new proposals will be automatically reconsidered for the next project cycle. We have supported many projects in the past that were funded in 2nd or even 3rd review.

Thanks to everyone for your hard work and creativity in putting these proposals together - this is the kind of thinking and sharing that makes the Clojurist Together community so awesome!

Q1 2024 Projects Awarded $9K USD

CIDER – VEMV
Clojure-lsp – Eric Dallo
Instaparse – Mark Engelberg
Scicloj – Daniel Slutsky

Q1 2024 Projects Awarded $2K USD

Jank – Jeaye Wilkerson
Sitefox – Chris McCormick. See his video.
UnifyBio – Benjamin Kamphaus
Wolframite – Thomas Clark and Jakub Holy

Please join us in congratulating this talented group. We’re looking forward to their project updates in the coming months.

Q1 2024 Projects Awarded $9K USD

CIDER: VEMV

Work will be based on CIDER’s issue trackers (cider, cider-nrepl, orchard). Some of the larger themes will be: cider-inspector-mode refinements, cider-log-mode refinements, and refactoring our Java parsing machinery.

Why is this project important to the Clojure community? Member survey in November suggests there is a need for this work.

Clojure-lsp: Eric Dallo

I will work on clojure-lsp project and related ones like lein-clojure-lsp, lsp4clj, and clojure-lsp- intellij. My project will include adding missing LSP features, options to create clojure project from scratch for fast onboarding, better performance and stability.

Why is this project important to the Clojure community? For IntelliJ users, is the only open source free tool to use the main robust clojure-lsp and have static analysis features as an IDE like Calva for VScode, emacs and vim.

I have in mind some activities like:

create a section in clojure-lsp webpage for guides and tutorials, with contents like for example “how to work in mono-repo projects”
Add more code actions and refactors, especially move-form and some highly requested by community
Improve the “work out of the box” experience for developers, requiring less configs or files to be able to use clojure-lsp features
Improve memory/performance, a tough constant work to make clojure-lsp a lightweight tool to run along with editors
Add more custom linters for diagnostics
Add more features to clojure-lsp-intellij, to make it a reliable tool for Clojure development on IntelliJ. Besides those tasks, I’ll keep actively helping the community in slack and github for LSP related issues and questions.

Instaparse: Mark Engelberg

My focus will be on evaluating and incorporating pull requests for instaparse. Then, I will look at new features requested by the community. Along the way, I will make sure to keep the documentation updated.

Why is this project important to the Clojure community? Instaparse has been incorporated into a number of other libraries, including some of the routing libraries (for parsing URLs) in some web stacks. Knowing how many libraries rely on its stability has placed an additional burden on me to carefully review and test pull requests.

Scicloj: Daniel Slutsky

Scicloj is a Clojure group developing a stack of tools & libraries for data science. Alongside the technical challenges, community building has been an essential part of its efforts since the beginning of 2019.
Its current main community-oriented goal is making the existing data-science stack easy to use. In particular, we need example-based documentation, easy setup, and recommended workflows for common tasks. All these, and the tools to support them, need to grow organically, driven by real-world use-cases.

I am currently working, in collaboration with others, on various components to support these needs:

maintaining the Scicloj website
running dev groups and study groups
The most active ones are:
2a. visual-tools – collaboration of tool-makers and discussion of literate programming, data visualization, and UI design.
2b. llm-meetups – discussions of the Clojure stack for large language models.
2c. jointprob – studying probability & statistics together with other tech communities.
developing tools & libraries:
3a. Kindly – a simple data-visualization standard to support compatibility across different tools.
3b. Clay – a notebook tool for interactive data exploration and literate programming.
3c. Note-to-test – support for testable documentation.
3d. Noj – a wrapper for a few of the relevant data-science libraries to support easy setup and some convenience functions around it.
running public meetups.
helping out individuals to get started with data science in Clojure.

Starting in Jan 2024, I am concentrating on two additional projects:
6. clojure-data-scrapbook – a community space for documenting data analysis workflows – similar to the clojure-data-cookbook, but less curated and more community-driven.
7. real-world-data – a study group where individuals will bring their own data problems and collaborate on common practices.

The project is to initiate items 6 & 7 as a core activity of Scicloj to and keep maintaining items 1-5, driven by the needs realised in 6 & 7. Everything will be done.

Why is this project important to the Clojure community? Clojure has a huge potential as a data science platform thanks to its REPL, simplicity, data-driven approach, visual support, interop support, and stability. This potential may apply not only to software developers and not only to scientists, but also to much broader crowds, practically anybody who has a data question.

Since 2019, Scicloj has been addressing this potential. On the technical side, the emerging stack of tools and libraries has matured very well. On the human side, there is still a long way to go till Clojure can become an obvious and welcoming choice for any person exploring some data. Even for people familiar with Clojure, some parts of the stack are not very well-known and not discoverable enough.

We have been continually addressing these challenges at Scicloj in multiple study groups and one-on-one sessions, and in developing tooling and workflows. Now, when the tooling is maturing, we are transitioning to the next phase, with the upcoming clojure-data-scrapbook and real-world-data projects. These will provide more Clojurians with the necessary support to get comfortable with their data analysis, and will allow us to keep evolving our workflows and documentation for more diverse workflows.

A well-documented and well-tested Clojure data science stack is expected to help many Clojure teams who often use Python when facing a data analysis need.

As a byproduct of our documentation efforts, some useful tools are emerging. We believe Clay and Note-to-test can be useful for documenting libraries in general, not just in the data-science scene.

Q1 2024 Projects Awarded $2K USD

Jank: Jeaye Wilkerson

There are some crucial missing pieces in jank which have been getting in the way of me reaching parity with Clojure. In order of importance, we have:

Dynamic vars
Most people would be surprised how extensively the Clojure compiler and runtime use dynamic vars. Everything from the current locals in the scope to the current line/file info to the currently loaded namespaces and the current function is kept in dynamic vars. These vars are thread-local and stack-based; Clojure handles carrying them over to new threads automatically and pushes/pops new values to not clobber what was already there (i.e. binding).

So far, I’ve worked around this by using mutable data, but that doesn’t benefit from thread locality or the stack-based nature of dynamic vars. Having this support will allow me to go back and improve existing features, like parsing and module loading, to better keep track of this data (and be more easily parallelized).

Syntax quoting jank has macro support, currently, but no syntax quoting, unquoting, or splicing. That means writing non-trivial macros like ns, and, or, and defn is not sane, so jank either doesn’t have them or has very stripped down versions of them. By supporting this, I can then go in and add these common macros and jank will immediately feel much more complete.

Bonus
I think the above two items are fairly complex and I don’t want to over-promise. However, I can see the possibility that I can push through them with some time remaining in the quarter, so I have a couple of other tasks I’ll tackle if that happens.

Meta hints jank doesn’t currently support ^:foo or ^{:foo true} meta hints on forms, though it does support functions like reset-meta!. Supporting these hints, in the lexer and parser, will clean up some existing jank code (which uses reset-meta! everywhere) and pave the way for type hinting, too.

Normalized interpolation syntax Within a native/raw, one can reach back into jank using the #{ foo } interpolation syntax. However, the community has pointed out that CLJS already uses ~{ foo } and it’d be more consistent for jank to do the same. On top of that, jank’s parsing for these interpolation forms is pretty rough right now and there is C++ code which would trip it up. It can be improved by hooking more tightly into jank’s parser, but that will require adding metadata to the parsed forms to convey their line/column info.

Why is this project important to the Clojure community? jank is the only native Clojure dialect which has its own JIT and embraces interactive programming. It unlocks REPL-driven development for a whole ecosystem previously unserved by Clojure.

Sitefox: Chris McCormick

Hear from Chris first-hand. Check out Chris' video about his Clojurists Together project here.

Here’s what I would like to accomplish in Sitefox using the Clojurists Together funding:

Bring dependencies up to date.
Tidy up the key-value database module & write basic tests.
Improve the end-to-end tests to ensure greater reliability under change. * Improve error handling by making errors more verbose.
Test and document deployment of Sitefox sites on 3 or more Node.js providers.
Make two concise how-to videos showing people how to building simple sites and apps with Sitefox.
Edit together text tutorials based on AI transcripts of the videos.
Remove “WIP” from the project description and coordinate a “ready for the public” release

Why is this project important to the Clojure community? Sitefox is a full stack ClojureScript library. That means it is deployed on Node.js rather than Java. I think this architecture is under-explored and has benefits for people who come from the non-JVM side of things.

UnifyBio: Benjamin Kamphaus

Broad project scope: Converting the CANDELBio ecosystem I helped create at the Parker Institute for Cancer Immunotherapy from its open source, but semi-abandoned state to UnifyBio, a world class data harmonization platform: Clojure-first and permissively open source (Apache 2.0).

The successor to CANDELBio’s pret tool will be the more generally useful Unify, at https://github.com/vendekagon-labs/unify and broadly useful for data harmonization or importing data into datalog-oriented stores. I’ll be streaming the dev process over video and sharing selection of this via YouTube.

The first major need I will be addressing under Clojurists Together funding is a documentation and tutorial overhaul: building out examples, CLI/API and use documentation, end-to-end tutorials, likely example Clerk notebooks (or comparable) showing all the steps from raw data collection, to the data-driven import process, to query, then analysis and visualization.

I’ll also be getting an automated release process in place, with supporting CI/CD, etc. From there, I’ll be looking to harden the existing functionality with better example systems and tests covering more use cases beyond biology.

From there, the priorities are:

Vetting integration with other components of the Clojure data science stack and supporting use of data integrated via Unify (eg access data through tech.ml.dataset’s api surface).
Building more compelling use cases for distributed processing for biology, especially around single cell and -omics data, expanding Unify’s functionality as necessary to do this.
Part of this will be assessing and possibly contributing to or deriving from or otherwise building successors to Onyx, Clojask, etc. (non-spark based Clojure distributed processing tools).
I’ll also be writing the current Datomic database layer backend to be more generalizable and able to be written to other stores, assessing Datahike as the first priority here.

As the project hits the maturity point for use (anticipated very soon, likely early January) with sufficient docs, tutorials, and examples, I’ll be sharing in Clojure community channel areas, especially data-science, data-engineering, datomic users, etc. and spend time supporting users who think they might benefit. I will also reach out to former PICI informatics employees at several organizations that I know are having trouble with data integration, to let them know there’s a successor to CANDEL that’s open source and staffed/supported, to see if I can get inroads for adoption from external bio users not otherwise involved in Clojure.

Why is this project important to the Clojure community? This is a pilot project that solves a variety of problems relevant to many, such as automating the process of converting ad hoc tables into harmonized entities that can be transacted into Datomic and other Datalog oriented databases. Also, this is already a first-in-class set of data harmonization tools for biological data science, some of which are being imitated by startups with many millions in funding. If it can be given more love and effort as an open source project, it can help establish Clojure in the life sciences, much like NextFlow did for Groovy.

The streams and dev blogs will also give provide a helpful resource for anyone who wants a better understanding of how production grade Clojure projects are built.

Wolframite: Thomas Clark and Jakub Holy

Currently, there is an existing library for wolfram<>clojure interop but it’s lack of documentation, reliability and usability mean that it is not widely used or known. We hope to fix all of these issues and so bring wolfram interop up to the standards of similar bridges like clojisr and libpython-clj. Specifically, fundamental goals would be to:

merge recent work
create comprehensive inline documentation
create big-picture example namespaces: including onboarding tutorials and real-world examples (publically available in visible places like the sci-cloj website and high-impact blogs).
expand kernel parallelism
expand wolfram external package integration
streamline user setup so that wolfram functions can be used almost as easily as other data libraries
build the foundations for closely integrating wolfram with the emmy symbolic clojure system

Why is this project important to the Clojure community? Of the areas of desired improvement that the Clojure survey highlighted, this project would address the specific categories of data analysis, documentation and user growth.

Data analysis/processing, as also expressed by the Clojure leadership team, is a key growth area for the language but library coverage can be fragmented, with missing depth of functionality.

Having access to specialised algorithms/functions however, can make or break analysis projects and so reestablishing a stable bridge between clojure and a first-in-class analysis language like Wolfram would go a long way in reassuring language choosers that Clojure can always meet their needs, even when there is no pure clojure library available.

Another key community area is the expansion of the community itself. Following on from above, there is a large section of the numerical scientific community who are not programmers but who rely on tools like Mathematica and Matlab and so interop in these areas will be crucial for community cross-over in the future. Generalized language interop is particularly important for safe onboarding of new users and experience suggests that there is a willing ‘market’ for integrating specialist tools within more comfortable general languages like Clojure.

Finally, this project would not only have its own benefits but it could lay the groundwork for future integration with the ‘emmy’ symbolic physics library. The emmy system is bringing open-source symbolic computation to both the back- and front-ends but it is missing key features and advanced libraries. A wolfram bridge could serve as a sure foundation and help create the real possibility of an almost unique physics programming space that clojure would be a great fit for but is not quite ready for.

Clojurists Together 2024 Long-Term Funding Announcement

Sat, 23 Dec 2023 14:00:00 +1200

The votes are in!! Clojurists Together members have voted to to fund 8 developers $1.5k/month for 12 months ($144k USD total!). We’re pleased to announce the following developers/teams who will be funded:

Bozhidar Batsov
Kira McLean
Michiel Borkent
Nikita Prokopov
Peter Taoussanis
Thomas Heller
Toby Crawley
Tommi Reiman

We are very excited to see what these developers will do over the next year. They will post updates every two months of what they’ve been working on, and we’ll share them in our regular monthly updates. Here’s what each of these developers plan to work on (although this is just a starting point and they’re free to change their plans as they see fit):

Bozhidar Batsov

Provide continued support for CIDER, nREPL and the related libraries and improve them in various directions. Some ideas that I have in my mind:

Make CIDER play better with alternative Clojure(Script) runtimes
Simplify some of CIDER’s internals (e.g. jack-in, session management)
Improve CIDER’s documentation
Provided out-of-the-box support for TreeSitter (via clojure-ts-mode)
Continue to move logic outside of cider-nrepl
Improvement to the nREPL specification and documentation; potentially built some test suite for nREPL specification compatibility
Various improvements to the nREPL protocol
Kick-off work on CIDER 2

Kira McLean

I’ll use the time that this money frees up to work on projects that benefit the Clojure community, starting with educational materials for the scicloj community, and continuing on with various related projects as the year goes on.

Michiel Borkent

I’ll continue to maintain and develop clj-kondo, babashka, SCI, cherry, squint and several all other related projects.

Nikita Prokopov

I propose to work on the following open-sourse projects:

Continue developing Humble UI, a UI framework in Clojure for building desktop applications
Documenting, promoting and teaching Humble UI
Develop data synchronization layer for DataScript, an in-memory database and Datalog engine
Support and extend Clojure Sublimed, a Sublime Text plugin for Clojure development

Peter Taoussanis

Planned work includes:

Ongoing work for existing open-source libraries: improvements, maintenance, support, etc.
Stable releases for new libraries: Tempel (data security framework), and a structured telemetry library (final name TBD).
Continued work on updating Carmine core for latest Redis versions/features.
Detailed roadmap and timelines TBD based on demand/feedback, and how things progress.

Thomas Heller

I’ll focus on maintenance and further development of shadow-cljs, and other shadow-themed projects.

Toby Crawley

My focus will be the ongoing maintenance for Clojars - including:

OS and system package upgrades
Reviewing and merging PRs
Deploying changes
Monitoring bandwidth/resource usage to detect anomalies
General operational tweaks and improvements
Tuning search algorithms
Security improvements, fixes, and responding to security reports

Tommi Reiman

I will work with Clojure Open Source projects, malli being the propable main focus, but also with new libraries that I find useful and are missing from the Clojure community/ecosystem.

Thanks

Thank you to all of our members for selecting these developers. If it wasn’t for your generous support, this wouldn’t be possible. I wanted to add a special thanks to Latacora, Roam Research, Whimsical, Stylitics, Pitch, Nubank, Cisco, Logseq, JUXT, Metosin, Solita, Adgoji, Grammarly, Nextjournal, ClojureStream, Shortcut, Flexiana, Toyokumo, Griffin, doctronic, 180° Seguros, and Kroo Bank. They have all contributed significant amounts to Clojurists Together which lets us award $144,000 in long-term funding to Clojure developers.

Thanks..and More

Wed, 20 Dec 2023 08:30:00 +0800

THANK YOU!

As 2023 comes to a close we want to reach out and thank you for supporting Clojure, open-source, and the Clojurists Together community.

We’ve been able to accomplish a lot this year with your support. Your input on our quarterly surveys is critical to ensuring that we are funding work that is needed, valued, and adopted by the community at large. We appreciate your subscription to our regular news and updates dispatches - as we believe it encourages wider use of the tools and resources of the developers we have funded - strengthening and advancing the open-source and Clojure community. It’s what we’re all about.

We’re hearing from about 25% of our members and subscribers on each of our quarterly surveys (which is actually pretty good as surveys go). In addition to requesting specific tools and improvements, we have heard a consistent call for better documentation (content, presentation, and organization) and more support for engaging and supporting new Clojure users. This year, we received and funded several proposals that focused on these needs and will continue to encourage work in these areas.

In 2023, we funded 30 shorter-term projects ($150,000 USD). 11 developers received a monthly stipend for the year ($187,500 USD in long-term funding). In total, we funded $337,500 of projects in 2023. Since 2018, Clojurists Together has awarded $935,000 to 76 developers working on more than 120 projects.

We encourage everyone in the Clojurist community to stay involved - by providing input on surveys and submitting project ideas for funding. In addition, members are able to vote on the annual Long Term Funding recipients as well as board members. The more ideas, solutions, and engaged members, the better!! And of course, as we increase membership funding, more resources will be available to fund important projects. In 2023, 93% of our membership revenue was allocated to projects – unheard of!! (You can join as a Developer or as a Company).

Hear from a few of our 2023 long-term developers:

“Clojurists Together has helped me maintain and improve babashka, SCI, clj-kondo while working on new projects like squint. I’m grateful that CT exists to help the Clojure open source ecosystem thrive.” - Michiel Borkent

“I greatly appreciate the funding from Clojurists Together to support my work on Clojars! Clojars is a critical piece of infrastructure for the Clojure community,and this funding allows me to focus on maintaining and improving it.” - Toby Crawley

“The continuous support for my work on CIDER by Clojurists Together allowed me to keep it at the top of my OSS priorities and to provide a steady stream of updates throughout the entire 2023. It’s safe to say that without Clojurists Together CIDER wouldn’t be what it is today. Thanks a lot for your support! You rock!” - Bozhidar Batsov

“Clojurists Together long-term funding has enabled me to take days off work and dedicate them to opensource projects, as well as providing a great incentive to turn weekends into opensource project time. This has enabled me to spend a lot of time working on https://clojure-doc.org – both reviewing and updating existing content as well as writing a lot of new content, to reflect the changes in the Clojure ecosystem over the last decade (much of the existing content dated back to Clojure 1.4!) – in addition to supporting regular updates and releases of projects that I’ve been maintaining somewhat irregularly over the years.” - Sean Corfield

“Thanks to Clojurist Together Long Term Funding I’ve been able to find quality time on developing and maintaining open source libraries including malli, reitit and others. I feel privileged for the support."- Tommi Reiman

FUN FACTS and THANK YOUS!

We are truly an international group bringing a wide range of experience. From Q1 2022 to Q3 2023, we funded developers working in 18 countries including Austria, Belgium, Brazil, Bulgaria, Canada, Denmark, England, Finland, France, Germany, Lithuania, Netherlands, Norway, Poland, Serbia, Sweden, UK and the US.

Our members are committed and find mentorship rewarding.

66% have been members since 2020.
82% have been developing in Clojure for 5 years or more.
88% have mentored others (formally or informally) or taught classes.

This staggering amount of work has benefited our members and the broader Clojurist community. A thanks goes out to all the developers for their commitment and contributions to the community over the last 6 years: Adam Helins, Alexander Oloo, Ambrose Bonnaire-Sergeant, Arne Brasseur, Ashima Panjwani, Baptiste Dupuch, Ben Brinckerhoff, Bobbi Towers, Bozhidar Batsov, Brandon Ringe, Bruce Hauman, Chris Badahdah, Charles Comstock, Christian Johansen, Christophe Grand, Dainius Jocas, Daniel Higginbotham, Danny Freeman, David Levy, David Nolen, Dragan Duric, Eric Dallo, Ethan Miller, Gert Goet, Grodziski, Henry Widd, Iizuka Masashi, Isaac Johnston, Jack Rusher, Jacob O’Bryant, James Reeves, Jeaye Wilkerson, John Stevenson, Joakim Tengstrand, Joel Holdbrooks, José Luis Lafuente, Juho Teperi, Karol Wójcik, Kira McLean, Konrad Kühne, Lee Hinman, Lukas Domagala, Martin Kavalar, Matthew Davidson, Matthew Huebert, Matthew Ratzke, Michael Sappler, Michiel Borkent, Mike Fikes, Mitesh Shah, Nikita Prokopov, Oleksii Kachaiev, Oliver Caldwell, Othman Azil, Peter Stromberg, Peter Taoussanis, Sam Ritchie, Savo Djuric, Sean Corfield, Sebastian Zartner, Thomas Heller, Tim Pope, Toby Crawley, Tommi Jalkanen, Tommi Reiman, Vladislav Protsenko, William Acton, Zach Oakes, Žygis Medelis, and the team at Gaiwan.

2023 developers receiving annual funding: Bozhidar Batsov, Michiel Borkent, Sean Corfield, Eric Dallo, Christophe Grand, Thomas Heller, Nikita Prokopov, Tommi Reiman, Peter Stromberg, Peter Taoussanis, and Toby Crawley.

In 2023, our shorter-term projects included: Aleph/Manifold, Biff, Bosquet, Clerk, clj-kondo et al, clj-Nix, Clojure Camp, clojure-ts-mode, Custom Formatters/Firefox. Deps-try. Donut, Doxa, Emmy, Exercism, GDL, Jank, Lucene Grep, Uncomplicate Neanderthal, Deep Diamond, Portfolio, and Quil.

Finally, a shout-out to the companies and organizations who have supported our work throughout the year and most for many years. They believe in Open Source development and have made a commitment to Clojure as an important tool for their product, service, and organizational projects. If your company might consider becoming a sponsoring member, please contact Daniel Compton at daniel@clojuriststogether.org to explore further.

Let’s join in celebrating this wonderful community - and hoping for peace in the New Year.

lvh, Maria, Daniel, Heather, Felix, Max (Clojurists Together Board), Kathy (Program Manager).

November 2023 Short-Term Project Updates

Wed, 06 Dec 2023 08:30:00 +0800

Check out the latest updates from Q2 and Q3 2023 Short Term Project developers. Thanks to members for your support - making this work possible!

Biff: Jacob O’Bryant
Bosquet: Žygis Medelis
Clj-kondo, babashka, cherry, SCI: Michiel Borkent
Deps-try: Gert Goet
GDL: Michael Sappler
Quil: Jack Rusher and Charles Comstock
Uncomplicate: Dragan Duric

Biff: Jacob O’Bryant

2023 Q3 Report 2. Published 30 November 2023.

Since the first update, I have completed:

wrote the second half of XTDB compared to other databases.
published another essay, Philosophy of Biff.
added a Should you use Biff? page to the Get Started docs.
published two how-to guides (including fully working example code): How to use Postgres with Biff and How to use re-frame with Biff.
finished the example code for a future “how to deploy Biff with Docker” guide. That repo includes code for building an uberjar + Docker container, and I’ve successfully deployed it to Fly.io and DigitalOcean App Platform.

On the last point: I was going to write up a quick accompanying how-to post to go along with that Biff-Docker example repo. However, I don’t really feel comfortable recommending Fly.io or DO App Platform at this stage. Fly.io had some weird, show-stopping networking errors when I tried to use it just recently. DO App Platform worked, but their UI around deployment/logs was clunky and didn’t inspire confidence (I did also encounter at least one small bug). I am extremely wary of unreliable deployments which have been a pain point for me in the past. If you’re small enough to consider using either of those platforms, I think you’re far better off going with plain VMs (e.g. DigitalOcean droplets), which is why that’s the default in Biff.

IMO Docker-based deployment is a much better fit for organizations that are to the point where using AWS/Azure/GCP/Kubernetes makes sense. As such, my plan is to get that example repo deployed on Kubernetes (DigitalOcean’s managed offering, specifically) and then write a how-to guide to go along with that.

I will say that I am excited about Fly.io. Of all the “next-gen Heroku” platforms I’m aware of (Fly, Render, Railway, DO App Platform), Fly is IMO the most promising. Making it easy to run any Docker-based app at the edge (instead of e.g. just Javascript apps) is a particularly good fit for apps that use htmx (like Biff apps, by default). I’m guessing that the issues I’ve experienced with Fly are due to them still having lots of growth and having trouble keeping up with it, which seems like not the worst problem you could have! After they’ve become as reliable as DO droplets, I think there’s a good chance I’ll have Biff use them as the default deployment option.

Anyway: thank you for the grant! I’m really happy with where Biff’s documentation is now–it solidly covers the four main areas of tutorials, reference, how-to guides and explanation (essays). I’ve also been receiving some really kind feedback from the community as I’ve been publishing these articles (for example.

Bosquet: Žygis Medelis

2023 Q3 Report 2. Published 30 October 2023.

Settle on Clerk-generated static content, published on GH Pages as the home for Bosquet documentation.
Documentation:
1. Getting Started guide
2. Configuration. Bosquet relies heavily on declaring how AI generation is executed. The parameter setting is getting quite rich.
3. Use cases. Generating interpretable code for math calculations
4. Papers. Implementation of various academic papers discussing LLM techniques.
5. Guide on how to use Short-term memory
Substantial time was spent on a dead end trying to work out local embedding vector generation. The rationale was to have a self-contained system offering embeddings. Deeplearning4j and StandfordNLP Java libs proved to be too opaque, with no good implementations for this task.
Support for OpenAI embeddings added to Bosquet. Now library users can create and use OAI embeddings as part of memory-driven workflows.
To store and use Embeddings we need Vector DB. I have settled on using Qdrant as the database of choice. The implementation is still to be tested and changed with more rigorous testing and possibly various LLM papers implementations (see ‘Papers’ in documentation)
With that done, two types of memory are now introduced
1. Short-term memory acts as a simple illustration of memory and retrieval concepts
2. Long-term memory using Qdrant and OAI embeddings (as noted above likely to evolve and change). Follow :memory/long-term-embeddings in system.edn to see how it is built.
To aid in embeddingless (simple memory) scenarios, I have added similarity metrics support to compare different texts. It is based on Apache Commons text package.
The caching of generation results is reintroduced. Now LLM requests can be fulfilled from the cache if prompt and parameters do not change. Great to boost development speed development and save on some costs.
Output coercion. To achieve more complex chained prompt executions (or in agent use cases) where outputs the output from one LLM step needs to feed into the other we need well-defined in and out formats. Bosquet introduced the coercing of LLM outputs into JSON and EDN formats. See Chain of Density paper implementation for details.

2023 Q3 Report 3. Published 30 November 2023

Hugging Face data set loader. For the work related to memory and embedding handling, I needed easy access to HF datasets. An implementation used to download and cache them was initially done in Bosquet but then moved to an independent small lib.
Text splitters. Building RAGs or dealing with long texts requires splitting them into chunks. Bosquet text splitting API supports choosing splitting units: sentence, token, and character. API allows specifying overlap between chunks counted in selected text units.
Document loaders. PDF, DOC any other sane format loading into LLM processing is now supported via the Apache Tika wrapping component.
Experimental evaluation. More complex or agent-based LLM processing needs automatic evaluation as a function guiding generation quality and direction. This is a very basic Q&A evaluation implementation. Example use is documented in the linked ‘LLMs as Optimizers’ paper implementation.
Long-term memory. Qdrant and OAI embeddings-based memory implementation. Long-term memory is configured as a Bosquet component and LLM apps or agents can use it to create embeddings, store, and query them. See Evaluation and Scicloj recording for example use.
Local LLM support. Bosquet supports calling models hosted locally via LM Studio.
Scicloj Meetup 6: ‘LLMs as Optimizers’ (OPRO) implementation with Bosquet
Bug fixing component initialization and error handling

Clj-kondo, babashka, cherry, SCI: Michiel Borkent

2023 Q2 Report 3. Published 31 October and 30 November 2023.
To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible! Open the details section for more info.

Top sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch.

October 2023 Update

babashka: native, fast starting Clojure interpreter for scripting.
- Support self-contained binaries as uberjars!
- Add java.security.KeyFactory, java.security.spec.PKCS8EncodedKeySpec, java.net.URISyntaxException
- Fix babashka.process/exec wrt babashka.process/*defaults*
- #1632: Partial fix for (.readPassword (System/console))
- Enable producing self-contained binaries using uberjars
- Bump httpkit to 2.8.0-beta3 (fixes GraalVM issue with virtual threads)
- Bump deps.clj and fs
- Expose taoensso.timbre.appenders.core
- nREPL: implement ns-list op
- SCI: optimize swap!, deref and reset! for normal atoms (rather than user-created IAtoms)
sci.configs: A collection of ready to be used SCI configs.
- A configuration for hoplon and javelin was added. You can play around with hoplon in a SCI-enabled environment here
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- #2207: New :condition-always-true linter, see docs
- #2013: Fix NPE and similar errors when linting an import with an illegal token \
  Published a new version (2023.10.20) with these changes:
- #1804: new linter :self-requiring-namespace
- #2065: new linter :equals-false, counterpart of :equals-true (@svdo)
- #2199: add :syntax check for var names starting or ending with dot (reserved by Clojure)
- #2179: consider alias-as-object usage in CLJS for :unused-alias linter
- #2183: respect :level in :discouraged-var config
- #2184: Add missing documentation for :single-logical-operand linter @wtfleming
- #2187: Fix type annotation of argument of clojure.core/parse-uuid from nilable/string to string (@dbunin
- #2192: Support :end-row and :end-col in :pattern output format (@joshgelbard
- #2182: Namespace local configuration does not silence :missing-else-branch
- #2186: Improve warning when --copy-configs is enabled but no config dir exists
- #2190: false positive with :unused-alias and namespaced map
- #2200: include optional :callstack in analysis
squint: CLJS syntax to JS compiler
Lots of stuff happened in October with squint!
- #350: js* should default to :context :expr
- #352: fix zero? in return position
- Add NaN? (@sher
- #347: Add :pre and :post support in fn
- Add number?
- Support docstring in def
- Handle multipe source :paths in a more robust fashion
- #344: macros can’t be used via aliases
- Add squint.edn support, see docs
- Add watch subcommand to watch :paths from squint.edn
- Make generated let variable names in JS more deterministic, which helps hot reloading in React
- Added a vite + react example project.
- Resolve symbolic namespaces (:require [foo.bar]) from :paths
- Add bit-and and bit-or
- Include lib/squint.core.umd.js which defines a global squint.core object (easy to use in browsers, see docs)
- Add subs, fn?, re-seq
- Add squint.edn with :paths to resolve macros from (via :require-macros)
neil: A CLI to add common aliases and features to deps.edn-based projects Version 0.2.62 released
- Fix NPE during neil dep upgrade
clojure-mode
- Porting this CLJS project such that it can run with squint also. You can now use this library directly from NPM as a JS library. See this page for a demo on how to use it directly from a CDN! This work is funded by Nextjournal.
cherry: Experimental ClojureScript to ES6 module compiler
- Released version 0.1.9
grasp: Grep Clojure code using clojure.spec regexes
- Fix self-requiring namespace (which clj-kondo now also catches via optional linter!)
lein-clj-kondo: a leiningen plugin for clj-kondo
- Bumped clj-kondo version
http-kit: Simple, high-performance event-driven HTTP client+server for Clojure.
- #543 Migrate away from SimpleDateFormat to java.time, fixes native-image issue and virtual threads
http-client: babashka’s http-client
- A number of small bugfixes and additions
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Expose destructure to scripts
- Macroexpand (.foo bar) form in macroexpand-1
- Optimize deref, swap!, reset! for host values
- Add time macro
nbb: Scripting in Clojure on Node.js using SCI
- sci.core itself was exposed to nbb users
fs - File system utility library for Clojure
- Minor fixes in glob by @eval, thanks!
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Get home directory via environment variable rather than system property by @DerGuteMoritz, thanks!
babashka.nrepl: The nREPL server from babashka as a library, so it can be used from other SCI-based CLIs
- Fix classpath op
- Implement ns-list op

November 2023 Update

Advent of Code

It is Advent of Code time of year again. You can solve puzzles in an online squint or cherry playground here.

Change the /squint/ part of the url to /cherry/ to switch ClojureScript dialect versions.

You can read more about the playground here.

November Updates

blog I’ve written two blog posts this month:
- Writing a Cloudflare worker with squint and bun
- Playing Advent of Code with Squint.
squint: CLJS syntax to JS compiler
Lots of stuff happened in November with squint! You could say that I’ve grown a little addicted to improving this project currently, driven by how users use it and also while developing the playground, a lot of potential improvements emerged.

Open for Squint Details

September & October 2023 Long-Term Project Updates

Sun, 19 Nov 2023 08:30:00 +0800

Thanks to our 2023 long-term developers for this amazing body of work. This is the 5th report of the year - with one more to come around the new year. (Projects listed are only some of what they are covering in this post).

Bozhidar Batsov: CIDER/REPL
Michiel Borkent: clj-kondo,babashka, squint, neil, CLI,clojure-mode, and more..
Sean Corfield: clojure-doc.org, toolsbuild, deps-new, honey-SQL, expectations
Toby Crawley: Clojars
Eric Dallo: Clojure-lsp, intellij
Christophe Grand: ClojureDart et.al.
Thomas Heller: Shadow-cljs
Nikita Prokopov: new projects, Clojure Sublimed, DataScript, Sublime Executor
Tommi Reiman: Malli, Reitit, Jsonista
Peter Stromberg: Calva, JavaScript REPL, Polylith
Peter Taoussanis: Carmine, Nippy, http-kit, Tempel, Telemere

Bozhidar Batsov

I’m happy to report that after numerous delays the long-awaited CIDER 1.8 (“Geneva”) was shipped on October 13th (which also happened to be my 39th birthday)! This was a truly colossal release that addressed many long-standing issues and introduced some impressive new features (e.g. much improved enrich-classpath, cider-log-mode, a new way to display javadoc and many improvements to the tests runner). See the release notes for more details.

This release was quickly followed by CIDER 1.9 and CIDER 1.10 - much smaller releases that mostly addressed some small issues and polished a bit some of the new functionality in CIDER 1.8. All this work also resulted in the list of open issues on CIDER finally dipping under 100 (currently they stand at 85). That feels nice!

Now that this is done, my focus will switch to completing the support for clojure-ts-mode in CIDER and finally cutting an nREPL 1.1 (which will bring TLS support).

Michiel Borkent

In this post I’ll give updates about open source I worked on during September and October 2023.
To see previous OSS updates, go here.

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch. On to the projects that I’ve been working on!

September Updates

I delivered my babashka talk at Strange loop talk and much of my attention went to the preparation of that (slides here). The talk is now available here.

I did manage to get some coding done as well, despite testing positive for COVID when I arrived back home… Here are updates about the projects/libraries I’ve worked in September.

clj-kondo: static analyzer and linter for Clojure code that sparks joy. Published a new version (2023.09.07) with these changes:
- #1332: New linter :unused-alias. See docs.
- #2143: false positive type warning for clojure.set/project
- #2145: support ignore hint on multi-arity branch of function definition
- #2147: use alternative solution as workaround for https://github.com/cognitect/transit-clj/issues/43
- #2152: Fix false positive with used-underscored-binding with core.match
- #2150: allow command line options = as in –fail-level=error
- #2149: :lint-as clojure.core/defmacro should suppress &env as unresolved symbol
- #2161: Fix type annotation for clojure.core/zero? to number -> boolean
- #2165: Fix error when serializing type data to cache
- #2167: Don’t crash when :unresolved-symbol linter config contains unqualified symbol
- #2170: :keyword-binding linter should ignore auto-resolved keywords
- #2172: detect invalid amount of args and invalid argument type for throw
- #2164: deftest inside let triggers :unused-value
- #2154: add :exclude option to :deprecated-namespace linter
- #2134: don’t warn on usage of private var in data_readers.clj(c)
- #2148: warn on configuration error in :unused-refeferred-var linter
- Expose more vars in clj-kondo.hooks-api interpreter namespace
babashka: native, fast starting Clojure interpreter for scripting. Version 1.3.185 released!
- #1624: Use Oracle GraalVM 21 (@lispyclouds)
- Use PGO to speed up loops (now 2-3x faster for (time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))!)
- Bump babashka.http-client to v0.4.15
- Bump rewrite-clj to v0.1.1.47
- #1619: Fix reflection issue with Thread/sleep in core.async/timeout
- Support interop on java.util.stream.IntStream
- #1513: Fix interop on Thread/sleep with numbers that aren’t already longs
- Bump babashka.cli to 0.7.53
- Fix #babashka.nrepl/66
- Various nREPL server improvements (classpath op, file lookup information for cider-find-var)
- Bump cheshire to 5.12.0
squint: CLJS syntax to JS compiler A lot of happened in squint this month:
- Many core var implementations got added: reduce-kv, max, min, every-pred, into-array, some-fn, keep-indexed, iterate, juxt, compare, to-array, fn?
- Bun compatibility
- Lots of bug fixes
- REPL improvements
- Adopt CLJS truth semantics: 0 and "" are no longer considered falsey
- Lots more coming next month!
neil: A CLI to add common aliases and features to deps.edn-based projects Version 0.2.61 released
- #181: fix neil --version
- fix tests by referring to latest hiccup (@teodorlu)
- #180: neil dep upgrade: allow upgrading from an unstable version to the latest unstable version (@teodorlu)
- #180: neil dep upgrade: with --unstable, opt-into unstable library updates (@teodorlu)
- #183: Don’t drop :exclusions when running neil dep add or neil dep upgrade ([@borkdude] and [@teodorlu])
CLI: Turn Clojure functions into CLIs!
- Small release with the option to add your own header on top of format-opts, thanks to @Sohalt
http-client: babashka’s http-client
- A number of small bugfixes and additions
A number of experiments around squint:
- bun-squint-loader: a demo of how to implement a loader for bun which lets you directly load .cljs files which are then compiled using
- squint cloudflare worker
rewrite-edn: Utility lib on top of rewrite-clj with common operations to update EDN while preserving whitespace and comments
- Fixed a round-tripping issue by bumping rewrite-clj
tools-deps-native and tools.bbuild: use tools.deps directly from babashka
- aarch64 binary (thanks @TimoKramer for contributing)
- update upstream projects
cherry: Experimental ClojureScript to ES6 module compiler
- Bump shared compiler code with squint and publish new version
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Bumped tools jar and fixed a bug concerning SHA comparison
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Add experimental :static-methods override to control how a static method is invoked. This allowed a fix in babashka for Thread/sleep on non-longs and for Class/forName which works arond a bug in Oracle GraalVM 21.
sci.configs: A collection of ready to be used SCI configs.
- @holyjak made a configuration for Fulcro which can be seen live in action here

October Updates

babashka: native, fast starting Clojure interpreter for scripting.
- Support self-contained binaries as uberjars!
- Add java.security.KeyFactory, java.security.spec.PKCS8EncodedKeySpec, java.net.URISyntaxException
- Fix babashka.process/exec wrt babashka.process/*defaults*
- #1632: Partial fix for (.readPassword (System/console))
- Enable producing self-contained binaries using uberjars
- Bump httpkit to 2.8.0-beta3 (fixes GraalVM issue with virtual threads)
- Bump deps.clj and fs
- Expose taoensso.timbre.appenders.core
- nREPL: implement ns-list op
- SCI: optimize swap!, deref and reset! for normal atoms (rather than user-created IAtoms)
sci.configs: A collection of ready to be used SCI configs.
- A configuration for hoplon and javelin was added. You can play around with hoplon in a SCI-enabled environment here
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- #2207: New :condition-always-true linter, see docs)
- #2013: Fix NPE and similar errors when linting an import with an illegal token
  Published a new version (2023.10.20) with these changes:
- #1804: new linter :self-requiring-namespace
- #2065: new linter :equals-false, counterpart of :equals-true (@svdo)
- #2199: add :syntax check for var names starting or ending with dot (reserved by Clojure)
- #2179: consider alias-as-object usage in CLJS for :unused-alias linter
- #2183: respect :level in :discouraged-var config
- #2184: Add missing documentation for :single-logical-operand linter (@wtfleming)
- #2187: Fix type annotation of argument of clojure.core/parse-uuid from nilable/string to string (@dbunin)
- #2192: Support :end-row and :end-col in :pattern output format (@joshgelbard)
- #2182: Namespace local configuration does not silence :missing-else-branch
- #2186: Improve warning when --copy-configs is enabled but no config dir exists
- #2190: false positive with :unused-alias and namespaced map
- #2200: include optional :callstack in analysis
squint: CLJS syntax to JS compiler
Lots of stuff happened in October with squint!
- #350: js* should default to :context :expr
- #352: fix zero? in return position
- Add NaN? (@sher)
- #347: Add :pre and :post support in fn
- Add number?
- Support docstring in def
- Handle multipe source :paths in a more robust fashion
- #344: macros can’t be used via aliases
- Add squint.edn support, see docs
- Add watch subcommand to watch :paths from squint.edn
- Make generated let variable names in JS more deterministic, which helps hot reloading in React
- Added a vite + react example project.
- Resolve symbolic namespaces (:require [foo.bar]) from :paths
- Add bit-and and bit-or
- Include lib/squint.core.umd.js which defines a global squint.core object (easy to use in browsers, see docs)
- Add subs, fn?, re-seq
- Add squint.edn with :paths to resolve macros from (via :require-macros)
neil: A CLI to add common aliases and features to deps.edn-based projects Version 0.2.62 released
- Fix NPE during neil dep upgrade
clojure-mode
- Porting this CLJS project such that it can run with squint also. You can now use this library directly from NPM as a JS library. See this page for a demo on how to use it directly from a CDN! This work is funded by Nextjournal.
cherry: Experimental ClojureScript to ES6 module compiler
- Released version 0.1.9
grasp: Grep Clojure code using clojure.spec regexes
- Fix self-requiring namespace (which clj-kondo now also catches via optional linter!)
lein-clj-kondo: a leiningen plugin for clj-kondo
- Bumped clj-kondo version
http-kit: Simple, high-performance event-driven HTTP client+server for Clojure.
- #543 Migrate away from SimpleDateFormat to java.time, fixes native-image issue and virtual threads
http-client: babashka’s http-client
- A number of small bugfixes and additions
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Expose destructure to scripts
- Macroexpand (.foo bar) form in macroexpand-1
- Optimize deref, swap!, reset! for host values
- Add time macro
nbb: Scripting in Clojure on Node.js using SCI
- sci.core itself was exposed to nbb users
fs - File system utility library for Clojure
- Minor fixes in glob by @eval, thanks!
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Get home directory via environment variable rather than system property by @DerGuteMoritz, thanks!
babashka.nrepl: The nREPL server from babashka as a library, so it can be used from other SCI-based CLIs
- Fix classpath op
- Implement ns-list op

Other projects

These are (some of the) other projects I’m involved with but little to no activity happened in September and October. See final section of each report (“Other Projects”) for details.
https://blog.michielborkent.nl/oss-updates-sep-2023.html
https://blog.michielborkent.nl/oss-updates-oct-2023.html

Discuss this post here
Published: 31 October and 30 September, 2023
Tagged: clojure oss updates

Sean Corfield

:tags [“clojure” “clojure-doc.org” “expectations” “honeysql” “jdbc” “open source” “community” “clojurists together”]}

In my previous Long-Term Funding update I said I would review/overhaul the “ecosystem” and “tutorials” sections (once I’d finished the “language” section).

`clojure-doc.org`

I finished reviewing and updating the last three language sections to Clojure 1.11
(Concurrency and Parallelism, Macros, and Laziness), and I added a new section about transducers to the Collections and Sequences section. In the next period, I’ll revisit the “TBD” items in the language section to see what I can do to address them.

I rewrote the Generating Documentation section (ecosystem) to focus on cljdoc.org and removed the outdated content.

The Web Development section (ecosystem) also got a major rewrite, adding a lot of new content, removing outdated content, and incorporating a lot of community feedback on a draft version (thank you!).

Finally, I added a new section to the tools.build Cookbook about template pom.xml file and the :pom-data approach (new in tools.build 0.9.6).

`tools.build` and `deps-new`

Following on from the tools.build Cookbook update, I updated deps-new to use that new release of tools.build and updated all the project templates to use :pom-data for generating pom.xml files. See the v0.5.3 Release

I need to do the same for clj-new at some point – perhaps in the next period!

HoneySQL

HoneySQL also saw a lot of work with two releases that mostly focused on improving BigQuery support (array subquery, select as struct, create or replace, ignore/respect nulls, and new :distinct and :expr clauses to facilitate certain non-standard queries), and introducing basic support for NRQL (New Relic Query Language) as a new dialect.

NRQL has non-standard quoting rules, non-standard entity names, and inlines all expression values, since it is mostly used directly within the New Relic web UI or via their CLI, neither of which support parameterized queries. New clauses and helpers have been added for :compare-with, :since, :timeseries,until, and :facet.

In addition, an important bug in the helper merge functions was fixed that affected anyone using the quoted-symbol style of DSL (instead of the keyword style).

See HoneySQL releases for more details of these two new versions.

Expectations

Expectations also saw two new releases this period. The first release focused on improving the way test failures are reported to be more consistent and informative. The second release was a minor one to improve clj-kondo support for more-of.

See Expectations releases for more details on these two new versions.

`next.jdbc`

Finally, next.jdbc 1.3.894 provides variants of with-transaction and on-connection that will rewrap an options-wrapped connectable. This was a long-requested feature that I had struggled with finding an elegant solution for. In addition, I updated most of the JDBC drivers that next.jdbc is tested against, to flush out any issues with those newer versions. Notably, SQLite no longer supports :return-generated-keys true but you can specify RETURNING * in your SQL instead.

What’s Next?

In November/December, I’m hoping to complete a review and update of the “cookbooks” section and make another pass of “TBD” items in the “language” section.

Toby Crawley

Clojars Worklog

September 2023

Commit Logs: clojars-web

Most of September was vacation, but I did make a few improvements towards the end of the month:

Prevent memory leak from in-memory session store This was the source of intermittent OOMs for years, and I finally tracked it down.
Require a license in the POM for new projects

October 2023

Commit Logs: clojars-web

The work this month was modernization: we moved away from yesql in favor of
honeysql, and to next.jdbc from clojure.java.jdbc:

Eric Dallo

During these months I worked a lot on clojure-lsp-intellij to make it stable and allow IntelliJ users have the same experience of using clojure-lsp in other editors, the plugin is way more stable now, and I’ve been working with @afucher in a clojure-repl-intellij OSS plugin which should work pretty well with this plugin so users will be able to have both REPL access and LSP features in Intellij, we should announce it soon!

For that to work and scale, I extracted all the clojure integration part from clojure-lsp-intellij to a separated library called clj4intellij, this new library allows the creation of Intellij plugins in Clojure without too much effort, this was the result of months of research and headaches about how IntelliJ’s API could work with Clojure, we are already successfully using it in clojure-repl-intellij!

clj4intellij

0.3.1

Support custom nrepl ports
Add NREPL and logger support.
Include clojure source to jar.
Add com.github.ericdallo.clj4intellij.app-manager namespace with functions to access ApplicationManager.
First release

clojure-lsp-intellij

0.9.0 - 0.13.0

Add support for paredit actions: slurp, barf, raise and kill.
Bump clojure-lsp to 2023.10.30-16.25.41.
Allow specifying a server log-path to better troubleshooting.
Fix find definition to work for external deps as well.
Improve troubleshooting section
Use nrepl and logger from clj4intellij.
Improve line indent to recognize some macros.
Fix exception on startup related to status bar.
Implement lineIdentProvider to handle enters and move cursor to correct position.
Start LSP server only when opening clojure files, avoiding starting on non Clojure projects. #20
Fix LSP not being disconnected on project close/switch.
Bump clj4intellij to 0.2.1.
Fix language attribute in intentionAction from plugin.xml. #18
Fix documentationProvider plugin.xml. #19
Extract Clojure intellij integration to separated lib clj4intellij.
Fix Find definition to work with Ctrl+B + Ctrl+click.
Add support for textDocument/didSave notification.
Fix rename refactor when file is not opened.

clojure-lsp

The main highlights are performance and memory improvement along with paredit features for clojure-lsp-intellij and other editors.

2023.10.30-16.25.41

General
- Bump clj-kondo to 2023.10.21-20231022.204832-4.
- Fix move-to-let/expand-let bug for multi-arity functions #1283
- Fix :dependency-scheme setting for .java files from jars #1653
- Bump graalvm to 21.
- Improve overall performance using GraalVM 21 PGO (Profile-Guided Optimizations).
- Extract the responsibility for merging clj-depend config #1265
- Support passing configurations to clj-depend via CLI #1694
- Bump clj-depend to 0.9.2
- Performance: remove keyword-usages elements from external analysis as they are not used for any feature and for big projects may affect memory. #1700
Editor
- New paredit refactorings:
  - forward-slurp
  - forward-barf
  - backward-slurp
  - backward-barf
  - raise
  - kill
- Improve rename to avoid internal errors and show proper error messages. #1691
- Exclude unused-public-vars when inside a comment block.
- Add :analysis-summary field to serverInfo command to get information about project for performance analysis.
- Add :analysis settings, with options to disable specific analysis for better performance on huge projects. #1700

Christophe Grand

ClojureDart

ClojureDart channel on Clojurians' Slack is getting close to 500 members.
We demoed ClojureDart at the London Clojurians meetup (video).
We didn’t had time to work on the REPL or multimethods (still planning to).

Improvements

In cljd.flutter, :watch now always deduplicate values. Previously deduplication only happened when destructuring was used; the rationale for the change is that if :watch returns the same values the generated UI will be the same. The only exception is when mutable objects are repeatedly returned. That’s why there’s now the :dedup false option to turn off deduplication of a given watch binding.
We reimplemented dynamic bindings on top of Dart Zones, this has two benefits:
- making bindings conveyance automatic across all async mechanisms,
- allowing to catch async errors! There’s a new *async-error-handler* dynamic var which can be bound to a function taking two arguments (exception and stacktrace), when bound it will catch uncaught errors happening in async mechanisms (futures, streams, async/await) started directly or indirectly by code under this binding!
In cljd.flutter we added helper directives for common widgets and cut on the boilerplate: :color, :height, :width and :padding.
This one is big for the ecosystem: we made it possible for cljd deps (managed via deps.edn) to have dependencies on Dart packages. This is big because it means that cljc or cljd libraries can use Dart dependencies without their own consumers having to redeclare them. The only requirement is for library authors when packaging to jars: copy pubspec.yaml` in the jar (or put a copy of it on the classpath before creating the jar).
We added a new special form: dart/async-barrier. Basically it’s a do which prevents await from leaking outside of the do (so the do form will evaluate to a Future). This is important when writing macros to prevent user code (which may contain await) from contamining macro-generated code.
In cljd.flutter we added a get-of helper to retrieve widget-scope values bound with :bind from a BuildContext object.
We ported clojure.data to cljd.data.
We added instance? to ClojureDart. This is something I have been reluctant to do because in Dart you can’t test an instance against a type value only against a type literal. That’s why we have dart/is? which is a special form and not a function. However when porting code to ClojureDart having to rewrite all instance? calls to dart/is? is tedious – and most of the time the type is passed as a literal to instance?. So to make porting easier we added an instance? function which throws when called as a function but is otherwise inline as a dart/is?. We do have plans for a true instance?.
We added into-array which suffer from a similar problem to instance?: the type of an array has to be statically known in Dart, it can’t be specified as a value. Here we followed CLJS lead and ignored the type for compatibility. Most certainly a behaviour which will have to be revisited when more libs are ported.
Last we added the possibility to have conflicting method definitions in a deftype/defrecord/reify. However one of the conflicting methods must have an ^:override meta. This was done to port some libraries with hacks around defrecord.

Fixes

Several fixes to the compiler, cljd.core. Amongst them:

type inference on reify
apply with some native Dart functions
not-empty inline was causing double evaluations
bug on dissoc! on transient hash maps
fix field lookup on defrecords fields whose names are not valid Dart names
##NaN, ##Infinite and ##-Infinite were not properly compiled
fix propagation of return-type hint in defn argvecs.

Future work

ClojureDart

New items:

Migrate from Clojure’s own reader to tools.reader. Currently ClojureDart uses LispReader from Clojure but this reader doesn’t allow to ignore the :clj feature when reading cljc so it requires to modify a lot of reader conditionals, even some which shouldn’t concern ClojureDart, and to order them precisely.
Value semantics on closures (not by default, as an option), this has the potential of simplifying caching in Flutter code.

Existing items:

Publish the Flutter-only REPL
Multimethods to allow more libs to be ported
Look into porting SCI to ClojureDart
New APIs to leverage our persistent data structures:
** maps (hash and sorted) in ClojureDart are original implementations (not the same as CLJ/CLJS) – hash maps could be seen as another refinement of the original, sorted maps constitute a novel implementation.
** Sorted colls should be good enough for direct use by Datascript.
** Both hash and sorted maps can support accelerated merge/diff/join/etc. operations.
cljd CLI written in cljd for easier project creation etc.
gen tests
…

Thomas Heller

shadow-cljs

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (e.g. Clojurians Slack).

Current shadow-cljs version: 2.52.10 Changelog

Notable Updates

Fixed some :dev-http issues that prevented proxying websockets or self-signed SSL certificates.
Fixed some node REPL issues, hopefully making it more reliable overall

Nikita Prokopov

(aka Niki Tonsky)

Must be something in the air that makes you start new projects in the Fall. Three new ones has popped up:

New project - clj-simple-router:

A minimal, order-independent Ring router
An introductory blog post

New project - toml-clj:

Fast TOML parser for Clojure
2000x faster than existing Instaparse-based ones
30x faster than tomlj (Java)

New project - extend-clj:

Easily extend clojure.core built-in protocols
Both Clojure and ClojureScript
First version let you implement your own Atoms
More to come

Old projects also have seen some love:

DataScript:

:xform is not called on ref attributes #455
Work started on automatic client-server synchronization. Don’t tell anyone, but you can follow progess in the branch

Clojure Sublimed:

Socket REPL: handle exceptions in lookup
Do not silence exception during lazy seq printing
Report number of reflection warnings in status bar
Eval inside already evaled region re-evals same region instead of going to top form
Printer can display newlines

Sublime Executor:

Don’t die if project has non-existing folders

And, of course, blogging. Unicode article has seen its five minutes of fame:

The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)

Tommi Reiman

Working mostly with Malli and Reitit. Will do an open source retreat to get planned things out in 2023.

Malli

Still WIP with the new effective type system.
Lot’s of small improvements released and waiting for a release.

0.13.0 (2023-09-24)

BREAKING Fallback to use result of first branch when decoding :or and :orn, #946
BREAKING: decode for :double and double? in cljs doesn’t allow trailing garbage any more #942
Faster generators for :map, #948 & #949
FIX: :altn can’t handle just one child entry when nested in sequence schema #945
Officially drop Clojure 1.10 support. Tests haven’t passed for some time with Clojure 1.10, but this was not noticed due to a faulty CI setup.
Use type inferrer when encoding enums #951
Use bound-fn in malli.dev/start! to preserve *out* #954
FIX: Malli generates invalid clj-kondo type spec for [:map [:keys [:+ :keyword]]] #952
FIX: malli.experimental.describe descriptions of :min and :max are backwards #959
FIX: Malli tuple should generate clj-kondo seqable #962

Reitit

0.7.0-alpha7 (2023-10-03)

Revert the group id change from alpha6
New release to bring alpha6 changes to the old group id
Updated dependencies:

[metosin/ring-swagger-ui "4.19.1"] is available but we use "4.18.1"

0.7.0-alpha6 (2023-09-11)

BREAKING: require Clojure 1.11, drop support for Clojure 1.10
BREAKING: new syntax for :request and :response per-content-type coercions. See coercion.md. #627
BREAKING: replace the openapi :content-types keyword with separate :openapi/request-content-types and :openapi/response-content-types. See openapi.md
NOTE!: all reitit libraries are now under the fi.metosin group on clojars instead of metosin. Use fi.metosin/reitit in your dependencies instead of metosin/reitit to get new versions.
- Reverted in alpha7 due to problems with renaming artifacts

Jsonista

A maintanance release

Something else

We had a family vacation in the Rhodes Island, which had massive wildfires earlier this year

Peter Stromberg

Calva

I had a bit of vacation from hacking on Calva during September. Which does not mean I had (or need ??) a vacation from Calva, I kept pretty busy with user support. And it was not all pause on the hacking either, more that I couldn’t really get a hold on some bugs and after some fruitless hunts I decided to wait for more information. Which I got, both from users and from my own investigations. There was also an issue with VS Code Insider builds, stopping our CI pipeline completely. Calva uses the Insider branch of VS Code for integration testing. I was pretty sure the VS Code team would fix it, so I waited that out instead of installing workarounds. But not without spending considerable time on the issue before figuring out that it was upstream, and where upstream.

The major issue hitting users was quite awful. A hang in Calva’s structural editor, which mostly manifested itself in moments of total Calva unresponsiveness. With the help of Ingy döt Net’s ever more minimal reproductions we finally understood the problem and could fix it. ?? There is also some other hang hitting users of WSL, that we haven’t figured out yet…

Calva user Albert Snow discovered that Calva’s ClojureScript Quick Start REPLs were broken on Windows. He set the Calva development environment up and we could pair on finding the issue, which he then fixed! ??

Also fixed:

An annoying glitch with some Calva REPL commands not working when the cursor was inside the ns form.
Another annoying glitch wheredisconnecting and then reconnecting a REPL didn’t work

Giving myself a JavaScript REPl with Joyride

As a not-too-frequent user of JavaScript, I often find myself lacking an easy way to experiment with JS code, especially in the way I am used to being able to experiment with Clojure code. I decided to use Joyride for it, and created a script that gives me a JavaScript REPL, right there in VS Code. It’s still very simple, and I plan to return to it, making it a bit more sophisticated, but it is already pretty useful.

Joyride Examples entry: Give yourself a JavaScript REPL

Polylith Real World example in the browser

When helping Joakim Tengstrand with feedback on an article about Polylith (pending), we realized that it would be very good with a way to test Polylith without having to set your machine up for Clojure development. So I created an experience for that, leveraging Gitpod and Furkan Bayraktar’s Real World example app.

Related: I also wrote about observing when ChatGPT taught itself about Polylith from only a single diagram from that coming article.

Image composition using Babashka & Membrane

But not together. Though enabling using Membrane to Babashka does present itself as something I might try to do one of these days.

Some venturing into image and text composition lead me to two different solutions. One invloving ImageMagick and Babashka, plus it had me create a missing Docker image. And one involving the super exciting Clojure UI library, Membrane:

Imagemagick + Pango + Babashka:
- Write up: ImageMagick + Pango + Babashka = ??
- CalvaTV: Interactive Shell Scripting with Babashka
- Docker image cospaia/magick-pango-babashka
Membrane
- Example project: REPL Playground for adding back article info to links shared on X/Twitter
- Write up: Pending…
- CalvaTV: Interactive Programming with Clojure & Membrane

Peter Taoussanis

Open source update

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open source work!

Recent work

This was another productive period with 100% of my time going to open source. Highlights:

The usual support, hotfixes, etc.
14 library releases including:
- Carmine v3.3.0 with the first stable release of a significantly improved message queue architecture and API.
- Nippy v3.3.0 with updated benchmarks, efficiency improvements, and experimental transducer support.
- Nippy v3.4.0-beta1 with significant compression performance improvements, support for Zstandard, and a much improved freezable? util.
- http-kit v2.8.0-beta2 with auto Java 21+ virtual threads for both client+server, extensive new benchmark suite and results, early support for Ring-style async handlers, and more.
Continued work on Tempel, an upcoming data security framework for Clojure.
Continued work on Telemere, an upcoming structured telemetry library for Clojure/Script.
Did an interview with Daniel Compton to be published soon.

Upcoming work

Tempel is nearing completion, I’m down to the final polishing and documentation. Aiming for the first public pre-release early November.
Telemere’s first pre-release is then planned for ~mid December.

- Peter Taoussanis

Long-Term Funding for 2024

Fri, 10 Nov 2023 08:30:00 +0800

Clojurists Together is excited to announce that we will be awarding each of 7 developers $1,500 USD/month for 12 months in 2024 (a total of $126,000).

This is the 3rd year that we have been able to fund a significant number of longer-term project developers. This is due to the generous support from our membership, particularly from companies whose major contributions have made this number of annual awards possible. A shout out to: Latacora, Roam Research, Whimsical, Pitch, Nubank, Cisco, Metosin, Stylitics, Logseq, JUXT, Solita, adgoji, Grammarly, Nextjournal, ClojureStream, Shortcut, Flexiana, Toyokumo, Griffin, Doctronic, 180 Seguros, and Kroo Bank.

As in past years, we will be sending members a draft list of potential nominees to ask if there are additional folks they would like added to the ballot. The final ballot will go out to members using a Ranked Vote election to determine the final 7 recipients. As always, your input and participation is important and helps make Clojurists Together effective by ensuring members’ voices inform the work undertaken.

Developers’ 2023 Updates

Updates from our Long-Term Developers are posted on our website every two months. They are testaments to the incredible and varied contributions they have been able to make because of this type of long-term support. Check out a few recent reports:
July/August 2023
May/June 2023
Custom Formatters for Firefox (Release)
March/April 2023
Jan/Feb 2023

Background

In 2021, we talked to developers to understand how Clojurists Together could better serve them. One of the things we heard was that developers were looking for more flexibility and stability in funding and that they appreciated Cognitect’s funding model.

In response, we created a long-term funding program alongside our existing shorter-term project grants - giving funded developers $1.5k/month for 12 months. We have seen that giving developers flexible, long-term funding gives them the space to do high-impact work. This might be continuing maintenance on existing projects, new feature development, or perhaps a brand-new project. We’ve been excited with what they came up with in the last few years and are looking forward to seeing more great work in 2024! Thanks all!

Past Recipients

2023 Recipients
· Bozhidar Batsov
· Christophe Grand
· Eric Dallo
· Michiel Borkent
· Nikita Prokopov
· Peter Stromberg
· Peter Taoussanis
· Sean Corfield
· Thomas Heller
· Toby Crawley
· Tommi Reiman

2022-2023 Special Project
· Sebastian Zartner (Custom Formatters/FireFox)

2021-2022 Recipients
· Bozhidar Batsov
· Michiel Borkent
· Dragan Djuric
· Thomas Heller
· David Nolen
· Nikita Prokopov

Call for Proposals. November 2023 Member Survey

Sun, 05 Nov 2023 08:30:00 +0800

Call for Proposals.

Clojurists Together is pleased to announce that we are opening our Q1 2024 funding round for Clojure Open Source Projects. Applications are open until the 24th of November 2023 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.

We will be awarding a total of $44,000 USD for 8 projects – 4 projects at $2,000 each and 4 projects at $9,000 each. The $2k funding tier is for experimental projects or smaller proposals, whereas the $9k tier is for those that are more established. Projects generally run 3 months, however, the $9K projects can run between 3 and 12 months as needed. We expect projects to start on January 1, 2024.

We recently surveyed our members to find out what types of initiatives they would like us to focus on for this round of funding. Their responses are summarized below. Thanks as always – it is extremely helpful in ensuring that the community is a vital source of input.

If you are working on a Clojure open source project or have a new one in mind, especially one mentioned as a focus area for our members, please consider applying. Or if you know someone that might be interested, please pass this information along. Let’s get the word out!

Our Members Speak: Feedback from the October/November 2023 Survey.

What areas of the Clojure and ClojureScript ecosystem need support?

Production-Grade Documentation and Libraries

• More Clojure (not ClojureScript) oriented server-side libraries and tools
• Documentation and tooling are still abysmal across the board.
• Documentation is something that could be extended; the official references sometimes can be cryptic when you’re googling for something. A more verbose manual would be helpful.

More Users, Increased Beginner Adoption

• Evangelism, bringing in new developers
• Better new user onboarding, simpler initial setup
• Beginner learning material and outreach to other communities outside of the Clojure and ClojureScript community
• Community building and events
• Make Clojure CLI (deps.edn) easier to digest. I get the feeling that I should be an expert before using it. Lein with all its shortcomings, just gets you 90% of the way without you having to learn the tool. It just works. I still don’t understand the difference between clj and Clojure (why are both needed) and can never remember the difference between -X -A -T -M and whatnot.

Frameworks, Tools, and Functions. Ensure relevancy in the eco-system.

• Improving linters and test frameworks. the windows instructions on how to install clojure to get more people in (“An early release version of clj on Windows is available at..” has been the state since forever)?
• I think it’s time for a Rails-/Django-/Phoenix- like framework :-) Maybe more companies would jump in and use the language. I know it’s a difficult thing to balance because if I were to build it I’d base it on Hiccup, HTMX, HoneySQL and Component but the community likes to reinvent the Component library a lot. That would also not cover the database layer that well.
• I would love to see improved support for primitive math operations. I’m constantly vexed by boxed loop variables.
• I would just generally say I find the experimental ClojureScript work Michiel Borkent is doing to be heading in a very interesting direction and would love to see it continue to be supported.
• I would like to get the “feel” that Clojure is modern. In many areas it feels like it has entered the 21st century.
• I feel like I am using xargs or sed for which I can never remember the arguments and have look them up again and again.
• The core language itself should be shored up: there are too many open bugs
• Anything that keeps Clojure/Clojurescript viable as a full stack ecosystem.
• Libs and tools around Datomic. Emacs IDEs which are not CIDER.
o IDE support, java 21 support
• Default MVC framework
• cljdart seems strategically important, and nativeimage perhaps
• Errors, async (for cljs)
• Squint

Data Science, AI

• Several comments about AI and Data Science in general.
• Small data analysis tooling, things like fancy pattern matching, specter, meander &c

What areas of the Clojure and ClojureScript ecosystem are strong? (compilation)

• Stability, ability to use non-Clojure libraries via interop, I don’t have to upgrade my build tooling every 3 weeks. Dev. Experience.
• Core library and frameworks. Both Clojure core and many libs are of high (code) quality (not always the documentation though)
• Routing libraries and React Wrappers (there are so many)
• Dedicated community. Clojurian Slack
• Probably the most senior developers who love their language • Building end user applications
• Clojure in general is excellent for my work!
• At this time I can do pretty much everything I want to do with full stack ClojureScript which is why I haven’t nominated anything that needs attention in the previous questions. Everything is great already!
• Build tools esp shadow-cljs
• Web “frameworks
• Api development
• Babashka, CIDER

Are there any particular libraries, tools, or projects that are important to you that you would like to see supported? (Listed by number of mentions):

(4) Jank, Shadow-cljs
(3) CIDER, ClojureDart Clj-kondo, tech.ml.dataset
(2) Babashka, Calva, Datatomic, FlowStorm, Mali, Portal, Re-Frame, SciCloj projects, Tablecloth
(1) Bifurcan (Zach Tellman), Bosquet, Clerk, Clj-mqtt-broker, Clojure Commons, Clojure2D, Clojure-lsp, Clojure-ts-mode, Cloverage, core.async, Cursive IDE, DataLevin, Deps, dtype-next, Electric Clojure, Fastmath, Fulcro, GraphQL, gRPC, datadog, Kaocha, Libpython-clj, Meander, Integrant, Nrepl, Open Telemetry, Pathom, Reagent, Snitch, sqlg-clj, thi.ng/geom
• More statistical programs build on neanderthal (generalized additive models, or Bayesian data analysis ala https://github.com/uncomplicate/bayadera). Someone picking up the visualisation library oz (vega/vega-lite).
• Michael Borkent’s work, Thomas Heller’s work. I also use binaryage/devtools, promesa, and applied-science.js-interop in nearly every project. Borkdude ecosystem.
• Not only, but definitely Sean Corfield’s, Peter Stromberg’s and Michiel Borkent’s projects

What would you like to be different in the Clojure community in the next 12 months?

Future Direction and Improvements

• Virtual threads seem like a big deal. My understanding is that Clojure’s core uses object synchronization that makes virtual threads a nonstarter for many applications–I imagine rectifying that might be a high priority.
• Big picture stuff that leads to more developer productivity (like Clojure Electric compiling away the network).
• Clojure data science moving into the areas that R/python and even Excel are covering
• ClojureScript / browser target future

Becoming relevant in currently growing fields (e.g., LLMs)
Reaching a mature state in the data-science field
• Catchup with Tooling aligned with JS/TS ecosystem
• Being less concentrated on ClojureScript is the improvement by itself for the Clojure community.

Production-Grade Documentation and Libraries

• I’d love to see a focus on production-grade, usable, and documented libraries. Too many production stacks rely on poorly thought-out weekend projects and frameworks that are abandoned and do not cleanly operate with deployment technology released in the last decade.
• Better docs, smarter toolsets

More Users, Increased Beginner Adoption

• New people joining the Clojure ecosystem, leveraging the changes in the JVM
• Many more new users
• Getting the beginner adoption higher. Seems that even other Clojure devs sometimes see using Clojure as a vendor lock in even though it definitely is not a more difficult language to learn than the others.
• More projects that directly address the popularity question
• Making Clojure a clear and visible option for many people who haven’t considered it yet
• Higher adoption
• Batteries-included starting journeys, now that deps replaced Lein

Community and Convening

• I wish there was an easy way to know of the CFPs of upcoming conferences so I don’t miss them.
• Get some community building going. with Strangeloop gone, ClojureD not happening this year, there is a gap widening.
• I’d like to see Clojure being talked about in the wider tech community, not just in Clojure-specific forums. It would be great to see more Clojure talks at mainstream conferences for example.
• The community seems nice, don’t touch anything!

2023 Annual Members' Meeting

Tue, 24 Oct 2023 08:30:00 +0800

Clojurists Together held its Annual Membership meeting on 10 October 2023 (10-11 a.m. Pacific Time). A big thanks to all of you who were able to attend. For those of you who couldn’t, here is a summary of the meeting and subsequent discussion.

Board Elections: The first order of business was to acknowledge our new board members and thank our departing members Chris Nuernberger and Ikuru Kanuma. In October, Members elected 4 board members for two-year terms:

Daniel Compton, Secretary-Treasurer (returning member)
Heather Moore-Farley (returning member)
Felix Barbalet (new to the board)
Max Penet (new to the board)

In addition, two board members have 1 year remaining of their board term:

lvh (Laurens Van Houtven), President
Maria Geller

Summary of Presentation:

In 2023, we were able to draw down a significant reserve by funding more long-term developers and short-term projects - benefiting the Clojurists community and as a by-product providing some stability in a tech marketplace that has experienced major layoffs in the last year.
If we assume a minimal reserve and a similar level of membership revenue in 2024, we will need to decrease our funding of projects slightly going forward - or focus on ways to increase company and individual memberships and/or membership contributions.
While growth of new memberships (both company and individuals) has slowed from previous years, our retention rate is remarkably high. (95%+)
We have been able to fund an incredible amount of quality work that has real value to both companies and individual developers. With added oversight of the board and regular input from the Clojurist community, the overall value and return on investment is very high. We provide proof of concept that “Sustainable open-source is sustainable”.
The hiring of a program manager has increased overhead slightly but improved the timeliness of payments and communication (Daniel was trying to do it all as a volunteer in his “spare time”). However, administrative expenses at 7% of revenue continue to run under average for non profits (15-20%) and Open Collective fees (10%).

Summary of Funding Activities:

Summary of 2023 Funding:
- Long-term funding: 10 developers, $18k each, $180k in total. Bozhidar Batsov, Michiel Borkent, Sean Corfield, Eric Dallo, Christophe Grand, Thomas Heller, Nikita Prokopov, Tommi Reiman, Peter Stromberg, Peter Taoussanis, Toby Crawley (5 months $7.5K)
- Funded 30 projects for $150k: 23 smaller projects ($130k total) in 2023 and 7 from Q3 2022 continued into 2023 ($20k). Adopted flexible funding, up to 12 months.
- Q1 2023: Aleph/Manifold, Clerk, clojure-ts-mode, Donut, Doxa, Exercism, Neanderthal
- Q2 2023: clj-kondo et al, clj-Nix, Clojure Camp, Emmy, Jank, Portfolio, Lucene Grep, Neanderthal
- Q3 2023: Biff, Bosquet, Deps-try, Emmy, GDL, Jank , Neanderthal, Quil
- Firefox Custom Formatters: Sebastian Zartner continued work to add Custom Formatters to Firefox. Released August, 2023. ($18k)

Company Membership: Thanks to all our company members (Map, Transduce, Filter Memberships)

Individual Members:
While we need to work on growing both our individual and company memberships to support more projects, our retention rate (95%) is incredibly high.

Summary of Financials:

Discussion and Follow-Up:
Has the board solicited major projects in the past - and how could we incorporate this approach as part of the funding model in addition to the open proposal model?

The board has solicited specific projects in the past (FireFox release a good example), however, it has been difficult to find developers that have both the specific expertise and the bandwidth to commit to major projects.
Follow-Up: We can include more specific questions in the Long Term Survey about the types of projects we should champion.
Follow-Up: We can connect with sponsor companies to understand more about their use and needs related to targeted platforms, developer tools, resources, etc.

Is the current reporting format meeting the needs of the membership - are there suggestions for improvement? (The reports are quite detailed and are written and submitted by the developers on a regular basis).

While the reports provide a useful way for members to access new tools and information, they also provide a way of demonstrating the value of the work funded by companies and individual members. A membership supports REAL work! Members attending scan current reports for the info that is most useful or interesting to them - so details are not a negative.
Follow-up: We should consider highlighting 5-10 accomplishments - easy access, intriguing, problem-solved, etc. for marketing our unique value as a community and an organization.

October 2023 Project Updates

Mon, 23 Oct 2023 08:30:00 +0800

Check out the latest reports from our developers working on shorter-term projects.

Biff: Jacob O’Bryant
Bosquet: Zygis Medelis
Clojure Camp: Daniel Higginbotham
Deps-try: Gert Goet
GDL: Michael Sappler
Jank: Jeaye Wilkerson
Neanderthal: Dragan Duric
Quil: Jack Rusher and Charles Comstock

Biff: Jacob O’Bryant

2023 Q3 Funding Report 1. Published 15 October 2023.

Published an essay Understanding htmx. Seems to have been well received. It’s had 1.4k page hits.
Wrote the first half of another essay, How does XTDB compare to other databases? (working title)
Studied some beginner SEO resources (this and this) and did some keyword research.

My conclusion is that the only Clojure-related search query with enough traffic to be worth trying to rank for is simply “clojure” itself. (e.g. “clojure web framework” seems like an obvious candidate, but Google says it gets only 10 - 100 searches per month.)

Looking at the current Google results for “clojure”, it actually seems like it might be possible eventually to rank in the second half of the page. But either way, I don’t think it’s worth trying to write about any particular topics/go after any particular search keywords; I’ll just keep writing whatever seems most useful based on community feedback/gut feel. And maybe at some point, I’ll make sure I have a handful of pages that would at least be good candidates for the “clojure” results page–like my existing why clojure essay, and perhaps a curated list of learning resources.

I would’ve liked to have written at least three essays at this point instead of just one and a half, but I had some stuff come up. The next six weekends are clear though :). Things I’d like to get done in that time:

Finish my current essay on XTDB
Write an essay about Biff’s rationale and philosophy
Write a framework comparison document that describes the differences between Biff and Kit/Fulcro/rolling your own.
Write several how-tos focused on swapping out Biff’s defaults: replace XTDB with Postgres/SQLite/Datomic; deploy with Docker instead of on a plain VM; replace htmx with re-frame.

The remaining how-tos and the Biff-from-scratch guide (see the content library roadmap) will need to wait until later.

Bosquet: Zygis Medelis

2023 Q3 Funding Report 1. Published 30 September 2023.

Goals

The main development direction for Bosquet is to provide an environment where LLM apps can execute autonomously. It needs to provide facilities for LLM agents to plan actions, use tools, and have memory access that enables this behavior. Initial functionality providing developers with prompt engineering, chaining, and completions remains Bosquet’s integral part.

Changes

Integrant-based system management

Autonomous agents need unified access to Memory, LLM Services, Planning, Tools, and other components. Integrant-based component management now added to Bosquet allows it. As part of the current release - LLM Services and Memory are declared via the Integrant system.

Bosquet Component configuration is implemented with juxt/aero library for added flexibility.

Multi LLM service support

Alongside previously available Open AI access (via wkok/openai-clojure), Bosquet now supports Cohere LLM (via danielsz/cohere-clojure).

Having access to different LLMs is not sufficient for autonomous agent execution. LLM Service components need to have well-defined input/output shapes for the agent to work with. Bosquet started adding schema definitions (done with metosin/malli) to declare the model’s capabilities and data formats (initial development stage).

Chat mode support

Bosquet had a gap in its functionality by not supporting chat mode. Now supported and based on ChatML. Chat mode benefits from existing Bosquet prompt management facilities, like Selmer templating, and Pathom based template chaining.

Memory

A critical component for further Bosquet development and coming up with a satisfactory architecture is proving to be hard. The current Bosquet release declares the Memory system that jacks into AI completion workflow to record AI interactions and inject relevant recalled memories into the prompt context.

Memory is implemented via Clojure protocols to enable pluggable memory storage, memory recall, and memory encoding algorithms. As part of the current release, a SimpleMemory is added. It uses an in-memory atom for storage and the most recent memory access recall.

Documentation

Bosquet already covers different and complex concepts of working with LLMs. It has accumulated out-of-order documents, descriptions that are obscure, or superseded. To address the lack of good Bosquet work explanations, I have started preparing a new documentation site https://zmedelis.github.io/bosquet/

Clojure Camp: Daniel Higginbotham

2023 Q2 Funding Report 3. Published 17 October 2023

Since our last update, we have continued exploring ways to partner with industry leaders to facilitate the process of connecting junior developers with Clojure jobs. We have a roadmap for engaging with partners over the next couple months, which will we be publicly sharing in the coming weeks.

Additionally, we’ve spent significant time exploring options to incorporate paid training in our offerings. The motivation for this was to find ways to develop Clojure Camp more sustainably. We decided that, for the near future, we want to focus our efforts on our vision of fostering a free, welcoming, friendly, and diverse peer learning community.

In addition to this organizational, administrative work, we’ve continued running our weekly study group sessions and improving our learning materials.

Finally, a piece of awesome news: one of our campers has landed a Clojure job! This is his her first programming job, and we are so thrilled for her!

Thank you, Clojurists Together, for your support in doing this work!

Deps-try: Gert Goet

2023 Q3 Funding Report 1. Published 18 October 2023.

I’ve been working on recipe functionality for deps-try (a tool to quickly try out Clojure libraries on rebel-readline).

I worked out a POC to explore what it would entail. The majority of the time went into working out some gnarly Java interop related to JLine’s history classes.

With this hurdle taken, and having worked out most of the options and flags for the CLI, I’m currently turning the POC into code for the mainline.
I’m looking forward to replace example code in some of my other projects, with a simple oneliner, e.g. deps-try --recipe malli-select/intro.

Planned future work

Listing recipes: Showing a table with all the recipes from the repository.
Allowing for recipe shortnames: Instead of providing a full url/path, just say deps-try --recipe malli/data-generation.
Having a --recipe-ns to only get the ns-form from the recipe in your history for when you only want the deps and the requires but nothing else in the history.
Turn some guides from clojure.org into recipes

Potential directions

Having repositories with recipes: This would allow for using shorter names to load recipes also for non-builtin recipes.
Supporting jvm-options and custom mvn-repositories: As this has potential security implications, this would best be combined with (trusted) repositories.
A repository can have a TRYME file which functions as a recipe

Keep an eye on the unstable releases the coming weeks if you want to testdrive the new functionality!

GDL: Michael Sappler

2023 Q3 Funding Report 1. Published 15 October 2023.

What I have done in the last 1.5 months:

GDL

extended scene2d API
- scene2d.ui is a simple&powerful GUI library included in libgdx. Example apps using it: hyperlap2d, spine.
- now 3 namespaces: gdl.scene2d.ui / gdl.scene2d.actor / gdl.scene2d.stage instead of gdl.ui (before).
use vis-ui for the scene2d GUI widgets (a java library advanced functionality based on top of libgdx.scene2d.ui ).
some simplifications/refactorings.
next goal: remove the global states and make code more functional.

Cyber Dungeon Quest

together with the GDL scene2d API I have started developing the ‘property-editor’ for all the game properties like creatures, items, weapons, spells, etc. This required changes to consolidate the different properties into one .edn file and namespace.

a lot of cleanup/refactoring (the first version of the game I wrote 10 years back as a student so there is a lot of old code still included )
the next task is to refactor ‘modifiers’ and ‘effects’ to make them data-based and editable too, and also to remove a lot of global state and make the code here also more functional.

Jank: Jeaye Wilkerson

2023 Q3 Funding Report 1. Published 15 October 2023.

For the past month and a half, I’ve been building out jank’s support for clojure.core/require, including everything from class path handling to compiling jank files to intermediate code written to the filesystem. This is a half-way report for the quarter.

High level requirements

Class paths

Clojure JVM benefits a great deal from being built upon an existing VM. In the native world, we don’t have things like class paths. Maybe the closest things would be include paths at compile-time and LD_LIBRARY_PATH at run-time, but neither of those capture the flexibility of JVM’s class paths, which work at both compile-time and run-time.

So, to start with, jank needs a similar system. This is a common pattern for jank, requiring me to implement not just Clojure, but a VM of my own, with the necessary parts to reach parity.

Progress

I’ve built out class path traversing for jank, which supports both directories and JAR files. This will allow jank to work out of the box with Clojure’s existing Maven dependencies and file structures, which is of course important.

jank traverses the class path exhaustively on startup and caches what it finds, mapping the module name (ns name or ns name with a nested class, like clojure.core$foo) to the relevant file. When a function like require or compile is called, jank will find the most relevant source to work with.

Core functions

There are a handful of related clojure.core functions for module loading, like require, compile, load-libs, load-lib, load-one, load-all, alias, etc. The next step, after having class path support, is to implement these.

Progress

I have a working implementation of (require 'clojure.core) and (compile 'clojure.core) now! They hook into the class path work and do the necessary work to require or compile. Compilation writes files to a particular directory, which is also in the class path. Requiring a module which is already loaded will not do anything.

There’s still a lot of work to do to build out the necessary core functions and have them work the same as in Clojure JVM. The implementations of require and compile that I have right now only accept a single symbol, rather than being variadic, supporting lib specs, flags, etc. So this is still an MVP, right now, but it works!

Class files

There’s no such thing as a class file in the native world. Maybe the closest equivalent would be an object file or, for C++20, a pre-compiled module. Those are both more limiting than a class file, though, since they’re not portable; compiled native code is generally targeting a specific platform/architecture. Trying to share these in a Maven dependency, for example, is only going to help those who are on the same hardware as you. Even then, we can run into ABI Incompatibilities.

So, while I’m interested in exploring support for intermediate object files and pre-compiled modules, I’m starting with intermediate files being just C++ source (which is what the jank compiler outputs for Cling to JIT compile). From there, another step toward machine code will be to target LLVM IR by having Clang compile the C++ source first. This is closer to JVM byte code, but LLVM IR is actually still platform/architecture specific!

Lastly, I’m very hesitant to provide a default of jank dependencies coming in as binary files, even if I can solve the portability problem, simply due to supply chain security concerns. I would rather live in a world where people share source dependencies with pinned versions and transparent updates. I do think that binary intermediate files make sense for local development, though, and they can greatly speed up iteration.

Progress

As of now, I have (compile 'clojure.core) compiling jank source to C++ source, which is being written to the class path. If you then later try to (require 'clojure.core), it will be loaded from the compiled C++ source. If the C++ source was on the class path already, it will be favored over the jank source.

One benefit of this implementation is that jank developers can include arbitrary C++ source along with their jank source and just require it alongside everything else. In order to work with this, the C++ source just needs to follow a particular interface.

A challenge I ran into with this is how to manage module dependencies. For example, if clojure.core depends on clojure.core$take, which depends on a local fn its own, clojure.core$take$fn_478, I need to ensure that all of these are loaded in order of deepest dependency (leaf node) first. I went back on forth on the design for this, but ultimately settled on something similar to what Clojure does.

I generate two C++ source modules for clojure.core itself. One is something like classes/clojure.core.cpp and the other is a special classes/clojure.core__init.cpp. When clojure.core is required, it will look for a clojure.core__init module first. Within that module is a special interface with an __init function which has a big list of all of the dependencies needed to actually load clojure.core. The __init function will just iterate through that list and load each one.

Finally, we can actually load clojure.core, which runs the top-level effects of creating all of the vars, the value for each being based on new types brought in from the dependencies.

This is different from Clojure, since the JVM has a standard way for one module to depend on another. That dependency is just conveyed, like using import in Java, and then the JVM ensures all dependencies are met before getting to the body of the module. Again, I need to reimplement that portion of the JVM for jank since the native world has no equivalent feature.

What’s remaining

Iterative compilation (tracking source timestamps to know how much to recompile) and support for reloading have not been touched yet. Aside from that, most things I have implemented are quite rough and need further polish to meet parity with Clojure. Although I have require and compile working in the simple case, none of the other related core functions have been implemented.

Performance wins so far

By pre-compiling clojure.core to C++ source, and then just requiring it on startup, the time it takes to boot the jank compiler + runtime and print hello world dropped from 8.7 seconds to 3.7 seconds. So that was all time spent compiling jank code to C++ code. What remains is almost entirely just time compiling C++. If I remove clojure.core loading altogether, it takes less than 0.2 seconds to run the same program. I’ll be digging more into the performance here, as I get more implemented, but I want to call out a couple of things.

We’ve already cut 5 seconds down, which is great!
Everyone knows that compiling C++ is not fast and we are set up to be able to start loading LLVM IR instead, after some more work
The creator of Cling informed me that LLVM tends to spend around 50% of its time in the front-end for C++, which means that by using LLVM IR we’ll be cutting down our compilation time by around 50%
I haven’t done any startup time benchmarking or profiling for jank yet, but if there’s time this quarter, you can bet that I’ll be digging deep into this

I have some exciting plans for visualizing jank’s performance, both the compiler and your application code, in a way which will ship with the compiler itself. More info on this in a later post.

Uncomplicate Neanderthal: Dragan Duric

2023 Q3 Funding Report 1. Published 30 September 2023.

My goal with this round is to polish Uncomplicate libraries (mainly Neanderthal, Deep Diamond, ClojureCUDA, ClojureCL, ClojureCPP), rather than develop new functionality.

In this round, I’ve done lots of Deep Diamond coding related to the port to JavaCPP. This enabled me to refresh my memory of how the very detailed and complex internal works, and to check and update many old tests, and write some, but not many, new tests. I am approaching the point where I would be able to say that all code is ported to JavaCPP pointers, and only then I’ll be able to work on documentation.

Here’s a breakdown of what I’ve been able to work on, regarding the proposed items:

Do a thorough re-visiting of existing code in major Uncomplicate libraries: I’ve been able to re-visit many parts of this code, and did a lot of check and fixes. Still a lot left to be done.
Read the code without rushing to implement new features: I haven’t been able to do it without implementing new features yet.
Write more tests for edge cases: I’ve worked on this, but not as much as I hoped. Still a lot of work in front of me in this regard.
Discover bugs and fix them: Discovered a fair amount, fixed most, but not all.
Discover places where code could be improved (without rushing the new functionality). I’ve improved many parts of code, but without the benefit of not rushing to the new functionality. When I complete the JavaCPP switch of Deep Diamond, I’ll be able to do it in this manner.
Re-visit documentation and improve it to better match the current state of Uncomplicate libraries: It has to wait for at least a few more weeks.
If opportunities arise, implement some new functionality based of all the aforementioned items: I’ve done this here and there.

I hope that in the next few weeks I’ll be able to stabilize the JavaCPP-based Deep Diamond (DNNL engine port is complete, but cuDNN needs more work) and that then I’ll be able to do a systematic pass of testing/bugfixing/documentation writing.

Quil: Jack Rusher and Charles Comstock

2023 Q3 Funding Report 1. Published 30 September 2023.

So far, we’ve managed to:

update all dependencies to the latest versions of Processing (4.3) and p5js (1.7.0), including packaging native deps for all major OSes
re-wrote the build system using deps.edn and build.clj
created a new test harness that allows side-by-side testing for Clojurescript (p5js) and Clojure (Processing)
got that test harness working with CLJS in a headless browser on Github CI 🎉

These changes resolve the primary barriers to using Quil – requiring a deprecated version of the JVM (Java 8) in order to render OpenGL sketches, and incompatibility with the new Apple M1 architecture – and pave the way for easier maintenance moving forward. We still need to migrate a number of existing manual tests to the new test harness to improve overall coverage, but it’s a good foundation to build on. In the long run, this should reduce the difficulty of accepting new contributions and in cutting future releases.

Sam Aaron has added one of us to the Clojars organization for Quil, so we’re hoping to publish a SNAPSHOT of the current state of Quil on October 8 to facilitate wider user testing. There are a few breaking changes in terms of visual output that we’ve observed in our own sketches, but everything seems to mostly work, and Jack used this version of Quil to prepare slides for his talk at Strange Loop/Papers We Love Conference in September without problems.

2023 Annual Meeting and Election Results

Mon, 09 Oct 2023 08:30:00 +0800

Greetings Clojurists!

On behalf of the board, I am happy to announce that the board election results are in. With almost 30% of the membership submitting ballots, we have two returning board members - Daniel Compton and Heather Moore-Farley. Our two new board members are Felix Barbalet and Max Penet. Congratulations to all - and thanks to everyone who volunteered. The new board positions are for 2-year terms.

Also a huge thanks to our departing board members Chris Nuernberger and Ikuru Kanuma for their commitment to Clojurists Together and time spent supporting our developers and their projects.

Please join us at the Annual Members Meeting this week - 10th of October, 10 a.m. Pacific Time. For an email reminder that includes the Zoom link, please use this form.

Any questions, feel free to contact me at kdavis@clojuriststogether.org

Looking forward to seeing you at the meeting.

Kathy Davis Program Manager

Announcing 2023 Board Nominations

Wed, 27 Sep 2023 14:09:25 +1200

Clojurists Together is in the process of electing new board members to fill the four volunteer positions that are expiring this year. These positions are for two-year terms.

We received 7 applications from the Clojure Community. 2 are from current board members who would like to continue to serve. All of the candidates are talented Clojurists that we would love (and be honored) to have on our board.

The board has nominated all 7 candidates for the current board election (in alphabetical order of first names):

Chip Nowacek
Daniel Compton (current Treasurer/Secretary)
Felix Barbalet
Heather Moore-Farley (current board member)
Job Samwel Gateri Abellu
Max Penet
Vincenzo Chianese

Next Steps

All current Clojurists Together Members should have received a link to their ballot to vote via email. If you haven’t received a ballot by 3rd October (and you’ve checked your spam folder to see if it’s hiding there), please contact kdavis@clojuriststogether.org.

Voting will close on 7th October at midnight Pacific Time. The top four candidates, as voted on by members will win. We will announce the winners shortly afterward and you’ll be able to meet them at the Annual members meeting at 10 am Pacific time, October 10, 2023.

Your Vote is Important!! Please Vote!

Meet the Candidates

Chip Nowacek

https://clojurians.slack.com/archives/C0218CKTVEK/p1692842517062129

Company: Two Stewards, LLC.

Why you would like to join: The community has been so supportive. I want to give back where I can. I have no other ambitions. I don’t really know enough or have time enough to have any.
A short bio: Building a chatbot interface to a knowledge graph using the full Clojure/Script/Datomic stack. Using the tech because of the community ethos.

Daniel Compton

http://github.com/danielcompton
https://twitter.com/danielwithmusic

Company: Whimsical

Why you would like to join:
I am a co-founder of Clojurists Together. I have been involved with all of the funding rounds since the beginning and am currently the treasurer and secretary for Clojurists Together.

A short bio: Daniel Compton is a software engineer, working at Whimsical. He lives in a small town in New Zealand with his family. He was the co-founder of Clojurists Together and has been deeply involved with running Clojurists Together since the beginning.

Felix Barbalet

https://github.com/xlfe
https://psithur.com/blog/building-psithur-connect/

Company: Qantas Airways Ltd (Australia)

Why you would like to join: I’ve been using Clojure professionally for 3+ years now, and currently lead a team of Clojure engineers. Clojure has been the continuation of a life-long learning journey for me, and I don’t see that slowing down. The kind of things I’m interested in are figuring out how to raise the profile of Clojure as a smart choice for large enterprises all the way down to startups, and to help reduce the barriers to entry to Clojure as a profession. I want to see Clojure continue to grow and I’d love to see more corporate support to bring Clojure to more people.

A short bio: I’ve spent 15 years working as a technologist in a range of roles including analytics, data science, data engineering, software architecture and software engineering. I have experience across highly-regulated industries (Government), consulting and startups. I have a B Economics (Honours) with specialisation in advanced econometrics, statistics, game-theory and behavioral economics and a graduate certificate in Cyber Security.

Heather Moore-Farley

https://github.com/tophat8855

Why you would like to join: I’ve been on the board for the past 2 years and can keep it up. I know the work of board meetings and prep follow-up isn’t glamorous, but is really important for organizations to feel like they are going somewhere, and for increasing a feeling of community. I think it can be easy to feel like a lone developer working on a project, but knowing groups like CT are supporting projects can alleviate that a bit. And CT can’t support projects without a committee.

A short bio: Heather is a software engineer, knitter, and bicyclist. She has been coding with Clojure and Clojurescript full-time for 5 and a half years. In her 8 years of professional software development, she has both benefited from and contributed to open source projects.

Job Samwel Gateri Abellu

https://www.linkedin.com/in/job-s-27352545/

Company: Ezra World

Why you would like to join: I am excited about the opportunity to contribute to the Clojurists Together Committee for several reasons:

Passion for Clojure: I have a deep passion for the Clojure programming language and its ecosystem.
Over the years, I have developed a strong technical expertise in Clojure through hands-on experience. Joining the committee would allow me to actively participate in the Clojure community and support its growth, which has been a significant part of my professional and personal journey.
Eager to Contribute to Open Source: While I haven’t yet contributed to open-source projects, I am genuinely eager to start. The mission of Clojurists Together resonates with me, and I see this as an opportunity to begin my journey of giving back to the open-source community, particularly within the Clojure ecosystem.
Commitment to Open Source: I firmly believe in the power of open source to drive innovation and solve complex problems collaboratively. Clojurists Together’s mission of providing financial support to open-source Clojure projects aligns with my values. I am enthusiastic about contributing to the sustainability of these projects and ensuring they continue to thrive.

I believe I am a good fit because of:

Technical Expertise: I bring a strong technical background in Clojure and ClojureScript, with hands-on experience in developing and maintaining projects. My technical skills and familiarity with the ecosystem will enable me to assess project proposals effectively and provide valuable insights.
Strategic Thinking: I have a track record of strategic thinking and problem-solving, which I believe will be valuable when assessing project proposals and making decisions that align with Clojurists Together’s goals and objectives.
Commitment and Dedication: I am dedicated to the long-term success of the Clojure community and the projects it supports. I understand the responsibilities that come with being a committee member, and I am committed to fulfilling them with dedication and integrity.
In summary, my passion for Clojure, technical expertise, strategic thinking, and commitment to open source make me confident that I would be a valuable addition to the Clojurists Together Committee. While I haven’t contributed to open-source projects before, I am eager to start this journey and actively participate in supporting the Clojure ecosystem. I look forward to the opportunity to work alongside fellow committee members to further the mission of Clojurists Together.

A short bio: I am Job Samwel Gateri Abellu, a dedicated Clojure enthusiast with over 6 years of experience in this elegant and functional programming language. My journey into the world of Clojure began when a friend sought my assistance on a project, sparking a profound interest that has grown with each passing year.

My educational background includes a degree in Information Technology, with a major in software development. This academic foundation, combined with my hands-on experience, has allowed me to cultivate a robust skill set in Clojure. Throughout my career, I have leveraged this expertise to tackle complex challenges and develop innovative solutions.

Notably, my professional journey has primarily unfolded within the dynamic FinTech industry. My experience in this sector has provided me with invaluable insights into the intersection of technology and finance, making me well-equipped to understand and contribute to projects that bridge these domains.

While I am relatively new to open-source contributions, my unwavering passion for the Clojure ecosystem and my commitment to continuous learning make me an eager advocate for its sustainability and growth. I bring strategic thinking and a deep dedication to open source, aligning seamlessly with Clojurists Together’s mission.

If elected, I pledge to diligently collaborate with my fellow committee members to select and support projects that advance our shared goals, ensuring they continue to thrive and benefit the entire Clojure community. It is an honor to be considered for this role, and I am enthusiastic about the opportunity to make a meaningful impact on the Clojure community through Clojurists Together.

Max Penet

https://github.com/mpenet
https://twitter.com/mpenet

Company: Exoscale

Why you would like to join: I would like to have more of an impact on the community. I generally quite like to help out when possible, via the various discussion channels. I have also been the recipient of such help numerous times and it’s only fair I give back some of my time to help out. I think I might be a good fit given how long I have been involved in the community and how much I rely on the Clojure community to be healthy and thriving.

A short bio: I currently work as a software engineer for Exoscale, a European cloud provider that relies heavily on Clojure. I have been involved in the Clojure community and using Clojure professionally for more than a decade now, in various fields. I authored, contributed, and maintain a number of open-source libraries. I also tend to keep an eye on what’s happening at the community level almost daily, trying to be helpful when I can. More importantly, I really appreciate what CT is doing and would love to be able to help sustain that effort.

Vincenzo Chianese

https://www.linkedin.com/in/vncz/

Company: Microsoft

Why you would like to join: Have been using Clojure for a long time (unfortunately not at work), but I have been sitting in multiple committees (technical and not) and worked in technology for a long time. I have spoken to a lot of conferences and would love to help spread Clojure methodologies around.

A short bio: Vincenzo Chianese is an Italian Software Developer currently working as API Architect for Microsoft. He has been working in the API space for almost 10 years from building tools for API developers and architecting big systems.

July and August 2023 Long Term Project Updates

Fri, 15 Sep 2023 10:30:00 +0800

Even though it was vacation season, our developers share their progress (and challenges) for an incredible outpouring of work on their 2023 long term projects! Check it out.

Calva: Peter Stromberg
Carmine V4: Peter Taoussanis
CIDER/REPL: Bohzidar Batsov
clj-Kondo, babashka, nbb, SCI, Cherry, Squint: Michiel Borkent
Clojar-doc.org: Sean Corfield
Clojars: Toby Crawley
ClojureDart: Christophe Grande
Clojure-lsp: Eric Dallo
Humble UI: Nikita Prokopov
Malli: Tommi Reiman
Shadow-cljs: Thomas Heller

Calva: Peter Stromberg

These two months were not just about Calva. 😀

Calva

The biggest change was one I thought would be really tiny. We upgraded our dependency on cljfmt, and it got to be a much bigger change than I had expected. cljfmt had changed its configuration format, and it was a bit of work to figure out how to adapt Calva’s formatter to this. What made matters much worse is that I initially missed this configuration change and released a quite broken version of Calva. Doing something that already is a bit tricky in fire fighting mode is not making it easier. Or nicer. Wonderful then to notice that Calva and Clojure users had my back. I got some really wonderful help. I’m working in the best community imaginable.

Some more changes:

Support for workflows involving Fiddle Files, of Clojure Design Podcast fame, was added. Please let us know if you use this support and how you fare with it!
Improve nREPL message diagnostics.
Fixing issues around shadow-cljs REPL start and connect
Restructure and complement the docs around using Calva with shadow-cljs
Improvements with evaluating expressions inside Rich Comment Forms
Improvements in how the nREPL server collects output side effects from the REPL process, following CIDER’s model
Improvements in the handling of, and messaging around, clojure-lsp binary downloads

Lingy

When testing and providing feedback on the development of Lingy, a new Clojure implementation running on Perl, I wanted to be able to connect Calva to the Lingy REPL. So that caused me to start and participate in the development of a Lingy nREPL server. Now users of Calva, and any other nREPL client, can interact with their Lingy application from the editor. (Yes, so this was partly about Calva 😄.)

Carmine V4: Peter Taoussanis

Open source update

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open source work!

Recent work

This was a productive couple of months! Managed to dedicate 100% of my time to open source. Recent work includes:

14 library updates, including pre-releases for major updates to Nippy and Carmine.
Significant improvements to all library documentation are underway, including:
- Cross-platform API docs via a Codox fork (work also submitted upstream).
- Improved compatibility with clj-doc. Thanks to Lee Read for assistance with some upstream improvements & troubleshooting advice 🙏.
- After much experimentation, I’ve settled on new tooling and a new workflow for writing documentation. This’ll allow me to much more easily write and maintain docs moving forward. The first change that will be apparent is the move to a wiki format (example) that allows more structure and easier searching.
- Relatedly- I’ve started updating and expanding all pre-existing docs, with a focus on more beginner-oriented info. I’m tackling this in steps, so it’ll take some time to migrate and update everything.
I’ve moved all my open source under a dedicated GitHub group to help keep things organized and more easily searchable.
I’ve updated my homepage to include better info on my open source - including release news.
I’ve started added basic GraalVM compatibility (and tests) to all libraries. Many are already covered, the rest will be covered whenever they get their next release.
(Just for fun) - I made a new logo for http-kit.
I’ve been deep in experimentation on a new telemetry library that I’m quite excited about. I’ll have more to share on this in future, but in the meantime I can say that I’m very happy with how the initial prototype is coming along 👍

Upcoming work

My current roadmap includes:

September: stable Nippy v3.3 and Carmine v3.3 releases.
October: first public release of Tempel, a new data security framework that I plan to talk more about closer the time.

I’ll also be continuing work on the new telemetry library (currently named Telemere), and on the ongoing documentation improvements. - Peter Taoussanis

CIDER/REPL: Bohzidar Batsov

The last couple of months were very productive for CIDER and all of its related projects. This was mostly due to our long-term contributor vemv being between jobs and eager to tackle some of the major items on our TODO list. I’ve decided to use a sizeable chunk of the donation money CIDER had accumulated over at OpenCollective to fund vemv’s work on CIDER & friends, and the results were great. Some highlights:

We’ve got a brand new and much improved https://github.com/clojure-emacs/enrich-classpath Now CIDER support using enrich-classpath with Clojure’s CLI (tools.deps) as well.
The test runner now has a fail-fast mode and shows timing information about the tests
We finally started to make use of Clojure 1.10’s improved error message. (see https://github.com/clojure-emacs/cider/issues/3418) This prevents stacktraces from showing up whenever the :clojure.error/phase indicates that it’s a compilation error.
Add new customization variable cider-clojurec-eval-destination to allow specifying which REPL CLJC evals are sent to.
CIDER can now infer the indentation for many macros, without the need to provide indentation metadata for them (similar to how SLIME works for Common Lisp)
There have been many small improvements around the ClojureScript support

We’ve also did a big cleanup of the backlog and got the open issues under 100 for the first time in quite some time!

There are also a ton of other small improvements and bug-fixes that have been implemented in those two months. I encourage everyone to check the full list of changes here. All this work is the reason why CIDER 1.8 is still not out - we want to pack more into this release before we focus on CIDER 2.0

Right now it seems that CIDER 1.8 will be the biggest and most important CIDER release in the past 2-3 years! The release should happen any day now (this time for real)!

On an unrelated note - clojure-ts-mode is now available on NonGNU ELPA. Its submission there triggered a few long conversations about potentially including clojure-mode and/or clojure-ts-mode in Emacs itself. It’s a complex topic that we’ll be discussing with the clojure-emacs maintainers and our users in the months to come.

That’s all I have for you today! I expect to write a few more detailed blog posts on some of the topics I mentioned here once CIDER 1.8 has been released.

clj-Kondo, babashka, nbb, SCI, Cherry, Squint: Michiel Borkent

Sponsors I’d like to thank all the sponsors and contributors that make this work possible! Top sponsors:
• Clojurists Together
• Roam Research
• Nextjournal
• Toyokumo
• Cognitect
• Kepler16
• Adgoji

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!
• Github Sponsors
• The Babaska or Clj-kondo OpenCollective
• Ko-fi
• Patreon
• Clojurists Together

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch.
On to the projects that I worked on in July!

July Updates

clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- A big fat new release: 2023.07.23. Several new linting rules and lots of fixes. See changelogs here.
http-client: Babashka’s http-client
- Added a websocket API, a fix for the :ssl-context {:insecure true} option and more. See CHANGELOG.
pod-babashka-fswatcher: babashka filewatcher pod
- The events emitted from the file watcher are now automatically deduplicated.
- An aarch64 binary for Mac is now available Thanks to @fjsousa and @lispyclouds.
edamame: Configurable EDN/Clojure parser with location metadata
- A small bugfix release around reading malformed reader conditional expressions
lein-clj-kondo: a leiningen plugin for clj-kondo
- This plugin now follows the version number of clj-kondo
squint: CLJS syntax to JS compiler and cherry Experimental ClojureScript to ES6 module compiler
- Add defclass in squint, inspired by shadow-cljs
- More work on getting squint and cherry to work in one build
- Provide UMD build which works better in Firefox Webworkers
- cherry can now be used in a playground at livecodes.io
- Fix doseq and add doall and dorun in squint
lein2deps: leiningen to deps.edn converter
- Allow anonymous function literals in project.clj
babashka: native, fast starting Clojure interpreter for scripting.
- Version 1.3.182 released, mostly library bumps and small bugfixes. See changelogs here.
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- More robust handling of downloading and unzipping tools jar
scittle: Execute Clojure(Script) directly from browser script tags via SCI
- Fixed a small bug with evaluating tags: when there would be whitespace + a “src” attribute, the whitespace would be executed and the attribute was ignored.
tools-deps-native and tools.bbuild:
- This EXPERIMENTAL combo allows you to use tools.build from babashka. In this release a reflection issue was addressed.
nbb: Scripting in Clojure on Node.js using SCI
- Add missing function to promesa
jet: CLI to transform between JSON, EDN, YAML and Transit using Clojure
- Release version 0.7.27 (see changelogs) with missing 1.11 functions and options for easier kebab/camel/etc. casing.

Other projects:
These are (some of the) other projects I’m involved with but little activity in July. Click for more details:

SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Support :require-macros
- Introduce eval-string+ which received an optional initial :ns key and also returns the last active :ns so you can preserve the namespace state over multiple evaluations.
- Released v0.8.40
process: Clojure library for shelling out / spawning sub- processes
- Implement :out :bytes to receive output as bytes (thanks Hans Bugge Grathwohl)
- Make :dir option accept java.nio.file.Path
sci.configs: A collection of ready to be used SCI configs.
pod-babashka-go-sqlite3: A babashka pod for interacting with sqlite3
quickdoc: Quick and minimal API doc generation for Clojure
Published: 2023-08-02

August Updates

In August, my attention was mostly directed at the upcoming Strange loop talk. I’m very excited to be part of the last iteration of this conference. It will also be my first time flying to the USA!

Rahul De and Anupriya Johari will be giving a workshop at JavaZone on Tuesday the 5th of September. Check the details here.

Here are updates about the projects/libraries I’ve worked in August:

jet: CLI to transform between JSON, EDN, YAML and Transit using Clojure
- Release version 0.7.27 (see changelogs) with missing 1.11 functions and options for easier kebab/camel/etc. casing.
quickdoc: Quick and minimal API doc generation for Clojure
- No update in quickdoc, but happy to see that Github have resolved a bug on their side with local anchors in HTML, which quickdoc relies on
- Require clojure 1.11 as the minimal clojure version
sci.configs: A collection of ready to be used SCI configs.
- Worked together with @niwinz to make sci.configs upgradable to promesa 10 and 11. Many thanks to Andrey for making promesa backward-compatible again, since sci.configs relies on Clojure libraries to be always upgradable without breaking changes.
nbb: Scripting in Clojure on Node.js using SCI.
- Bumped sci.configs and promesa
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- The tools jar relocated to Github releases so deps.clj was updated to this new location, with backward compatibility.
- Per my request, Alex added a .sha256 file to Github releases so the downloaded jar file could be verified against corruption
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Clojure compatibility: allow (def foo/foo 1) in namespace foo
- Clojure compatibility: reset file metadata on var when it’s re-evaluated from other file
- Add sci.async/eval-form and sci.async/eval-form+
babashka: native, fast starting Clojure interpreter for scripting.
- expose sci.core in babashka
- Asahi linux support (linux on Apple m1/m2)
- Several other library upgrades and Clojure compatibility fixes
- Compatibility with the newest integrant version
pod-babashka-go-sqlite3: A babashka pod for interacting with sqlite3
- Upgrade sqlite version so it supports json fields
cherry
- Add defclass to cherry (similar to squint)
- Expose clojure.string and clojure.walk namespaces
- Fix overriding core vars
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- working towards a new release with a large number of small bug fixes, see upcoming changelog
http-client](https://github.com/babashka/http-client): babashka’s http-client
- A number of small bugfixes and additions

Other projects

These are (some of the) other projects I’m involved with but little to no activity happened in August. Click for more details.

pod-babashka-fswatcher: babashka filewatcher pod
edamame: Configurable EDN/Clojure parser with location metadata
lein-clj-kondo: a leiningen plugin for clj-kondo
squint: CLJS syntax to JS compiler and cherry Experimental ClojureScript to ES6 module compi
lein2deps: leiningen to deps.edn converter
scittle: Execute Clojure(Script) directly from browser script tags via SCI
tools-deps-native and tools.bbuild

Other projects

These are (some of the) other projects I’m involved with but with little or no activity in July and August. Click for more details.

sql pods: babashka pods for SQL databases
CLI: Turn Clojure functions into CLIs!
cljs-showcase: Showcase CLJS libs using SCI
fs - File system utility library for Clojure
process: Clojure library for shelling out / spawning sub-processes
babashka.book: Babashka manual
instaparse-bb
rewrite-clj: Rewrite Clojure code and edn
pod-babashka-buddy: A pod around buddy core (Cryptographic Api for Clojure).
gh-release-artifact: Upload artifacts to Github releases idempotently
neil: A CLI to add common aliases and features to deps.edn-based projects
carve - Remove unused Clojure vars
grasp: Grep Clojure code using clojure.spec regexes
quickblog: Light-weight static blog engine for Clojure and babashka
4ever-clojure - Pure CLJS version of 4clojure, meant to run forever!
pod-babashka-lanterna: Interact with clojure-lanterna from babashka
joyride: VSCode CLJS scripting and REPL (via SCI)
clj2el: transpile Clojure to elisp
deflet: make let-expressions REPL-friendly!
babashka.json: babashka JSON library/adapter
deps.add-lib: Clojure 1.12’s add-lib feature for leiningen and/or other environments without a specific version of the clojure CLI
Published: 2023-08-30

Tagged: clojure oss updates Discuss these posts here. To see previous posts go here.

Clojar-doc.org: Sean Corfield

In my previous Long-Term Funding update I said I would review/overhaul the “ecosystem” and “tutorials” sections.

On a personal note…

I ended the previous update with a personal note but I’m going to start this update with one. It’s been a very difficult couple of months. My mother passed away in early July (on my birthday!) and much of the month involved a lot of back and forth with the funeral home in England and family around the world. My wife & I attended the service via Zoom at the end of July and then it took some additional time to get the service booklet and recording distributed to family and friends.

Then in early August, both my wife and I got COVID-19 – after three and a half years of avoiding it, and having all our shots and boosters. My wife tested positive soon after symptoms started and got paxlovid. I had all the same symptoms too, but kept testing negative until I was outside the window for paxlovid – and then started testing positive. It took about two weeks for us both to test negative reliably. We’re both still recovering from the fatigue and brain fog but every day is an improvement. Wear your masks, folks, and get all your shots and boosters!

Consequently, I didn’t get as much done as I’d hoped in the past two months.

`clojure-doc.org`

I incorporated feedback from the community on the tools.build cookbook. Many thanks, in particular, to @phronmophobic who provided extensive feedback and Pull Requests!

I reviewed the “ecosystem” and “tutorials” sections but only so far as to remove outdated content. I reviewed and updated the main Content page to reflect the current state of the site, reordering sections and removing outdated content.

Feedback from the community suggested that I should review sections in a different order to my initial plan, so I turned my attention to the “language” section and updated the following pages from Clojure 1.5 to Clojure 1.11:

In some cases that just meant double-checking the code examples still worked as shown, but in other cases it meant updating the examples to use newer functions, adding new examples showing alternative approaches that are now possible, or changing the error messages shown to match the current behavior (since Clojure 1.10 did a lot to improve error messages).

I still need to make additional passes over several of these pages to address the remaining “TBD” items (mostly adding more examples).

HoneySQL

Several complicated changes were made to HoneySQL this period, leading to the 2.4.1066 release, which included the first pass at supporting temporal queries, and reworking how :insert-into, :columns, and :values work together which should make it easier to avoid generating invalid SQL as well as making it easier to extend HoneySQL to support additional features around INSERT statements.

Polylith

The Polylith project (and documentation) was still using my old (archived) build-clj wrapper so I worked on a Pull Request to switch everything to plain tools.build usage as a better example for the community. That has been merged in and updated documentation will be released soon (on cljdoc.org instead of GitBook!).

`clj-new`

This project also still used build-clj so I updated all the project templates to use tools.build directly and released version 1.2.404 so that, going forward, newly-generated projects will be better examples for the community. deps-new had previously been updated to generate projects using tools.build directly.

`clj-commons`

Information about CLJ Commons governance was spread across the clj-commons website and the meta repository’s README and other pages. Based on some community feedback in June, I wanted to consolidate that information and bring it up to date.

As I started on that, I realized that the clj-commons project list was very outdated so I decided to regenerate it (there’s a Clojure script for this). That uncovered a number of projects that were missing either the ORIGINATOR file in the root of the repo (how clj-commons identifies the original author of a project) or the .github/CODEOWNERS file that lists the current active maintainers.

I went through every clj-commons repo and added the missing files, updated the projects.clj script to support # comments in CODEOWNERS, and regenerated the projects.html page.

Finally, I consolidated and updated the information about how CLJ Commons accepts and maintains projects, and updated the README in the meta repo to reflect that this information is all on the main website now:

What’s Next?

In September/October, I’m hoping to complete a review and update of the “tutorials” and “ecosystem” sections of clojure-doc.org, and then in the remaining period, I’ll tackle the “cookbooks” section and make another pass of “TBD” items in the “language” section.

:tags “clojure” “clojure-doc.org” “honeysql” “clj-commons” “open source” “community” “clojurists together” “polylith”

Clojars: Toby Crawley

Commit Logs: clojars-web, infrastructure

I took this month to clean up some long-standing issues:

And a few quality-of-life improvements:

The CHANGELOG file also covers any user-facing changes.

Note: this report is also available on tcrawley.org

ClojureDart: Christophe Grande

ClojureDart

ClojureDart keeps to steadily get new users. We got featured on a Youtube channel for Flutter devs. Hopefully we increase the reach of Clojure both by allowing Clojurists to reach mobile/desktop but also by drawing more people to Clojure.

We are also glad to have received quality PRs adding missing functions or fixing divergences in the way things print.

We started working on a REPL (limited to Flutter apps for now), we expect to make it public in September.

The lack of multimethods begins to feel like a blocker for porting existing libs so it’s another tppic we should address in the next two months/

Last, we keep publishing short videos on Youtube https://www.youtube.com/@clojuredart/shorts and we also started a newsletter on ClojureDart and nerdy stuff.

Fixes

Several fixes to the compiler, cljd.core or flutter.cljd. Amongst them:

fix CI for Dart 2 which was broken by tests for records support (which are a Dart 3 feature)
allow destructuring in the arg list of protocol implementations
fix type-inference regression on a combination of if and recur
*-array* functions were not properly hinted
workaround for a Dart parser bug https://github.com/dart-lang/sdk/issues/52904
fix aliases in emitted code for when a protocol is extended from another namespace
fix hot reloading error when a protocol extension is removed – this issue and the previous one were triggered by the REPL work
make set! more robust (the implementation was a bit hacky and didn’t perform some checks)
rseq wasn’t behaving properly on vectors whose size was a multiple of 32
some code was improperly optimized away when a throw appeared in some nested ifs in statement position
widgets below a :vsync were not refresh on app state changes, only on animation updates
issues with set! expressions used in argument position
potential double evaluation when casting to a nullable type
…

Improvements

refactoring of the Subscribable protocol in cljd.flutter (breaking change but almost no users had implemented it) to simplify the handling of default values by pushing the responsibility to the consumer rather than to the producer.
support of namespaced maps in the reader (the cljd one used at runtime, not the clj one used to read source).
retriable/retry!: (retriable expr) behaves a bit like future, except that:
- its body is the one of a try, you can have catches and finally: (retriable expr (catch Object o st ...))
- it can be retried by calling retry! on it – returning a future which yields when the current retry is done (completed or failed). The intent is to allow to retry failed IO (or trigger refreshes) and be able to tie a spinner lifetime to the current try.
the compiler now watches for changes into :local/root deps to ease codevelopment of libs and apps.

Future Work

ClojureDart

Publish the Flutter-only REPL
Multi-methods to allow some libs to be ported
Look into porting Datascript and SCI to ClojureDart
New APIs to leverage our persistent data structures:
- maps (hash and sorted) in ClojureDart are original implementations (not the same as CLJ/CLJS)
  - hash maps could be seen as another refinement of the original, sorted maps constitute a novel implementation.
- Sorted colls should be good enough for direct use by Datascript.
- Both hash and sorted maps can support accelerated merge/diff/join/etc. operations.
cljd CLI written in cljd for easier project creation etc.
gen tests
…

Clojure-lsp: Eric Dallo

During this year I’ve been working on clojure-lsp support for IntelliJ, it was the only mainstream editor that didn’t have a good way to use clojure-lsp features, it was really hard to integrate with the LSP protocol because of Intellij’s API but making the plugin in Clojure helped a little bit with that, so after a lot of work, I’m excited and happy to announce clojure-lsp-intellij, a new plugin for IntelliJ to have all clojure-lsp features available!

clojure-lsp-intellij

0.1.0 - 0.9.0

Avoid noisy exception after startup
Add textDocument/codeAction support. #3
Add support for refactorings via workspace/executeCommand. #4
Add support for textDocument/rename feature. #6
Add support for workspace/applyEdit. #7
Add support for LSP notification window/showMessage and request window/showMessageRequest.
Improve status bar to show icon instead of text.
Add troubleshooting section to ‘Tools > Clojure LSP’
Add brace matcher for [], {} and ()
Fix completion of items with /
Add support for comments.
Add support for quote handlers.
Add support for completion. #2
Support find defintion of external dependencies. #1
Fix LSP startup messages to properly mention the task being done
Require plugin restart after install because of Clojure load in Classloader.
Support more intellij versions until 2021.3
Improvements to plugin compatibility
Support initialize and subsequent requests.
Support textDocument/didChange, textDocument/didClose, textDocument/didOpen.
Support textDocument/hover.
Support textDocument/references.
Support textDocument/formatting.
Support textDocument/codeLens and codeLens/resolve.
Add status bar with support for restarting server.

clojure-lsp

The main highlight are performance and memory improvement, also we had formatting improvements to match latest cljfmt features.

2023.08.06-00.28.06

General

Fix truncation of namespaced keywords #1640
Add rewrite-clj node to cursor-info. - Fixing semantic-tokens, collons not managed by lsp anymore. #1550
Fix :paths-ignore-regex setting to consider settings reload
Bump clj-kondo to 2023.07.14-20230717.090255-3. #1624
Fix inconsistencies with :defined-by->lint-as
Improve memory usage during cache save, avoiding “Out of memory” exceptions.
Prevent file rename when a namespace is defined in multiple files #1574
Fix user formatting setting being override by :style/indent metadata in macros
Bump cljfmt to 0.11.2. #1634
Bump lsp4clj to 1.8.1

Editor

Avoid returning all known keywords on empty keywords completion for performance reasons.

API/CLI

Improve mem/cpu usage using less analysis for tasks.

Humble UI: Nikita Prokopov

Last two months have been DataScript-focused. I’ve implemented a major new feature: pluggable durable storages. I’ve also wrote SQL adapter for them and migrated Grumpy Website to DataScript + SQLite to battle-test the implementation.

It has been working well so far (~2 weeks, lots of updates).

DataScript:**

New incremental/lazy storage implementation. Store large databases on disk/in other DBs efficiently, load back only the parts you actually use, all completely transparent for user. It even has docs!
New SQL storage implementations, supporting MySQL, PostgreSQL, H2 and SQLite.
Schema altering (compatible changes only) via d/reset-schema! or d/with-schema
JVM: branching-factor can now be set per-database
New API: d/find-datom. Works like d/datoms, but only returns single datom and is faster than (first (d/datoms ...))
CLJS: Optimized various parts of CLJS version related to compilation and index access
Do not throw from d/touch when finding hanging refs

Grumpy Website:**

Migrate from storing posts in EDN to storing them in DataScript + persist in SQLite storage
Battle-test DataScript storage
Migrate from Component to Mount
Implement full-text search, powered by Lucene
Cross-post to Mastodon
Highlight mentions and tags in posts
Pagination, suggest, subscribe and about pages
Accumulate and render statistics

Skija:

Catch up with current Skia version (m109 → m116, ~year of updates)
Extract library file atomically #54 #56 w/ @dzaima

Humble UI:

OkLCH example
Fixed NPE in text-field undo #80
Non-macos Ctrl + X/C/V/Y #81

Sublime-Executor:

Kill running process on Sublime exit
Strip away escape sequences from output
Better gitignore matching
Allow running any command on top of another one, implicitly killing previous one

Clojure Sublimed:

Show file/line/column information when clojure_sublimed_eval_code fails

New project — Dark Mode Toggle:

A simple menubar utility to quickly switch between dark and light modes

Malli: Tommi Reiman

I was off the grid on July, back to OS on August.

Malli

Continued with the new effective type system - WIP
Small fixes and reviews and released 0.12.0:

0.12.0 (2023-08-31)

FIX: retain order with :catn unparse, fixes #925
BREAKING: Do not require timezone data directly for cljs #898 with malli.experimental.time
Remove non-root swagger definitions #900
FIX: malli.core/-comp keeps interceptor order with long chains #905
FIX: malli.dev/start! exception does not contain source #896
FIX: don’t add extra :schema nil to swagger :parameters #939
Add :gen/return support in malli.generator #933
Make uuid transformer to be case insensitive #929
Add :default/fn prop for default-value-transformer #927
Updated dependencies:

borkdude/edamame 1.3.20 -> 1.3.23

Reitit

OpenApi3-support ended to be a a much bigger change than anticipated, still alpha
Got the big refactor done
Paired with Joel on remaining issues & reviewed lot of issues, soon….

Spec-tools

First new release in 30 months! 0.10.6

Something else

The coffee store is closed-look

Shadow-cljs: Thomas Heller

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (eg. Clojurians Slack).

Current shadow-cljs version: 2.52.3 Changelog

Blog Posts

Wrote a blog series about CLJS Frontend development alternatives to full Single Page Apps.

Notable Updates

Replaced the babel-js based ES Module -> CommonJS rewriter, which is used for ESM based npm modules. This had been planned for a long time and was the only remaining part of shadow-cljs that actually required node at runtime. Now this is done entirely within the JVM, which as a side benefit got a bit faster. The old behavior is still available in case problems arise, but will be removed in the future.

August 2023 Short Term Project Updates

Sat, 02 Sep 2023 08:30:00 +0800

Check out the latest from the shorter term projects we funded in Q1 and Q2 2023 and Q3 2022. We’ve got updates from Christian Johansen, Daniel Higginbotham, Danius Jocas, Dragan Duric, Jeaye Wilkerson, José Luis Lafuente Esquembre, Kira McLean, and Matthew Davidson.

A quick reminder to seriously consider volunteering for a 2-year term on our board. We have 4 positions opening up this year. The deadline for submitting your name is Sept. 15. You can help us to support all the great work underway and continue to get the word out about the Clojurists Together funding opportunities and our awesome community. Find more information here.

Aleph Manifold: Matthew Davidson
clj-Nix: José Luis Lafuente Esquembre
Clojure Camp: Daniel Higginbotham
Clojure Cookbook: Kira McLean
Donut: Daniel Higginbotham
Jank: Jeaye Wilkerson
Lucene Grep: Dainius Jocas
Neanderthal: Dragan Duric
Portfolio: Christian Johansen

Aleph Manifold: Matthew Davidson

Project Update: 31 August 2023
Q1 2023 Funding Round: Report 3

HTTP/2 – server

Final HTTP/2 support on the server is now under review. The code is written, but the existing test suite is fragile and specific to the HTTP/1 code, so many tests still need updating.
Highlights
- Massive refactoring and documentation improvements
- HTTP/1 code adapted for independent HTTP/2 multiplexed streams
  - Much simplified core
    - prior connection state no longer required since streams are independent
    - client and server streams now similar enough that more code can be shared between them, unlike the HTTP/1 code
- Application-level protocol negotiation (ALPN) now the default for all servers
  - specify which HTTP versions you support, and the server will pick as needed for incoming connections
  - falls back to HTTP/1 if needed
- Cleartext H2C supported on the server
- Header and date code in hot loop (used literally every response) now optimized
  - Upgraded deps to Netty 4.1.96.Final, byte-streams 0.3.4

Other Aleph improvements

Added instructions to CONTRIBUTING on SSL/TLS certs and CA setup and debugging, which are vital for HTTP/2 work

Planned future work

Straighten out the tests
Add compression support
Add more handler options for settings and window updates
Add multipart support
- HTTP/2 doesn’t need it, and unfortunately, Netty’s HTTP2 code doesn’t support it, but some people said they’d like to keep using it to minimize disruption to their code base
Add proxy support

Potential new directions

HTTP/3
- Should be relatively easy (🤞), since the gap between HTTP/2 and 3 is much smaller than between 1 and 2. Would mostly need to handle the switch to QUIC/UDP.
Flow control
- HTTP/2’s flow control mechanism was deprecated for complexity and disagreement between browsers, but not actually removed. We could add code to support this if people really wanted it. A better option would be to support HTTP/3’s new flow control headers.

clj-Nix: José Luis Lafuente Esquembre

Project Update: 30 August 2023
Q2 2023 Funding Round: Report 2

In the second half of this funding round, I worked on making the project more user-friendly.

New documentation

I created a new website for the documentation: https://jlesquembre.github.io/clj-nix/

New nix module

I added the possibility of configuring the build using a nix module, see clj-nix Module.

The nix module is marked as experimental, but usable. It’s the way I recommend using clj-nix, since it hides the project internals. If you already are a clj-nix user, you can continue calling mkCljBin and related functions. Under the hood, the module calls those functions, and I’ll continue maintaining the functional API.

I’ll continue working on the module interface, feel free to open an issue on GitHub to share any feedback.

Maintenance

I also spent some time fixing some bugs and doing some minor improvements, see the full list on GitHub

Clojure Camp: Daniel Higginbotham

Project Update: 31 July 2023
Q2 2023 Funding Round: Report 2

At Clojure Camp we continue to build our materials for mentors and students and to hold a study group. We’ve also begun reaching out to industry stakeholders and mentors to shape a long-term roadmap for this effort that increases the likelihood that participants will be able to find paid work.

Accomplishments include:

Continuing weekly study group sessions
Building out https://currmap.clojure.camp/, a clear path for learning Clojure
Made more progress on setting up our operations
Started industry outreach, looking for partners that can help on both the jobs side and on the marketing side

Clojure Cookbook: Kira McLean

Project Updates: 1 June and 2 September 2023
Q3 2022 Funding Round: Reports 2 & 3

Report 2: The last few months of development on the Clojure Data Cookbook have been focused on filling out the main reasons for the book, which have been translated in to some of the introductory chapters, as well as implementing more of the examples that are the core of the book. Whilst development has been slower than I would like due to the nature of being an adult with a hectic life, I’m excited about the progress that’s been made and look forward to polishing the first three chapters over the summer. Some specific work that’s been done in this last phase includes:

Sub-chapters 2.2 and 2.3 have been filled out more, along with more of the introductory part of the book. Examples for working with different types of databases are implemented as well as ones for exporting data from a notebook. Commits including this output are available on github.
Much effort has gone into coming to a consensus within the community around what default data science “stack” to implicitly endorse by its inclusion and usage in the book. We’ve settled on tablecloth for tabular data processing, Hanami for data visualisation, Neanderthal for math, along with several other libraries that are emerging as the “standard” ones for certain tasks working with data in Clojure.
This, and much of the thought that went into the introductory chapters, was mostly what formed the core of the talk I gave at the conj this year. More of the libraries that will be used are on slide 6 in the talk.
An initial solution for publishing the book online has been implemented. I’ll want to improve the process as updates are published more regularly, but for now a basic skeleton of the book website is available online here: https://scicloj.github.io/clojure-data-cookbook/ (URL is likely to change for the final version, this one should work from June 1, 2023 for at least few months.)

Report 3: In the last couple of months I’ve made progress toward completing the contents of the cookbook, but I’ve had to admit to myself that I took on more than I could realistically do in my spare time. Despite my best efforts there is still much work to be done compiling the book into a consumable format.

I will continue this work indefinitely and still plan on finishing this project, but the demands of work and other commitments on my time have meant that progress is slower than I would have hoped on this side project.

For now, the information is mostly complete and, with help from the community, best practices for performing a variety of data manipulation and analysis tasks are now documented in the cookbook repo. These are not filled in yet with prose or detailed explanations and not organized in a way that would be ideal to consume for someone who wasn’t already comfortable navigating a Clojure codebase. But progress has definitely been made. The contents of the first three chapters are ready to be edited into a consumable format – the examples are written, the code works, and the steps are documented. The next task on my list is organizing all of the code into sensible sections with explainer text surrounding them so that the book can be published somewhere online.

Donut: Daniel Higginbotham

Project Update: 6 August 2023
Q1 2023 Funding Round: Report 3

Since the last update I’ve made progress on creating an auth plugin. There are implementations in place for cookie-based auth and a Sign In With Google button. The next step is to abstract these for more general usage.
Per-repo changes include:

donut-party/endpoint

Re-worked the implementation of ring middleware I had been using the ring-defaults library to compose a foundational middleware stack but I found it too difficult to debug. The middleware are all configured as donut components so that it’s easier to inspect what middleware are being used and what their configurations are, and so that there’s a consistent interfact for changing middleware options.
Cookie session store component Added a donut component that lets you configure a cookie session store

donut-party/email

A new library that provides a helper for constructing emails independent of whatever email service you use. Features include:

Use text and HTML email templates for email body
Use text template for email subject
Set global options (like :from) and easily override those options
Parameterizes the email sending function so you can replace it with a mock in tests
Parameterizes template rendering function so you can use something other than selmer if you want

donut-party/frontend

Added load-script helper function for asynchronously loading js scripts
Updated form handling so that you can set initial form values adjacent to the form’s components, as opposed to having to set the values via a re-frame dispatch
Handle auth and identity concerns
Created a frontend route writer, compiling frontend routes to a cljc file so that the backend can access the routes

donut-party/system

Introduced registry refs. This allows components to refer to each other using a registry name, as opposed to an absolute path in the system. Useful for plugin development.
Added a mock-component helper which can be used to mock function components. In cases where your component initializes to a function (e.g. send-email), you can now easily mock those components for tests. The mock function records arguments for test comparisons, and you can set the value it should return.

I appreciate the support of Clojurists Together and the donut community!

Jank: Jeaye Wilkerson

Project Update: 26 August 2023
Q2 2023 Funding Round: Report 2

The terms of this work were to research a new object model for jank, with the goal of optimizing allocations, while also making jank code faster across the board. This is my second and final report and I’m excited to share my results!

Please note that I have a very detailed breakdown of my results, with several more graphs, here: https://jank-lang.org/blog/2023-08-26-object-model/

To briefly summarize, this quarter I:

Prototyped a new object model for jank
Ported the whole jank compiler and runtime to the new object model
Benchmarked thoroughly and continuously

Overall ray tracing speeds

I’m very pleased to report that jank is now nearly twice as fast at running the same ray tracing code as Clojure JVM, with jank clocking in at 36.96ms versus Clojure’s 69.44ms. Since jank was only marginally faster than Clojure at the start of the quarter, this also means the improvements in the past quarter have been nearly 2x overall.

Other runtime objects

Maps, vectors, and strings have all seen performance improvements to both allocations and usage. Some improvements were marginal, while others were in the 2x region. My full post linked above goes more into detail and talks about potential future gains.

Fast math

Math has sped up the most out of anything, which bodes very well for our ray tracing numbers. Here are the results for fully boxed subtraction, where no type info is known, subtraction between an unknown box and an unboxed double, and fully unboxed subtraction. In all cases, jank is now significantly faster than Clojure JVM. These wins apply across the board for all binary math operations.

Thank you!

Thank you, Clojurists Together, for sponsoring this work. jank has climbed quite the mountain of performance gains to now challenge the JVM in these benchmarks.

This is the last performance-oriented bout of work for a while. jank is where it needs to be, I think, in order for me to start investing more in pushing the compiler and runtime features closer to parity with Clojure JVM.

I’m very happy to know that Clojurists Together is sponsoring jank development again, for the upcoming quarter. The sponsored work will be focused on building out jank’s module system, implementing clojure.core/require, preparing for iterative compilation, and setting the stage for AOT compilation and leiningen integration.

After this work, using jank for multi-file projects will be possible. Soon after that, I hope, we can start using leiningen to manage jank projects. This will mean adventurous devs can start actually using jank themselves, which I expect will only add to the momentum I currently have.

Lucene Grep: Dainius Jocas

Project Update: 1 September 2023
Q2 2023 Funding Round: Report 2

The highlight of this update is the release of the lucene-monitor Clojure library.

lucene-monitor is a Clojure wrapper around the Apache Lucene Monitor framework. I’ve tried to make the library simple to get started and flexible when needed. lucene-monitor provides a pretty tasty data-driven API and, given my recent interest in Clojure transducers, a transducer compatible API. Check it out and let me know what you think!

Updates

As of now, 4 Clojure libraries are extracted out of the lucene-grep:

lucene-monitor: a wrapper for the Lucene Monitor framework;
lucene-custom-analyzer: data-driven builder for Lucene Analyzers;
lucene-query-parsing: data-driven builder of Lucene Query Parsers;
lucene-text-analysis: helpers to experiment with the Lucene Analyzers.

All these libraries were updated to the newest Lucene version.

Other things I’ve worked on:

Lucene Grep

The lucene-grep was updated and released with these improvements:

Lucene 9.7.0;
The prepared Lucene Analyzers can now be added and loaded via SPI.

Also, I’ve experimented with Apache OpenNLP integration into the lucene-grep. So far I don’t know whether to include new dependencies by default, because it makes the binary bigger, compile times longer, and the lucene-opennlp includes a pretty outdated version of the OpenNLP library.

Lucene in Vespa.ai

I’ve contributed a Lucene Linguistics component to Vespa.ai. This is not strictly based on lucene-grep or related to Clojure (maybe it is possible to start a REPL in Vespa container nodes after all?) but the work is heavily inspired by lucene-custom-analyzer library (and learnings while making it) which was extracted from the lucene-grep. Sample apps with the Lucene Linguistics component are coming hopefully soon. The component should make the transition from Lucene based search engines like Elasticsearch to Vespa almost a mechanical task. I encourage anyone interested in search, recommendation systems, or information retrieval in general, to give Vespa.ai a try. it is great!

What is next?

Even though the sponsorship from Clojurist Together is over I’m planning to have more fun with Clojure and Lucene:

I’ll try to integrate the extracted libraries to other Clojure projects that depend on Lucene.
Build a demo of an Elasticsearch-Percolator-like system that does monitoring in a scalable and distributed mode.
A blog post on using the shiny new Word2VecSynonymFilter from Clojure.

Neanderthal: Dragan Duric

Project Update: 31 July and 31 August 2023
Q2 2023 Funding Round: Reports 2 and 3

Report 2: My goal with this round is to port Neanderthal, ClojureCUDA, and Deep Diamond to JavaCPP-based native libraries.

This second month was dedicated to porting the CPU data structures and engines from DirectByteBuffer-based custom C bindings (Neanderthal Native) to JavaCPP-based MKL bindings. I managed to port all structures and engines, and make all related tests pass. I also hoped to do the CUDA engines and data structures to JavaCPP from the old JCUDA bindings, but I’m late on that. It’s something that I hope to do in the first half of the third month.

Of course, that wasn’t a straight port. On one hand, I had to make internal changes and adaptations to support JavaCPP’s way of doing things. On the other hand, I used this as an opportunity to explore avenues to decrease the code size through more macrology and to push more intensely towards “don’t repeat yourself” style. It’s a double-edged sword, I know, but MKL and other similar APIs are massive, and I am a sole person who has to support all these exotic obscure functionalities…

Next month will be dedicated to porting Neanderthal’s CUDA backend to use JavaCPP (via ClojureCPP).

All in all, I feel that the project is still on track even though I would have liked to achieve more in the first two months, but it is what it is. I still think I’ll be able to port ClojureCUDA, Neanderthal, and Deep Diamond to ClojureCPP by the end of the third month, or at least everything except Deep Diamond.

What’s equally important, I’m using every opportunity to improve everything that I could, instead of just taking the shortest cut at every corner. So the benefits will be felt long-term in these libraries, as well as this domain in Clojure.

I released most of the resulting code in a couple of gigantic commits instead of many smaller ones because I didn’t want any release to contain a completely broken library.

Report 3: My goal with this round was to port Neanderthal, ClojureCUDA, and Deep Diamond to JavaCPP-based native libraries.

More specifically, I proposed to implement:

a port of Neanderthal’s MKL engines and CPU related stuff to JavaCPP instead of neanderthal-native (for sure).
a port of ClojureCUDA to JavaCPP’s CUDA. (probably, depending how 1 goes)
a port of Neanderthal’s GPU matrix engine to new, JavaCPP-based ClojureCUDA (almost sure, if ClojureCUDA port goes well)
update Deep Diamond to use new infrastructure.
improve relevant internal parts of Neanderthal code with more macrology (double-edged sword, I know, but also concentrates bugs at one place each).
TESTS! to make sure everything works as well as before (of course!)

In the third month, I continued with porting the Neanderthal’s CUDA engine. This wasn’t without challenges, but, surprisingly, it went well after all. After this, I hoped that Deep Diamond’s port would be a bit easier, since a lot of internal details are behind the Neanderthal’s and ClojureCUDA’s API. However, for proper MKL API support in JavaCPP I had to use the very latest 1.5.10 snapshots. These snapshots then mandate DNNL (Intel’s tensor and DL library) upgrade to 3.2 (from the 2.7 that was used in Deep Diamond previously). Alas, Intel introduced many breaking changes in the API and implementation, so I have to play the good old discover-how-it-works-by-poking-around, and do the full blown re-implementation of DNNL API internal support in Deep Diamond, instead of just porting a few internals to JavaCPP’s way of doing things. I’ve started doing that, and as of this writing, I’ve discovered how to solve most tricky changes, and I am in the middle of switching the internal/dnnl part of Deep Diamond.

More specifically, here’s the status by the proposed bullet points:

DONE: a port of Neanderthal’s MKL engines and CPU related stuff to JavaCPP instead of neanderthal-native (for sure).
DONE: a port of ClojureCUDA to JavaCPP’s CUDA. (probably, depending how 1 goes)
DONE: a port of Neanderthal’s GPU matrix engine to new, JavaCPP-based ClojureCUDA (almost sure, if ClojureCUDA port goes well)
PARTIAL (in progress): update Deep Diamond to use new infrastructure.
DONE: improve relevant internal parts of Neanderthal code with more macrology (double-edged sword, I know, but also concentrates bugs at one place each).
DONE (but of course, this is something that is ongoing anyway): TESTS! to make sure everything works as well as before (of course!)

In short, although I haven’t managed to do everything that I hoped I will, I’m satisfied since I’ve done the major parts, and the unexpected DNNL upgrade would have to be done anyway eventually.

As I’ve been lucky to be granted one more CT funding round, which is centered on improving the overall quality of Uncomplicate libraries, upgrading the Deep Diamond support for DNNL and new CUDA infrastructure would fit well with the tasks that I’m planning to do in the Q3 round anyway, so I expect that by the end of it I’d be very satisfied with the result.

Portfolio: Christian Johansen

Project Update: 31 August 2023
Q2 2023 Funding Round: Report 2

In the second half of the Q2 funding period I have worked on the plugin capabilities in Portfolio, the new accessibility plugin, and barked up some wrong trees in an attempt at fixing a tricky problem 😅

Plugins can now inject JavaScripts into the iframe document where Portfolio renders your “scenes” (your component examples). In order for these scripts to be able to do something useful, Portfolio will use window.postMessage to announce when components have been rendered, and listen for commands via the same channel - allowing custom scripts to interact with Portfolio’s data storage (and, by extension render interesting things in its UI).

I built a new accessibility extension on top of the new capabilities. It uses axe-core to assess your components. Validation can be switched on and off in the UI (or completely disabled in code). When on, components will be assessed as you navigate through them. There is also a global option to assess all components and have results highlighted in the left-hand menu, which should make it easier to track down non-conforming components.

The accessibility feature isn’t quite ready yet, but I’m expecting to release it in September. As for my barking at trees, I have tried to solve an outstanding issue in Portfolio’s rendering. Portfolio invokes components in the main process, then renders the result in an iframed document. This breaks down for components that are side-effects, such as some solutions for CSS-in-CLJS (which stick style tags in ). I have tried to a few ways to solve this in a way that supports the current API, but all of them have had worse side-effects than the current situation, so I have put this issue on the back-burner.

Once again thank you so much for the support. Portfolio is a much better tool thanks to it.

2023 Board Nominations and Our Annual Meeting

Thu, 24 Aug 2023 08:30:00 +0800

Clojurists Together is having our third board elections, and our third annual members meeting.

Key dates

(All dates are EOD, in Pacific Time)

Board nominations close: Sept. 15, 2023
Voting opens: a few days after submissions close and the board has nominated candidates
Voting closes: October 7, 2023
Annual members meeting: Oct. 10, 2023 - 10 am Pacific time

Board Elections

Committee members are elected for a two-year term. Each election cycle, half of our board seats come up for re-election. This year there are four seats available.

If you are interested in standing for election, please fill out this form by Sept. 15th, 2023 - 5 pm Pacific Time. If you can’t access the form, contact us, and we can accept your nomination by email. Nominations are open to anyone, you don’t have to be a Clojurists Together member to stand for election. Our bylaws do require you to be a member if elected to the board, though we provide a stipend that offsets the cost of your membership.

As part of the nomination, if we get more than 12 candidates for board membership, the board will nominate no more than 12 candidates. Our bylaws state:

The Board shall nominate no more than 12 candidates seeking board membership in any given election. In nominating candidates for Director positions and in choosing the number of candidates to nominate overall, the Board shall use reasonable efforts to maintain a Board composition consisting of at least: (1) 25% female Directors, (2) 25% non-Caucasian Directors, and (3) 35% from any category(ies) of persons (e.g., race, gender, ability) commonly considered to have suffered from discrimination at some time and then-currently under-represented in the technology industry, in each case as determined by the Board in its reasonable discretion.

The main responsibilities of a committee member are:

Participate in the general discussions of the month-to-month running of the program
Evaluate and vote on which open source projects to fund
Help in decision-making for the future plans of Clojurists Together
These responsibilities take roughly one hour/month, though there are peaks and troughs of activity as we go through our quarterly funding cycle. If you have more time to offer, there are lots more things that need developing, automating, designing, e.t.c. It would be great to have you help out with those things, but we don’t want to exclude people from standing because they don’t have a lot of spare time.

Elections will be held once the candidates are announced, and all Clojurists Together members will be eligible to vote.

Annual Members Meeting

We are also holding our third members meeting at 10 am Pacific time, October 10, 2023. This will be an opportunity for Clojurists Together to share information about 2023 to date and discuss future plans, present the new board members, and most importantly take questions from and engage with members.

More details on this will follow including a videoconferencing link.

Q3 2023 Funding Announcement

Thu, 17 Aug 2023 08:30:00 +0800

Hi folks. We’re excited to announce the projects we’ll be funding for Q3 2023. (8 projects $44K USD in total). As usual, there were a lot of great project proposals - so making a decision was not easy.

The good news, however, is that proposals are automatically reconsidered for the next 2 cycles. We have supported many projects in the past that were funded in the 2nd or even 3rd review.

Thanks to everyone for your hard work and creativity in putting these proposals together - this is the kind of thinking and sharing that makes the Clojurist Together community so awesome!

Projects Awarded $9K USD

Bosquet: Zygis Medelis
Emmy: Sam Ritchie
Neanderthal, Diamond, ClojureCUDA, ClojureCL, ClojureCPP: Dragan Djuric
Quil: Jack Rusher and Charles Comstock

Projects Awarded $2K USD

Biff: Jacob O’Bryant
Deps-try: Gert Goet
GDL: Michael Sappler
Jank: Jeaye Wilkerson

LARGER PROJECTS AWARDED $9K USD

Bosquet: Zygis Medelis

Bosquet’s goal is to make AI/LLM-based application building simple and productive. There are many types of AI applications and equally many approaches to building them. The scope of this work is to expand AI agent-based architecture support in Bosquet.

Main tasks:

Input/output specs. Agents are functions with specific inputs and outputs. Add LLM input/output specification and coercion inspired by or using Malli/Clojure spec.
Agents and Tools. Expand on initial LLM Agent support. More agent types, more out-of-the-box tools. The best outcome would be a clear architecture and infrastructure for users to add any type of agents and tools. Thus adding new tools and agent types is guided not by the blind expansion of supported integrations but by the illustration of different modes and aspects of agent applications.
Memory. Without LLM memory, any larger processing tasks would be impossible to achieve. Vector DB (or other types of memory implementation) support is essential to add.

When implementing the above, the growing scope of work should not reduce the library’s usability. Documentation, Clerk notebooks, examples, and sound architecture are to take priority over adding functionality.

Emmy: Sam Ritchie

Last quarter’s funding enabled me to build out a suite of visualization tools powered by Emmy’s mathematical functions, shipped in the Emmy-Viewers library. Emmy is now powerful enough to back a math and physics curriculum up through the college level; the only other Web-enabled system with this ability is Mathematica, with a $3,000 price tag and many restrictions.

The next step is to build out a community of learning and growth around these ideas, so that we can get kids and classrooms excited and using Clojure as the foundation of their journeys through math and physics.

This quarter, I want to build out a collaborative experience for all of this math visualization tooling. I want a Google Docs-style experience for interactive documents with sophisticated mathematical visualizations, where multiple users can work together on the same page, save and share the work they’ve created and build on existing mathematical play and exploration. The system should allow for programmable side-notes, with access to the same computing environment that the original author had. This same mechanic could power an “executable Wikipedia”, a wiki-style editable environment where pages contained running code and felt more like namespaces.

Research groups like Ink&Switch have done amazing work (https://www.inkandswitch.com/upwelling/, https://www.inkandswitch.com/peritext/) building out the technology to power an experience like this. We have glimmers of the final product with Clerk and Maria, but the final push will take some work.

Neanderthal: Dragan Djuric

My goal with this round is to polish the Uncomplicate libraries (mainly Neanderthal, Deep Diamond, ClojureCUDA, ClojureCL, ClojureCPP), rather than develop new functionality.

Uncomplicate libraries include several infrastructure libraries for high-performance computing, AI, Deep Learning, Math, statistics, data science, etc. Over the years, they grow to be really large. Although they contain orders of magnitude fewer lines of code than the equivalent Python or Java libraries, they cumulatively have 40.000 lines of highly dense Clojure code, especially Neanderthal, which clocks at around 25.000.

Over the years, I managed to do improve these libraries constantly, including several large refactorings, without breaking backwards compatibility of public-facing API. This was possible in part due to Clojure’s awesomeness, but also due to the many thousand of automatic tests that I’ve developed, and my constant insistence on fixing code issues before they become forgotten hard-to-trace bugs.

However, as the number of features grows, the proportion of hard-to-reach branches in edge cases grows. They hide cases that I didn’t have time to cover with automatic tests. They might have been tested once upon a time, but do they still hold after the major ports? I hope they do, but it’s impossible to never introduce a slight coding mistake, especially when porting a thousand lines of code to new backends.

In addition to this, there are parts of public API that might have stale documentation (Neanderthal), or without proper docstrings (parts of Deep Diamond). I just didn’t have the time and resources to dedicate enough time to this. But it’s something that users see every day, and it needs improvement!

In short, I propose to:

Do a thorough re-visiting of existing code in major Uncomplicate libraries.
Read the code without rushing to implement new features.
Write more tests for edge cases.
Discover bugs and fix them.
Discover places where code could be improved (without rushing the new functionality).
Re-visit documentation and improve it to better match the current state of Uncomplicate libraries.
If opportunities arise, implement some new functionality based of all the aforementioned items.

In even shorter terms, I propose to do some hammock time, combined with some unexciting chores that enhance the stability and user-friendliness of Uncomplicate libraries.

Quil: Jack Rusher and Charles Comstock

Quil is a wrapper around the Processing computer graphics system that’s used by artists and teachers around the world. It has been moribund for the last several years, does not work with the latest version of Processing, nor on JVMs >1.8, nor on Apple arm processors. We would like to fix all of that, improve the quality of the codebase (maintainability, testing, &c), and update the examples/playground website. Ultimately, we would also like to train some more junior people to help maintain the project going forward.

Why is this project important to the Clojure community? Quil is often used to teach beginners, rapidly prototype visualizations and GUIs, produce art and design artifacts, &c. It has been an important part of the Clojure ecosystem since Sam Aaron created it 10+ years ago.

EXPERIMENTAL OR SHORT-TERM PROJECTS AWARDED $2K USD

Biff: Jacob O’Bryant

I’d like to:

Write a bunch of how-to articles
Write some essays/background info
Start writing “Biff from scratch,” a series of guides that will show you how to put together a web app in the style of Biff without actually using any Biff code

Along the way I’ll be reading up on SEO, posting things to Hacker News, and thinking about what content topics might be helpful for a non-Clojure audience. I want to use Biff to bring more people into the Clojure community.

For the specific content I have planned, see the Roadmap section of Biff’s content library which I’ll be keeping up-to-date. I’ll only be able to get to a fraction of those within the funding timeframe, and I’m sure the list will change as I go. So if any of those topics catch your eye, let me know so I can prioritize them.

Why is this project important to the Clojure community?
Biff has been slowly gaining traction; currently, the #biff channel on Clojurians gets about 15 unique participants per month, trending upward (https://cdn.findka.com/biff/slack-participants.png). More importantly, I think there’s a real opportunity for Biff to drive growth for the Clojure community as a beginner-friendly, comprehensive web framework.

Deps-try: Gert Goet

The plan is to add a possibility to deps-try (a CLI to start a rebel-readline powered REPL with libraries you want to try) to load recipes. A recipe (i.e. a local or remote Clojure file) essentially seeds the REPL-history which would make it easy for someone to ‘step through’ some code. E.g. library authors could add such a recipe-file to their repositories to demonstrate how to use a library.

Why is this project important to the Clojure community? lein-try was what got me into programming Clojure: no distraction from setting up/learning a new editor, but just fire up a REPL with some specific libraries and try out snippets from the Clojure cookbook.

I thought it was valuable to have this for tools-deps as well (using rebel-readline for user-friendliness) and launched deps-try almost 5 years ago.

As an experienced Clojure developer, I still fire up deps-try whenever I run into a new library (not in the least a new Clojure alpha version) and I want to quickly try it out. After 3 years since the last commit, I recently started hammocking and coding what a new version would look like.

GDL Michael Sappler

My proposal is to connect two things that are not connected yet - game development and clojure.

I believe it is possible to achieve a new generation, a new dimension of games written in an evolving language and in an open manner. Games need to grow and breathe. The most successful games were games with lots of mods.

I believe Clojure can have some advantages over the traditional way of creating games: functional programming, but also embracing state and being practical, macros which can make the language evolve.

My original proposal was one project gdx. Since then I have created 3 public repositories in GitHub:

x.x is probably the most useful invention, it is an entity component system using just plain maps and multimethods.
The other is now GDL and not gdx which should mean game development language. Till now it is just a helper/wrapper around libgdx.
And the third project from which everything came is cyber Dungeon Quest.

Right now there is not much to the game in terms of content (although much more is not shown). I am working on all 3 projects at once and trying to find the most simple and effective way to organise game code. Cyber Dungeon Quest is around 8500 lines of code and it was 10K a few months ago and I just focused only on cleaning the code and understanding the best way to do things.

More information can be found on my GitHub.

My near-term goals are to integrate the component system in cyber Dungeon Quest and make all the hard-coded values configurable and save most of the game state in only one place, and then build a ui to easily edit the domain objects. Next is to find a way to reduce the amount of Side effects by using some kind of transaction system that is close in spirit to datomic architecture. I am not sure yet if I can directly use datomic for performance reasons, but it would make a lot of things quite easy like replays, timetravel, networking etc. I am not fixing myself too much and see where the project grows. In this manner, in the last months I have made amazing discoveries, mostly with x.x ECS and have been led to interesting places.

Jank: Jeaye Wilkerson

The next big step of jank entails implementing clojure.core/require and everything involved. Right now, jank compiles everything from one file (and re-compiles clojure.core every time it starts); the runtime/compiler understand namespaces, but there is no compilation cache, no class paths for looking up modules, no dependency loading, etc.

Implementing require would involve these broad strokes (IN SCOPE):

Adding a notion of class paths to the compiler in a Clojure-compatible way
Adding the necessary load-libs, load-lib, load-one, load-all, etc
Generating the equivalent of class files, for jank, when loading files
Iteratively compiling, based on cached files
Support for :reload and :reload-all code paths
Pre-compiling clojure.core, which will greatly speed up start times
Testing and distribution of this on Linux and macOS, primarily To keep things sane, this Q will likely not include these, but I’ll do as much as I can (OUT OF SCOPE):
Namespace aliasing
The ns macro, since jank’s macro system isn’t quite ready for it yet
Benchmarking load times against Clojure
Windows support for this new feature
STM for module loading; this will be needed, eventually, but is too much to tackle for one Q
Project management tooling (leiningen, deps.edn) integration
REPL server

After this work is done, jank will be in a position to integrate with leiningen and actually be used for multi-project files.

2023 Annual Meeting and Board Elections

Fri, 11 Aug 2023 08:30:00 +0800

Greetings Clojurists Together members and supporters. It's that time again! We've undertaken many projects this year thanks to you and as a result, have strengthened the tools and resources available to the entire Clojure community.

2023 ANNUAL MEETING

Our 3rd annual convening is fast-approaching - so we wanted to give you advance notice of the date and agenda. We know you are busy, but if you could reserve an hour to meet, we would value both your participation and input. Please hold the following date and time on your schedules (certainly not a complete list - but enough to check your time).

Auckland Wed., Oct 11, 6 am
Chicago Tues., Oct 10,12 pm (noon)
New York, Tues., Oct 10, 1 pm
São Paulo, Brazil,Tues., Oct 10, 2 pm
Belgrade, London, Paris, Stockholm Tues., Oct 10, 7 pm
Amsterdam, Barcelona, Berlin, Helsinki Tues., Oct 10, 8 pm

PRIOR TO THE MEETING: BOARD NOMINATIONS AND VOTING

You’ll receive an email towards the end of August explaining the process in more detail.
Call for nominations for expiring board seats: Aug. 25, 2023
Board nominations close: Sept. 15, 2023
Voting opens a few days after the submissions close and after the board has nominated the final candidates
Voting closes: Sept 29th, 2023
New term board members announced at Annual Meeting Oct. 10/11

AGENDA ANNUAL MEETING OCT 10/11:

Welcome new board members
Summary reports on 2023 projects, membership, survey results, and financials
Q&A, Discussion regarding community needs and future direction

We hope to see you there. This is a lively, informed, and opinionated group - so we’re looking forward to hearing from you!

FireFox 116.0 Release

Tue, 08 Aug 2023 08:30:00 +0800

Custom Formatters for Firefox

It’s been quite a while since my last post regarding custom formatters in Firefox. Though the long wait is finally over. Firefox 116.0 ships with custom formatters support!

In addition to the overview below, you can review the Firefox 116 release notes and the tweets and blog by the Firefox DevTools team. For more background and the initial decision to fund this important project, check out Clojurists Together’s post from February 2022.

So let’s get to it!!

The main point of bringing custom formatters to Firefox was to allow the CLJS DevTools (custom formatters for ClojureScript) to work in Firefox. To get to that point required a lot of work. First, I needed to find a way how to parse the custom formatters defined in a website in a safe way. To allow executing the code in a safe context, I’ve re-used a functionality that was already used by the Web Console to support instant evaluation. Though I had to lift some of the restrictions imposed by that functionality.

After that, I switched the logic behind their display from the normal tree view used in o ther places within the Firefox DevTools to a custom component. This simplified the logic behind them, allows to align the display to Chrome’s implementation and paved the way to handle the config object.

Also, once the basic functionality of the feature was there, I added a way to gracefully handle errors within formatters by logging them to the console.

Initially, my focus lay on the display within the Web Console. Though the Web Console isn’t the only part where custom formatters are supported. I’ve also added support for them within the tooltips shown when hovering variables in the Debugger while script execution is stopped. Thanks to the DevTools team, there’s also support for them within the Scopes and Watch Expressions panel. All those changes included creating automated test cases for this new feature.

Once those steps were finished, I could finally remove the experimental flag, behind which this feature was implemented. And last but not least, I’ve also added some documentation of the feature.

This rounded up the implementation regarding the Firefox side. Though, as initially noted, the main goal was to get the CLJS DevTools to work with Firefox. And that also required some work on their side. So, with the help of Antonin Hildebrand I’ve added support for Firefox there, as well, and had to further tweak the display later on. And I also edited the documentation there to include the support in Firefox. Antonin then also released a new version 1.7 of those tools after that. So if you want to have Firefox support using the CLJS DevTools, please make sure to download the latest version of them.

Give the feature a try!

You can enable custom formatters from within the Settings panel by checking the “Enable custom formatters” option. Once that’s done, custom formatters are available the next time you open the Firefox DevTools.

Download the latest version of the CLJS DevTools and integrate them into your project.

With that, ClojureScript variables are displayed in a much more readable way in the DevTools. Here’s an example that covers pretty much everything they do:

All this is explained in more detail in the post at the Firefox Developer Experience blog and in the Firefox DevTools documentation.

Conclusion

While the project took way longer than expected, I am happy that the feature finally made it into Firefox and people can profit from it.

And that wouldn’t have been possible without the help of Nicolas Chevobbe from the Firefox DevTools team and the creator of the CLJS DevTools, Antonin Hildebrand. Also Jan ‘Honza’ Odvarko from the Firefox DevTools team helped coordinate the implementation and tracked the progress. So, a big thank you! Also, thanks to Daniel who reached out to me for that project and for supporting me!

I’ve learned a lot during this project. And I hope you find this feature helpful.

July 2023 Project Updates

Wed, 19 Jul 2023 08:30:00 +0800

Hope all of you are having a great summer (or winter in the southern hemisphere)..Here is the first round of reporting from our Q2 2023 project developers. Catch up on all of their great work!

Q2 2023 Project Updates

clj-Nix: Jose Luis Lafuente Esquembre
Clojure Camp: Daniel Higginbotham
Emmy: Sam Ritchie
Jank: Jeaye Wilkerson
Lucene Grep: Dainius Jocas
Uncomplicate Neanderthal, Clojure CUDA, Deep Diamond: Dragan Djuric
Portfolio: Christian Johansen

clj-Nix: Jose Luis Lafuente Esquembre

Published 12 July 2023. Q2 2023 Funding Round Report 1.

Updates

For the first half of the funding round, I refactored the clj-nix CLI interface, which is used to generate the deps-lock.json files. Now, if your project has multiple deps.edn files and aliases, you can define what dependencies to include in the lock file.

The CLI added the following flags: --deps-include, --deps-exclude, --alias-include and --alias-exclude.

An optimized lock file saves bandwidth and speeds up the nix build. I also added support to use Babashka as a build tool. To do that, use the --bb flag, see the clj-nix README for more info.

As part of the work to support Babashka, I updated Babahska in nixpkgs PR NixOS/nixpkgs#241119. Those changes benefit all nix users, not only clj-nix users.

I also updated clojure-lsp to use the latest clj-nix version: PR clojure-lsp/clojure-lsp#1623. Try it with nix run github:clojure-lsp/clojure-lsp -- --version

Some other minor improvements I did:

Refactored the flake.nix file, to fix the nix flake check command.
Added GitHub Actions to update the clojure and nix dependencies automatically.
deps-lock command checks if deps-lock.json is tracked by git. If not, runs git add --intent-to-add
Add extraJdkModules option to customJdk
Add wrap option to mkBabashka
Check that the main-ns has a :gen-class in mkCljBin

Next steps

Feedback welcome! For the second half of the round, I plan to continue working on some minor improvements based on users feedback. If something is important to you, feel free to leave a comment on any of the current open issues, or open a new one.

I also want to add the option to configure a clj-nix build using NixOS modules. With a module interface, we don’t need to expose the user to the internal machinery of clj-nix. (The NixOS modules name is misleading, you can use modules without NixOS. Projects like devenv or home-manager use that approach). This is a big change, I don’t think I’ll be able to finish it in the second half of the roundReport 1 Q2 2023 Funding Round. , but I’ll start to work on it.

Clojure Camp: Daniel Higginbotham

Published 30 June 2023. Q2 2023 Funding Round Report 1.

We are so grateful to Clojurists Together for funding Clojure Camp! Our next milestone is to expand our program to include two more study groups, with two mentors and five students each. Over the past month, we’ve focused on clarifying and documenting the systems we’ve been using to effectively run a study group and help people learn Clojure.

Accomplishments include:

Conducted weekly study group sessions with our first batch of learners
Began migrating ClojoDojo, a study partner pairing app, over to Clojure Camp
Made progress on setting up Clojure Camp operations, building out our digital workspaces for knowledge management
Documented our curriculum
Updated learner exercises

Emmy: Sam Ritchie

Published 3 July 2023. Q2 2023 Funding Round Report 1.

Done in June

I cut a first release of the Emmy-Viewers library last week!

Emmy-Viewers currently contains powerful 2D and 3D plotting primitives, based on the Mafs.cljs and MathBox.cljs libraries, as well as support for embedding interactive controls into these 2D and 3D scenes using Leva.cljs.

Here is an example of a namespace full of 3D plots: https://emmy-viewers.mentat.org/dev/examples/mathbox/functions

This is a crazy powerful system, capable now of representing most of what you’d need for a math curriculum up through high school and on into graduate-level physics and calculus.

How do I use it?

The developer experience goes like this. You:

install Emmy-Viewers via Clojars as a normal Clojure dependency
choose Portal or Clerk as your presentation environment. (Only Clerk can handle 3D for now.)

Once you’ve configured a namespace using the README instructions, you can use the Emmy-Viewers API to write down values like this:

(mafs/of-x sin {:color :blue})

And the presentation environment (Clerk, for example) will generate an interactive scene:

None of this requires any ClojureScript compilation; Emmy-Viewers works as a pure Clojure dependency.

Examples

The examples directory in the Emmy-Viewers repo has a bunch of usage examples. Here are some highlights:

2D examples gallery via Mafs: https://emmy-viewers.mentat.org/dev/examples/mafs
3D examples gallery via MathBox: https://emmy-viewers.mentat.org/dev/examples/mathbox/functions

Both of these are actually FULLY EDITABLE in the browser! Open the links above with /edit appended to the URL, and you’ll see a mini IDE on the left side of the page, with available commands listed at the bottom. Try changing values and hitting option-Enter to re-evaluate the page. Any change you make will flow down through the full namespace.

editable 2D: https://emmy-viewers.mentat.org/dev/examples/mafs/edit
editable 3D: https://emmy-viewers.mentat.org/dev/examples/mathbox/functions/edit

Some more examples:

(p, q) torus knot: https://emmy-viewers.mentat.org/dev/examples/manifold/pq_knot
more 3D surfaces and manifolds: https://emmy-viewers.mentat.org/dev/examples/manifold/fdg
Klein bottles and mobius strips: https://emmy-viewers.mentat.org/dev/examples/manifold/klein
3D geometry primitives: https://emmy-viewers.mentat.org/dev/examples/mathbox/geom

Next we have some physics and differential equation simulations:

Strange attractor: https://emmy-viewers.mentat.org/dev/examples/mathbox/ode
particle stuck on an ellipse: https://emmy-viewers.mentat.org/dev/examples/simulation/ellipsoid
editable version!! https://emmy-viewers.mentat.org/dev/examples/simulation/ellipsoid/edit
two particles stuck together with a spring: https://emmy-viewers.mentat.org/dev/examples/simulation/double_ellipsoid
geodesics of a torus: https://emmy-viewers.mentat.org/dev/examples/simulation/toroid

What’s Next?

Next, I’m going to use the exercises in Sussman’s “Structure and Interpretation of Classical Mechanics” as a guide for adding more physics-aware functions to the API. These exercises will serve as examples and documentation.

I also want to think through how to improve this “editable online” experience by possibly fleshing out the ability to save and persist these scenes, maybe by integrating with https://maria.cloud/.

Finally, there is a lot of work on the plotting API that would be great for new contributors, like adding support for color schemes to the 3D plots. If you find that interesting and would like to get involved, please let me know!

Jank: Jeaye Wilkerson

Published 13 July 2023. Q2 2023 Funding Round Report 1.

The terms of the work are to research a new object model for jank, with the goal of optimizing allocations, while also making jank code faster across the board. This is a half-way report and I’m excited to share my results!

Please note that I have a very detailed breakdown of my work, the design choices made, and the implementation details here: https://jank-lang.org/blog/2023-07-08-object-model/

To briefly summarize, I spent the first half of this quarter:

Exploring the top ECS frameworks as an option for jank’s object model
Prototyping a tagged object implementation
Benchmarking everything along the way

ECS

The ECS frameworks aren’t going to be a good fit, since they’ll require multiple allocations per object and the key metric I’m trying to shrink here is object allocation time. However, there are good learnings to be had around their data locality designs and judicious usage of compile-time computation to set the runtime up to be fast.

Tagged objects

Most Clojure code is built using the same numbers, strings, maps, vectors, and lists. The hyper-polymorphic cases of completely custom types and protocols is not the general case and shouldn’t have to impact the performance of it. I’ve prototyped a solution which optimizes the default case of using Clojure’s built-in types, while still allowing for entirely dynamic objects.

The results have been very promising.

Map allocations

Map allocations were the primary target. Details for why they were slow are in my blog post, but the new object model brings us within a very small margin of Clojure.

Map utilities

Map utilities like count and get were already very fast, but the new object model cuts them down even more.

What’s left?

I’m now ripping apart the jank runtime to add in the tagged object system. At the end of the quarter, I’ll have holistic benchmarks showing the improvements across the board. These benefits, once integrated into jank, will impact every jank object. Numbers, strings, vectors, maps, lists, and so on will all be significantly faster to both allocate and use.

Lucene Grep: Dainius Jocas

Published 15 July 2023. Q2 2023 Funding Round Report 1.

TL;DR

It was a little busy lately so my update is a bit uneventful. But my summer holidays are coming and I hope to spend some quality time working on making the Lucene library a little easier to use for the fellow Clojurists.

Context

The goal of the project is to tear apart lucene-grep project into a bunch of libraries.
lucene-grep is a CLI app that was created to scratch an itch of making Lucene to be compiled by GraalVM native image during the COVID lockdowns. Due to the nature of the effort the code was not designed to be used elsewhere. By participating in the Clojurist Together I want to refactor and re-design the existing codebase for reuse.

Updates

As of now, out of the lucene-grep 3 libraries are extracted:

lucene-custom-analyzer: data-driven Lucene Analyzers;
lucene-query-parsing: data-driven Lucene Query Parsers;
lucene-text-analysis: helpers to play with the Lucene Analyzers.

All these libraries were updated to depend on the newest Lucene version. I hope to write proper blog posts and/or demo apps with potential uses of the libraries.

Other things I’ve worked on

I’ve been having fun with other hacks.

The new GraalVM

I’ve upgrade lucene-grep to be compiled with the new GraalVM. The biggest adventure there was that GraalVM changed the way how compile time environment variables are used. Now, the env vars should be passed with -E property e.g. -ELMGREP_FEATURE_STEMPEL=true.

Clerk based publishing

I’ve set up a publishing system based on Clerk and Github Pages: journal, source. Hopefully, in the Journal I’ll publish proper writeups and presentations of the work I’m about to do in this project.

What is next?

In the coming months I want to design a Clojure library to use the Lucene Monitor Library.

That is it!

Uncomplicate Neanderthal, Clojure CUDA, Deep Diamond: Dragan Djuric

Published 30 June 2023. Q2 2023 Funding Round Report 1.

My goal with this round is to port Neanderthal, ClojureCUDA, and Deep Diamond to JavaCPP-based native libraries.

This first month was dedicated to the work on the first releasable version of the ClojureCPP library, and on porting ClojureCUDA to the JavaCPP-provided bindings.

So far I’ve been able to fully port ClojureCUDA, and to improve JavaCPP to the level that it could be released as standalone library that does not require many changes.

Next month will be dedicated to porting Neanderthal’s CPU and CUDA backends to use JavaCPP (via ClojureCPP). I hope that I discovered and solved most hard problems by now, so this won’t bring big surprises. On the other hand, I expect do gather addition ideas for improvement and fixes in JavaCPP and JavaCUDA during the Neanderthal port.

All in all, I feel that the project is on track and the progress goes as expected, which means that I think I’ll be able to port ClojureCUDA, Neanderthal, and Deep Diamond to ClojureCPP by the end of the third month, to the level that I can release the new version of all 4 libraries.

I released most of the resulting code in a couple of gigantic commits instead of many smaller ones because I didn’t want any release to contain broken, non-compilable library.

Portfolio: Christian Johansen

Published 14 July 2023. Q2 2023 Funding Round Report 1.

In the first half of the Q2 funding period I have focused my work on the main aspirations from my application: error handling, and improved first use experience.

Portfolio now catches more errors than before, and also displays more helpful information about them. As far as I can tell, Portfolio now catches and properly handles and renders all runtime errors that you can produce from your code. A new heads-up display was added to display some asynchronous errors that can’t necessarily be attributed to the currently rendered components. If you manage to produce an error that is only visible in the browser console with the latest version of Portfolio, please report it as a bug.

Portfolio now has a more friendly, and hopefully more helpful first use experience. Documentation has been expanded and improved - and importantly - is now self-hosted by Portfolio. When you first set up Portfolio, the UI displays the relevant documentation to help you get fully started, and all of Portfolio’s documentation is always available via a new button in the sidebar. I will keep working on the content for this solution.

The solution for self-hosting documentation still uses markdown files that can be readily browsed on Github as well, so you don’t have to run Portfolio to read it. But when you do, you have relevant references close at hand.

Portfolio’s React adapter has been upgraded with an error boundary that integrates with the above described error handling features. It now also supports using hooks directly in defscene.

I added a small REPL utility to Portfolio. You can now tap> a component instance, and Portfolio will render it in a temporary REPL folder.

Finally I have done some exploratory work on an accessibility extension to make it easier to develop accessible components. I will continue this work in the next half of the funding period.

The funding from Clojurists Together has allowed to me to set aside dedicated time to focus on Portfolio, which has helped me raise the level of polish. For this I am very grateful. Thank you all so much! 🙏

2023 Long Term Projects: May and June Updates

Thu, 06 Jul 2023 08:30:00 +0800

There is a lot of work to catch up on! Our 10 developers working on long-term projects check in with their May and June project updates. We also have two updates from Q1 2023 projects (Donut and Adelph/Manifold).

2023 Long-Term Projects

Bozhidar Batsov
Michiel Borkent
Sean Corfield
Eric Dallo
Christophe Grand
Thomas Heller
Nikita Prokopov
Tommi Reiman
Peter Stromberg
Peter Taoussanis

Q1 2023 Projects

Aleph/Manifold: Matthew Davidson
Donut: Daniel Higginbotham

Bozhidar Batsov

CIDER

For the past few months the primary focus of my Clojure-related work was CIDER. We’ve made some important steps toward the next release:

We’re working on a “debug on error” functionality (see https://github.com/clojure-emacs/cider/pull/3337) This also resulted in some internal improvements to the existing debugger codebase.
We’re working on a new way to interact with application logs from CIDER, which we currently call “cider-log-mode” (see https://github.com/clojure-emacs/cider/pull/3352)
- This also resulted in the creation of the standalone library logjam, which CIDER uses internally.
We’re now using the latest version of compliment, which comes which a bunch of code completion improvements (see https://github.com/alexander-yakushev/compliment/blob/master/CHANGELOG.md#0315-2023-06-22)

As usual the next release will also feature a few smaller improvements and bugfixes that you can peruse here. Just as importantly we’ve started to discuss the plans for CIDER 2.0. Everyone’s more than welcome to participate in the conversation there!

In other news:

There’s a small new bugfix release of clojure-mode (see https://github.com/clojure-emacs/clojure-mode/blob/master/CHANGELOG.md#5161-2023-06-26)
There are also new releases of orchard and cider-nrepl
We’re working on some improvements for refactor-nrepl and enrich-classpath

Michiel Borkent

In this post I’ll give updates about open source I worked on during May and June 2023. To see previous OSS updates, go here.

Sponsors

I’d like to thank all the sponsors and contributors that make this work possible!

Top sponsors:

If you want to ensure that the projects I work on are sustainably maintained, you can sponsor this work in the following ways. Thank you!

Github Sponsors:

If you’re used to sponsoring through some other means which isn’t listed above, please get in touch. On to the projects that I’ve been working on!

May 2023 Updates

The following projects had updates in May 2023. Note that only highlights are mentioned and not a full overview of all changes. See the project’s changelogs for all changes.

Preparations for babashka conf are in full swing and I’m preparing a talk with the title ‘Growing an ecosystem’.
This month I’ve had the honor to visit the JUXT 10 year anniversary in London and met a lot of fellow Clojurians over there.
Babashka and SCI will be featured at the last iteration of Strange Loop!
My OSS work is funded by Clojurists Together in Q2
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- Version 2023.05.18 - 2023.05.26 were released. Full changelogs here. Highlights:
- Linter :uninitialized-var moved from default :level :off to :warning
- #2065: new linter :equals-true: suggest using (true? x) over (= true x) (defaults to :level :off).
- #2066: new linters :plus-one and :minus-one: suggest using (inc x) over (+ x 1) (and similarly for dec and -, defaults to :level :off)
- #2058: warn about #() and #"" in .edn files
babashka: native, fast starting Clojure interpreter for scripting.
- Released 1.3.180, mostly a maintenance release
- See the complete CHANGELOG
scittle: Execute Clojure(Script) directly from browser script tags via SCI
- #58: build system for creating scittle distribution with custom libraries. See plugins/demo.
- Use window.location.hostname for WebSocket connection instead of hardcoding "localhost" (@pyrmont)
- Upgrade sci.configs to "33bd51e53700b224b4cb5bda59eb21b62f962745"
- Update nREPL implementation: implement eldoc (info, lookup) (@benjamin-asdf)
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Introduce all new programmatic API
- Automatically use file when exceeding Windows argument length
deps.add-lib: Clojure 1.12’s add-lib feature for leiningen and/or other environments without a specific version of the clojure CLI
- First clojars release
nbb: Scripting in Clojure on Node.js using SCI
- Nbb is now compatible with bun. To run nbb in a bun project, use bunx --bun nbb.
squint: CLJS syntax to JS compiler
- Fix import with $default
cherry Experimental ClojureScript to ES6 module compiler
- Support with-out-str
http-client: Babashka’s http-client
- Add :authenticator option
sci.configs: A collection of ready to be used SCI configs.
- This project now has a configuration for datascript, for anyone who wants to use SCI together with datascript. See this commit.
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Support :require-macros
process: Clojure library for shelling out / spawning sub-processes
- Support :pre-start-fn in exec
- Allow passing :cmd in map argument
- Better testing for exec by @lread
fs - File system utility library for Clojure
- :paths argument for fs/which by @lread
- Support inputstream in fs/copy
- Add fs/owner to return owner of file

Other projects

These are (some of the) other projects I’m involved with but little to no activity happened in the past month.

edamame: Configurable EDN/Clojure parser with location metadata
- Improvements for reading namespaced maps
babashka.book: Babashka manual
- Several corrections
- Dynamic :exec-args
- Script-adjacent bb.edn docs
CLI: Turn Clojure functions into CLIs!
- Support --no-option and parse as {:option false}
- Support grouped aliase like -ome as {:o true, :m true, :e true}
pod-babashka-go-sqlite3: A babashka pod for interacting with sqlite3
- Better error message when connection is not a string
instaparse-bb
- Add transform function
jet: CLI to transform between JSON, EDN, YAML and Transit using Clojure
- Add option to elide commas
quickdoc: Quick and minimal API doc generation for Clojure
rewrite-clj: Rewrite Clojure code and edn
sql pods: babashka pods for SQL databases
pod-babashka-buddy: A pod around buddy core (Cryptographic Api for Clojure).
gh-release-artifact: Upload artifacts to Github releases idempotently
neil: A CLI to add common aliases and features to deps.edn-based projects
cljs-showcase: Showcase CLJS libs using SCI
carve - Remove unused Clojure vars
grasp: Grep Clojure code using clojure.spec regexes
quickblog: Light-weight static blog engine for Clojure and babashka
lein2deps: leiningen to deps.edn converter
4ever-clojure - Pure CLJS version of 4clojure, meant to run forever!
pod-babashka-lanterna: Interact with clojure-lanterna from babashka
pod-babashka-fswatcher: babashka filewatcher pod
joyride: VSCode CLJS scripting and REPL (via SCI)
clj2el: transpile Clojure to elisp
deflet: make let-expressions REPL-friendly!
babashka.json: babashka JSON library/adapter

June 2023 Updates

First a few updates of what I’ve been up to outside of sitting behind a screen. June was packed with two trips and a vacation so there aren’t as many updates as usual.

Babashka-conf happened June 10th in Berlin. It was more than I could have hoped for: a professionally organized event with the creative, positive, welcoming spirit we’re used to from other Clojure conferences. Thanks everybody for coming out, especially to the speakers, organization and Malcolm + staff for recording the videos. You can view all the talks here. To see photos, comments, etc you can look for the #babashka_conf hash-tag on social media.
I’ve had the pleasure to visit the JUXT 10th year anniversary this month in London. Check out this wonderful talk by Alexander Davis on the state of frontend, with some nice comments about squint at the end.
End of June and beginning of July I’m away on a vacation to Switzerland to recover a bit from all of this fun. I hope to take it easy on the coding and just relax a bit and recharge for what is to come next.
Babashka and SCI will be featured at the last iteration of Strange Loop!

The following projects had updates in June. Note that only highlights are mentioned and not a full overview of all changes. See the project’s changelogs for all changes.

squint: CLJS syntax to JS compiler and cherry Experimental ClojureScript to ES6 module compiler
- Both projects can now be used simultaneously in one build. The use case for this is when you have projects like clerk that ship with multiple options for evaluating CLJS at runtime and you want to offer both squint and cherry as options.
sql pods: babashka pods for SQL databases
- Version 0.1.2 was released which contains upgrades of database drivers and next.jdbc library. Also a bug was fixed around mssql.
CLI: Turn Clojure functions into CLIs!
- Implemented an alternative to shutdown-agents which does not kill threads when using an exec function, e.g. when spinning up a web server. Also see TDEPS-198.
cljs-showcase: Showcase CLJS libs using SCI
- Namespace state is now preserved over multiple blocks
clj-kondo: static analyzer and linter for Clojure code that sparks joy.
- Actively working towards a new release, probably next month.
fs - File system utility library for Clojure
- Add gzip and gunzip functions (thanks to Lauri Oherd)
deps.clj: A faithful port of the clojure CLI bash script to Clojure
- Tried to improve the situation where the downloaded tools jar may be corrupt and causes trouble when calculating the classpath, using a crc32 check. See babashka issue.
SCI: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs
- Support :require-macros
- Introduce eval-string+ which received an optional initial :ns key and also returns the last active :ns so you can preserve the namespace state over multiple evaluations.
- Released v0.8.40
process: Clojure library for shelling out / spawning sub-processes
- Implement :out :bytes to receive output as bytes (thanks Hans Bugge Grathwohl)
- Make :dir option accept java.nio.file.Path
babashka: native, fast starting Clojure interpreter for scripting.
- 1575: fix command line parsing problem with -e + *command-line-args*
- 1576: make downloading/unzipping of deps.clj tools .zip file more robust (see deps.clj)
- released version 1.3.181
- 1581: bb print-deps: sort dependencies (thanks to Teodor Heggelund)
- 1579: add clojure.tools.reader/resolve-symbol built-in

Other projects

These are (some of the) other projects I’m involved with but little to no activity happened in the past month.

scittle: Execute Clojure(Script) directly from browser script tags via SCI
nbb: Scripting in Clojure on Node.js using SCI
http-client: Babashka’s http-client
sci.configs: A collection of ready to be used SCI configs.
edamame: Configurable EDN/Clojure parser with location metadata
babashka.book: Babashka manual
pod-babashka-go-sqlite3: A babashka pod for interacting with sqlite3
instaparse-bb
jet: CLI to transform between JSON, EDN, YAML and Transit using Clojure
quickdoc: Quick and minimal API doc generation for Clojure
rewrite-clj: Rewrite Clojure code and edn
pod-babashka-buddy: A pod around buddy core (Cryptographic Api for Clojure).
gh-release-artifact: Upload artifacts to Github releases idempotently
neil: A CLI to add common aliases and features to deps.edn-based projects
carve - Remove unused Clojure vars
grasp: Grep Clojure code using clojure.spec regexes
quickblog: Light-weight static blog engine for Clojure and babashka
lein2deps: leiningen to deps.edn converter
4ever-clojure - Pure CLJS version of 4clojure, meant to run forever!
pod-babashka-lanterna: Interact with clojure-lanterna from babashka
pod-babashka-fswatcher: babashka filewatcher pod
joyride: VSCode CLJS scripting and REPL (via SCI)
clj2el: transpile Clojure to elisp
deflet: make let-expressions REPL-friendly!
babashka.json: babashka JSON library/adapter
deps.add-lib: Clojure 1.12’s add-lib feature for leiningen and/or other environments without a specific version of the clojure CLI

Discuss this post here. Tagged: clojure oss updates

Sean Corfield

In my previous Long-Term Funding update I said I would review/overhaul the Libraries pages (both authoring and the directory) and write the tools.build cookbook.

The library authoring guide has been rewritten to use the Clojure CLI, deps-new, and deps-deploy and was well-received by the community, who provided some useful feedback that I have also incorporated into the guide. The information from the library directory has been integrated into The Clojure Toolbox via a couple of Pull Requests that added optional tool-tip descriptions and libraries that were on clojure-doc but missing from the Toolbox. Thanks to James Reeves for accepting those PRs!

What else did I get done?

ClojureCLR, HoneySQL

There’s been quite a bit of activity around ClojureCLR recently, so I’ve been testing .NET-related things on Windows and on Ubuntu. David Miller submitted a patch to tools.cli to add CLR support which I released as tools.cli v1.0.219 and I updated HoneySQL to add CLR support: honeysql v2.4.1033.

tools.nrepl has been ported to ClojureCLR and Peter Strömberg (maintainer of Calva) has created a ClojureCLR starter project for VS Code/Calva which I’ve also been helping to test on Windows and Ubuntu.

HoneySQL saw another release, mostly improving documentation and docstrings, near the end of the this period: v2.4.1045. Both releases improved the experience with :on-conflict clauses.

`next.jdbc`

next.jdbc v1.3.883 was also released in this period, also mostly improving documentation and docstrings, and adding an active-tx? predicate to expose whether next.jdbc thinks you are currently in a with-transaction context.

`clojure-doc.org`

All of the content from the library directory has been incorporated into The Clojure Toolbox at this point. Every library that was previously listed on clojure-doc.org is now listed on the Toolbox and all of the one-line descriptions have been added to the Toolbox as well (which now show up as tooltips when you hover over the library name/link). The Toolbox still has a lot of libraries listed without descriptions so, hopefully, that’s something the community can add over time (or help James with automating, using project descriptions from GitHub, perhaps?).

The library authoring guide has been substantially rewritten to use the Clojure CLI, deps.edn, and build.clj. The old Leiningen-based library authoring guide has been lightly updated and is still available, linked from the new guide.

In addition to the library work mentioned above, I’ve been working on the tools.build cookbook. I shared an early draft to get community feedback and then shared the completed version this week. The whole thing is over 3,000 words now, with a lot of code examples. I’ve tried to distill everything I’ve learned about tools.build into a single document that covers various scenarios that go beyond what is in the official tools.build guide.

Some additional community feedback has already been incorporated and more will be incorporated over the next few weeks, I expect.

What’s Next?

In July/August, I’m hoping to complete a review and update of both the “ecosystem” and “tutorials” section of clojure-doc.org, and then in the two remaining periods, I’ll tackle the “cookbooks” and “language” sections.

On a personal note…

I mentioned in the previous update that my mother was in hospital and I want to thank everyone who reached out to me with kind words and support. She came home and was doing well for a while but then she had another fall and she’s back in hospital as I write this, this time with severe anemia on top of her other issues. She’s had a blood transfusion and seems to be doing better but we don’t know when she’ll be home. It’s times like these when I really do feel the five and a half thousand miles between us…

{:tags [“clojure” “clojure-doc.org” “honeysql” “clojure-clr” “jdbc” “open source” “community” “clojurists together”]}

Eric Dallo

During these 2 months, I mainly focused on improving clojure-lsp, fixing bugs and adding some features mentioned above, especially improving the java support. Also, I’ve been working for some months now in a new Intellij plugin called clojure-lsp-intellij, which I should finish the alpha and announce soon!

clojure-lsp

Main highlights:

Recently I focused on java interop improvements in both clojure-lsp and clj-kondo, so now we have more java analysis to provide features, we have now hover doc (pic1) and completion for java static members! We still have to enhance clj-kondo and lsp to be able to provide for all java usages besides static ones only, but it’s a huge start!
Keywords completions are now smarter, checking other namespaces and sorting better.
We have more visual feedbacks when LSP is doing post start tasks in the editor.
clojure-lsp now understands ClojureDart projects!

2023.05.04-19.38.01

General

Bump clj-kondo to 2023.04.15-20230503.152749-8

Editor

Fix edn tree to consider symbols. #1556
Fix edn tree to consider vector root nodes. #1557
Fix edn tree to handle invalid edn code and not throw exceptions while typing code.

API/CLI

Avoid enabling unecessary analysis features for API/CLI lint, improving memory usage.

2023.07.01-22.35.41

General

Update flake.nix to build with babashka. #1373
Bump clj-kondo to 2023.06.02-20230630.144012-16.
Improve support for ClojureDart .cljd files. #1589
Slightly reduce OutOfMemory exceptions that may happen with the JVM version.
Support ignore unused-public-vars via :linters :clojure-lsp/unused-public-var :exclude-when-contains-meta clj-kondo setting.
Fix restructure-keys when map has an :or. #1583
Bump lsp4clj to 1.8.0.
Add post startup tasks progress feedbacks, like “Generating stubs”, “Analyzing JDK source” and “Fetching Clojars”.
Bump cljfmt to 0.10.6. #1605

Editor

New code actions: Replace ':refer :all' with ':refer [my-refer]' and Replace ':refer :all' with alias. #1575
Enhance java support for hover and completion of static class members.
Improve :paths-ignore-regex to ignore features avoiding impact in huge files that are intented to be excluded.
Fixed semantic-tokens for full qualified namespace
Add score to completion items for a better completion client sorting. #1595
Revamp keyword completion. #1599
Avoid LSP errors when cleaning a file without namespaces. #1603

API/CLI

New feature: Find all references via API and CLI. #1572

clj-kondo

#2106: Support .cljd files as source files.

jet.el

#7: json with ' (single quote) fails to convert to edn.

Christophe Grand

ClojureDart

The period started on the Conj heels and we were all pumped up. We’re seeing a steady influx of new users. With more users we spent more time supporting them but experienced users are starting to help too, and we are getting more PRs, it’s a good sign!

Two of the “future work” items of previous update have landed during this period: Dart 3 support and the new reader.

Last, we started publishing short videos on Youtube https://www.youtube.com/@clojuredart/shorts (Don’t check your speakers they don’t have audio.)

Fixes

Several fixes to the compiler, cljd.core or flutter.cljd.

Amongst them:

rseq wasn’t behaving properly on vectors whose size was a multiple of 32,
some code was improperly optimized away when a throw appeared in some nested ifs in statement position,
widgets below a :vsync were not refresh on app state changes, only on animation updates,
issues with set! expressions used in argument position,
potential double evaluation when casting to a nullable type,
…

Improvements

Tear-offs of default constructors. Dart has this feature that a method (or even a constructor) can be “torn off”: if you don’t specify an argument list you get a closure over the object with the same signature as the method (same idea for constructors – if you don’t know Dart: Dart doesn’t support overloading so constructors (but the default) are named, they are just static methods).
Documentation on generics
Documenting the fact that defs are initialized on demand and not eagerly.
We started populating a FAQ
We spent a lot of time improving compilation time (we found a lot of small gains until we finally found the function with a quadratic runtime), some users saw their recompilation time go from almost 2 minutes to a couple of seconds.
more samples (Wevbiew, FFI to C)
require named
some and every? are now based on reduce to avoid sequences
inst literals can now appear in source code,br>

New features

Dart 3. Dart 3 supports landed in two times: first a couple of days after the release of Dart 3 which made sure that ClojrueDart was compiling to proper Dart 3 (because Dart 3 has breaking changes over Dart 2.12 – but we can still target Dart 2, we autodetect which one is used). Then in a second time we got records support – Dart records are immutable typed tuples and are a new feature of Dart 3.
Finally the new reader (which can be used asynchronously if a stream is consue but synchronously when reading a string) landed. Support for tagged literals is still in the work.
We ported clojure.set (and its tests) as cljd.set, it was mostly a copy/paste & tweak port.

Future work: ClojureDart

Add tagged literals to the reader
We have found a path allowing a Flutter-only REPL could be hacked in a couple of days, is it still worth the hack?
Look into porting Datascript and SCI to ClojureDart
New APIs to leverage our persistent data structures:
- maps (hash and sorted) in ClojureDart are original implementations (not the same as CLJ/CLJS) – hash maps could be seen as another refinement of the original, sorted maps constitute a novel implementation.
- Sorted colls should be good enough for direct use by Datascript.
- Both hash and sorted maps can support accelerated merge/diff/join/etc. operations.
Multimethods
cljd CLI written in cljd for easier project creation etc.
gen tests
…

Thomas Heller

shadow-cljs

Time was mostly spent on doing maintenance work and some bugfixes. As well as helping people out via the typical channels (eg. Clojurians Slack).

Current shadow-cljs version: 2.24.1 Changelog

Notable Updates

Added full support for package.json "exports" since its use has become more widespread.

Nikita Prokopov

Less releases these last two months, more research and reports.

DataScript:

Lots of small optimizations for ClojureScript version (who would’ve thought that declare or case could be slow?), with roughly up to 7% perf improvements across the board.
Prototyping faster “index sub-slicing” for cases when you e.g. need to find values of the same attribute accross many entities. Seeing up to 30% improvements for this particular case on Roam 3M datoms graph.

Humble UI:

Prototyping state management solution based on signals

Clojure Sublimed:

Better indenting of reader conditionals (turned out they use parentheses, but their content is more like a map).

Blogging:

Humble Chronicles: Managing State with Signals. Some research about what to do with components in Humble UI.
A Case for ClojureScript 2.0. Some reflection on why ClojureScript feels so different from Clojure and where I think it should be going.

Tommi Reiman

Had a busy 2 months and did not have enough focus time to deliver the things I planned on OS. Just started my 9 week summer vacation, will be few weeks off the grid, but then will jump back into OS.

Malli

Continued with the new effective type system - WIP
Working with Schema inheritance (optional, solving real-world problems), WIP

Reitit

Work on the upcoming 0.7.0 Version, with 5 new alpha releases. Thanks for all the alpha-testers!
Managed to fix a foundational issue by Introducing two-phase Schema compilation
Goal was to ship the 0.7.0 out in June, but ended up not being happy with the new syntax and started to do a big refactor on it. Almost done.

Something else

Summer.

Peter Stromberg

As usual the bulk of my open source energy is poured into Calva, a Clojure/ClojureScript/ClojureCLR/ClojureDart/Babashka/nbb/Joyride /etcetera development environment that takes Interactive Programming seriously.

I also got to contribute to Clojure-related starter projects and was interviewed for Flexiana’s new Clojure Corner series: Clojure Corner with Peter Strömberg

Calva

Over at Twitter someone asked me if I was up to something exciting. Implicitly wondering if Calva was about to get some cool new big thing (I think). My answer was that it is mostly about maintenance currently. However, I find Calva maintenance exciting!

Maintenance has many aspects. Is the documentation helpful? Are there bugs that create that extra friction making them a priority? Is there some feature that could be made more powerful with some change? What about some new features I feel curious about and that I can finish with one or two late-night hacking sessions? The best part: I get to talk to Calva users and consider their feedback, questions and suggestions.

Here’s a summary of Calva maintenance May + June 2023. I’m including some of the rationales, to give you a feel for how we reason when maintaining Calva. Wall of text:

Calva now makes an effort to try format code with incomplete structure (missing opening or closing brackets). This is common when formatting a selection, or formatting pasted code. It gets extra important for beginners who do not ”see” the structure as clearly as us with experience from Clojure or some other LISP(s). Not being familiar with the structure also makes you less likely to use Calva’s structural editing power. Having the broken code formatted helps in highlighting the structure and what is missing from it. While at it we also got some glitches with format-on-paste feature fixed. It’s a bit more complicated than you might think, as this issue might illustrate. Thanks Alexander Kouznetsov for the help in figuring this out!
Closing/fixing incomplete structure is not new in Calva. It has been used for Calva’s commands for evaluating to the cursor from arbitrary deep before the cursor. Which is very handy for investigating the steps in threads with the REPL, and for including let bindings in what is evaluated. It has so far not been available for your custom REPL evaluation commands, which is now fixed with the $selection-closing-brackets interpolation variable.
The Custom REPL Commands have been available only from Clojure files. This is now changed so that you can fire these commands from any file, as long as the REPL is connected. Good for Clerk Markdown Notebooks, which was the driver for this change.
The command Expand Selection now considers binding pairs, making it easy to select key/value paris in maps or bindings in let boxes, etcetera.
Stefan van den Oord fixed a long standing and mysterious issue we have had with the deps.edn + shadow-cljs REPL connect sequence. It turned out we didn’t handle the case of selecting multiple shadow-cljs launch builds. (This is correctly handled for the shadow-cljs sequence, making our suggestion to use this sequence instead work as a ”solution”.)
Selecting a deps.edn alias that provides :main-opts can break Calva’s connection of the REPL, because calva provides its own main-opts to start the nREPL server. The warning message Calva used to put up worked to help users navigate around this, but it was also terribly confusing. Thanks to Dustin Getz and Sean Corfield for helping with finding a better Ux!
Connecting a shadow-cljs REPL is now a more managed process than it used to be. I’m already noticing a drop in user support time for this. Freeing up you users and us Calva maintainers for higher level conversations. 😀
Traditionally REPL connect sequences have been intended per workspace. Babashka changes this. To fire up a Babashka REPL often the built in sequence works fine, but if you want to start it in WSL… Now you can define these sequences both globally and locally. Starting Babashka in WSL and connecting VS Code is simplified with a sequence like this one defined in your User VS Code settings file:
```
  "calva.replConnectSequences": [

    {

      "name": "Bashbabka (WSL)",

      "projectType": "custom",

      "customJackInCommandLine": "bash -c 'bb --nrepl-server JACK-IN-NREPL-PORT'",

    },

  ],
```
Actually, in order to support ^that^ sequence we also needed to add support for fully custom connect sequences. The "custom" project type is new since a few weeks.
Calva Notebooks are a bit of a special take on notebooks in that we insist that any Clojure file can be a notebook. This has been more than a tiny bit hampered by that evaluating a notebook has also evaluated the Rich Comments in there… This is now fixed. You dare evaluate a Calva Notebook if you dare evaluate the file in its regular form.
There were also numerous small fixes and things happening that I either skip mentioning here, or that I have forgotten about. 😀
For a few days of this period I was fire fighting. My changes introduced regressions, and my fixes for the regressions introduced regressions. Nothing super major, but there is a promise we want to keep with Calva: We prioritize regressions that we introduce. As can be picked up in The Tao of Calva: Moving fast is great. Breaking things is fine, as long as you fix them fast.

Starter projects

I am a big fan of small starter projects. They can load a lot of experimentation and failure experience into a simple and approachable package that is easy for beginners and non-beginners alike to pick up and use. Hopefully for a quicker and smoother experience than the starter project creator had. Hereby I am encouraging you all to consider this when you have experimented with some tech stack, or tech stack component. It is my experience that I learn better from creating them as well. Both by the activity of structuring the project and writing the README in a way that I can hope is understandable, and from the feedback and contributions I get from others trying to use my project.

Anyway. This period around I created one new starter project and gave some love to an old and still popular one.

Dockerized ClojureCLR Starter Project. Celebrating that ClojureCLR got a new nREPL server, and confirming that it works well with Calva, the result was a starter project. As I am on a Mac and don’t have reasons for having .Net installed, I choose to use Docker Compose to set the project up. This also makes it super quick to go from Zero to a ClojureCLR REPL running and connected to your editor. Special Calva convenience added. Please consider contributing configuration for your favorite Clojure IDE.
rn-rf-shadow is a ClojureScript + Reagent + re-frame + React Native starter project, powered by shadow-cljs and Expo. It has helped a quite a few ClojureScript React Native projects to get started.
- It is now up-to-date with latest React, latest Reagent, latest everything.
- The dependency bumps were the result of me adding React Navigation to the project. This makes sense for a lot of projects and is easy enough to rip out if your project does not need it. There is now also a branch demonstrating how to use React Native libraries, in this case the react-native-countdown-timer (no README update for this yet).

Please follow me

I’m @PEZ on Github.
I’m @pappapez on Twitter.

Thanks for sponsoring me! ❤️

Clojurists Together: This long term sponsoring is fantastic. It makes wonders for how I can fit open source contributions into my family life.
Github Sponsors: Same here, it’s long term and it makes my family respect Clojure, Calva, Open Source and that I want to spend time with it.

Peter Taoussanis

You can read more from Peter at Peter Taoussanis

Recent releases include:

Sente: v1.18.0 - see release notes for details
Timbre: v6.2.1 - see release notes for details
http-kit: v2.7.0 - see release notes for details

Upcoming work:

Carmine v3.3.0-RC1 will be out in the first week of July. This includes a rewrite of Carmine’s message queue system, with major improvements in mq performance, observability, and documentation.
Tempel v1.0.0-beta1 is still on track for end of August, more info on that closer the time.
Moving forward, all my libraries will include testing for GraalVM when relevant. Thanks to Michiel Borkent for Babashka, and for his assistance with testing. As usual, my current open-source plan is available here.

A big thanks to Clojurists Together, Nubank, lambdaschmiede, and other sponsors of my open-source work 🙏

Q2 2023 Project Updates

Aleph/Manifold: Matthew Davidson

(Report 2. Published 30 June 2023)

HTTP/2 support

Client-side HTTP/2 is now generally available, as of 0.7.0-alpha1
H2C cleartext is now supported (use with caution)

Other Aleph changes

Massive refactoring of Aleph internals
Much better documented
Split up pipelines for multiplex codec
Added helper Java classes for channel initialization and ALPN negotiation
Added pr support for Netty classes

Donut: Daniel Higginbotham

(Report 2 Published 25 May, 2023)
Over the last couple months I’ve made a lot of changes across the Donut ecosystem to get the framework closer to realizing the vision of providing a foundation for building single-page apps. I’ve focused on creating a cookie-based auth plugin that provides both backend API endpoints and frontend components.

Per-repo changes include:

donut-party/endpoint

This repo provides components you can add to your system to configure it for serving HTTP API requests.

Added ServerComponent donut.system components
This encapsulates a default configuration for running a jetty server
Added HTTPComponentGroup donut.system component group and http-plugin plugin
These make it possible for a developer to add a collection of donut.system components to their system with just a lien of code
Improved docstrings

donut-party/endpoint-test

This repo provides a test harness for applications that use donut.system and donut.endpoint to define API handlers. It handles system setup/teardown and provides helpers to:

Construct endpoint paths
Send requests to your app’s request handler
Parse responses back into Clojure data structures

Updates:

Updated plugin definition to use latest syntax from donut.system I’d updated donut.system’s plugin syntax to be more readable and more data-oriented, and this required an update to donut.endpoint.test.harness/test-harness-plugin. The plugin provides some default configuration for the library’s helpers.
Revised interface for request helpers
I significantly rewrote the interface for request handlers to take a single argument, a map, rather than relying on variadic positional arguments. I found the positional arguments too difficult to remember and not as readable.
Added a README
Added support for edn content-type

donut-party/frontend

Added support for auth responses The frontend framework can handle API responses structured to convey an auth token to the frontend, and store that token in the re-frame app db.
Update XHR handling to add auth header when token present The frontend library has a lot of tools for performing XHR requests. I updated them to include an Authorization HTTP header when an auth token is present in the re-frame app db.

donut-party/donut-cli

Updated project generator Updated the template used for new projects, and updated the CLI to use the updated templated.

donut-party/system

Added dependency-pairs function
This makes it easier to grok depedencies and put them in a graph
Added ability to specify repl system
Previously, the tools in donut.system.repl required you to use a named-system named :donut.system/repl. This change makes it possible to pass in the name of any named system and use that.
Added namespace for visualizing the dep graph with visjs
Calling (donut.view.visjs/show your-system) will open a browser window that uses visjs to show a dependency graph of your system.
Added component caching
Sometimes you don’t want to constantly stop and restart components. For example, you probably don’t want to stop and start a threadpool for every test. This addition lets you cache a component, preserving a component instance across stops and starts. Clearing the cache will make the component respond to the next stop signal.

Call for New Proposals. June Survey Results.

Tue, 27 Jun 2023 08:30:00 +0800

Call for Proposals

Clojurists Together is pleased to announce that we are opening our Q3 2023 funding round for Clojure Open Source Projects. Applications are open until the 20th of July 2023. Apply today!

We surveyed our members in late June - to find out what types of initiatives they would like us to focus on for this round of funding. Their responses are summarized below. Thanks as always – it is extremely helpful in ensuring that the community is a vital source of input.

If you work on a Clojure open source project, especially one mentioned as a focus area for our members, please consider applying.

Our Members Speak: Feedback from the June Survey.

What groups, meetups, or sites do you visit regularly that might be a good place to introduce both beginning and seasoned Clojurists to our work? (outside of Clojurians Slack, GitHub, Reddit - /r/clojure, and Twitter)?

Clojure Berlin
Clojure Hispano group at Telegram
clojure-toolbox
clojureverse
clojuredocs
Clojurians Zulip
Hacker News
lobste.rs
London Clojurians
Mastodon
NYC Clojure Meetup and other Meetups
r/programming subreddit
Youtube channels and content creators

What would you like to be different in the Clojure Community in the next 12 months?

Some selected comments from the survey are listed below:

Documentation

Much better and slicker documentation and outreach. Documentation that is slick and fun and makes it clear how you enter into using the language and why.

Support for Beginners

The Clojure survey finds “learning the idioms” as the top obstacle to learning Clojure, so that might be a place to make a difference. Also, people often want to see sample Clojure applications (not libs) to understand how to put pieces together, develop, and deploy them. More support on things like that would be great.
I think we should bring more stuff under the CljTogether umbrella, including e.g. clj-commons &c, and then have people work on the commons directly; same goes for beginner training; discoverability matters.
I’d like there to be much more up-to-date, maintained beginner material and maybe also mentoring. Using Clojure has made me enjoy programming much more, and I’d like more people to also have that experience. Some of the barriers to entry may seem artificial to seasoned Clojure devs, but I think it’s important to remember that in some cases even a little bit of friction can deter people away from the language. While some may think “well those people aren’t fit for the language if they give up from a little friction,” I think that’s a poor way to think, and trying to get more people into using Clojure is, in general, going to improve the language, the tooling, and the community.
Make Clojure reachable to beginners in any aspect possible. Write official documentation for people who are learning to program. What we have is great for experienced programmers. We need a different layer of documentation. Also make debugging easier as it is beginners will make a lot of mistakes. Error messages are Key. Gve them colors, or at least the option to have them. Elevate everything to and from Java to Clojure at least with an official wrapper just to have a unified way to present the errors.
I’ve been running workshops at meetups for 5+ years. Could be an opportunity to have a small ClojuristsTogether “meetup pizza fund” (IMO, a fairly high-leverage use of funds to get support Clojure growth).
I’m now part of Clojure Camp (and we appreciate CT’s support!). There may be an opportunity for “summer of code” type open-source internships – ie. sponsor new people to Clojure, not experienced devs; pair them with an experienced dev, to work on an open-source project (ex. as part of yearly developer funding, each developer is expected to mentor one junior clojure dev; the junior also gets some small funding and has expectations to be met) – I could help with administering this; could do this in partnership with Clojure Camp if interested.
I think it’s rather hard to discover all the cool libraries clojure has to offer. There are enough amazing resources to learn the basics, but next step when one starts to build apps is underserved. You can find frameworks like biff or kit to get you started, and they’re great start, but discovering things beyond their default choices is hard. Probably some lib finder tools on top of clojars can help?
It seems that having a more standard, official, well-documented way to create new projects using templates is something that could help with adoption, or at least with getting started. Developers from other languages are used to having that kind of tooling, and while it exists in the Clojure world, it’s not quite as straightforward in my experience (maybe that has changed more recently). People are still starting out with Leiningen and I think that’s partly because it still seems more straightforward to them in terms of creating new projects and running tests than does the Clojure CLI.

The responsibility for improving the official tooling is more on the Clojure core team, but I think the community could improve this by
creating more guides that discuss the existing tools around the Clojure CLI, like for using clj-new. Library and tooling authors can also
add examples for the Clojure CLI, rather than just having Leiningen examples (or in some cases maybe they should even get rid of the
Leiningen examples in favor of the Clojure CLI).

This sort of dichotomy, while not a big deal to seasoned Clojure devs, seems to create some friction for beginners. They’re immediately hit
with a decision they may feel is pretty important - “Which build tool should I use?” - and for which they may have a hard time deciding.
They pick one, but inevitably find examples for the other for things they’re trying to do.

Comprehensive, Multi-media Clojure Resource and Destination

I wish there was something like what Onyx was trying to be.
Culture wise I come back to that youtube idea. There needs to be more free, quality content for beginner and intermediate devs. It’s a trope (that clojurists love to hate) that clojure needs is Rails. I think this misses the most underrated contributor to Rails’ success: Railscasts.
Michael Hartl’s tutorials/books are a good example. This isn’t to detract from the quality stuff that does exist, and perhaps this isn’t something that can be bought; it might just require a singular voice with the type of dedication (to say nothing of skill & resources) to produce such content consistently over a fairly long time
I think we should bring more stuff under the CljTogether umbrella, including e.g. clj-commons &c, and then have people work on the commons directly; same goes for beginner training; discoverability matters

Grow the Clojure Community

More companies using Clojure; Making Clojure more known in the business circles. More new users.
I think the Clojure community is amazing and I like seeing the language grow, albeit slowly. I think we all as a community need to figure out a way to break the stigma of starting new projects in clojure. Wild idea, working on creating some partnerships with companies that like what Clojure has to offer but fear that they won’t be able to hire enough developers. This kind of partnership can help companies give clojure a go as their backbone technology and bring more hobby-clojurists to make their main language of choice. I know too many people who love Clojure and fantastic developers, but don’t put effort to dive deeper than basics as they aren’t sure they can find a job with Clojure.
I think the presence of Clojure in the greater developer community has decreased quite a bit from a few years ago. Probably more stuff should be done to get more people to adopt it. Introductory-type stuff would be most critical I think.
There is an opportunity to grow the community by creating python to clojure specific material.
There is a high bar of entry into Clojure compared to some other languages, like JavaScript. That is because for many, in my experience, the Lisp syntax is intimidating and unusual. It’s also because the community is small and so getting oriented in the beginning is hard. We love Emacs but for many it is a tool that belongs to people who love their tools, and there are a lot of programmers who find that off-putting. Clojure errors are also scary. Anyway, all these things ensure Clojure may remain “niche”, and maybe that is okay, but mentoring people, being friendly and welcoming, having documentation that is slick, etc etc. – all that costs money and it’s maybe the only thing that can get people into the language, no matter how good a language it is.
There are more people coming to Clojure from Python and JavaScript backgrounds, where there is no prior knowledge of the JVM. It would be helpful to also teach the basics of the Java SDK (threads, IO, etc.).
We need more marketing efforts to attract people to the language.
Developer advocates, DevRels, Marketing

Other Feedback

AI-assisted coding solutions. They’ll improve and become a part of developer workflow in the next year(s), so we need to have some good story here. At least integrate clojure repl with popular tools/agents, once the leaders emerge.
Standard recommended frameworks for building applications (back-end HTTP services and front-end UI framework) with documentation. These exist now, but there is no one accepted way to accomplish these things, and it makes Clojure appear immature to people new to the ecosystem. It also discourages the development of tooling for those frameworks.
I would target python interopt so we can use the data science libraries.
Community-aided core development. I’d like the community to think about what it can do without waiting on the core team.
Keep supporting reagent and re-frame.
Support improvements in server-side rendering (preferably using Reagent)
I see the clojure community being less concentrated on ClojureScript…
Integration JS ecosystem: I would love to see funding for better integration with the overall JS ecosystem. ES6 module output would be great to future-proof ClojureScript for use with tools like Remix etc.
ClojureScript feels behind JS in many ways. I would love to see more guides, tutorials or blog post about how to get some of the many cool things from the JS world to play nice with ClojureScript.
Consider being a fiscal host on OpenCollective? They’ve changed their pricing model now so that they take 0% if you take 0% as a host. Could make certain logistics things easier.

Q2 2023 Funding Announcement

Mon, 29 May 2023 08:30:00 +0800

Greetings all. We’re excited to announce the projects we’ll be funding for Q2 2023. (8 projects $44K USD in total). There were a lot of great projects - so making a decision was, as usual, difficult. The good news, however, is that proposals will automatically be reconsidered for the next 2 cycles. We have supported many projects in the past that did not make it in the initial round - so stay tuned! Thanks to everyone for your thoughtful proposals - this is the kind of thinking and sharing that makes the Clojurists Together community so awesome!

Projects Awarded $9K USD

Emmy: Sam Ritchie
Clj-kondo, babashka, cherry, SCI: Michiel Borkent
Clojure Camp: Daniel Higginbotham
Neanderthal, Clojure CUDA, Deep Diamond: Dragan Duric

Projects Awarded $2K USD

clj-nix: José Luis Lafuente
Jank: Jeaye Wilkerson
Lucene Grep: Dainius Jocas
Portfolio: Christian Johansen

LARGER PROJECTS AWARDED $9K USD

Emmy: Sam Ritchie

I want to make the SICMUtils computer algebra system into a best-in-class, modular set of tools for doing serious work and exploration in math and physics, and sharing that work in the browser. When used with NextJournal’s Clerk, https://maria.cloud/, and the components I built with last quarter’s funding, I think SICMUtils could take the place of Mathematica for students and educators and help cement Clojure as a serious contender for top data science language.

Concretely, I would use the quarter to:

Rebrand SICMUtils as “Emmy” after Emmy Noether
split the 30kloc project into modules, to make the components easy to use from other projects. Examples of useful components include:
A battle-tested symbolic expression simplifier and pattern-matching rules
An extensible symbolic expression compiler, capable of emitting LaTeX, fast numerical functions, fast matrix-valued functions, etc
Forward- and reverse-mode automatic differentiation
Modules for mathematical objects like polynomials, rational functions, quaternions, and geometric algebra
Differential geometry code used in general relativity research

With last quarter’s funding, I produced a number of components for creating and interacting with 2d and 3d visualizations, as well as tooling for NextJournal’s Clerk to make it easy to create interactive documents embedding these components.

I’ll extend this work by building out a library of Clerk viewers that make it easy to visualize and work with interactive versions of all of the important mathematical objects in the SICMUtils library.

Finally, I’ll use the system to produce a series of interactive essays that explore mathematics and physics, as a way of showing off the power of the system.
A stretch goal would be to ship these interactive essays both using Clerk and using https://www.maria.cloud/, so that all text and code would become interactive as well.

As an example of what is possible, see this interactive visualization of a (p, q) torus knot.

I was able to use the SICMUtils automatic differentiation and function compilation features to turn the following inefficient description of the curve for one of these knots into a highly optimized JavaScript function that ran 10-20x faster than the hand-tuned JavaScript of the example I was porting: ```clojure (defn torus-knot “Returns a function of theta that produces a 3-vector of the XYZ coordinates of a (p, q) torus knot wrapped around a torus (donut) with major radius R and minor radius r.”

Clj-kondo, babashka, cherry, SCI: Michiel Borkent

Clj-kondo:

Support an arbitrary amount of reader conditionals in .cljc files via configuration. This is mostly useful for ClojureDart (:cljd),
babashka (:bb), nbb (:org.babashka/nbb) and shadow-cljs targets like :node. It’s often not selfevident if people are writing both for JVM Clojure + ClojureScript (which is how clj-kondo by default understands .cljc files) or for other combinations of Clojure dialects. I want to add support for configuring what Clojure dialects apply to your project and what Clojure dialects should be linted as (e.g. :node should just be linted as :cljs). If necessary I’ll also add support for specific dialects like ClojureDart.
Help with clj-kondo configuration for Electric Clojure
Numerous other issues, there’s always plenty to do! See the clj-kondo project board: and see here for a list of most upvoted issues:
As clj-kondo is the foundation for the static analysis in clojure-lsp: improvements in the interaction between the two, most specifically the analysis data.

Babashka

Make it easier to use scripts in projects from anywhere on the system. bbin is already helping a lot with this. However, if we allow scripts that are on the path to be combined with their relative bb.edn file to be invoked while taking into account the dependencies from bb.edn, this would be a lower bar of entry for having system wide scripts and might also simplify the implementation of bbin itself. Eventually I’d like to include some of bbin’s features into babashka itself, as a bb install command and this would be the first step towards that.

Port Clojure 1.12 features to babashka

Allow user-land middleware to participate in the babashka nREPL server
babashka.http-client: this library is now included in babashka but still needs some better configuration options for SSL contexts and http proxy.
Addressing issues of several other built-in libs in bb: babashka.cli, fs, process, etc.
Better error locations for clojure.test output (https://github.com/babashka/babashka/issues/1518)
Report exception causes in console error report (https://github.com/babashka/babashka/issues/1515)
Several other issues: https://github.com/babashka/babashka/issues

Cherry

Cherry is a CLJS compiler that can be used as a standalone tool but also to (partially) replace self-hosted CLJS in exising projects. This mode is known as cherry.embed: The embed mode is already used in malli as an alternative to SCI: instead of interpreted CLJS we now get compiled CLJS for serializable functions. To be more generally useful, cherry needs to emit namespaced functions which it currently doesn’t. Eventually something like scittle may be implemented using cherry which would give the same convenience but a smaller bundle and better performance.

SCI:

Add the ability to request the stacktrace at arbitrary execution points in user land (https://github.com/babashka/sci/issues/871) (also related to the babashka issue about clojure.test locations)
Multiple minor issues related to JVM and CLJS interop: https://github.com/babashka/sci/issues

Clojure Camp: Daniel Higginbotham

Vision
At Clojure Camp, we are creating a free learning community to help new developers of all backgrounds build a secure foundation for professional programming success — with Clojure! We hope to model a positive tech environment through a commitment to diversity and through our emphasis on creating a fun, friendly, supportive, and kind environment.

Clojure Camp is rooted in an equity ethos: it’s open to all while prioritizing the experience of those who face the most hurdles in tech. Our Community is a place where Women, BIPOC folks, and LGBTQ+ folks belong.

We believe that learning Clojure is a great long-term investment because it helps people learn a better way of approaching programming, and because it brings creative satisfaction. We want to make it accessible to more people.

We believe this will have a long-term positive impact on the Clojure community by improving our reputation as a welcoming and helpful community, and by increasing the pool of Clojure developers.

Product
For the next six months, we are focusing on two “products”: a study group matchmaking service and a metacircular project incubator.

Study Group Matchmaking
We have created a study group format and matchmaking service that’s proving to be effective with our initial cohort of learners. About five learners are paired with two mentors who guide the learners during weekly video calls, reviewing the work the learners have done over the previous week. In between video calls, learners use a tool to match them with other learners in their group for pair programming and support.

We want to continue building out this model by refining the curriculum and developing other avenues of learning and collaboration. Also, we want to start doing some outreach to attract new developers to participate. We’ve received a lot of interest from potential mentors; now we just need to find some students for them!

Metacircular Project Incubator
We’ve designed Clojure Camp to be a kind of project incubator, where motivated volunteers can propose their learning projects and get our support. The kinds of support we provide include:
• Implementation feedback. We are available to brainstorm ideas or otherwise spend time chatting with project leaders to help them refine their offering.
• Networking. We can refer project leaders to others who might be able to help, and we run a discord server for project leaders to reach out to each other.
• Moral Support. Part of our motivation for creating this structure is that we want to help people avoid burnout. It’s a lot easier to do this sustainably when you’re in community.
• Advertising. We help project leaders get their projects in front of a qualified audience, allowing them to focus on what they do best: helping people learn!

Our core team already has a number of projects we’ve begun working on in this spirit, including:

Speaker coaching
Email newsletter

Neanderthal, Clojure CUDA, Deep Diamond: Dragan Duric

In short, I propose to implement:

a port of Neanderthal’s MKL engines and CPU related stuff to JavaCPP instead of neanderthal-native (for sure).
a port of ClojureCUDA to JavaCPP’s CUDA. (probably, depending how 1 goes) - a port of Neanderthal’s GPU matrix engine to new, JavaCPP-based ClojureCUDA (almost sure, if ClojureCUDA port goes well)
update Deep Diamond to use new infrastructure.
improve relevant internal parts of Neanderthal code with more macrology (double-edged sword, I know, but also concentrates bugs at one place each).
TESTS! to make sure everything works as well as before (of course!)

EXPERIMENTAL OR SHORT-TERM PROJECTS AWARDED $2K USD

clj-nix: José Luis Lafuente

Why is this project important to the Clojure community? Nix is a great tool to build and deploy software, but Clojure is not well supported in the Nix ecosystem. clj-nix makes easier to integrate Clojure on a Nix project.

What are you wanting to achieve with this funding?
I want to refactor the CLI to be more granular about the dependencies used at build time. Currently, all dependencies in all aliases are added to the lock file. I want to add some flags to the CLI to allow users to manually define the deps.edn files, and the aliases to use. Once CLI refactor is done, I want to add support for calling Babashka at build time, adding the possibility to use Babashka, and the dependencies defined in the bb.edn file, in the Nix build phase.

Jank: Jeaye Wilkerson

jank is the only native Clojure dialect which has its own JIT and embraces interactive programming. It unlocks REPL-driven development for a whole ecosystem previously unserved by Clojure.

Clojurists have demonstrated their desire for native executables with their use of GraalVM. Compared to Graal, jank will offer REPL support, better native interop, smaller binaries, and faster compilation times.

Clojure’s object model is intense. In fact, representing it 1:1 from Java to C++ is impossible, since C++ has stricter rules are duplicate base classes and bases with same-name fields and different types. Furthermore, C++, even with the Boehm GC, is much slower at creating objects than the JVM is. It’s bread and butter work for the JVM. Also, while everything is an Object in the JVM, C++ doesn’t have the same notion. If every jank class were to inherit from the same Object class, it would have very serious performance implications when it comes to allocations.

So jank has two key problems here:

Creating new boxed values is slow, compared to the JVM
Not every jank type can actually be turned into an object, which sometimes means doing some weird dancing to get from one type, through another, and finally to the object base; this generally requires virtual function calls

So far, I’ve worked around the first one by optimizing other things, so jank can be faster than Clojure in a given program for example, but when measuring just the object creations, Clojure is still around twice as fast. I want to fix this.

This task would entail implementing and benchmarking a few different solutions, all of which move jank’s object model away from C++ inheritance and toward something more dataoriented. This gets us around C++’s virtual inheritance allocation costs, but it can also allow every jank type to be treated as an object, which will not only simplify jank’s runtime code, but will itself be a key optimization.

Right now, I have two key design ideas:

A very template-heavy approach, which uses bit fields to keep track of which behaviors an object has, as well as which data storage it has
An ECS-based approach, which separates object identity from storage, which would aid in cache performance and data locality issues

So far, I have prototyped the first approach and found object creation is nearly twice as fast. This funding would allow me to implement both of these solutions fully, benchmark them, and research further ways to improve them. Finally, I will integrate the fastest solution into jank and reap the benefits.

Lucene Grep: Dainius Jocas

What are you wanting to achieve with this funding? I want to tear the lucene-grep project apart into several reusable idiomatic Clojure libraries/tools/tutorials that would help the Clojure community to leverage the Apache Lucene library, e.g. a Clojure library whose single purpose is to create Lucene Analyser in a data driven fashion https://github.com/dainiusjocas/lucene-custom-analyzer.

Also, I want to combine the knowledge encoded in other Clojure projects when it comes to using Apache Lucene and either contribute to existing or fill in the gaps by creating several single purpose idiomatic Clojure libraries.

Why is this project important to the Clojure community? Apache Lucene is a treasure trove of a battle tested functionality for building search and data analysis applications. As of now, there are few ok’ish Lucene wrapper options e.g. https://github.com/jaju/lucene-clj. But Apache Lucene is already a dependency in multiple Clojure systems such as Datomic, Crux, etc. I wan’t to spend some quality time going through the use cases and expose modularise the functionality.

Portfolio: Christian Johansen

What are you wanting to achieve with this funding? I will use the funding to improve the experience for new users. Specifically I will add some self-hosted documentation such that Portfolio can guide users via its UI once set up. I will also improve Portofolio’s error handling and make it provide more helpful pointers when things go wrong. If time permits, I will keep working on a recently started accessibility testing feature for Portfolio.

Why is this project important to the Clojure community? The community has voiced a desire for more developer tooling. Portfolio is a developer tool for frontend ClojureScript work. While it is good that Clojure(Script) makes it easy to use tools built for the underlying platform (e.g. Storybook), strong native CLJ(S) tooling is necessary to fully harness the power of our amazing language and runtime, and make it an attractive alternative. My hope is that Portfolio eventually is one piece of what makes ClojureScript the greatest frontend toolkit out there.

May 2023: Short Term Project Updates

Wed, 24 May 2023 08:30:00 +0800

With several project cycles winding down, we have final reports in from Clerk, Clojure-ts-mode, Exercism, Kaocha, and Uncomplicate Neanderthal. Great work all! As always thanks for your commitment and contributions to the Clojurists Together community.

Project Clerk: Martin Kavalar
Project Clojure-ts-mode: Danny Freeman
Project Exercism: Bobbi Towers
Project Kaocha: Arne Brasseur
Project Uncomplicate Neanderthal: Dragan Duric

Project Clerk: Martin Kavalar

Update: 2 May 2023; Final Report
Funding Round: Q1 2023

Interactive Links & Homepage, Book Updates, Viewer Customization

In April we worked on the following:

🔗 Interactive Links, Index and Homepage
Links can now be followed in interactive mode and the index can be viewed. Previously this could only be seen after a build!. Add support evaluating a given doc by entering it in the browser’s address bar. Use these features to build a new welcome page that gives more useful information, including links to potential notebooks in the project.
Getting this right took a bit longer than we hoped but we’re looking forward to build on top of those features to better surface the docs going forward. Wikidata-style links to other notebooks and vars are also on the roadmap.
👁 Improved support for customization of viewer options
Customization of viewer options like the budget or auto-expansion of results has gotten an overhaul. They can now be set per-doc or per-result consistently using the same keys.
🍒 Experimental support for cherry for compiling viewer fns
Took a first step towards supporting compiling Clerk viewer functions using cherry. This opens the door to more performant viewer fns since it removes the interpretation overhead.
📖 Book Updates
Documented the Viewer Customization Options in the Book of Clerk.
🐞 Smaller Bugfixes & Improvements
We plan to follow up with a v0.14 release shortly. What we had planned but didn’t yet get around to is documenting how to use Clerk as a library for Dashboards. We did settle on an approach that we’re happy with however, so getting the docs updated should not be long. Thanks again for supporting Clerk with this funding! 🙏

Project clojure-ts-mode: Danny Freeman

Update: 15 May 2023; Final Report
Funding Round: Q1 2023

Project Update:

Clojure-ts-mode is now in a pretty usable state and should be ready for people to try out. Through this funding project I’ve implemented the following features:

Syntax Highlighting
Fixed style indentation
Complete imenu support
S-expression navigation

Additionally I’ve been working on the documentation to make getting started with clojure-ts-mode easier. It is available for install now through package-vc on Emacs 29


(package-vc-install "https://github.com/clojure-emacs/clojure-ts-mode")

And should be available on MELPA package repository soon.

Next steps

I was not able to get semantic indentation implemented yet, as I found the indentation mechanisms in tree-sitter difficult to use at first. However, I have a much better understanding now of them (and how to debug them). Over the coming months I will be working on semantic indentation to more closely match what clojure-mode does today. Once I have semantic indentation in a good place I will probably consider clojure-ts-mode ready for a 1.0.0 release. Until then it will stay in the 0.. version range.

Documentation is always a work in progress and will continue to improve over time.

Additionally, I will request to have clojure-ts-mode listed in Non-GNU ELPA package repository. This should make it easier to install for people that do not have MELPA configured.

Project Exercism: Bobbi Towers

Update 29 April 2023: Final Report
Funding Round: Q1 2023

Inline evaluation via SCI

I’m very excited about this feature because it transforms the online editor into a proper interactive Clojure environment. When the track was first launched in 2021 we received some valuable feedback from fellow Clojurists, who said that the online editor was quite lacking to someone familiar with using an editor connected REPL. I too consider this an inseparable part of the Clojure development experience, so this is something I’ve wanted to do for a long time.

Once I prototyped the desired behavior using Nextjournal’s clojure-mode, the next task was to figure out how to best integrate it into the existing Ruby on Rails/React application while making as minimal impact on the codebase as possible. The first thing I tried was to use scittle to load SCI via the

Clojurists Together

Call for Proposals. Feb. 2026 Survey

And Now the Survey…

February 2026 Survey

88% of respondents use or refer to projects funded by Clojurists Together

Plans for Conference Attendance in 2026 (number of mentions):

What areas of the Clojure ecosystem need support? (select responses)

Last Call for Q2 2026 Funding Survey

Clojars Maintenance and Support: November/December 2025 Update

Critical Infrastructure: Clojars Maintentance and Support Update by Toby Crawley

Annually-Funded Developers' Update: November and December 2025

Dragan Djuric

Eric Dallo

0.78.2 - 0.87.2

2025.11.28-12.47.43

Michiel Borkent

Sponsors

Thanks..and more

We’ve been able to accomplish a lot this year with your support.

The developer’s work we fund is highly valued - and used daily.

Short-Term Projects Funded in 2025

Fun Facts and Thank You’s

December Q3 2025 Project Updates

AND NOW FOR THE REPORTS!

Ambrose Bonnaire-Seargent: Malli

Mutable registries are a dev-time abstraction

Thomas Clark: Fastmath

Table of Contents

Overview

Surveying the scene

Revised goals and towards future-proofed user-experience

Outlook

Jeremiah Coyle: Fireworks

Primary goals

Secondary goals

Dragan Djuric: Uncomplicate Clojure ML

Final progress after the third month:

Jeaye Wilkerson: Jank

Clojurists Together 2026 Annual Funding Announcement

Bozhidar Batsov

Michiel Borkent

Clojure Camp

Eric Dallo

Jeaye Wilkerson

Thanks

Vote on 2026 Annual Funding

Deadline for your vote to be counted: December 12, 2025 Midnight Pacific Time

Bozhidar Batsov

Adrian Bendel

Michiel Borkent

Clojure Camp (Rafal Dittwald, Jordan Miller, and others)

Thomas Cothran

Alex Coyle

Jeremiah Coyle

Eric Dallo

Dragan Djuric

Siavash Mohammady

Nikita Prokopov

James Reeves

Tomasz Sulej

Peter Taoussanis

Jeaye Wilkerson

Oleksandr Yakushev

Annually-Funded Developers' Update: September/October 2025

Dragan Djuric

Eric Dallo

0.44.0 - 0.78.1

Michiel Borkent

Sponsors

Clojars Maintenance and Support: August-October 2025 Update

2025 Critical Infrastructure: Clojars Maintentance and Support Update by Toby Crawley

November 2025 Short-Term Q3 Project Updates

AND NOW FOR THE REPORTS!

Jank: Jeaye Wilkerson

Malli: Ambrose Bonnaire-Sergeant

Uncomplicate Clojure ML: Dragan Duric

Progress during the second month:

Call for Applications: 2026 Annual Funding

PROCESS

2025 Board Election Results. Annual Meeting October 29.