This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-09
Channels
- # announcements (3)
- # babashka (1)
- # beginners (66)
- # clj-kondo (2)
- # cljdoc (46)
- # cljs-dev (7)
- # clojure (16)
- # clojure-australia (2)
- # clojure-china (1)
- # clojure-europe (3)
- # clojure-hk (1)
- # clojure-japan (1)
- # clojure-korea (1)
- # clojure-my (1)
- # clojure-sg (1)
- # clojure-taiwan (1)
- # clojurescript (4)
- # community-development (53)
- # conjure (6)
- # css (7)
- # cursive (6)
- # datascript (1)
- # datomic (5)
- # exercism (5)
- # graalvm (12)
- # helix (8)
- # jobs-rus (1)
- # kaocha (1)
- # lsp (19)
- # nrepl (1)
- # overtone (2)
- # pedestal (1)
- # polylith (2)
- # portal (2)
- # react (25)
- # reagent (1)
- # shadow-cljs (7)
- # spacemacs (8)
- # vim (9)
No worry. We use the specific UUIDv4 regex at OrgPad for all the parsing. The more general one will definitely work too. Btw. this ties into my work on speeding up random-uuid in CLJS: https://clojure.atlassian.net/browse/CLJS-3369 The pseudo-random version is about 2x faster and can be applied immediately. The upgraded version, that tries to use the crypto API needs some work on detection.
Sorry I took so long to get to this.
I have 2 comments to make on the regex:
1. Yes, the individual patterns should have been [0-9a-fZ-F]
. That was a mistake.
2. I actually started with the shorter form:
#"^[0-9a-zA-Z]{8}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{12}$"
(That's a copy-paste from my first version, which includes the a-z mistake)
The reason for fully expanding it was a long discussion with @mfikes on February 3rd. Mike identified that the shorter form of regex was significantly slower than when fully expanded. We benchmarked various approaches, and eventually came up with the fully expanded version.So, the correct one would be:
#"^[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]$"
Yes, it's long and messy, but it's hidden inside the namespace where few people look, and it's significantly fasterYes, about 2x in my testing. We can perhaps reformat it with (re-pattern (str ...))
as suggested in Jira and DM. There are still some questions about how that behaves on namespace load and with the compiler.
This is where Mike's advice comes in. He's better at this than I am, but he pointed out that the Google Closure compiler (which is essentially a block box from the ClojureScript perspective) is unable to identify that the re-pattern
/`str` code is unneeded when the function is not used. However, the literal syntax for the regex is identified and works cleanly.
Should the version of Clojure in https://github.com/clojure/clojurescript/blob/8528937440d4c5a2c8fc86813c5a9928ab184daa/deps.edn#L5 be updated now?
I created https://clojure.atlassian.net/browse/CLJS-3370 for the regex update, and included some more uuid tests