Fork me on GitHub
#announcements
<
2020-07-28
>
lucio10:07:53

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. https://github.com/luciodale/navi

lennart.buit10:07:27

As a possible improvement ^^

lucio10:07:16

Looking great! Will play with this thank you! 🙂

alexmiller13:07:34

A new development version of clj is now available (1.10.1.590). This has not yet been promoted to "stable" release but you can https://github.com/clojure/homebrew-tools#version-archive-tool-releases if you'd like to use it:

brew uninstall clojure
brew install clojure/tools/[email protected]
Changes in this version: • Added support for https://clojure.org/reference/deps_and_cli#_executing_a_function_that_takes_a_map with data from aliases and overrides on the command line (-X) • Added support for using https://clojure.org/reference/deps_and_cli#_paths • Added explicit https://clojure.org/reference/deps_and_cli#_replace_project_environment_tool for :deps/:paths override (can now pass with -T alias) • Added new program for https://clojure.org/reference/deps_and_cli#_local_maven_install (as execution function) • Deprecated support for unqualified lib names (like cheshire) - will warn on use (use cheshire/cheshire instead) • More fixes for https://clojure.atlassian.net/browse/TDEPS-152 to address problems with -Spom for both new and synced pom srcDirectory • Many changes in https://clojure.github.io/tools.deps.alpha/ • Added new https://clojure.github.io/tools.deps.alpha/#clojure.tools.deps.alpha/calc-basis API • Added https://clojure.org/reference/deps_and_cli#_basis_injection via a JVM system property

alexmiller13:07:34

A new development version of clj is now available (1.10.1.590). This has not yet been promoted to "stable" release but you can https://github.com/clojure/homebrew-tools#version-archive-tool-releases if you'd like to use it:

brew uninstall clojure
brew install clojure/tools/[email protected]
Changes in this version: • Added support for https://clojure.org/reference/deps_and_cli#_executing_a_function_that_takes_a_map with data from aliases and overrides on the command line (-X) • Added support for using https://clojure.org/reference/deps_and_cli#_paths • Added explicit https://clojure.org/reference/deps_and_cli#_replace_project_environment_tool for :deps/:paths override (can now pass with -T alias) • Added new program for https://clojure.org/reference/deps_and_cli#_local_maven_install (as execution function) • Deprecated support for unqualified lib names (like cheshire) - will warn on use (use cheshire/cheshire instead) • More fixes for https://clojure.atlassian.net/browse/TDEPS-152 to address problems with -Spom for both new and synced pom srcDirectory • Many changes in https://clojure.github.io/tools.deps.alpha/ • Added new https://clojure.github.io/tools.deps.alpha/#clojure.tools.deps.alpha/calc-basis API • Added https://clojure.org/reference/deps_and_cli#_basis_injection via a JVM system property

martinklepsch13:07:39

> 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?

alexmiller13: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

alexmiller13:07:06

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

martinklepsch13:07:54

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

alexmiller13:07:09

just the naming format

alexmiller13: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

vlaaad14:07:50

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?

vlaaad14:07:42

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

alexmiller14:07:15

we considered it, decided not to do it for now

vlaaad14:07:20

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

alexmiller14: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"

vlaaad14:07:51

that’s fair

alexmiller14:07:14

we reserve the right to change our mind :)

seancorfield16:07:30

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

seancorfield16:07:37

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

vlaaad18:07:51

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

alexmiller18:07:39

thx, I hear you

alexmiller18: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.

seancorfield18:07:00

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.

seancorfield18:07:07

{: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.

seancorfield18:07:19

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.

alexmiller18:07:40

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

seancorfield18:07:43

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

alexmiller19:07:05

A new dev version of clj 1.10.1.596 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: https://insideclojure.org/2020/07/28/clj-exec/