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

[danle...@gmail.com]

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 Unique Identifiers) as described by RFC-4122. This library 
extends the standard Java UUID class to provide true v1 (time based) and 
v3/v5 (namespace based) identifier generation. Additionally, a number of 
useful supporting utilities are provided to support serialization and 
manipulation of these UUIDs in a simple, efficient manner.

Why is it useful?

The JVM UUID class only provides a constructor for random (v4) and 
(non-namespaced) pseudo-v3 UUID's. Where appropriate, this library does use 
the internal JVM UUID implementation. The benefit with this library is that 
clj-uuid provides an easy way to get v1 and true namespaced v3 and v5 
UUIDs.  v1 UUIDs are really useful because they can be generated faster 
than v4's as they don't need to call a cryptographic random number 
generator.  v5 UUID's are necessary because many of the interesting things 
that you can do with UUID's require namespaced identifiers.
http://danlentz.github.io/clj-uuid/
http://github.com/danlentz/clj-uuid/


Best,
Dan Lentz

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 is nice to have, thank you! uuid v5 generation seems to be something 
> I reimplement over and over, but which is never big enough for a library. I 
> would like to stop doing that and just include your library in the future.
>
> However, I think your v3/v5 implementations need much more control over 
> canonicalization to guarantee consistent uuid generation on different 
> machines. Right now you just turn a string into bytes with 
> String.getBytes() and feed that to a hash algorithm. The bytes generated 
> are going to depend on the platform charset, and there's no way to just 
> feed plain bytes in to get around this issue because these functions demand 
> a string.
>
> I think you should add a UuidNameBytes protocol and implement a sensible 
> default encoding for strings (say UTF-8), and some implementations for at 
> least byte arrays and uuids. Then your v3/v5 functions can accept anything 
> "byte-able" as a name argument. I've done something like this before and 
> would be happy to submit a pull request if you are interested.
>
> Finally, this is just a style point, but you use :use a fair amount in 
> your namespaces. :use is an anti-pattern in Clojure and avoided because it 
> obscures where the functions come from. (I had a lot of trouble reading 
> your digest namespace because of it!)
>
> On Monday, February 16, 2015 at 7:25:17 PM UTC-6, danl...@gmail.com wrote:
>>
>> Hello Clojurians,
>>
>> I've just been polishing my modest library, clj-uuid <
>> http://danlentz.github.io/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 Unique Identifiers) as described by RFC-4122. This library 
>> extends the standard Java UUID class to provide true v1 (time based) and 
>> v3/v5 (namespace based) identifier generation. Additionally, a number of 
>> useful supporting utilities are provided to support serialization and 
>> manipulation of these UUIDs in a simple, efficient manner.
>>
>> Why is it useful?
>>
>> The JVM UUID class only provides a constructor for random (v4) and 
>> (non-namespaced) pseudo-v3 UUID's. Where appropriate, this library does use 
>> the internal JVM UUID implementation. The benefit with this library is that 
>> clj-uuid provides an easy way to get v1 and true namespaced v3 and v5 
>> UUIDs.  v1 UUIDs are really useful because they can be generated faster 
>> than v4's as they don't need to call a cryptographic random number 
>> generator.  v5 UUID's are necessary because many of the interesting 
>> things that you can do with UUID's require namespaced identifiers.
>> http://danlentz.github.io/clj-uuid/
>> http://github.com/danlentz/clj-uuid/
>>
>>
>> Best,
>> Dan Lentz
>>
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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: 
> http://modularity.org/templates/clean-blog.html
>
> clean-blog is intended as a live site, rather than a static site generator 
> like Cryogen: https://github.com/cryogen-project/cryogen , although it 
> does have a site-generation option via lein gen.
>
> It could be that you want to add a blog section to an existing website, 
> and clean-blog provides those modules.
>
> But mostly it's another demonstration of a working project using Stuart 
> Sierra's component library, showing how to compose applications from 
> components, bespoke and pre-existing ones.
>
> If you want to build your own blog-site in Clojure, and have ideas for 
> custom features you might want to add, clean-blog might give you the 
> jump-start you need.
>
> You can see an example of clean-blog (which I'm using to run my own blog) 
> at http://malcolmsparks.com
>
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 time mean :  1.130674 µs

user> (criterium.core/bench (java.util.UUID/randomUUID))

Evaluation count : 31868100 in 60 samples of 531135 calls.
Execution time mean : 1.920089 µs



On Monday, February 16, 2015 at 8:25:17 PM UTC-5, danl...@gmail.com wrote:
>
> Hello Clojurians,
>
> I've just been polishing my modest library, clj-uuid <
> http://danlentz.github.io/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 Unique Identifiers) as described by RFC-4122. This library 
> extends the standard Java UUID class to provide true v1 (time based) and 
> v3/v5 (namespace based) identifier generation. Additionally, a number of 
> useful supporting utilities are provided to support serialization and 
> manipulation of these UUIDs in a simple, efficient manner.
>
> Why is it useful?
>
> The JVM UUID class only provides a constructor for random (v4) and 
> (non-namespaced) pseudo-v3 UUID's. Where appropriate, this library does use 
> the internal JVM UUID implementation. The benefit with this library is that 
> clj-uuid provides an easy way to get v1 and true namespaced v3 and v5 
> UUIDs.  v1 UUIDs are really useful because they can be generated faster 
> than v4's as they don't need to call a cryptographic random number 
> generator.  v5 UUID's are necessary because many of the interesting 
> things that you can do with UUID's require namespaced identifiers.
> http://danlentz.github.io/clj-uuid/
> http://github.com/danlentz/clj-uuid/
>
>
> Best,
> Dan Lentz
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 (writing) that 64th bit.  To avoid the complexity of all the 
edge cases, we encapsulate the basic primitives of working with
unsigned numbers entirely within the abstraction of "mask" and
"mask offset".  Using these, we built the two fundamental bitwise operations
that are used for most of the UUID calculation: ldb (load-byte) and
dpb (deposit-byte).

This scrap of code from my clj-uuid.bitmop library is extremely useful for 
working 
with "unsigned" long/binary values (analogously to how one might using the 
common-lisp
functions by the same name).  And, it has been "good enough" to do pretty 
well
so far in terms of performance.  But I'm sure that there are gifted 
binariticians
in the audience that can improve this. (Note, the namespace uses 
ztellman/primitive-math
which changes the semantics of some arithmetic operations and some type 
hinting.  Also
some of the 'let's are there for that reason. It may be helpful to refer to 
the link.

;;; https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/bitmop.clj


(defn ^long expt2 [^long pow]
  (bit-set 0 pow))

(defn ^long mask [^long width ^long offset]
  (if (< (+ width offset) 64)
(bit-shift-left (dec (bit-shift-left 1 width)) offset)
(let [x (expt2 offset)]
  (bit-and-not -1 (dec ^long x)

(declare ^long mask-offset ^long mask-width)

(defn ^long mask-offset [^long m]
  (cond
(zero? m) 0
(neg?  m) (- 64 ^long (mask-width m))
:else (loop [c 0]
(if (pos? (bit-and 1 (bit-shift-right m c)))
  c
  (recur (inc c))

(defn ^long mask-width [^long m]
  (if (neg? m)
(let [x (mask-width (- (inc m)))]
  (- 64  ^long x))
(loop [m (bit-shift-right m (mask-offset m)) c 0]
  (if (zero? (bit-and 1 (bit-shift-right m c)))
c
(recur m (inc c))

(defn ^long ldb
  "Load Byte"
  [^long bitmask ^long num]
  (let [off (mask-offset bitmask)]
(bit-and (>>> bitmask ^long off)
  (bit-shift-right num off

(defn ^long dpb
  "Deposit Byte"
  [^long bitmask ^long num ^long value]
  (bit-or (bit-and-not num bitmask)
(bit-and bitmask
  (bit-shift-left value (mask-offset bitmask)

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 though is something I will want 
to revisit a little bit down the line -- ldb and dpb
Have proven themselves useful enough to try to first look at ways to optimize 
them for the "general use" case.  The 
.countTrailingZeros code seems to take a much more efficient approach to 
"mask-offset" and IIRC may completely eliminate
"mask-width".  I'm going to play with it today and I'll report back any 
interesting results.

This group is really a fantastic resource.  You guys are awesome.

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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/bench (uuid/v1))

Evaluation count: 139356300 in 60 samples of 2322605 calls.
Execution time mean: 443.707611 ns


user> (criterium/bench (java.util.UUID/randomUUID))

Evaluation count : 30850980 in 60 samples of 514183 calls.
Execution time mean : 2.012861 µs


Also, the test suite has much greater coverage with individual tests for 
each v1, v,3, v4, v5 uuid version.
And, finally, there more interesting notes about some of the esoteric 
details of the node-id representation
and the way it is calculated to disambiguate it from any legal 802 MAC 
hardware address.  And more


http://danlentz.github.io/clj-uuid

On Tuesday, February 24, 2015 at 7:26:30 AM UTC-5, danl...@gmail.com wrote:
>
> 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 though is something I will 
> want to revisit a little bit down the line -- ldb and dpb 
> Have proven themselves useful enough to try to first look at ways to 
> optimize them for the "general use" case.  The 
> .countTrailingZeros code seems to take a much more efficient approach to 
> "mask-offset" and IIRC may completely eliminate 
> "mask-width".  I'm going to play with it today and I'll report back any 
> interesting results. 
>
> This group is really a fantastic resource.  You guys are awesome. 
>
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 individual tests for 
each v1, v,3, v4, v5 uuid version.
And, finally, there more interesting notes about some of the esoteric 
details of the node-id representation
and the way it is calculated to disambiguate it from any legal 802 MAC 
hardware address.  And more ;)


==

user> (criterium/bench (uuid/v1))

Evaluation count: 139356300 in 60 samples of 2322605 calls.
Execution time mean: 443.707611 ns


user> (criterium/bench (java.util.UUID/randomUUID))

Evaluation count : 30850980 in 60 samples of 514183 calls.
Execution time mean : 2.012861 µs


-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 :302673360 in 60 samples of 5044556 calls.

Execution time mean : 201.153073 ns




On Sunday, March 1, 2015 at 7:35:16 PM UTC-5, danl...@gmail.com wrote:
>
> 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 individual tests for 
> each v1, v,3, v4, v5 uuid version.
> And, finally, there more interesting notes about some of the esoteric 
> details of the node-id representation
> and the way it is calculated to disambiguate it from any legal 802 MAC 
> hardware address.  And more ;)
>
>
> ==
>
> user> (criterium/bench (uuid/v1))
>
> Evaluation count: 139356300 in 60 samples of 2322605 calls.
> Execution time mean: 443.707611 ns
>
>
> user> (criterium/bench (java.util.UUID/randomUUID))
>
> Evaluation count : 30850980 in 60 samples of 514183 calls.
> Execution time mean : 2.012861 µs
>
>
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 4:11:42 AM UTC-5, Colin Yates wrote:
>
> Note - at least in chrome on OS X the link is broken as it terminates at 
> the hype (http://danlentz.github.io/clj-).
>
> Great work despite the chrome breaking project name ;).
>
> On Monday, 2 March 2015 00:35:16 UTC, danl...@gmail.com wrote:
>>
>> 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 individual tests for 
>> each v1, v,3, v4, v5 uuid version.
>> And, finally, there more interesting notes about some of the esoteric 
>> details of the node-id representation
>> and the way it is calculated to disambiguate it from any legal 802 MAC 
>> hardware address.  And more ;)
>>
>>
>> ==
>>
>> user> (criterium/bench (uuid/v1))
>>
>> Evaluation count: 139356300 in 60 samples of 2322605 calls.
>> Execution time mean: 443.707611 ns
>>
>>
>> user> (criterium/bench (java.util.UUID/randomUUID))
>>
>> Evaluation count : 30850980 in 60 samples of 514183 calls.
>> Execution time mean : 2.012861 µs
>>
>>
>>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 relative performance number has been a little bit of a moving 
target as things improved quickly and I grabbed the number from a little 
too far back in the REPL. 

Thanks Jacob.  I really do hope this is a library that people will find 
modestly useful.



On Tuesday, March 3, 2015 at 2:45:38 PM UTC-5, Jacob Strength wrote:
>
> That is pretty amazing, I'll have to remember this library next time I 
> need to use UUID's.
> Also I think you meant 450% faster.
>
> On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:
>>
>> 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 individual tests for 
>> each v1, v,3, v4, v5 uuid version.
>> And, finally, there more interesting notes about some of the esoteric 
>> details of the node-id representation
>> and the way it is calculated to disambiguate it from any legal 802 MAC 
>> hardware address.  And more ;)
>>
>>
>> ==
>>
>> user> (criterium/bench (uuid/v1))
>>
>> Evaluation count: 139356300 in 60 samples of 2322605 calls.
>> Execution time mean: 443.707611 ns
>>
>>
>> user> (criterium/bench (java.util.UUID/randomUUID))
>>
>> Evaluation count : 30850980 in 60 samples of 514183 calls.
>> Execution time mean : 2.012861 µs
>>
>>
>>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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" 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 relative performance number has been a little bit of a moving 
> target as things improved quickly and I grabbed the number from a little 
> too far back in the REPL. 
>
> Thanks Jacob.  I really do hope this is a library that people will find 
> modestly useful.
>
>
>
> On Tuesday, March 3, 2015 at 2:45:38 PM UTC-5, Jacob Strength wrote:
>>
>> That is pretty amazing, I'll have to remember this library next time I 
>> need to use UUID's.
>> Also I think you meant 450% faster.
>>
>> On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:
>>>
>>> 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 individual tests for 
>>> each v1, v,3, v4, v5 uuid version.
>>> And, finally, there more interesting notes about some of the esoteric 
>>> details of the node-id representation
>>> and the way it is calculated to disambiguate it from any legal 802 MAC 
>>> hardware address.  And more ;)
>>>
>>>
>>> ==
>>>
>>> user> (criterium/bench (uuid/v1))
>>>
>>> Evaluation count: 139356300 in 60 samples of 2322605 calls.
>>> Execution time mean: 443.707611 ns
>>>
>>>
>>> user> (criterium/bench (java.util.UUID/randomUUID))
>>>
>>> Evaluation count : 30850980 in 60 samples of 514183 calls.
>>> Execution time mean : 2.012861 µs
>>>
>>>
>>>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 
involve all kinds of non-obvious supporting facilities such as a monotonic 
clock or message-digest algorithm.  

V1 UUID's are uniquified in three different ways: a unique 6 byte node id 
is computed (the details are interesting, but refer to the source for 
more).  It is combined with a thread-safe, concurrent monotonic timestamp 
that is guaranteed to generate always increasing values regardless of clock 
precision or degree of concurrency.  Finally, a 2-byte "clock-seq" value is 
randomly seeded at load-time and incorporated into the calculation.  So, 
even if the system is restarted on the exact same node with the hardware 
clock for some reason adjusted backwards and it is attempted to generate 
another UUID at the exact "same" millisecond as one which had been 
generated prior, there is only a 1 in 65536 chance of issuing a duplicate.  

We do not use the MAC address actually.  clj-uuid/node.clj at master · 
danlentz/clj-uuid 
 has 
more detail, but this topic is specifically addressed by the RFC.  the 
following excerpt describes the node address calculation:

;;   "A better solution is to obtain a 47-bit cryptographic quality random
;;   number and use it as the low 47-bits of the Node-ID, with the least
;;   significant bit of the first octet of the Node-ID set to one.  This
;;   bit is the unicast/multicast bit, which will never be set in IEEE 802
;;   addresses obtained from network cards.  Hence, there can never be a
;;   conflict between UUID's generated by machines with and without network
;;   cards."
;;. . .
;;. . .
;;   "In addition, items such as the computer's name and the name of the
;;   operating system, while not strictly speaking random, will help
;;   differentiate the results from those obtained by other systems...
;;   ... A generic approach... IS TO ACCUMULATE AS MANY SOURCES AS POSSIBLE
;;   INTO A BUFFER, USE A MESSAGE DIGEST SUCH AS MD5 OR SHA1, TAKE AN
;;   ARBITRARY 6 BYTES FROM THE HASH VALUE, AND SET THE MULTICAST BIT
;;   AS DESCRIBED ABOVE."
;;
;; -- [RFC4122:4.5 "Node IDs that do not Identify the Host"]

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.



On Tuesday, March 3, 2015 at 3:11:23 PM UTC-5, Colin Yates wrote:
>
> Are v1 as "unique" as randomUUID()?
>  On 3 Mar 2015 20:08, "danl...@gmail.com "  > wrote:
>
>> 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" 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 relative performance number has been a little bit of a moving 
>>> target as things improved quickly and I grabbed the number from a little 
>>> too far back in the REPL. 
>>>
>>> Thanks Jacob.  I really do hope this is a library that people will find 
>>> modestly useful.
>>>
>>>
>>>
>>> On Tuesday, March 3, 2015 at 2:45:38 PM UTC-5, Jacob Strength wrote:

 That is pretty amazing, I'll have to remember this library next time I 
 need to use UUID's.
 Also I think you meant 450% faster.

 On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:
>
> 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 individual tests 
> for each v1, v,3, v4, v5 uuid version.
> And, finally, there more interesting notes about some of the esoteric 
> details of the node-id representation
> and the way it is calculated to disambiguate it from any legal 802 MAC 
> hardware address.  And more ;)
>
>
> ==
>
> user> (criterium/bench (uuid/v1))
>
> Evaluation count: 139356300 in 60 samples of 2322605 calls.
> Execution time mean: 443.707611 ns
>
>
> user> (criterium/bench (java.util.UUID/randomUUID))
>
> Evaluation count : 30850980 in 60 samples of 514183 calls.
> Ex

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

[danle...@gmail.com]

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've been thinking about this for a bit and our posts just happen to be 
> within a minute of each other! A hash bucket is filling up somewhere, I 
> just know it!
>
> On 4 Mar 2015, at 04:13, Colin Yates > 
> wrote:
>
> Ha - the irony of you and I posting a message about uniqueness at pretty 
> much the same time :).
> On 3 Mar 2015 20:11, "Lucas Bradstreet"  > wrote:
>
>> Hi,
>>
>> Nice work!
>>
>> I wanted to clarify something: it seems to me that the v1 uuids clj-uuid 
>> generate are not exactly equivalent or comparable to the uuids generated by 
>> java.util/randomUUID? It appears that V1 uuids are time (and MAC) based 
>> and don't use a cryptographic random number generator, so the use cases are 
>> different and the speed difference seems like more of a trade off. 
>>
>> If I'm completely off base then please just say so. 
>>
>> Thanks for the good work. Even with the above limitations I can see 
>> myself using the faster version in the future. 
>>
>> Lucas
>>
>> On 2 Mar 2015, at 14:52, Jacob Strength > 
>> wrote:
>>
>> That is pretty amazing, I'll have to remember this library next time I 
>> need to use UUID's.
>> Also I think you meant 450% faster.
>>
>> On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote:
>>>
>>> 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 individual tests for 
>>> each v1, v,3, v4, v5 uuid version.
>>> And, finally, there more interesting notes about some of the esoteric 
>>> details of the node-id representation
>>> and the way it is calculated to disambiguate it from any legal 802 MAC 
>>> hardware address.  And more ;)
>>>
>>>
>>> ==
>>>
>>> user> (criterium/bench (uuid/v1))
>>>
>>> Evaluation count: 139356300 in 60 samples of 2322605 calls.
>>> Execution time mean: 443.707611 ns
>>>
>>>
>>> user> (criterium/bench (java.util.UUID/randomUUID))
>>>
>>> Evaluation count : 30850980 in 60 samples of 514183 calls.
>>> Execution time mean : 2.012861 µs
>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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 members are moderated - please be pa

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

[danle...@gmail.com]

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 new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[danle...@gmail.com]

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 it would be possible, 
> but I wasn't sure. 
>
> Luckily my current use cases don't depend on keeping UUIDs secret, but I 
> was still wondering if there was a trade off. A mention in the docs seems 
> worthwhile. 
>
> Cheers 
>
> > On 4 Mar 2015, at 21:40, "danl...@gmail.com " <
> danl...@gmail.com > wrote: 
> > 
> > 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 you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Understanding the Persistent Vector

[danle...@gmail.com]

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 will have a small break first, but I intend to do the same kind of 
> series for persistent hash maps/sets. Maybe even RRB-trees if people are 
> interested (I found them to be pretty hard to grasp by the paper alone).
>
> Again, Great Work!
>>
>
> Thanks! =)
>
> -- Jean Niklas
>
>
> Frank
>>
>> On Saturday, February 28, 2015 at 11:14:17 AM UTC-5, Jean Niklas L'orange 
>> wrote:
>>>
>>> Hello fellow Clojurians,
>>>
>>> I am happy to announce that I have finished my blogpost series on the 
>>> persistent
>>> vector. It consists of five parts:
>>>
>>>1. The basic algorithms 
>>>
>>>2. Indexing 
>>>
>>>3. The tail optimisation 
>>>
>>>4. Transients 
>>>
>>>5. Performance 
>>> 
>>>(which is a summary of this detailed blogpost 
>>>)
>>>
>>> I hope this will help you to get a good understanding of how the 
>>> algorithms on
>>> the data structure work, how the optimisations work, and how efficient 
>>> it is on
>>> the JVM.
>>>
>>> Constructive criticism, both positive and negative, is appreciated.
>>>
>>> Enjoy!
>>>
>>> (NB: I haven't gotten around to fix the illustrations in part 3, so
>>> unfortunately it will be a bit hard to read if you print it out in 
>>> grayscale.
>>> It's on my todo-list.)
>>>
>>> -- Jean Niklas L'orange
>>>
>>>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

compile time evaluation

[danle...@gmail.com]

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-time 
evaluation with quasi-quotation, instead?

`~(+ 1 1)

;; => 2

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: compile time evaluation

[danle...@gmail.com]

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 the dumb question though.



On Thursday, March 19, 2015 at 1:46:02 PM UTC-4, Ambrose Bonnaire-Sergeant 
wrote:
>
> Not equivalent, macro expansion happens at compile time, unquotes are 
> evaluated at runtime.
>
> On Thu, Mar 19, 2015 at 11:59 AM, danl...@gmail.com  <
> danl...@gmail.com > wrote:
>
>> 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-time 
>> evaluation with quasi-quotation, instead?
>>
>> `~(+ 1 1)
>>
>> ;; => 2
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN][book] Clojure Reactive Programming

[danle...@gmail.com]

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 that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure, not the go to for data science

[danle...@gmail.com]

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 this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] com.dean.interval-tree

[danle...@gmail.com]

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 use 
this as a library for building efficient, ordered collection types on an 
extensible weight-balanced tree. 

This code has been in production for a few years now, however it is still 
young in terms of a publicly released data-structure  library.   Comments 
and suggestions are, of course, very much welcome!

Best, 

Dan Lentz
Dean & Company

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/f5b4a13c-e5df-4fcc-957c-aaebeb715fabn%40googlegroups.com.

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

[danle...@gmail.com]

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 a given timeframe. 

On Tuesday, April 6, 2021 at 11:53:42 AM UTC-4 peste...@gmail.com wrote:

> Very cool, thanks for sharing!
>
> This looks like it would be perfect for Advent of Code puzzles. Out of
> curiosity, what are real-life problems that benefit from the use of an
> interval map?
>
> On Tue, Apr 6, 2021 at 2:04 PM danl...@gmail.com  
> wrote:
> >
> >
> > 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 use 
> this as a library for building efficient, ordered collection types on an 
> extensible weight-balanced tree.
> >
> > This code has been in production for a few years now, however it is 
> still young in terms of a publicly released data-structure library. 
> Comments and suggestions are, of course, very much welcome!
> >
> > Best,
> >
> > Dan Lentz
> > Dean & Company
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clojure/f5b4a13c-e5df-4fcc-957c-aaebeb715fabn%40googlegroups.com
> .
>

-- 
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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/1ea8346f-ac9c-47e7-a06e-f7511ac01439n%40googlegroups.com.

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

[danle...@gmail.com]

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@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Function to Generate EDN :readers Map for Namespace Records?

[danle...@gmail.com]

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 Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[danle...@gmail.com]

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:

v6 — a fast, time-encoding, lexically sortable, unique identifier. This  is 
a field-compatible version of v1, reordered for improved DB locality. 

v7 — unix time-encoding, lexically sortable, index-friendly UUID with 
randomized monotonic counter, and cryptographically secure random portion. 
As such, creation of v7 UUIDs may be slower, but have improved entropy 
characteristics compared to v1 or v6 UUIDs.

This release is fully backward compatible with also some improvements and 
bug fixes, so I’d recommend all users upgrade to [danlentz/clj-uuid "0.2.0"]

 If interested, please read on at https://github.com/danlentz/clj-uuid

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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/215e7518-29fd-45e2-8ac6-5ac837f84f2en%40googlegroups.com.

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

[danle...@gmail.com]

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.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:
>
> v6 — a fast, time-encoding, lexically sortable, unique identifier. This 
>  is a field-compatible version of v1, reordered for improved DB locality. 
>
> v7 — unix time-encoding, lexically sortable, index-friendly UUID with 
> randomized monotonic counter, and cryptographically secure random portion. 
> As such, creation of v7 UUIDs may be slower, but have improved entropy 
> characteristics compared to v1 or v6 UUIDs.
>
> This release is fully backward compatible with also some improvements and 
> bug fixes, so I’d recommend all users upgrade to [danlentz/clj-uuid 
> "0.2.0"]
>
>  If interested, please read on at https://github.com/danlentz/clj-uuid
>
> 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 members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/af5c3642-c87f-42a2-98a7-18621fd36137n%40googlegroups.com.