Re: [ANN] Clojure 1.9.0-alpha4

[Atamert Ölçgen]

On Sat, Jun 4, 2016 at 9:28 AM, <676c7...@gmail.com> wrote:

> This isn’t only an optimisation but also a change in behaviour, isn’t
> it?
>
> Clojure 1.9.0-alpha3:
>
> user=> (let [[x & xs] #{1 2 3}] x)
> UnsupportedOperationException nth not supported on this type:
> PersistentHashSet  clojure.lang.RT.nthFrom (RT.java:948)
>
> Clojure 1.9.0-alpha4:
>
> user=> (let [[x & xs] #{1 2 3}] x)
> 1
>

I hope this will be considered a regression and the old behavior will be
restored.



>
> Perhaps the documentation needs to be updated?
> http://clojure.org/reference/special_forms#_vector_binding_destructuring
>
>
> --
> David
>
> --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: [ANN] Clojure 1.9.0-alpha4

[676c7473]

This isn’t only an optimisation but also a change in behaviour, isn’t
it?

Clojure 1.9.0-alpha3:

user=> (let [[x & xs] #{1 2 3}] x)
UnsupportedOperationException nth not supported on this type: 
PersistentHashSet  clojure.lang.RT.nthFrom (RT.java:948)

Clojure 1.9.0-alpha4:

user=> (let [[x & xs] #{1 2 3}] x)
1

Perhaps the documentation needs to be updated?
http://clojure.org/reference/special_forms#_vector_binding_destructuring


-- 
David

-- 
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: Get the name of parameters in a function

[Atamert Ölçgen]

On Sat, Jun 4, 2016 at 1:45 AM, James Reeves  wrote:

> You can do it with a macro.
>
> - James
>
> On 3 June 2016 at 22:22, Steven Zhou  wrote:
>
>> Is it possible to write down a function do the following?
>>
>> (defn foo
>> [input]
>> 
>> )
>>
>> (def x "Hello")
>> (def y "Clojure")
>>
>> (foo [x y])
>> => {:x "Hello" :y "Clojure"}
>>
>
This seems to do what you want:


(defmacro foo [vars]
 (let [keys_ (mapv keyword vars)]
`(zipmap ~keys_ ~vars)))



Note the difference between ~(mapv keyword vars) & ~vars. The former maps
(keyword) over a vector of symbols, then resolves their value (which is
themselves). The latter resolves the vector of symbols directly, each
element in turn gets resolved to their respective definitions.

If you rewrite this to use a (foo [& vars] ...) and be called as (foo x y),
I think it would be easier to see what's happening.



>
>>
>> Regards,
>> -Steven
>>
>> --
>> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: lazy-seq and somewhat greedy apply

[Jason Wolfe]

In case it's useful, here is a fully lazy variant of 'apply concat':

https://github.com/plumatic/plumbing/blob/master/src/plumbing/core.cljx#L179

-Jason

On Friday, June 3, 2016 at 2:26:43 AM UTC+8, 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.

Re: Get the name of parameters in a function

[James Reeves]

You can do it with a macro.

- James

On 3 June 2016 at 22:22, Steven Zhou  wrote:

> Is it possible to write down a function do the following?
>
> (defn foo
> [input]
> 
> )
>
> (def x "Hello")
> (def y "Clojure")
>
> (foo [x y])
> => {:x "Hello" :y "Clojure"}
>
>
> Regards,
> -Steven
>
> --
> 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.

Get the name of parameters in a function

[Steven Zhou]

Is it possible to write down a function do the following?

(defn foo 
[input]

)

(def x "Hello")
(def y "Clojure")

(foo [x y])
=> {:x "Hello" :y "Clojure"}


Regards,
-Steven

-- 
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: ClojureScript 1.9.36 - cljs.spec fixes & performance enhancements

[David Nolen]

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.36"]

This release fixes a cljs.spec bug around instrumented multi-arity
fns. It also includes various fixes and performance enhancements from
Clojure. Another performance related change is writing out analysis
caches as Transit if transit-clj is available. This is automatic and
requires no configuration and gives a modest speed bump when launching
REPLs.

As always feedback welcome!

## 1.9.36

### Enhancements
* Write analysis caches as Transit if transit-clj available

### Changes
* Clojure 1f25347
* Clojure 47b8d6b
* Optimize seq (&) destructuring as per commit (0aa3467) of Clojure

### Fixes
* CLJS-1611: Function arity dispatch returns arity
* only print specs in REPL if we actually have some
* CLJS-1663: Calling instrumented multi-arity function causes exception
* CLJS-1650: `cljs.reader/read-map` now returns array-map/hash-map based on
the size of the sequence.

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

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

[Tom]

On Thursday, June 2, 2016 at 8:57:24 PM UTC-5, Gary Fredericks wrote:
>
> 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).
>

Ah OK. I didn't know this. Thanks, I'll take a look.
 

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

Yup. I was hoping to avoid this, but seems like I'll have to.
 

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