Clojurians Log v2

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.

I think you can do something like this in a GitHub action?

Morning!

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?

Good Morning!

Morning

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

It works well but I’m not sure how it would apply to Clojars etc.

Good morning!

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.

good morning!

good morning

@orestis I feel ya. Supposedly it’ll be like this the rest of the year.

the weather, I mean.

Good morning!

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

morning lovely people!

morning @thomas

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/kaocha/commit/615e70eb303c508fb97cdbf83e898b14602340d1

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 😛

These are the dirty secrets of our industry I guess.

morning

@ordnungswidrig Are you talking about regal in general?

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?

I mean regex as data compared to regex as a dsl (“actual regexes” 🙂 🤷

This is what that regex compiles to

#"lambdaisland/kaocha(\s+\{\s*:mvn/version\s+\")[^\"]+(\"\s*\})"

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.

How is one giant string more readable than information around each sub-string?

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)

https://www.reddit.com/r/Clojure/comments/7r4hd8/comparison_between_parsers_for_day_16_advent_of/

btw, I have also created documented regexes by just giving names to each sub-part and then using re-pattern and 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

morning

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.

string concat + re-pattern

I guess, but then you lose out on the niceties of regex literals

#=(re-pattern (str ....)) 👿

not good enough

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.

Ruby has a modifier for ignoring whitespace

/regex
some more regex
.../x

hm, if Ruby can have it why can’t we!?

Turns out we do!

(re-find #"(?x) hello world" "helloworld")

who knew?? 😄

oooooh! well, then I was grumpy for nothing

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

with still syntax highlighting

that’s actually pretty good too since it allows comments, but I think my personal preference would just be using that x flag

I think Java regexes also allow comments.

(?#comment)

hm interesting

well, that was a mind-expanding 10 minutes on this channel 🙂

I haven't been able to figure out a working example though ;)

The wonders of #clojure-europe 🙂

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.

That can become handy.

Also forward references are neat: > If forward references are supported, the regex (\2two|(one))+ matches oneonetwo.

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.

I didn’t know that.

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