Fork me on GitHub

I just made Navi, a cljs library that changes the active menu tab based on the relevant section scrolling position. There are jquery and js solutions out there, but 1 - I didn't want to add jquery to the project and 2 - several js libs had some minor glitches that pushed me to roll my own version 🙂. ATM, the library does everything for you in that it's not very flexible, but it can become more dynamic to work also with side menus and whatnot. If you have a cljs project, I'd love to hear what you think about it. It'll take 2 minutes to set it up.

simple_smile 3
Lennart Buit10:07:27

As a possible improvement ^^

✔️ 3

Looking great! Will play with this thank you! 🙂

Alex Miller (Clojure team)13:07:34

A new development version of clj is now available ( This has not yet been promoted to "stable" release but you can if you'd like to use it:

brew uninstall clojure
brew install clojure/tools/[email protected]
Changes in this version: • Added support for with data from aliases and overrides on the command line (-X) • Added support for using • Added explicit for :deps/:paths override (can now pass with -T alias) • Added new program for (as execution function) • Deprecated support for unqualified lib names (like cheshire) - will warn on use (use cheshire/cheshire instead) • More fixes for to address problems with -Spom for both new and synced pom srcDirectory • Many changes in • Added new API • Added via a JVM system property

💯 57
clojure-spin 24

> Deprecated support for unqualified lib names (like cheshire) - will warn on use Interesting. That’s lots of libraries, is there a problem with unqualified names?

Alex Miller (Clojure team)13:07:09

yes, but I will talk more about this elsewhere rather than reply in-thread here. I'm going to write several blogs today about different facets of the above

👍 15
Alex Miller (Clojure team)13:07:06

we're deprecating the single part naming format, you should use cheshire/cheshire instead


Oh right, I forgot that that’s implicit. Was fearing that all those libs would need to be published under updated coordinates

Alex Miller (Clojure team)13:07:09

just the naming format

👍 3
Alex Miller (Clojure team)13:07:22

if you use Cursive, please note that Cursive needed to catch up to the tools.deps api changes mentioned above so you will need the latest 1.9.3-eap1 if you want Cursive to work with clj integration


clj -A:deps -X:install :jar '"/path/to.jar"'
I’m going to cry escaping this in powershell 😄 Have you considered converting edn symbols back to strings for overrides to -X?


I think it’s fair to expect that command line args “gravitate” towards strings

Alex Miller (Clojure team)14:07:15

we considered it, decided not to do it for now


I’m curious to hear the reasoning, because I thought about it and decided it’s a good idea — mainly because escaping is hard

Alex Miller (Clojure team)14:07:10

because "everything is an edn string" is simpler than "everything is an edn string except symbols which are quoted and read as strings"


that’s fair

Alex Miller (Clojure team)14:07:14

we reserve the right to change our mind :)


@U064X3EF3 In the paths and maven install examples in the CLI/deps reference, you seem to be missing the actual alias inside the :aliases structure.


(I asked a follow-up in #tools-deps )


> because "everything is an edn string" is simpler than "everything is an edn string except symbols which are quoted and read as strings" This is a true statement, yet I hope you will reconsider. I think it is good to have some sort of "string gravity" for command line argument parsing in the expense of being simple, because using cli args is done for solving the task at hand rather than writing a program to share, read, run and reason about. It is much more rare to use symbols at runtime as function arguments — they are usually used near macros and loading namespaces, which is probably an uncommon configurable option for solving a task at hand. Much more common when using command line arguments is specifying urls and file paths, that are both make more sense as strings rather than symbols. Requiring strings being escaped makes it harder to use, and since escaping is different in different terminals, that makes sharing snippets of clj -X... invocations more problematic.

Alex Miller (Clojure team)18:07:56

the problem is broader than just this though - does true mean true or "true" ? what about nil or "nil"? what's the mechanism for actually passing a symbol etc? I did go down this path for a while. may go back again, will listen for more feedback.


The downside of treating everything as a string is that 1234 comes in as a String instead of a Long and any ... yeah, Booleans and also structured arguments like {:a 1} -- now that has to be parsed in your function and if you have :args in deps.edn it will be treated differently -- as EDN.


{:fn something/foo :args {:port 8080}} invoked with -X:whatever :port 8888 has a Long as the default value but String for any provided override which is... ugly.


Given that -X:some-alias is very explicitly invoking a Clojure function (and not -main), I would much rather have the arguments pre-`read` rather than having to deal with strings from the command-line but native Clojure data from the :args defaults -- and I'll happily pay the '"string"' tax for that convenience.

💯 3
Alex Miller (Clojure team)18:07:40

everything already comes in as a string, the question is whether you pre/post process around edn/read-string


I meant "inside the called function", in case that wasn't clear.

Alex Miller (Clojure team)19:07:05

A new dev version of clj is now available thanks to the keen eyed clj bug hawks in #tools-deps - if you like some more long form words, I have written some here:

❤️ 42
bananadance 15
🚀 18
parrot 6
🪲 3