Re: Deep transients

2016-06-02 Thread Gal Dolber 
Nice book! I've been looking for something like that, thanks for sharing!

On Thu, Jun 2, 2016 at 10:24 PM Colin Fleming 
wrote:

> BTW if you're interested in Specter, Brian Marick has an interesting book
> which aims to teach Specter by implementing it:
> https://leanpub.com/specter. I bought it but haven't had time to work
> through it yet, but from an initial skimming it looks very nice.
>
> On 3 June 2016 at 16:11, Mark Engelberg  wrote:
>
>> That's an interesting idea.  Maybe there's a way to build a set of
>> Specter navigators that operate on transients, and then use its
>> corresponding eqiuvalences for assoc-in, update-in, etc.
>>
>> On Thu, Jun 2, 2016 at 9:01 PM, Colin Fleming <
>> colin.mailingl...@gmail.com> wrote:
>>
>>> Have you looked at Specter? I actually don't know if it uses transients
>>> under the hood or not, or if you can make it do so, but it seems like a
>>> good fit for the data manipulation problem, at least.
>>>
>>> On 3 June 2016 at 14:43, Mark Engelberg 
>>> wrote:
>>>
 Let's say I have an object represented by a series of nested maps:

 {:a {:b 1} :c {:d 2}}

 and now I'm going to be making a whole slew of edits to the submaps.

 To do this efficiently, I need to make all the levels of the map
 transients, because any update to the inner map also updates the outer map:

 (transient {:a (transient {:b 1}), :c (transient {:d 2})})

 and then at the end I need to do a nested persistent! operation.

 However, there aren't good facilities for dealing with nested
 transients, for example, there's no assoc!-in.  So it's a real pain to work
 with.

 Has anyone dealt with this already, and developed a suite of tools for
 working with nested transients, or other techniques for making batch
 updates efficient for deeply nested objects?

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email t

Re: Deep transients

2016-06-02 Thread Colin Fleming 
BTW if you're interested in Specter, Brian Marick has an interesting book
which aims to teach Specter by implementing it: https://leanpub.com/specter.
I bought it but haven't had time to work through it yet, but from an
initial skimming it looks very nice.

On 3 June 2016 at 16:11, Mark Engelberg  wrote:

> That's an interesting idea.  Maybe there's a way to build a set of Specter
> navigators that operate on transients, and then use its corresponding
> eqiuvalences for assoc-in, update-in, etc.
>
> On Thu, Jun 2, 2016 at 9:01 PM, Colin Fleming  > wrote:
>
>> Have you looked at Specter? I actually don't know if it uses transients
>> under the hood or not, or if you can make it do so, but it seems like a
>> good fit for the data manipulation problem, at least.
>>
>> On 3 June 2016 at 14:43, Mark Engelberg  wrote:
>>
>>> Let's say I have an object represented by a series of nested maps:
>>>
>>> {:a {:b 1} :c {:d 2}}
>>>
>>> and now I'm going to be making a whole slew of edits to the submaps.
>>>
>>> To do this efficiently, I need to make all the levels of the map
>>> transients, because any update to the inner map also updates the outer map:
>>>
>>> (transient {:a (transient {:b 1}), :c (transient {:d 2})})
>>>
>>> and then at the end I need to do a nested persistent! operation.
>>>
>>> However, there aren't good facilities for dealing with nested
>>> transients, for example, there's no assoc!-in.  So it's a real pain to work
>>> with.
>>>
>>> Has anyone dealt with this already, and developed a suite of tools for
>>> working with nested transients, or other techniques for making batch
>>> updates efficient for deeply nested objects?
>>>
>>> --
>>> 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.
>>
>
> --
> 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: Deep transients

2016-06-02 Thread Mark Engelberg 
That's an interesting idea.  Maybe there's a way to build a set of Specter
navigators that operate on transients, and then use its corresponding
eqiuvalences for assoc-in, update-in, etc.

On Thu, Jun 2, 2016 at 9:01 PM, Colin Fleming 
wrote:

> Have you looked at Specter? I actually don't know if it uses transients
> under the hood or not, or if you can make it do so, but it seems like a
> good fit for the data manipulation problem, at least.
>
> On 3 June 2016 at 14:43, Mark Engelberg  wrote:
>
>> Let's say I have an object represented by a series of nested maps:
>>
>> {:a {:b 1} :c {:d 2}}
>>
>> and now I'm going to be making a whole slew of edits to the submaps.
>>
>> To do this efficiently, I need to make all the levels of the map
>> transients, because any update to the inner map also updates the outer map:
>>
>> (transient {:a (transient {:b 1}), :c (transient {:d 2})})
>>
>> and then at the end I need to do a nested persistent! operation.
>>
>> However, there aren't good facilities for dealing with nested transients,
>> for example, there's no assoc!-in.  So it's a real pain to work with.
>>
>> Has anyone dealt with this already, and developed a suite of tools for
>> working with nested transients, or other techniques for making batch
>> updates efficient for deeply nested objects?
>>
>> --
>> 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.
>

-- 
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: Deep transients

2016-06-02 Thread Colin Fleming 
Have you looked at Specter? I actually don't know if it uses transients
under the hood or not, or if you can make it do so, but it seems like a
good fit for the data manipulation problem, at least.

On 3 June 2016 at 14:43, Mark Engelberg  wrote:

> Let's say I have an object represented by a series of nested maps:
>
> {:a {:b 1} :c {:d 2}}
>
> and now I'm going to be making a whole slew of edits to the submaps.
>
> To do this efficiently, I need to make all the levels of the map
> transients, because any update to the inner map also updates the outer map:
>
> (transient {:a (transient {:b 1}), :c (transient {:d 2})})
>
> and then at the end I need to do a nested persistent! operation.
>
> However, there aren't good facilities for dealing with nested transients,
> for example, there's no assoc!-in.  So it's a real pain to work with.
>
> Has anyone dealt with this already, and developed a suite of tools for
> working with nested transients, or other techniques for making batch
> updates efficient for deeply nested objects?
>
> --
> 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

2016-06-02 Thread Mark Engelberg 
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
> 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.

Deep transients

2016-06-02 Thread Mark Engelberg 
Let's say I have an object represented by a series of nested maps:

{:a {:b 1} :c {:d 2}}

and now I'm going to be making a whole slew of edits to the submaps.

To do this efficiently, I need to make all the levels of the map
transients, because any update to the inner map also updates the outer map:

(transient {:a (transient {:b 1}), :c (transient {:d 2})})

and then at the end I need to do a nested persistent! operation.

However, there aren't good facilities for dealing with nested transients,
for example, there's no assoc!-in.  So it's a real pain to work with.

Has anyone dealt with this already, and developed a suite of tools for
working with nested transients, or other techniques for making batch
updates efficient for deeply nested objects?

-- 
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: test.check for-all reuses generated values?

2016-06-02 Thread Gary Fredericks 
The generator should definitely always generate unique values (though only 
because gen/uuid does that), though as you say shrinking is different case 
that would be problematic for what you're doing. When you say "I don't see 
any other error" have you accounted for the fact that test.check normally 
returns *two* results after shrinking (the first failure, and the final 
failure)? This could be especially difficult to notice if the first failure 
was not an exception, and is being reported as merely false while the 
stacktrace of the final failure takes up your whole screen.

To be more precise, the original failure is under the :result key of the 
test.check result, while all the shrinking info is under :shrunk (including 
another :result key).

Other than that I don't have any ideas, but you should be able to check 
your theory about for-all reusing generated values by collecting them in an 
atom or something like that.

Gary

On Thursday, June 2, 2016 at 9:51:46 AM UTC-5, Tom wrote:
>
> Hi,
>
> I'm doing something like:
>
> (def valid-email (gen/fmap (fn [[name domain]] (str name "@" domain)) 
> (gen/tuple (gen/not-empty gen/string) gen/uuid)))
>
> (defspec test-email
>   100
>   (for-all [email valid-email]
>(tx-email! (get-in system [:database :conn]) email)
>
> The email has a unique-by-value constraint (in datomic) and this 
> transaction fails occasionally because the unique-by-value constraint 
> fails. However, this:
>
> (= 1000 (count (distinct (gen/sample valid-email 1000
>
> always succeeds. It seems like for-all reuses a generated value sometimes. 
> Could this be possible? Or maybe this happens when test.check tries to 
> shrink the test case? Except I don't see any other error, one that would 
> cause it to try to shrink.
>
> Thanks.
>
> -Tom
>
>

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

2016-06-02 Thread 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: lazy-seq and somewhat greedy apply

2016-06-02 Thread Andy L 
> 1- concat is defined to have 4 different arities: 0-arg, 1-arg, 2-arg,
> 3+args. In order to figure out which arity to use, apply has to realize at
> least as many elements as the minimum number of args required by the
> largest arity, which in this case is 3
> 2- apply has a small bug that causes it to realize one element more than
> necessary, in this case making it realize 4 elements rather than 3, here's
> a ticket with a patch fixing that issue:
> http://dev.clojure.org/jira/browse/CLJ-1583
>
>
Thx for the explanation. In my original code, I have a "lazy" sequence of a
size determined by specified in the content and the entire thing read of
I/O without a way of telling that I/O is closed. "read" function hangs and
blocks the code if performed too many times.

I redesigned my code to avoid that combination.

Best,
Andy

-- 
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: lazy-seq and somewhat greedy apply

2016-06-02 Thread Nicola Mometto 
Two things at play here:

1- concat is defined to have 4 different arities: 0-arg, 1-arg, 2-arg, 3+args. 
In order to figure out which arity to use, apply has to realize at least as 
many elements as the minimum number of args required by the largest arity, 
which in this case is 3
2- apply has a small bug that causes it to realize one element more than 
necessary, in this case making it realize 4 elements rather than 3, here's a 
ticket with a patch fixing that issue: 
http://dev.clojure.org/jira/browse/CLJ-1583

Nicola

> On 2 Jun 2016, at 19:26, Andy L  wrote:
> 
> Hi,
> 
> I have a riddle I am not sure how to solve:
> ```
> user=> (defn just-a-demo-seq[] (println "in just-a-demo-seq") [1 2 3 4 5 6 7 
> 8 9])
> #'user/just-a-demo-seq
> user=> (def do-not-print-it (apply concat (repeatedly just-a-demo-seq)))
> in just-a-demo-seq
> in just-a-demo-seq
> in just-a-demo-seq
> in just-a-demo-seq
> #'user/do-not-print-it
> ```
> 
> Question is why `just-a-demo-seq` is invoked 4 times.
> 
> We spent some time trying to answer the question to the point of analyzing 
> RT.java and core.clj and pretty much ruled out `concat`. It seems that 
> `apply` os somewhat greedy exercising too many elements of the lazy sequence.
> 
> Any insight?
> 
> Thanks,
> Andy
> 
> --
> 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.


signature.asc
Description: Message signed with OpenPGP using GPGMail

lazy-seq and somewhat greedy apply

2016-06-02 Thread Andy L 
Hi,

I have a riddle I am not sure how to solve:
```
user=> (defn just-a-demo-seq[] (println "in just-a-demo-seq") [1 2 3 4 5 6
7 8 9])
#'user/just-a-demo-seq
user=> (def do-not-print-it (apply concat (repeatedly just-a-demo-seq)))
in just-a-demo-seq
in just-a-demo-seq
in just-a-demo-seq
in just-a-demo-seq
#'user/do-not-print-it
```

Question is why `just-a-demo-seq` is invoked 4 times.

We spent some time trying to answer the question to the point of analyzing
RT.java and core.clj and pretty much ruled out `concat`. It seems that
`apply` os somewhat greedy exercising too many elements of the lazy
sequence.

Any insight?

Thanks,
Andy

-- 
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] Clojure 1.9.0-alpha4

2016-06-02 Thread Ghadi Shayban 
Let bindings from thbe macroexpansion of (let [[x & xs] v] ...)

;; old macroexpand
[G__1   v
 vec__2 G__1
 x  (nth vec__2 0 nil)
 xs (nthnext vec__2 1)]

;; new macroexpand
[G__6   v
 vec__7 G__6
 seq__8(seq vec__7)
 first__9  (first seq__8)
 seq__8(next seq__8)
 x first__9
 xsseq__8]

On Wednesday, June 1, 2016 at 7:49:00 PM UTC-4, Frank Castellucci wrote:
>
>
> How was this accomplished?
>
> On Wednesday, June 1, 2016 at 10:17:14 AM UTC-4, Rich Hickey wrote:
>>
>> To give people an idea of the update-in and seq destructuring 
>> improvements: 
>>
>> (let [d3 {:a {:b {:c 2}}}] 
>>   (dotimes [_ 10] 
>> (time (dotimes [_ 1000] 
>> (update-in d3 [:a :b :c] inc) 
>>
>> ;;; 1.9 alpha3 ;; 
>> user=> "Elapsed time: 6489.189065 msecs" 
>> "Elapsed time: 6501.518961 msecs" 
>> "Elapsed time: 6479.994554 msecs" 
>> "Elapsed time: 6477.236659 msecs" 
>> "Elapsed time: 6490.542382 msecs" 
>> "Elapsed time: 6494.044657 msecs" 
>> "Elapsed time: 6475.188285 msecs" 
>> "Elapsed time: 6498.734628 msecs" 
>> "Elapsed time: 6486.312312 msecs" 
>> "Elapsed time: 6476.566904 msecs" 
>> nil 
>>
>> ;;; 1.9 alpha4 ;; 
>> user=> "Elapsed time: 1613.631053 msecs" 
>> "Elapsed time: 1614.271583 msecs" 
>> "Elapsed time: 1607.393994 msecs" 
>> "Elapsed time: 1605.966032 msecs" 
>> "Elapsed time: 1605.731867 msecs" 
>> "Elapsed time: 1605.836779 msecs" 
>> "Elapsed time: 1617.090363 msecs" 
>> "Elapsed time: 1611.065741 msecs" 
>> "Elapsed time: 1611.249945 msecs" 
>> "Elapsed time: 1624.351585 msecs" 
>> nil 
>>
>> (let [v (into [] (range 100))] 
>>   (dotimes [_ 10] 
>> (time (dotimes [_ 10] 
>> (loop [[x & xs] v] 
>>   (if xs 
>> (recur xs) 
>> x)) 
>>
>> ;;; 1.9 alpha3 ;; 
>> user=> "Elapsed time: 1531.858419 msecs" 
>> "Elapsed time: 1521.997662 msecs" 
>> "Elapsed time: 1499.931748 msecs" 
>> "Elapsed time: 1499.745901 msecs" 
>> "Elapsed time: 1496.63342 msecs" 
>> "Elapsed time: 1499.363234 msecs" 
>> "Elapsed time: 1506.309383 msecs" 
>> "Elapsed time: 1514.943316 msecs" 
>> "Elapsed time: 1534.90731 msecs" 
>> "Elapsed time: 1524.550125 msecs" 
>> nil 
>> ;;; 1.9 alpha4 ;; 
>> user=> "Elapsed time: 155.544283 msecs" 
>> "Elapsed time: 131.861647 msecs" 
>> "Elapsed time: 141.774727 msecs" 
>> "Elapsed time: 238.939786 msecs" 
>> "Elapsed time: 294.832594 msecs" 
>> "Elapsed time: 278.476703 msecs" 
>> "Elapsed time: 133.259029 msecs" 
>> "Elapsed time: 139.917267 msecs" 
>> "Elapsed time: 137.444001 msecs" 
>> "Elapsed time: 147.852057 msecs” 
>> nil 
>>
>>
>> The code now produced for [x & xs] style destructuring is now as good as 
>> the best first/next code you could write by hand, while the code produced 
>> for [x y z] destructuring of indexed items is the same (fast, indexed) as 
>> always. 
>>
>> Rich 
>>
>> > On May 31, 2016, at 11:41 AM, Stuart Halloway  
>> wrote: 
>> > 
>> > Clojure 1.9.0-alpha4 is now available. 
>> > 
>> > Try it via 
>> > 
>> > - Download: 
>> https://repo1.maven.org/maven3/org/clojure/clojure/1.9.0-alpha4 
>> > - Leiningen: [org.clojure/clojure "1.9.0-alpha4"] 
>> > 
>> > 1.9.0-alpha4 includes the following changes since 1.9.0-alpha3: 
>> > 
>> > - fix describe empty cat 
>> > - improve update-in perf 
>> > - optimize seq (&) destructuring 
>> > 
>> > 
>> > -- 
>> > 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.

test.check for-all reuses generated values?

2016-06-02 Thread Tom 
Hi,

I'm doing something like:

(def valid-email (gen/fmap (fn [[name domain]] (str name "@" domain)) 
(gen/tuple (gen/not-empty gen/string) gen/uuid)))

(defspec test-email
  100
  (for-all [email valid-email]
   (tx-email! (get-in system [:database :conn]) email)

The email has a unique-by-value constraint (in datomic) and this 
transaction fails occasionally because the unique-by-value constraint 
fails. However, this:

(= 1000 (count (distinct (gen/sample valid-email 1000

always succeeds. It seems like for-all reuses a generated value sometimes. 
Could this be possible? Or maybe this happens when test.check tries to 
shrink the test case? Except I don't see any other error, one that would 
cause it to try to shrink.

Thanks.

-Tom

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

[JOB] CLJS / React Native Developer needed in Berlin - remote possible!

2016-06-02 Thread Brave Clojure Jobs 
"We are looking for a Clojure (Script) Developer, preferably with 
experience in React Native and re-frame.

Status is a hybrid instant messaging platform and DApp (distributed 
application) browser for cryptocurrencies and smart contracts. We intend to 
play a part in shaping the future of payments and communication through our 
decentralised community project in one of the fastest growing technology 
industries, and are looking for a motivated individual to join our team."

More details at Brave Clojure Jobs 


-- 
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: ClojureScript 1.9.14, clojure.spec port

2016-06-02 Thread Shaun LeBron 
Great stuff, thanks!  I'm not familiar, but is the `clojure.spec.gen` namespace 
going to be ported?

On Wednesday, June 1, 2016 at 1:01:58 PM UTC-5, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "1.9.14"]
> 
> 
> This release includes a complete and faithful port of clojure.spec to
> ClojureScript. The functionality resides in the new cljs.spec
> namespace. All features present in Clojure 1.9.0-alpha4 are
> implemented, including REPL support, testing support and macro
> checking.
> 
> 
> As always feedback welcome.
> 
> 
> ## 1.9.14
> 
> 
> ### Enhancements
> * clojure.spec ported to cljs.spec
> 
> 
> ### Fixes
> * CLJS-1649: Possible issue with in cljs.reader or cljs.core/PersistentHashMap
> * CLJS-1647: Rethrow exception from parallel-build
> * CLJS-1642: cljs.core/reductions does not respect 'reduced'
> * CLJS-1635: Var type implements IEquiv but not IHash
> * CLJS-1629: Fix warning about duplicate test-pr-str
> * CLJS-1637: Missing docstrings for a few vars

-- 
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: Specter 0.11.0, performance without the tradeoffs

2016-06-02 Thread 'Gunnar Völkel' via Clojure 
Following the convention not to use `def` in non-top-level positions, you 
should use `intern` instead of `def`.

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