Re: Using a function in another function

[Max Countryman]

The issue is (add1 (add1 [x])) is malformed: you probably mean (add1 (add1 x)).

An addn function could be implemented with iterate:

(defn addn [n x]
  (nth (iterate add1 x) n))


> On Nov 10, 2016, at 06:51, 'Rickesh Bedia' via Clojure 
>  wrote:
> 
> I have this function:
> (defn add1 [x]
> (+ 1 x))
> which is just a very simple function that adds 1.
> 
> I now want to create a new function called add2 that uses add1 twice.
> I have tried
> (defn add2 [x]
> (add1 (add1 [x]))
> but this doesn't work. (Can someone explain why this doesn't work. I think 
> its maybe I am calling the function incorrectly)
> 
> I have ideas about using recur because I eventually want to create a function 
> addn where the function takes arguments n and x and calls add1 n times to x
> 
> -- 
> 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 
> .

-- 
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] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

> On Jun 22, 2016, at 06:27, Bruno Bonacci  wrote:
> 
> @Brian, The clock drift problem was in answer to your question and generally 
> it was referring to the pure System/currentTimeMillis implementation. The 
> System/nanoTime, as it is now, is completely broken as it offsets against the 
> wall clock and not the previous System/nanotime, but that it is easy to fix.

Note that the current implementation mirrors Skuld’s.

When calculating a timestamp we provide an epoch, derived at startup. The epoch 
is constructed by taking a sampling of the difference between 
System/currentTimeMillis and System/nanoTime and averaging the results: this is 
meant to detect jitter. We don’t use the wall clock at any point after that for 
constructing flakes.

Because timestamps are persisted to disk, the next time we run our generator, 
we ensure that the epoch used is always larger than the last timestamp written. 
(We could also use the epoch to derive a timestamp and ensure the derived 
timestamp is larger, which might be better thinking about it now.) This 
protects against clock skew between runs.

To address your question about clock skew during runs, it’s true that 
System/nanoTime is not necessarily monotonic. However the process of generating 
a new flake always rejects timestamps that appear in the past relative to the 
last flake. So a monotonic property is built into our program. As you note, 
this could result in thrashing if the delta is extreme or System/nanoTime is 
somehow always returning smaller values—but I don’t know of a better way of 
addressing that issue currently.

I think the salient point here though is that we do enforce a monotonic 
property at the application level which should protect us against duplicate IDs.

-- 
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] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

I also released Flake 0.4.2 today which includes an important bugfix where two 
competing threads could have caused duplicate IDs in certain circumstances as 
well as a new method for deriving timestamps.


> On Jun 21, 2016, at 16:29, Max Countryman  wrote:
> 
> Brian,
> 
> I think you make good points here, especially with regard to the size of IDs.
> 
> I’d also like to point out that while adding the process and thread IDs 
> helps, it doesn’t eliminate the possibility of duplicate IDs: this is why 
> it’s necessary to write out the last used timestamp in a separate thread.
> 
> Just a clarification with regard to disk persistence: we aren’t writing out 
> the epoch, we’re writing out the last used timestamp periodically, in its own 
> thread. Yes, the `init!` API is cumbersome, but it’s an important safety 
> valve which helps protect against duplicate IDs.
> 
> My understanding from reading the documentation and various StackOverflow 
> answers is that System/nanoTime is monotonic, but I don’t know what 
> guarantees it makes across threads.
> 
> 
> Max
> 
> 
>> On Jun 21, 2016, at 10:00, Brian Platz > <mailto:brian.platz@place.works>> wrote:
>> 
>> Bruno,
>> 
>> I think the more you can reduce the chance of collision the better and the 
>> thread-local capability is a good idea, but in the process you've almost 
>> doubled the bits.
>> 
>> For me anyhow, an ID need to be produceable at a reasonable rate (1 million 
>> a second per machine is good for me), have near-zero probability of 
>> collision and take up the least amount of space possible.
>> 
>> Under those criteria, I think 128 bits is a reasonable target and the 
>> thread-safe atom I would expect to handle such volume (although I haven't 
>> tested).
>> 
>> If you need a billion per second and don't want 100 machines producing them, 
>> then I think you are at the point of needing to have thread independence and 
>> probably have to increase the bit-count, and your ideas provide a good path 
>> towards such a solution.
>> 
>> Your comment on the file persistence is a good one, I wonder if the 
>> potential problems are real enough to warrant the risks.
>> 
>> My other curiosity is if System/nanoTime is guaranteed to increment across 
>> threads. I know at least a while ago that this guarantee did not exist.
>> 
>> -Brian
>> 
>> 
>> On Tuesday, June 21, 2016 at 8:38:58 AM UTC-4, Bruno Bonacci wrote:
>> 
>> Hi this change it is actually easier than it sounds. Looking at the code, I 
>> came across a couple of things which I think might be better.
>> 
>> 1) use of filesystem persistence.
>> 
>> Not too sure that the file based persistence is a good idea. Maybe this is a 
>> good idiomatic design for Erlang, but definitely it doesn't look nice in 
>> Clojure.
>>  
>> In particular I'm not too sure that by storing the init time epoc we 
>> actually accomplish anything at all.
>> I would argue that there are a number of problems there, race conditions on 
>> data, tmp file purged out, and still doesn't protect against the case the 
>> clock drift during the use.
>> 
>> 2) use of CAS (atom) for storing the VM state.
>> If if is truly decentralized then you shouldn't need an atom at all. The 
>> disadvantage of the CAS is that, when many thread race to the same change, 
>> only one will succeed and all the other ones will fail and retry. Which mean 
>> that if you have 100 threads (for example) only 1 will succeed all the other 
>> 99 will fail and retry. Again at the second round only 1 will succeed and 98 
>> will retry, and so on.
>> Therefore the total number of attempts will be 
>> 
>>  
>> <https://lh3.googleusercontent.com/-ZVELcKNoB9M/V2kxgYmlFMI/B8Q/nR6jLFjKSI0611-WiQpQHXAcY3SueVIdwCLcB/s1600/Screen%2BShot%2B2016-06-21%2Bat%2B13.21.24.png>
>> 
>> If you want to develop a real "decentralized" id generator, I think, you 
>> need to drop the atom in favour of a thread local store.
>> Now to do so and make collision impossible we need to add more bits:
>> 
>> 64 bits - ts (i.e. a timestamp )
>> 48 bits - worker-id/node (i.e. MAC address)
>> 32 bits - worker-id/process (pid) 
>> 64 bits - worker-id/thread (thread num)
>> 32 bits - seq-no (i.e. a counter)
>> By adding the process id (pid) and the thread id there is possibility of 
>> having two systems running and creating the same id at the same time.
>> Finally by using thread-local storage there is no need of p

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Brian,

I think you make good points here, especially with regard to the size of IDs.

I’d also like to point out that while adding the process and thread IDs helps, 
it doesn’t eliminate the possibility of duplicate IDs: this is why it’s 
necessary to write out the last used timestamp in a separate thread.

Just a clarification with regard to disk persistence: we aren’t writing out the 
epoch, we’re writing out the last used timestamp periodically, in its own 
thread. Yes, the `init!` API is cumbersome, but it’s an important safety valve 
which helps protect against duplicate IDs.

My understanding from reading the documentation and various StackOverflow 
answers is that System/nanoTime is monotonic, but I don’t know what guarantees 
it makes across threads.


Max


> On Jun 21, 2016, at 10:00, Brian Platz  wrote:
> 
> Bruno,
> 
> I think the more you can reduce the chance of collision the better and the 
> thread-local capability is a good idea, but in the process you've almost 
> doubled the bits.
> 
> For me anyhow, an ID need to be produceable at a reasonable rate (1 million a 
> second per machine is good for me), have near-zero probability of collision 
> and take up the least amount of space possible.
> 
> Under those criteria, I think 128 bits is a reasonable target and the 
> thread-safe atom I would expect to handle such volume (although I haven't 
> tested).
> 
> If you need a billion per second and don't want 100 machines producing them, 
> then I think you are at the point of needing to have thread independence and 
> probably have to increase the bit-count, and your ideas provide a good path 
> towards such a solution.
> 
> Your comment on the file persistence is a good one, I wonder if the potential 
> problems are real enough to warrant the risks.
> 
> My other curiosity is if System/nanoTime is guaranteed to increment across 
> threads. I know at least a while ago that this guarantee did not exist.
> 
> -Brian
> 
> 
> On Tuesday, June 21, 2016 at 8:38:58 AM UTC-4, Bruno Bonacci wrote:
> 
> Hi this change it is actually easier than it sounds. Looking at the code, I 
> came across a couple of things which I think might be better.
> 
> 1) use of filesystem persistence.
> 
> Not too sure that the file based persistence is a good idea. Maybe this is a 
> good idiomatic design for Erlang, but definitely it doesn't look nice in 
> Clojure.
>  
> In particular I'm not too sure that by storing the init time epoc we actually 
> accomplish anything at all.
> I would argue that there are a number of problems there, race conditions on 
> data, tmp file purged out, and still doesn't protect against the case the 
> clock drift during the use.
> 
> 2) use of CAS (atom) for storing the VM state.
> If if is truly decentralized then you shouldn't need an atom at all. The 
> disadvantage of the CAS is that, when many thread race to the same change, 
> only one will succeed and all the other ones will fail and retry. Which mean 
> that if you have 100 threads (for example) only 1 will succeed all the other 
> 99 will fail and retry. Again at the second round only 1 will succeed and 98 
> will retry, and so on.
> Therefore the total number of attempts will be 
> 
>  
> 
> 
> If you want to develop a real "decentralized" id generator, I think, you need 
> to drop the atom in favour of a thread local store.
> Now to do so and make collision impossible we need to add more bits:
> 
> 64 bits - ts (i.e. a timestamp )
> 48 bits - worker-id/node (i.e. MAC address)
> 32 bits - worker-id/process (pid) 
> 64 bits - worker-id/thread (thread num)
> 32 bits - seq-no (i.e. a counter)
> By adding the process id (pid) and the thread id there is possibility of 
> having two systems running and creating the same id at the same time.
> Finally by using thread-local storage there is no need of process level 
> coordination (atom) and no risk of retries because every process is stepping 
> on each others toes.
> 
> With such setup 100 threads will be able to increment their own thread local 
> counter independently (given that you have 100 execution cores).
> 
> What do you think?
> Bruno
> 
>  
> 
> 
> -- 
> 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 

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Hi Bruno,

> On Jun 17, 2016, at 03:49, Bruno Bonacci  wrote:
> 
> Hi Max,
> 
> That's a interesting library thanks.
> 
> Does the library guarantee monotonically increasing IDs? Eg protection 
> against clock reset and other clock fluctuations?

Like the Erlang implementation, Flake asks the user to call an init 
function—this writes out the last known timestamp to disk in a separate thread. 
Next time the Flake process is run, it compares the current time to the time 
written to disk and throws an exception if time seems to moving in the wrong 
direction.

Apart from that, the generation function does a comparison of timestamps as 
well, again throwing an exception if the last known timestamp as compared to 
the current is in the future.

These are the same guarantees that Boundary’s implementation seems to make with 
what I believe is a slight improvement on the persisted timer (writing out the 
actual Flake timestamp instead of just an arbitrary interval). 

> Another thing I've noticed is that you are using (System/currentTimeMillis) 
> to get the wall clock on every generation.
> 
> (System/currentTimeMillis) causes a low level system call which in turn 
> causes a context switch.
> 
> Maybe one way to improve could be use a initial (System/currentTimeMillis) on 
> the first init! and then
> use System/nanoTime to calculate the time elapsed from the init.
> The advantage would be that System/nanoTime runs in the UserSpace (not Kernel 
> Space) and it doesn't require
> a system call (so no context switch).
> 
> This could really help the case of a bulk production of IDs and any other 
> burst situation.

I really like this idea. I’m certainly open to pull requests if you wanted to 
take a stab at it otherwise I may try my hand at making this improvement. :)

> 
> Bruno 
> 
> 
> On Friday, June 3, 2016 at 4:40:26 PM UTC+1, Max Countryman wrote:
> Hi Mark,
> 
> I haven’t done any benchmarking comparing Flakes to UUIDs. However the 
> primary benefit of flake IDs, over a traditional UUID, e.g. UUID-1, is flakes 
> do not require coordination (i.e. to avoid clock-skew and duplicate IDs), 
> provide k-ordering (UUID-1’s bit ordering breaks this), and use the standard 
> Unix epoch. It would be interesting to compare performance, but the features 
> of flakes are certainly their primary selling points.
> 
> 
> Max
> 
>> On Jun 2, 2016, at 20:38, Mark Engelberg > > wrote:
>> 
>> This is interesting.  Is it faster than uuid for generation and/or comparing 
>> for equality?
>> 
>> On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman > 
>> wrote:
>> Hi,
>> 
>> I’m happy to announce a new release of Flake, the decentralized, k-ordered 
>> unique ID generator.
>> 
>> Flake 0.4.0 includes a number of important breaking changes, but by far the 
>> most important is dropping `generate` in favor of `generate!` which now 
>> returns a ByteBuffer. Previously `generate` returned a BigInteger, however 
>> this arbitrarily limits how an application can handle IDs and goes against 
>> the spirit of the Erlang implementation. In order to maintain backwards 
>> compatibility, a helper `flake->bigint` was added to the core namespace. 
>> Applications which already consume flakes should update their calls to 
>> `generate` so they are `generate!` and wrap them with `flake->bigint` if 
>> BigIntegers are desirable or already used.
>> 
>> Github: https://github.com/maxcountryman/flake 
>> <https://github.com/maxcountryman/flake>
>> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md 
>> <https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md>
>> 
>> Thanks!
>> 
>> 
>> Max
>> 
>> --
>> 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 
>> <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 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>&

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Hi again Mark,

I set up some basic micro-benchmarks 
<https://github.com/maxcountryman/flake/blob/b5cddf0069ae7e0d2db2e13206929a6c6d08f0f1/test/flake/test_core.clj#L75-L85>
 out of curiosity. Full disclosure, I’m not entirely sure I’m using criterium 
correctly here, but the results on my machine seem to show comparable 
performance: Flake generation is slightly faster (by a few nanoseconds) and 
Flake comparison is slightly slower (also by a few nanoseconds) as compared to 
Java’s random UUID.

Just to reiterate what I said before, while it’s encouraging to see the 
performance is perhaps at least comparable to at least one implementation of a 
UUID, that really isn’t the reason to use Flakes in the first place.

Also if my tests aren’t set up correctly, I’d certainly appreciate any help 
correcting them!


Max

> On Jun 3, 2016, at 08:40, Max Countryman  wrote:
> 
> Hi Mark,
> 
> I haven’t done any benchmarking comparing Flakes to UUIDs. However the 
> primary benefit of flake IDs, over a traditional UUID, e.g. UUID-1, is flakes 
> do not require coordination (i.e. to avoid clock-skew and duplicate IDs), 
> provide k-ordering (UUID-1’s bit ordering breaks this), and use the standard 
> Unix epoch. It would be interesting to compare performance, but the features 
> of flakes are certainly their primary selling points.
> 
> 
> Max
> 
>> On Jun 2, 2016, at 20:38, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>> 
>> This is interesting.  Is it faster than uuid for generation and/or comparing 
>> for equality?
>> 
>> On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman > <mailto:m...@me.com>> wrote:
>> Hi,
>> 
>> I’m happy to announce a new release of Flake, the decentralized, k-ordered 
>> unique ID generator.
>> 
>> Flake 0.4.0 includes a number of important breaking changes, but by far the 
>> most important is dropping `generate` in favor of `generate!` which now 
>> returns a ByteBuffer. Previously `generate` returned a BigInteger, however 
>> this arbitrarily limits how an application can handle IDs and goes against 
>> the spirit of the Erlang implementation. In order to maintain backwards 
>> compatibility, a helper `flake->bigint` was added to the core namespace. 
>> Applications which already consume flakes should update their calls to 
>> `generate` so they are `generate!` and wrap them with `flake->bigint` if 
>> BigIntegers are desirable or already used.
>> 
>> Github: https://github.com/maxcountryman/flake 
>> <https://github.com/maxcountryman/flake>
>> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md 
>> <https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md>
>> 
>> Thanks!
>> 
>> 
>> Max
>> 
>> --
>> 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 
>> <mailto: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 
>> <mailto:clojure%2bunsubscr...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en 
>> <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 
>> <mailto:clojure%2bunsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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 
>> <mailto: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 
>> <mailto:clojure+unsubscr...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en 
>> <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 g

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Hi again,

I just released flake 0.4.1, containing a bugfix where `timer/read-timestamp` 
would throw an uncaught exception when the provided path did not exist.

Thanks,


Max

> On Jun 2, 2016, at 18:03, Max Countryman  wrote:
> 
> Hi,
> 
> I’m happy to announce a new release of Flake, the decentralized, k-ordered 
> unique ID generator.
> 
> Flake 0.4.0 includes a number of important breaking changes, but by far the 
> most important is dropping `generate` in favor of `generate!` which now 
> returns a ByteBuffer. Previously `generate` returned a BigInteger, however 
> this arbitrarily limits how an application can handle IDs and goes against 
> the spirit of the Erlang implementation. In order to maintain backwards 
> compatibility, a helper `flake->bigint` was added to the core namespace. 
> Applications which already consume flakes should update their calls to 
> `generate` so they are `generate!` and wrap them with `flake->bigint` if 
> BigIntegers are desirable or already used.
> 
> Github: https://github.com/maxcountryman/flake
> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md
> 
> Thanks!
> 
> 
> Max
> 
> -- 
> 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.

-- 
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] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Hi Mark,

I haven’t done any benchmarking comparing Flakes to UUIDs. However the primary 
benefit of flake IDs, over a traditional UUID, e.g. UUID-1, is flakes do not 
require coordination (i.e. to avoid clock-skew and duplicate IDs), provide 
k-ordering (UUID-1’s bit ordering breaks this), and use the standard Unix 
epoch. It would be interesting to compare performance, but the features of 
flakes are certainly their primary selling points.


Max

> On Jun 2, 2016, at 20:38, Mark Engelberg  wrote:
> 
> This is interesting.  Is it faster than uuid for generation and/or comparing 
> for equality?
> 
> On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman  <mailto:m...@me.com>> wrote:
> Hi,
> 
> I’m happy to announce a new release of Flake, the decentralized, k-ordered 
> unique ID generator.
> 
> Flake 0.4.0 includes a number of important breaking changes, but by far the 
> most important is dropping `generate` in favor of `generate!` which now 
> returns a ByteBuffer. Previously `generate` returned a BigInteger, however 
> this arbitrarily limits how an application can handle IDs and goes against 
> the spirit of the Erlang implementation. In order to maintain backwards 
> compatibility, a helper `flake->bigint` was added to the core namespace. 
> Applications which already consume flakes should update their calls to 
> `generate` so they are `generate!` and wrap them with `flake->bigint` if 
> BigIntegers are desirable or already used.
> 
> Github: https://github.com/maxcountryman/flake 
> <https://github.com/maxcountryman/flake>
> Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md 
> <https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md>
> 
> Thanks!
> 
> 
> Max
> 
> --
> 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 
> <mailto: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 
> <mailto:clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> <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 
> <mailto:clojure%2bunsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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 
> <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 
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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.

[ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

[Max Countryman]

Hi,

I’m happy to announce a new release of Flake, the decentralized, k-ordered 
unique ID generator.

Flake 0.4.0 includes a number of important breaking changes, but by far the 
most important is dropping `generate` in favor of `generate!` which now returns 
a ByteBuffer. Previously `generate` returned a BigInteger, however this 
arbitrarily limits how an application can handle IDs and goes against the 
spirit of the Erlang implementation. In order to maintain backwards 
compatibility, a helper `flake->bigint` was added to the core namespace. 
Applications which already consume flakes should update their calls to 
`generate` so they are `generate!` and wrap them with `flake->bigint` if 
BigIntegers are desirable or already used.

Github: https://github.com/maxcountryman/flake
Changes: https://github.com/maxcountryman/flake/blob/master/CHANGELOG.md

Thanks!


Max

-- 
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: find shorter clojure code automatically

[Max Countryman]

Hi Jeremy,

My understanding is Eastwood might be a tool which can find some specific kinds 
of syntax sugar in automated way. Check it out:  

https://github.com/jonase/eastwood/blob/master/README.md


Max

> On Mar 4, 2016, at 03:33, Jeremy Vuillermet  
> wrote:
> 
> Hello,
> 
> Every time I go to a code base I don't know, I discover new functions from 
> clojure api that I was not aware of. 
> Those are usually simple shortcut functions that don't do much but make the 
> code shorter.
> 
> Just doing a research on this group for "shorter code" and "better code" 
> there are some cases like that.
> For example (first (first mycoll)) can be shortened with (ffirst mycoll). 
> There are so many place, as a relatively new clojure programmer, where I 
> could shorten code like that.
> 
> So my question is : Do we have a tool where we can copy/paste some code or 
> link github repo to find those opportunities for improvement.
> 
> If no, would it be hard to make such a tool ? Does this need regex or dealing 
> with the ast ?
> 
> Thanks
> Jeremy
> -- 
> 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.

-- 
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: Heard about clojure today. is it one of the big tecnologies for the future? or is it becoming deprecated?

[Max Countryman]

Clojure is not becoming deprecated. A major release happened just yesterday in 
fact.


> On Jan 20, 2016, at 08:04, Miguel Domingos  
> wrote:
> 
> Hi,
> 
> Just checked GIT Hub Pulse and it is very low. I just heard about this 
> technology today, so I don't know.
> https://github.com/clojure/clojure/pulse
> 
> Thanks,
> Miguel
> 
> -- 
> 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 
> .

-- 
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: Library suggestions requested for clojure-toolbox.com

[Max Countryman]

Hi James,

I’m not sure if it’s worth mentioning, but I wrote a port of Boundary’s Flake 
k-ordered unique ID generator for Clojure:

https://github.com/maxcountryman/flake 


Max

> On Oct 5, 2015, at 12:40, James Reeves  wrote:
> 
> If you've written or know about a Clojure or ClojureScript library, and it's 
> not already on clojure-toolbox.com , I'd 
> like to hear about it.
> 
> Post the name and URL (and an optional category) as reply to this message, 
> and I'll add it to the site.
> 
> - James
> 
> -- 
> 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 
> .

-- 
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: A generalization of iterate

[Max Countryman]

Your problem with recur is because you can only recur from the tail position. 

> On Sep 23, 2015, at 12:28, nchurch  wrote:
> 
> Yeah, it consumes stack just like the Clojurescript version of Iterate.  I'm 
> curious if anyone knows how to avoid this.  The Clojure version of Iterate is 
> Java; and for some reason 'recur' can't be used inside of lazy-cat (not 
> really documented, but apparently true). 
> 
>> On Tuesday, September 22, 2015 at 9:21:57 PM UTC-7, Max Countryman wrote:
>> I wonder if something like this is a little easier to read?
>> 
>> (defn generate
>>   ([f coll]
>>(generate f coll (reverse coll)))
>>   ([f coll args]
>>(let [next-val (apply f args)]
>>  (lazy-cat coll (generate f [next-val] (conj (butlast args) 
>> next-val))
>> 
>> Where your Fibonacci example becomes:
>> 
>> (take 100 (generate +’ [1 1]))
>> 
>> As for your other questions, I can’t be of much help. But isn’t there 
>> nontrivial memory overhead to consider with this approach?
>> 
>> 
>>> On Sep 22, 2015, at 18:19, nchurch  wrote:
>>> 
>>> I was going through 4clojure (highly recommended!) and doing the Fibonacci 
>>> exercise.  It occurred to me that the iterate function could be generalized 
>>> in a reasonable way, so that the next value is generated by applying the 
>>> function to the last N items so far, where N is the number of initial 
>>> arguments beyond the function.  Thus:
>>> 
>>> (generate inc 1) 
>>> 
>>> works just like iterate, while
>>> 
>>> (generate + 1 1)
>>> 
>>> generates the Fibonacci sequence.
>>> 
>>> Here's the code:
>>> 
>>> (defn generate
>>>   [f & more]
>>>   (letfn [(recurse
>>> [coll args]
>>> (let [next-val (apply f args)]
>>>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
>>> next-val)]
>>> (recurse more (reverse more
>>> 
>>> Code is also on Github.
>>> 
>>> I see this as part of a larger class of generalized sequence functions: for 
>>> instance, extra arguments in a function given to reduce could refer to N 
>>> arguments back in the sequence (might be useful, for instance, in smoothing 
>>> a sequence of values using an average).
>>> 
>>> Questions: is there an existing home for this kind of functionality?  And 
>>> could the above code be improved?  (I just used the definition of iterate 
>>> as a starting point.)
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 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.

-- 
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: A generalization of iterate

[Max Countryman]

I wonder if something like this is a little easier to read?

(defn generate
  ([f coll]
   (generate f coll (reverse coll)))
  ([f coll args]
   (let [next-val (apply f args)]
 (lazy-cat coll (generate f [next-val] (conj (butlast args) next-val))

 Where your Fibonacci example becomes:

(take 100 (generate +’ [1 1]))

As for your other questions, I can’t be of much help. But isn’t there 
nontrivial memory overhead to consider with this approach?


> On Sep 22, 2015, at 18:19, nchurch  wrote:
> 
> I was going through 4clojure (highly recommended!) and doing the Fibonacci 
> exercise.  It occurred to me that the iterate function could be generalized 
> in a reasonable way, so that the next value is generated by applying the 
> function to the last N items so far, where N is the number of initial 
> arguments beyond the function.  Thus:
> 
> (generate inc 1) 
> 
> works just like iterate, while
> 
> (generate + 1 1)
> 
> generates the Fibonacci sequence.
> 
> Here's the code:
> 
> (defn generate
>   [f & more]
>   (letfn [(recurse
> [coll args]
> (let [next-val (apply f args)]
>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
> next-val)]
> (recurse more (reverse more
> 
> Code is also on Github .
> 
> I see this as part of a larger class of generalized sequence functions: for 
> instance, extra arguments in a function given to reduce could refer to N 
> arguments back in the sequence (might be useful, for instance, in smoothing a 
> sequence of values using an average).
> 
> Questions: is there an existing home for this kind of functionality?  And 
> could the above code be improved?  (I just used the definition of iterate as 
> a starting point.)
> 
> 
> 
> 
> -- 
> 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 
> .

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

Tools comparable to Luigi for Clojure or the JVM?

[Max Countryman]

Hi,

I’m working on a project at work for which we’re currently considering a Python 
tool built by Spotify called Luigi[1]. Luigi is a tool for building data 
processing pipelines (hence the name). It’s capable of connecting to various 
processors such as Hadoop and is limited in scope to building and managing 
these pipelines as a directed graph. I’m curious if there are similar tools for 
the JVM we should be taking into consideration? (Certainly a big plus if it’s 
Clojure, from my perspective.) Note that we’re processing a relatively small 
amount of data: at this point we’re just taking in some server logs and doing 
post-processing over them to build aggregates of certain statistics.

Thanks,


Max

[1] https://github.com/spotify/luigi

-- 
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/Pedestal vs Go

[Max Countryman]

Alan,

Absolutely no need to apologize! :) I would hardly consider myself an expert 
either, I’m basing my understanding on the experiences I’ve had at my day job 
and the large body of developing articles and blogposts related to the language 
that seem to pop up at a near-constant rate on your favorite programming news 
aggregator.

If people are doing FP with Go somewhere, that’s awesome and I would love to 
see it. My suspicion is it’s difficult and generally not what you “want” to be 
doing with the language. Go’s popularity is a big disappoint for me personally, 
but again your experience may differ.


Max

> On Sep 15, 2015, at 10:18, Alan Moore  wrote:
> 
> Max,
> 
> You obviously know way more than I do about Go... I stand corrected, thanks. 
> I did know that it doesn't support TCO so it doesn't surprise me that other 
> language features went the wrong way too.
> 
> I did not mean to misinform anyone, my apologies for speaking beyond my core 
> competency (Go is not one of them.) I was trying to give our friend some 
> hope... Those of us with day jobs in C/C++ (and Go) need some of that to keep 
> us sane. :-(
> 
> Alan
> 
> -- 
> 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.

-- 
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/Pedestal vs Go

[Max Countryman]

Hi Alan,

>From my experience this is not true: Go does not provide generics and actively 
>resists what most of us would consider good functional programming--Go is very 
>opinionated and doesn't allow much deviation from these opinions, by design.  
>So implementing practical immutable data structures would be difficult and 
>likely of limited utility in Go. That said, you should still try yourself if 
>given the opportunity. 


Max

> On Sep 14, 2015, at 21:44, Alan Moore  wrote:
> 
> One more thing: if you are truly stuck with Go you can still adopt functional 
> patterns, style and data structures to good effect. Just because the opening 
> paren is on the wrong side of the function name doesn't mean you can't find 
> (or write?) an immutable data structure library for Go and promote functional 
> programming ideas within your team.
> 
> Here is are some simple examples from C++ (from one of the authors of the D 
> language):
> 
> http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c
> http://bartoszmilewski.com/2013/11/25/functional-data-structures-in-c-trees
> https://github.com/BartoszMilewski/Okasaki
> 
> I'm pretty sure you could port these or some other implementation to Go 
> fairly easily - YMMV.
> 
> Alan
> 
>> On Mon, Sep 14, 2015 at 7:18 PM, Alan Moore  
>> wrote:
>> I'll second Paul's comments and raise you two:
>> 
>> 1) Depending on your app's use cases, speed going forward will be gained 
>> primarily from parallelism. I think Clojure has a better story there than Go 
>> but that is just my opinion.
>> 
>> 2) It is very hard to fight against cultural bias against the JVM. I work in 
>> embedded systems where anything but C/C++ (or Lua, Python) is taboo. Your 
>> best bet is to "Go" with their momentum and when they run into a roadblock 
>> in Go (probably something related to mutability/locks in the face of heavy 
>> load), give a shot at the same problem with Clojure.
>> 
>> Obviously this has to be done in a non-intrusive way (on the other end of a 
>> socket) but will give you a chance to prove Clojure and the JVM can handle 
>> the job. Unfortunately your company won't gain the other benefits of Clojure 
>> beyond just performance (e.g. clarity, simplicity, etc.) because the rest of 
>> the code base will be in Go but... clearly that ship has already sailed.
>> 
>> Good luck! Let us know how things turn out.
>> 
>> Alan
>> 
>> --
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/p_cZoGCpvbE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> -- 
> "Whatever you can do, or dream you can do, begin it. Boldness has genius, 
> power, and magic in it. Begin it now." - Goethe
> -- 
> 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.

-- 
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/Pedestal vs Go

[Max Countryman]

Hi,

I'd love to see some discussion about this as well: I've struggled to justify 
the JVM in a production environment that's dominated by Go. My experience with 
my team has been that they are very unwilling to use the JVM and will go to 
great lengths to avoid it. The argument seems to be that Go produces light, 
extremely fast binaries, and has phenomenal networking libraries built into the 
standard lib, making it ideal for writing server-side components that may 
handle large amounts of data and need to scale horizontally. Despite my 
attempts to have members of my team checkout Clojure the final decision has 
always been to use Go instead. I'm personally a bit concerned that Go has 
started to become the replacement for Java and that the relevance of the JVM 
may be declining. It would be great to see some counterpoints to Go vis-à-vis 
Clojure and the JVM. 


Max



Sent from my iPhone
> On Sep 13, 2015, at 12:44, Alan Thompson  wrote:
> 
> Hi,
> 
> I'm about to start a new web project and they are thinking about using Go 
> (golang) instead of a JVM (preferably Clojure) based approach.  The idea is 
> "BARE METAL SPEED!!!", but I really think the network and DB will be the 
> bottlenecks, not Clojure vs Go.
> 
> Is anybody out there aware of any speed comparisons using Clojure/Pedestal 
> and/or Go?  I'm thinking basic measurements like connections/sec, latency, 
> simultaneous users, etc.
> 
> Thanks,
> Alan
> -- 
> 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.

-- 
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: are there any real examples on Github of how to use reducers?

[Max Countryman]

Kyle Kingsbury’s linearizability checker “Knossos” uses reducers. (See the 
core, history, and util namespaces.)

https://github.com/aphyr/knossos


> On May 21, 2015, at 19:55, piastkra...@gmail.com wrote:
> 
> 
> Can anyone point me to a project on Github that is using Clojure 1.5 
> reducerers? 
> 
> 
> 
> 
> -- 
> 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 
> .

-- 
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: Using :refer 'sparingly'

[Max Countryman]

I wonder if a reason could be to ensure it’s obvious where a function came 
from? For example (foo …) is ambiguous, it could be defined in the current 
namespace or it may have been referred from another whereas (my-ns/foo …) is 
explicit.


> On May 17, 2015, at 08:04, Akiva  wrote:
> 
> In Stuart Sierra's article here 
> (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he recommends 
> to use :refer sparingly but doesn't explain why this is a good idea. Only 
> thing I could think of without putting too much effort into it is that it 
> makes it slightly more tedious when you want to use a function from a 
> namespace that hasn't been already explicitly referred.
> 
> Are there no benefits other than possibly excluding function names that might 
> otherwise suffer a namespace clash (assuming their namespace isn't being 
> aliased already)?
> 
> Thanks,
> Akiva
> 
> -- 
> 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.

-- 
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: Multimethod or protocol or...? Clojure design feedback

[Max Countryman]

I personally prefer multimethods, generally speaking—I think they feel more 
idiomatic. Although it does depend on the context of what you’re doing. In some 
cases a protocol may be the correct choice. Here the multimethod seems fine.


> On May 14, 2015, at 16:34, Jason Marmon  wrote:
> 
> I'm working on a tool to orchestrate the migration from mongodb to datomic, 
> and i'm looking for a bit of design feedback as i'm new to clojure. 
> 
> 
> 
> The user needs to provide functions that transform mongodb documents into 
> datomic txes. Do y'all prefer the top or bottom style, or think there's a 
> different way to implement this design that might be better?
> 
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 11
> 12
> 13
> 14
> 15
> 16
> 17
> 18
> 19
> ;; Multimethod for transforming data based on the name of the source mongodb 
> collection 
> (defmulti transform identity)
>  
> (defmethod transform "events" [data]
>;; do something with data
>  )
>  
> (defmethod transform "users" [data]
>;; do something with data
>  )
>  
> ;;
>  
> (defprotocol Collection-Transformer
>(transform [mongo-db document]))
>  
> (def user-transformer
>  (reify Collection-Transformer
>   (transform [m d] "do stuff")))
> 
> -- 
> 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 
> .

-- 
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: Comparison with atom values

[Max Countryman]

To compare the value of the atom, you should deref it first. Using deref, 
you’ll get the current value of the atom:

=> (deref a)
0

Or using the reader macro:

=> @a
0

So:

=> (= @a 0)
true

Hope that helps,


Max

> On Feb 12, 2015, at 11:27, Newbie  wrote:
> 
> I am trying to compare atom values with numbers. For e.g. - 
> 
> (def a (atom 0))
> (print a) gives --> #
> (= a 0) gives --> false
> 
> How do I make this work? How do I compare 0 with the atom value? I want to do 
> the same for a string to?
> I cannot use compare-and-set! for my situation.
> 
> 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 
> .

-- 
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: Clarity on Stuart Sierra's component system

[Max Countryman]

Hi Colin,

I'm by no means an expert on Component but I have used it for my last several 
projects. What I've discovered is where I have query functions such as yours I 
pass the db component through to their call sites from a component which 
contains the db as state. For example, I have a component which contains 
various HTTP routing logic. Some of my routes result in db queries. To 
facilitate this I pass the db all the way through. It's sometimes a little 
clunky and there may be better ways of doing this, e.g. maybe all the routes 
which depended on db state could be partitioned in their own component. 

I hope that's helpful,


Max

> On Nov 28, 2014, at 03:28, Colin Yates  wrote:
> 
> Hi all,
> 
> Am I right in thinking that in order to use 
> https://github.com/stuartsierra/component every consumer of a component must 
> also be a component?
> 
> For example, if I have a component DB and I want to use that DB in (defn 
> blob-query [db criteria]...), do I pull the DB out of the system map and call 
> it or am I expected to make a BlobQuery component which offers a (blob-query 
> [criteria]) API?
> 
> Initially I thought the "system" was just the stateful components, but after 
> watching https://www.youtube.com/watch?v=13cmHf_kt-Q and reading the doc, 
> particularly the "all or nothing" warnings I think I might have missed 
> something.
> 
> 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.

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

A more general case of some->?

[Max Countryman]

Hi,

Recently I found myself wanting a macro similar to some-> or some->> but one 
where I could specify an arbitrary predicate instead of nil?. For example, I 
have a Ring request map which I wish to pass through a number of functions. Any 
of these functions might return an error response and if so I do not want to 
evaluate any remaining forms--much like how some-> will not evaluate after a 
nil response. To do this, I wrote a macro that is essentially some-> but which 
takes a predicate.

Here's the macro I ended up with:

(defmacro until-pred->
  "Like some-> but evalutes via -> until or if a predicate is true."
  [pred expr & forms]
  (let [g (gensym)
pstep (fn [step]
`(if (~pred ~g)
   ~g
   (-> ~g ~step)))]
`(let [~g ~expr
   ~@(interleave (repeat g) (map pstep forms))]
   ~g)))

An example of how I might use this:

(defn my-handler
  [request]
  (until-pred-> error-response? request
check-auth
check-balance
...))

That said, I'm wondering if there is a more idiomatic way of passing Ring 
request maps through a series of functions, each of which might be a terminal 
step? I'm also curious if there's a particular reason some-> wasn't implemented 
in a more general way; perhaps the fact that I can so easily write a macro that 
achieves this myself is a good enough reason?

Thanks,


Max

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