This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (174)
- # announcements (5)
- # aws (9)
- # babashka (17)
- # beginners (259)
- # boot-dev (1)
- # calva (6)
- # cider (19)
- # circleci (7)
- # clj-kondo (9)
- # cljfx (51)
- # cljs-dev (4)
- # clojure (83)
- # clojure-australia (2)
- # clojure-dev (9)
- # clojure-europe (78)
- # clojure-nl (3)
- # clojure-spec (4)
- # clojure-switzerland (1)
- # clojure-uk (18)
- # clojurescript (22)
- # conjure (17)
- # cursive (17)
- # data-science (1)
- # datomic (15)
- # defnpodcast (1)
- # events (2)
- # fulcro (39)
- # graalvm (16)
- # graphql (1)
- # kaocha (5)
- # lambdaisland (11)
- # malli (6)
- # meander (1)
- # off-topic (26)
- # pathom (10)
- # re-frame (10)
- # reitit (6)
- # rewrite-clj (7)
- # sci (3)
- # shadow-cljs (28)
- # sql (12)
- # test-check (10)
- # tools-deps (31)
Morning. December is really showing itself from its worst side this year. Dark and grey every day.
Yeah it’s not helping with the 2020 blues. Gray and cold and dark and wet here in Copenhagen
One of the things I enjoy the least with maintaining OSS is the actual release process. The pains involve updating a bunch of files with the correct version, especially random version strings in Readmes and tagging, How do you manage these things?
I still have Reseda under just a git sha because I can’t be bothered to figure out Clojars and bundling Cljs stuff.
In comparison to Javas public Maven Repo, releasing to Clojars is “relatively” simple and straightforward, but I still have to google every time what the steps were.
@orestis do you want the GitHub Action to do the bundling, or also the “pushing to Clojars” part?
@javahippie I’ve no clue, haven’t thought about it! We’re using a GitHub action for doing releases of our software on elastic beanstalk on AWS, and the pattern there is that on every commit to master it will run a build and upload an artifact to S3, but the deployment action is meant to be run on purpose by a human.
If your environment variables are right, you could push to Clojars with a leiningen plugin in the action. But I am too paranoid to store my Clojars Credentials in GitHub, so I release manually every time
Updating the Readme should include more than the version (otherwise no reason for a release, right?). For the reference to the latest version on clojar I used the embedded SVG which is nasty but maybe the best you can do? When it comes to published documentation you can used a preprocessor of any kind to do text replacement in the most simple case.
@ordnungswidrig re updating the readme, that kind’a depends I guess. If your current version is
1.2.3-SNAPSHOT, then I guess you can let PR’s update the readme with any new functionality you need/want to document. And then on release you change the version to
1.2.3 , publish, and update the version to
1.2.4-SNAPSHOT (not that I’m doing that).
Also, one could imagine that more finegrained docs live other places than in the readme.
Had a lovely start today with 45 mins of the Defn podcast on my ears while on my ballance rollers.
For the lambda island libraries we update anything that looks like a deps.edn or leiningen version vector/map for the current project to the version number that is being released, and commit that before the release. This way it always shows the most recently released version on github, and it shows the version you are looking at in cljdoc.
https://github.com/lambdaisland/open-source/blob/master/src/lioss/release.clj <-- code to do that lives here
That’s neat. But honestly the need for prgrammatic creation of a regex is on the edge of what I consider to be comfortable with 😛
I think in this case I could have still quite easily written these regexes directly. It would be a lot more concise but harder to maintain.
I think the idea of regal is pretty great. For perf reasons I would probably generate the regexes in a REPL session and then inline them manually. They don't need to be evaluated each time I run my code. But I will keep the original regal expression around because it's way more readable.
@borkdude no, but the need to construct regexes is always kind of edgy, isn’t it?
This is what that regex compiles to
not sure what you're saying @ordnungswidrig? would you consider regex in general a smell or red flag?
well, regex are fine (unless you’re trying to parse HTML with it). But constructing regex via something like regal should be kind of a last resort when you really need it. I think the actual string regex representation is fine and way more readable in almost any case.
btw, there are also parser combinator libraries for clojure that let you parse strings with good performance, similar to spec (but then designed for actual text)
btw, I have also created documented regexes by just giving names to each sub-part and then using
str to create it, just for readability. or little functions to create the sub-parts based on some dynamic input
Yeah, I’ve used that before and I totally see the use case for “AST”-based regex creation. But for the daily simpler cases
foo-bar: (\d+)-(\w+) I strongly prefer the string over a clojure reresentation of it. 😉
I'm quite comfortable writing plain old regex so I don't use regal myself that often. Regal came about when I was working on this: https://github.com/lambdaisland/trikl/blob/trikl1/src/lambdaisland/trikl1/specs.clj here the benefits are multiple, I can define each sub section separately, can validate subparts as well as the combined versions, and I can generate each as needed in my tests
Regular string regex would be perfect for 99.9% of use cases if whitespace was ignored when compiling the pattern the same way it’s ignored in pretty much every other compiled language. The syntax is simple and easy to grasp. The only real problem is that fact that there is no obvious way to semantically partition the patterns you write when spaces are considered part of the pattern.
regex literals are great because they are different from strings and this can be reflected in syntax highlighting and the quality of life feature of not having to double escape a bunch of stuff (another common issue with regex readability).
I guess with a suitably clever macro you can accomplish many great things, but it would be a lot nicer to just be able to ignore whitespace…
it seems the only escaping that happens is for backslashes: https://github.com/clojure/tools.reader/blob/99c627f74f9f99bebe69ddb3c0044b322f59f3fb/src/main/clojure/clojure/tools/reader.clj#L94
Yeah, in regex in many other languages you have to double escape every escaped character like \s \n \t etc.
Very simple solution:
(require '[clojure.string :as str]) (defn regex [& parts] (-> (str/join parts) (re-pattern))) (def re (regex #"\w+" #"bar")) (prn re) (prn (re-matches re "foobar"))
This now allows you to document each part:
(def re (regex #"\w+" ;; match leading char #"bar" ;; match bar ))
that’s actually pretty good too since it allows comments, but I think my personal preference would just be using that x flag
Advanced regexes are advanced. “Lookbehind Zero-Length Assertions” is burned into my memory from my times as a perl developer
(?<!a)b matches a “b” that is not preceded by an “a”, using negative lookbehind.
Also forward references are neat:
> If forward references are supported, the regex
But honestly I would not know by heard what of this funky stully is supported by Java.
Java's regex is very powerful, and it has 2 engines with different performance characteristics dependent on your regex.
Yeah pro tip if you're looking for the docs on Clojure regexes, look for the javadoc for Pattern. Very comprehensive! https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/regex/Pattern.html