This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-09
Channels
- # announcements (47)
- # asami (43)
- # babashka (37)
- # beginners (119)
- # bitcoin (1)
- # calva (5)
- # circleci (5)
- # clj-kondo (36)
- # cljs-dev (5)
- # cljsrn (1)
- # clojure (92)
- # clojure-australia (2)
- # clojure-bay-area (2)
- # clojure-europe (121)
- # clojure-italy (7)
- # clojure-japan (1)
- # clojure-nl (4)
- # clojure-serbia (2)
- # clojure-uk (66)
- # clojuredesign-podcast (2)
- # clojurescript (19)
- # conjure (2)
- # cursive (13)
- # data-oriented-programming (2)
- # datomic (53)
- # defnpodcast (7)
- # depstar (33)
- # events (1)
- # fulcro (21)
- # graalvm (47)
- # jobs (1)
- # kaocha (1)
- # lambdaisland (1)
- # luminus (2)
- # malli (14)
- # membrane (16)
- # off-topic (45)
- # polylith (2)
- # re-frame (11)
- # reitit (7)
- # releases (1)
- # reveal (15)
- # rewrite-clj (123)
- # shadow-cljs (7)
- # sql (21)
- # startup-in-a-month (3)
- # tools-deps (25)
- # vim (2)
Thank you! After @borkdude's praise I could not not check out #rewrite-clj :)
I think I am pretty much ready to merge the clj-commons/rewrite-clj v1 branch to main. After that, I’ll work toward getting a release up on clojars. Before I do the merge anybody want to review the https://github.com/clj-commons/rewrite-clj/blob/v1/CHANGELOG.adoc#rewrite-clj-v1? I’m looking for anything that makes you think, “uh oh, that will be a problem”.
I could try these changes, maybe on the weekend? An alpha
would help.
I have a rewrite-clj program that used/hacked things for getting namespaced keyword support.
It could be a useful report, verifying if I was able to update rewrite-clj->rewrite-cljc with only moderate pain
(I do expect at least some little surprise due to my hacking)
Cool, yeah, thanks, I think the real feedback can only come when people actually try out the first alpha.
Do I understand correctly you are rewriting #rewrite-clj? 😹
Oh ha! That’s very meta! I do use rewrite-clj to generate rewrite-clj’s public APIs. Which is fun.
I know I want to upgrade those libs to the clj-commons one anyway, so might as well get it over with now. Been using your playground so far
Yeah, rewrite-clj v1 branch, is pretty much equivalent to my rewrite-cljc-playground with more fixes and some minor changes to namespaced elements.
cool, then I can also have a clojars release of rewrite-edn. which I already did but I forgot I have a git dep :P
BTW, I am already running carve and rewrite-edn tests against rewrite-clj v1 via its libs tests.
Awesome. I also saw (not read entirely) the conversations with zprint. I assume you also test clj-format?
Yeah, I’m not exactly sure how antq manages a clojars release when it is using a git dep to rewrite-cljc-playground.
Maybe @slipset knows what happens when you deps-deploy a library with a gitlib to clojars?
I’m not sure how long it has been since you had a peek at v1 namespaced elements changes @borkdude, it’s similar to what we discussed ages ago, but if you have a time for a https://github.com/clj-commons/rewrite-clj/blob/v1/CHANGELOG.adoc#rewrite-clj-v1 that’d be great.
I mean: you switched to Y. Yes, ok, but from what X? Where did you switch from? It raises more questions than answers to me ;)
I thought rewrite-clj v0 used read-string
from other namespaces - other than from tests, this is not the case, I’ll delete the note.
Luckily rewrite-clj didn't because I would not have been able to use it with GraalVM at the time and clj-kondo wouldn't have happened and then babashka probably neither
Ya, I think I actually temporarily introduced a bad read-string
due to a booboo in transcribing prefixed requires.
The thing that I wonder most about after reading it is this one: > Namespace map prefix, is now stored in a namespaced map qualifier node. Prior to v1, was stored as a keyword. You give a lot of examples of any combination of things, but you call sexpr on everything, while I was wondering what the difference for this map prefix was
And the other thing: does this affect how you call :children on a namespaced map node, what you get back and how you should process it?
Thinking out loud here: I’m still a bit confused as to what is and is not the public API. For example node record fields were not documented in v0. This indicates they are an implementation detail. This will change if we support serialization of nodes, but for now they are considered internal. So I think I’ll express differences between the old an new namespaced map prefix from the perspective of the public node API.
In clj-kondo I do rely on this, but I'm using my own fork anyway. so is clojure-lsp I think
That's good. Maybe this is because they are not doing analysis with rewrite-clj anymore, but only rewriting
For clarity and to support current-ns auto-resolve ::
, ex. #::{:a 1}
which rewrite-clj v0 did not support at all.
Yes, I manipulate a lot of the nodes just by hand, by iterating over the :children
, etc
Yeah, it is a bit awkward when you want to treat a map as a map whether it be a namespaced-map-node or a map-node.
But v1 node traversal matches v0, and I like that. I have an https://github.com/clj-commons/rewrite-clj/issues/131.
user=> (rewrite-clj.node/sexpr (first (:children (p/parse-string "#::{:a 1}"))))
?_current-ns_?
user=> (rewrite-clj.node/sexpr (first (:children (p/parse-string "#::{:a 1}"))) {:auto-resolve {':current 'foo}})
foo
yes, excellentLast question: can you tell more about cljs perf things you removed to improve compatibility between both?
And lastly: lots of respect for your thorough work. This is an important piece of software for the clj ecosystem and you stepped up, a lot of thanks.
Yeah… I should actually provide a link to cljs perf because I have one somewhere… rundis made some efforts to optimize rewrite-cljs and wrote up a blog post. I dropped most of them in favour of a unified single code base for rewrite-cljs and rewrite-clj. Ah here it is: http://rundis.github.io/blog/2015/clojurescript_performance_tuning.html
Well, you and others have certainly been supportive, thanks for the continued feedback over the journey.
@lee I have done this in clj-kondo: > First quickwin - Moving away from multimethods Guess that perf improvement I saw in general usage? I can't say that I noticed.
And this was against ClojureScript circa 2015, so… dunno what perf changes have happened since then.
They do incur some perf overhead so switching to a closed set of cases does make sense
This is what I did in edamame, the parser which is largely inspired by the rewrite-clj parser
The nice thing is that is that we can improve performance if there are issues without breaking things.
I put that under potentially breaking, because it might make rewrite-clj v1 cljs unusable if perf is really poor.
I guess if that is the case, the JVM can also benefit from some optimizations at the same time
I was also thinking about a prior conversation we had about version schemes and using commit count. Perhaps subjective, but I’m thinking a benefit of using commit count really makes the version seems less precious and makes cutting a release less precious (which to me is good).
What does that have to do with the version number? Both can be scripted (I certainly use a script for this)
If you really want to make your versions meaningless, use dates. clj-kondo uses http://yyyy.mm.dd
I can explain why I did this for clj-kondo: this project will never be finished, so always just use the newest
For babashka I do want to indicate something along the lines of API breaking or important new functionality, so I use 0.2.13 now. When spec goes in it will certainly be 0.3.0 or so
Ok, I’m going to go and incorporate your very helpful feedback into the change log and tomorrow will merge to main! Thanks as always!
Funny thing about rewrite-cljc and rewrite-clj v1… all I really wanted to do was fix a little bug in cljfmt… huh!
No, not yet. There were a few actually, I think https://github.com/weavejester/cljfmt/pull/77#issuecomment-470721499, but it was missing namespaced map support in rewrite-clj v0 and lotsa missing stuff in rewrite-cljs that really lit the flame.