[ANN] clj-uuid: thread-safe, performant unique identifiers

Hello Clojurians, I've just been polishing my modest library, clj-uuid and would like to invite everyone to have a look if such a thing might be of interest. What is it? clj-uuid is a Clojure library for generation and utilization of UUIDs (Universally U

Re: [ANN] clj-uuid: thread-safe, performant unique identifiers

Adding a UUIDNameBytes protocol is an excellent idea. That is definitely something I will look at doing. Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new

Re: [ANN] clj-uuid: thread-safe, performant unique identifiers

These were really good suggestions. As you mentioned, I implemented a UUIDNameBytes Protocol with a default representation of UTF8 for strings and will directly pass-through byte-array local-part for use in v3/v5. On Tuesday, February 17, 2015 at 1:06:11 AM UTC-5, Francis Avila wrote: > > This

Re: [ANN] clean-blog @ modularity.org

I enjoy your blog. It's like my morning cup of British. It really takes the biscuit. :) Best, Dan On Wednesday, February 18, 2015 at 9:28:57 PM UTC-5, Malcolm Sparks wrote: > > I've added a blog-site template called 'clean-blog' to the collection at > http://modularity.org - documented here:

Re: [ANN] clj-uuid: thread-safe, performant unique identifiers

I did some work to reduce consing and our generation of v1 (time-based) UUID's using clj-uuid are now about 40% faster than invoking the JVM's java.util.UUID/randomUUID static method: user> (criterium.core/bench (uuid/v1)) Evaluation count : 51250020 in 60 samples of 854167 calls. Execution t

can binary arithmetic guru help improve these "bitmasking" ops?

So, much of the pain involved in handling UUID's correctly on the JVM relates to the fact that there is no primitive unsigned numeric type that can represent the full range of possible values of the msb and lsb. Ie., we need to always deal with the unpleasant "am I negative?" approach to reading (w

Re: can binary arithmetic guru help improve these "bitmasking" ops?

Lief you have a really valid point here. I was definitely aware that there are only about a dozen actual masks that get used, so I had been looking for a good way to unroll that computation. So, you definitely have showed me something useful with your macro approach. I think doing that thoug

Re: can binary arithmetic guru help improve these "bitmasking" ops?

Ok, for anyone following my adventures optimizing clj-uuid, I've gotten another substantial win. Check it out: #'uuid/v1:443 nanoseconds #'java.util.UUID/randomUUID: 2000 nanoseconds == user> (criterium

clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

Ok, for anyone following my adventures optimizing clj-uuid, I've gotten another substantial win. Check it out:http://danlentz.github.io/clj-uuid #'uuid/v1:443 nanoseconds #'java.util.UUID/randomUUID: 2012 nanoseconds Also, the test suite has much greater coverage with

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

Dammit, I knew as soon as I went and posted something with numbers I'd find some low hanging fruit I overlooked. So now, 10x as fast. #'uuid/v1:201 nanoseconds #'java.util.UUID/randomUUID: 2012 nanoseconds clj-uuid> (criterium.core/bench (uuid/v1)) Evaluation count :

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

At first I was gonna go with "*Dan's Miraculous UUID-o-Matic: computes a UUID before light can travel 200 feet in a vacuum*" but I got tired of typing the namespace. Thanks for the kind words, though. Dan clj-uuid by danlentz On Monday, March 2, 2015 at

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

I invoked "engineer's privilege" to quote the number very conservatively. In one of the later episodes, didn't Scotty confide that the Enterprise actually went up to warp 11, he just never told anyone? :) Actually, you are right -- I noticed it after I hit "send". As you can tell, the relativ

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

PS. We are now TEN TIMES faster, so it is a lot easier to compute that percentage: #'uuid/v1:201 nanoseconds #'java.util.UUID/randomUUID: 2012 nanoseconds Best, Dan On Tuesday, March 3, 2015 at 3:06:35 PM UTC-5, danl...@gmail.com wrote: > > I invoked "engineer's privilege

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

v1 UUID's are deterministically unique across both space and time. Random UUID's are random. There is an (infinitesimally small chance of a duplicate). To my knowledge, the reason random uuid's exist and are part of the RFC is that they are bone simple to implement, whereas v1 and v3/v5 in

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

Lucas, if there are any good reasons why one should pay 10 times the cost to generate a UUID randomly, I'd like to hear them. Thank you very much for your kind words and please see my prior reply to Colin. Best, Dan On Tuesday, March 3, 2015 at 3:24:42 PM UTC-5, Lucas Bradstreet wrote: > > I'

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

My pleasure! Just to be clear, clj-uuid does NOT use the hardware MAC address and does NOT pose any security concern. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

Also, if someone were given another time based UUID to use as a basis of comparison, they could eliminate 47 more bits of randomness to guess at. So, I think you make a good point that I think will be worthwhile to mention in my documentation. Thank you. -- You received this message because

Re: clj-uuid: time-based uuid now 350% faster than java.util.UUID/randomUUID

Yep. I can't overstate how useful feedback from this group has been to find new ways to optimize the code and to try to make the documentation more clear and useful. On Wednesday, March 4, 2015 at 11:17:30 AM UTC-5, Lucas Bradstreet wrote: > > Thanks for the extra analysis. My feeling was that

Re: [ANN] Understanding the Persistent Vector

This was fantastic. Really looking forward to the RRB Tree. On Wednesday, March 4, 2015 at 12:31:54 PM UTC-5, Jean Niklas L'orange wrote: > > Hi Frank, > > On Wednesday, March 4, 2015 at 12:24:42 PM UTC+1, Frank Castellucci wrote: >> >> Will you be doing this for other data types? >> > > I wil

compile time evaluation

I noticed the macro #'const in the im.chit/hara library: https://github.com/zcaudate/hara/blob/master/src/hara/expression/compile.clj#L3 which is essentially: (defmacro const [body] (eval body)) (const (+ 1 1)) ;; => 2 would it be equivalent (and idiomatic) in clojure to effect compile-ti

Re: compile time evaluation

Thanks -- I deleted the post as soon as I wrote it but, I guess as Shakespeare said, "stupidity will out". Or something along those lines. But awesome about #= that is exactly what i was looking for -- I was thinking of making my own #eval reader tag so that's nice to have. Sorry again for th

Re: [ANN][book] Clojure Reactive Programming

I am now a proud owner of your e-book! Congratulations, I am looking forward to reading this latest addition to my Clojure library. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note th

Re: clojure, not the go to for data science

http://www.scribd.com/doc/30605092/Saturn-v-Flight-Manual I have tracked down the flight manual of the Saturn-V rocket so we can objectively decide whether emacs is more, or less, difficult. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to

[ANN] com.dean.interval-tree

https://github.com/dco-dev/interval-tree I’m pleased to announce that my company has released our first modest contribution back to the Clojure community. In brief, this library provides “interval map”, “interval set”, “ordered-set”, and “ordered-map” collections, but more fundamentally we

Re: [ANN] com.dean.interval-tree

I agree that would be a useful addition to the README. Well, maybe one practical example could be if you had a situation where you scheduled various overlapping shifts of employees and you wanted to know who was on duty at a particular time. Or all of the people on duty during some portion of

Re: ANN: byte vector backed, utf8 strings for Clojure

By "transient-utf8-writer" -- would that give you, effectively, something comparable to what is called an "adjustable-string" in common-lisp? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroup

Function to Generate EDN :readers Map for Namespace Records?

Instead of trying to do it that way, how about just a thin layer of macrology around defrecord? Within the def-record-reader firm you have access to all the info you need for each reader, without extensive code-walking etc -- -- You received this message because you are subscribed to the Goog

[ANN] clj-uuid 0.2.0 (RFC-9652)

Good morning UUID fans. I just wanted to mention that clj-uuid is out and provides support for RFC,http://www.ietf.org/rfc/rfc9562.txt which updates the older RFC-4122 with new features and recommendations. What does this mean to you? Primarily, this means support for two new UUID types: v

Re: [ANN] clj-uuid 0.2.0 (RFC-9652)

and… I botched the subject line.RFC-9562 http://www.ietf.org/rfc/rfc9562.txt On Thursday, September 26, 2024 at 7:13:12 AM UTC-4 danl...@gmail.com wrote: > Good morning UUID fans. I just wanted to mention that clj-uuid is out > and provides support for RFC,http://www.ietf.org/rfc/rfc9562.