This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-08
Channels
- # babashka (18)
- # beginners (35)
- # biff (15)
- # cider (24)
- # clj-commons (26)
- # clj-kondo (12)
- # clojure (18)
- # clojure-austin (1)
- # clojure-dev (2)
- # clojure-europe (15)
- # clojure-losangeles (1)
- # clojure-nl (1)
- # clojure-norway (88)
- # clojure-seattle (2)
- # clojure-spec (14)
- # clojure-uk (27)
- # clojuredesign-podcast (5)
- # clojurescript (25)
- # cursive (3)
- # datahike (26)
- # datalevin (13)
- # datomic (39)
- # etaoin (19)
- # events (1)
- # fulcro (12)
- # graphql (1)
- # hyperfiddle (40)
- # introduce-yourself (3)
- # joyride (8)
- # lsp (53)
- # missionary (7)
- # nyc (1)
- # off-topic (31)
- # overtone (10)
- # reitit (6)
- # shadow-cljs (9)
- # slack-help (9)
- # thejaloniki (1)
- # tools-deps (12)
@ericdallo i use an automated process based on the https://clojure-lsp.io/installation/#script method of installation and since the script uses the https://github.com/clojure-lsp/clojure-lsp/blob/master/install#L77 to get the latest version and if the version there is unreleased like its now, it errors my tooling out. would it be possible to use a different file? like how we do in bb wth BABASHKA_RELEASED_VERSION
? i can do a PR for this if you think this is useful.
awesome, will take a look at the release process and add in the new file!
that would need some json parsing i think
not as easy just looking at this one file
lemme see if getting it from github isnt too complex/needs more moving parts, then can try that
well this is the install script, needs bb before 😛
often i run this on bare things
@ericdallo does the version file get updated automatically somewhere?
so its pretty much manually updated when we want to release? not even some script that does it? how about https://github.com/clojure-lsp/clojure-lsp/blob/master/release ? is this used somewhere?
but we don´t upload the version to anywhere, although I don't see much problem update that to the release as well if that makes sense
Not sure if this is the right channel... When I
(defn Vec ...)
I get this warning (in Calva) Vec already refers to #'clojure.core/Vec clj-kondo(redefined-var)
But I then I also see
user=> clojure.core/Vec
Syntax error compiling at (/tmp/form-init15592520369737587153.clj:1:7899).
No such var: clojure.core/Vec
thanks. I'm not in there yet, so didn't see it in my channels
coming from here: https://github.com/clojure/clojure/blob/08a2d9bdd013143a87e50fa82e9740e2ab4ee2c2/src/clj/clojure/gvec.clj#L170
thanks
is the kondo warning wrong?
yeah I know
but why does the warning say #'clojure.code/Vec
not clojure.core.Vec
ok, I'll report it to #clj-kondo
the answer is because deftype and defrecord are a bit lumped together, records do create vars
but kondo could do better there, right?
I think it's done this way since it's easier to implement navigation information etc like this to just regard them as vars, even though it's not technically correct
e.g.:
Clojure 1.11.0-alpha4
user=> (defn ->Vec [])
WARNING: ->Vec already refers to: #'clojure.core/->Vec in namespace: user, being replaced by: #'user/->Vec
so I'd kinda recommend just using :refer-clojure :exclude
for these names, even though technically Vec
isn't already a var. Feel free to post a Github issue about this though
> 1.11.0-alpha4 👀
that I only use to watch tv at night, but incidentally, answer slack questions if they pop up ;)

I also found this edge case:
user=> (deftype Dev []) (defn Dev [])
user.Dev
Syntax error compiling def at (REPL:1:1).
Expecting var, but Dev is mapped to class user.Dev
adding deftype support to SCI? 🙂
but as explained previously (I think) this is only for compatibility with some clj libraries (yes nbb too, same SCI), not something that I really recommend using
I was just reporting another edge case I found in (JVM) clojure concerning deftype + var name clashes. Nothing more than that