Re: Calling proxy without reflection

[Nicola Mometto]

https://dev.clojure.org/jira/browse/CLJ-2379

> On 2 Aug 2018, at 10:22, Nicola Mometto  wrote:
> 
> yes, the problem is with `proxy` and redefinition, I'm working on a patch to 
> fix this
> 
>> On 2 Aug 2018, at 07:55, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>> 
>> For those following along at home, it turned out not to be a problem with 
>> the lein-virgil plugin.  It's apparently a bug in Clojure.  Renzo and I 
>> distilled it down to the following steps:
>> 
>> user=> (definterface Interface (test []))
>> user.Interface
>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> #'user/p
>> user=> (defn get-test [o] (.test ^Interface o))
>> #'user/get-test
>> user=> (get-test p)
>> 1
>> user=> (definterface Interface (test []))
>> user.Interface
>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> #'user/p
>> user=> (defn get-test [o] (.test ^Interface o))
>> #'user/get-test
>> user=> (get-test p)
>> 
>> ClassCastException user.proxy$java.lang.Object$Interface$936446c6 cannot be 
>> cast to user.Interface  user/get-test (form-init7484886365563813996.clj:1)
>> 
>> 
>> 
>> -- 
>> 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 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.

Re: Calling proxy without reflection

[Nicola Mometto]

yes, the problem is with `proxy` and redefinition, I'm working on a patch to 
fix this

> On 2 Aug 2018, at 07:55, Mark Engelberg  wrote:
> 
> For those following along at home, it turned out not to be a problem with the 
> lein-virgil plugin.  It's apparently a bug in Clojure.  Renzo and I distilled 
> it down to the following steps:
> 
> user=> (definterface Interface (test []))
> user.Interface
> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> #'user/p
> user=> (defn get-test [o] (.test ^Interface o))
> #'user/get-test
> user=> (get-test p)
> 1
> user=> (definterface Interface (test []))
> user.Interface
> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> #'user/p
> user=> (defn get-test [o] (.test ^Interface o))
> #'user/get-test
> user=> (get-test p)
> 
> ClassCastException user.proxy$java.lang.Object$Interface$936446c6 cannot be 
> cast to user.Interface  user/get-test (form-init7484886365563813996.clj:1)
> 
> 
> 
> -- 
> 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: Calling proxy without reflection

[Nicola Mometto]

Ok, just taking a cursory look and what you're seeing might be related to 
double-loading.

It might be that the fixes that went in around ~1.5/1.6 missed some edge-cases 
related to `proxy`, I'll investigate more this evening

> On 30 Jul 2018, at 11:50, Mark Engelberg  wrote:
> 
> OK, I just pushed the repo (work in progress) to github. 
> https://github.com/Engelberg/mister-rogers 
> <https://github.com/Engelberg/mister-rogers>
> At the bottom of mister-rogers.wrappers I tacked on the three lines we've 
> been discussing.
> https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80
>  
> <https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80>
> 
> Here's a REPL interaction:
> 
> C:\devel\Clojure\mister-rogers>lein repl
> 
> recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
> :reloading (mister-rogers.core mister-rogers.protocols mister-rogers.problem 
> mister-rogers.wrappers mister-rogers.core-test)
> 
> recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
> :reloading (mister-rogers.core mister-rogers.protocols mister-rogers.problem 
> mister-rogers.wrappers mister-rogers.core-test)
> nREPL server started on port 49492 on host 127.0.0.1 - 
> nrepl://127.0.0.1:49492 <http://127.0.0.1:49492/>
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.9.0
> Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
> 
> user=> (in-ns 'mister-rogers.wrappers)
> #namespace[mister-rogers.wrappers]
> mister-rogers.wrappers=> (get-test p)
> 
> ClassCastException 
> mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9 cannot be 
> cast to mister_rogers.wrappers.Interface  mister-rogers.wrappers/get-test 
> (wrappers.clj:82)
> 
> 
> Thanks for looking at this.
> 
> 
> On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto  <mailto:brobro...@gmail.com>> wrote:
> Can you paste an entire repl session, starting from how you launch it (e.g. 
> lein repl vs clj -- ideally not from a project) reproducing this?
>  I'm interested in taking a look but I simply cannot repro :/
> 
>> On 30 Jul 2018, at 11:40, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>> 
>> Yes, it is in a fresh environment.
>> 
>> I find that the problematic example does work in the user namespace, but it 
>> doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be 
>> really specific).
>> 
>> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto > <mailto:brobro...@gmail.com>> wrote:
>> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd 
>> expect.
>> 
>> Are you testing this in a fresh environment?
>> 
>> 
>>> On 30 Jul 2018, at 11:31, Mark Engelberg >> <mailto:mark.engelb...@gmail.com>> wrote:
>>> 
>>> I'm using 1.9.0.  Is this a behavior that recently changed?
>>> 
>>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto >> <mailto:brobro...@gmail.com>> wrote:
>>> Which version of clojure? This works fine in 1.10
>>> 
>>> Clojure 1.10.0-master-SNAPSHOT
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (definterface Interface (test []))
>>> user.Interface
>>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>>> #'user/p
>>> user=> (defn get-test [o] (.test ^Interface o))
>>> #'user/get-test
>>> user=> (get-test p)
>>> 1
>>> 
>>> 
>>>> On 30 Jul 2018, at 11:26, Mark Engelberg >>> <mailto:mark.engelb...@gmail.com>> wrote:
>>>> 
>>>> Those fishy things were errors I made when simplifying and transcribing 
>>>> the proxy to post, but I have it correct in my own code.
>>>> 
>>>> Here's a more precise, tested minimal example:
>>>> 
>>>> (definterface Interface (test []))
>>>> (def p (proxy [Object Interface] [] (test [] 1)))
>>>> (defn get-test [o] (.test ^Interface o))
>>>> 
>>>> => (get-test p)
>>>> This throws an error that it can't cast the proxy to Interface.
>>>> 
>>>> If you remove the ^Interface type hint, then

Re: Calling proxy without reflection

[Nicola Mometto]

Can you paste an entire repl session, starting from how you launch it (e.g. 
lein repl vs clj -- ideally not from a project) reproducing this?
 I'm interested in taking a look but I simply cannot repro :/

> On 30 Jul 2018, at 11:40, Mark Engelberg  wrote:
> 
> Yes, it is in a fresh environment.
> 
> I find that the problematic example does work in the user namespace, but it 
> doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be 
> really specific).
> 
> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto  <mailto:brobro...@gmail.com>> wrote:
> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd 
> expect.
> 
> Are you testing this in a fresh environment?
> 
> 
>> On 30 Jul 2018, at 11:31, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>> 
>> I'm using 1.9.0.  Is this a behavior that recently changed?
>> 
>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto > <mailto:brobro...@gmail.com>> wrote:
>> Which version of clojure? This works fine in 1.10
>> 
>> Clojure 1.10.0-master-SNAPSHOT
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (definterface Interface (test []))
>> user.Interface
>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> #'user/p
>> user=> (defn get-test [o] (.test ^Interface o))
>> #'user/get-test
>> user=> (get-test p)
>> 1
>> 
>> 
>>> On 30 Jul 2018, at 11:26, Mark Engelberg >> <mailto:mark.engelb...@gmail.com>> wrote:
>>> 
>>> Those fishy things were errors I made when simplifying and transcribing the 
>>> proxy to post, but I have it correct in my own code.
>>> 
>>> Here's a more precise, tested minimal example:
>>> 
>>> (definterface Interface (test []))
>>> (def p (proxy [Object Interface] [] (test [] 1)))
>>> (defn get-test [o] (.test ^Interface o))
>>> 
>>> => (get-test p)
>>> This throws an error that it can't cast the proxy to Interface.
>>> 
>>> If you remove the ^Interface type hint, then get-test will work but will 
>>> trigger reflection.
>>> 
>>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>> 
>>> 
>>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto >> <mailto:brobro...@gmail.com>> wrote:
>>> That's exactly what you should do and it does work, e.g.:
>>> 
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] 
>>> {:a 1})))
>>> {:a 1}
>>> 
>>> In your small example you have two errors that might be fishy: a missing 
>>> arg vector to pass to the super ctor and an extra `this` parameter in the 
>>> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>> 
>>> 
>>>> On 30 Jul 2018, at 10:56, Mark Engelberg >>> <mailto:mark.engelb...@gmail.com>> wrote:
>>>> 
>>>> Let's say I have a proxy object:
>>>> 
>>>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>>> 
>>>> Now, I want to call (.interfaceMethod p).  How do I do this without 
>>>> reflection?
>>>> I would have thought that (.interfaceMethod ^MyInterface p) would work, 
>>>> but this results in an error message that this proxy object cannot be cast 
>>>> to MyInterface.
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> 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 group and stop receiving emails from it, send an 
>>>> email to clojure+unsubscr...@googlegroups.com 
>&g

Re: Calling proxy without reflection

[Nicola Mometto]

No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd 
expect.

Are you testing this in a fresh environment?


> On 30 Jul 2018, at 11:31, Mark Engelberg  wrote:
> 
> I'm using 1.9.0.  Is this a behavior that recently changed?
> 
> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto  <mailto:brobro...@gmail.com>> wrote:
> Which version of clojure? This works fine in 1.10
> 
> Clojure 1.10.0-master-SNAPSHOT
> user=> (set! *warn-on-reflection* true)
> true
> user=> (definterface Interface (test []))
> user.Interface
> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> #'user/p
> user=> (defn get-test [o] (.test ^Interface o))
> #'user/get-test
> user=> (get-test p)
> 1
> 
> 
>> On 30 Jul 2018, at 11:26, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>> 
>> Those fishy things were errors I made when simplifying and transcribing the 
>> proxy to post, but I have it correct in my own code.
>> 
>> Here's a more precise, tested minimal example:
>> 
>> (definterface Interface (test []))
>> (def p (proxy [Object Interface] [] (test [] 1)))
>> (defn get-test [o] (.test ^Interface o))
>> 
>> => (get-test p)
>> This throws an error that it can't cast the proxy to Interface.
>> 
>> If you remove the ^Interface type hint, then get-test will work but will 
>> trigger reflection.
>> 
>> Thanks for looking at this. It seems like it should work, but it doesn't.
>> 
>> 
>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto > <mailto:brobro...@gmail.com>> wrote:
>> That's exactly what you should do and it does work, e.g.:
>> 
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] 
>> {:a 1})))
>> {:a 1}
>> 
>> In your small example you have two errors that might be fishy: a missing arg 
>> vector to pass to the super ctor and an extra `this` parameter in the method 
>> impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>> 
>> 
>>> On 30 Jul 2018, at 10:56, Mark Engelberg >> <mailto:mark.engelb...@gmail.com>> wrote:
>>> 
>>> Let's say I have a proxy object:
>>> 
>>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>> 
>>> Now, I want to call (.interfaceMethod p).  How do I do this without 
>>> reflection?
>>> I would have thought that (.interfaceMethod ^MyInterface p) would work, but 
>>> this results in an error message that this proxy object cannot be cast to 
>>> MyInterface.
>>> 
>>> 
>>> 
>>> -- 
>>> 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 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 
>> <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.
>

Re: Calling proxy without reflection

[Nicola Mometto]

Which version of clojure? This works fine in 1.10

Clojure 1.10.0-master-SNAPSHOT
user=> (set! *warn-on-reflection* true)
true
user=> (definterface Interface (test []))
user.Interface
user=> (def p (proxy [Object Interface] [] (test [] 1)))
#'user/p
user=> (defn get-test [o] (.test ^Interface o))
#'user/get-test
user=> (get-test p)
1


> On 30 Jul 2018, at 11:26, Mark Engelberg  wrote:
> 
> Those fishy things were errors I made when simplifying and transcribing the 
> proxy to post, but I have it correct in my own code.
> 
> Here's a more precise, tested minimal example:
> 
> (definterface Interface (test []))
> (def p (proxy [Object Interface] [] (test [] 1)))
> (defn get-test [o] (.test ^Interface o))
> 
> => (get-test p)
> This throws an error that it can't cast the proxy to Interface.
> 
> If you remove the ^Interface type hint, then get-test will work but will 
> trigger reflection.
> 
> Thanks for looking at this. It seems like it should work, but it doesn't.
> 
> 
> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto  <mailto:brobro...@gmail.com>> wrote:
> That's exactly what you should do and it does work, e.g.:
> 
> user=> (set! *warn-on-reflection* true)
> true
> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] {:a 
> 1})))
> {:a 1}
> 
> In your small example you have two errors that might be fishy: a missing arg 
> vector to pass to the super ctor and an extra `this` parameter in the method 
> impl (proxy, unlike reify, is anaphoric and binds `this` for you)
> 
> 
>> On 30 Jul 2018, at 10:56, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>> 
>> Let's say I have a proxy object:
>> 
>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>> 
>> Now, I want to call (.interfaceMethod p).  How do I do this without 
>> reflection?
>> I would have thought that (.interfaceMethod ^MyInterface p) would work, but 
>> this results in an error message that this proxy object cannot be cast to 
>> MyInterface.
>> 
>> 
>> 
>> -- 
>> 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 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 
> <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+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 
> <http://groups.google.com/group/clojure

Re: Calling proxy without reflection

[Nicola Mometto]

That's exactly what you should do and it does work, e.g.:

user=> (set! *warn-on-reflection* true)
true
user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] {:a 
1})))
{:a 1}

In your small example you have two errors that might be fishy: a missing arg 
vector to pass to the super ctor and an extra `this` parameter in the method 
impl (proxy, unlike reify, is anaphoric and binds `this` for you)


> On 30 Jul 2018, at 10:56, Mark Engelberg  wrote:
> 
> Let's say I have a proxy object:
> 
> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
> 
> Now, I want to call (.interfaceMethod p).  How do I do this without 
> reflection?
> I would have thought that (.interfaceMethod ^MyInterface p) would work, but 
> this results in an error message that this proxy object cannot be cast to 
> MyInterface.
> 
> 
> 
> -- 
> 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: concat and mapcat not sufficiently lazy

[Nicola Mometto]

Yes, you’re right that neither directly handles `concat`, however CLJ-1583 
improves the behaviour of both your examples and is _necessary_ to fix any 
`apply` related laziness issues

user=>  (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
1
2
3
1
user=> (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
1
2
3
1

While CLJ-1218 in conjunction with CLJ-1583 “fixes” the mapcat example:

user=>  (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
1
1

So to make all your examples as lazy as possible we need a combination of 
CLJ-1218, CLJ-1583 and a `join`-like `concat`




> On 18 Jul 2018, at 09:24, Mark Engelberg  wrote:
> 
> Thanks, I hadn't seen those issues.
> https://dev.clojure.org/jira/browse/CLJ-1218 
> <https://dev.clojure.org/jira/browse/CLJ-1218> talks about mapcat, and 
> https://dev.clojure.org/jira/browse/CLJ-1583 
> <https://dev.clojure.org/jira/browse/CLJ-1583> talks about apply. Those are 
> aspects of the problem, for sure, but fixing those two issues would not solve 
> the problem with (apply concat ...), I don't think, because another facet of 
> the problem is that concat's args are of the form [x y & zs].
> 
> Gary Fredericks recognizes this problem in the comments for CLJ-1218: "I 
> realized that concat could actually be made lazier without changing its 
> semantics, if it had a single [& args] clause that was then implemented 
> similarly to join above."
> 
> But for the most part, the comments are focused on fixing mapcat by 
> implementing a new function, join, rather than fixing the problem with concat 
> directly.  Seems better to fix concat, if possible.
> 
> I'm truly astonished I haven't gotten bitten by this before.  This is a 
> pattern I use frequently in my code; I guess I just never had deep enough 
> recursion for it to slow things down enough for me to realize what was 
> happening.
> 
> 
> 
> On Wed, Jul 18, 2018 at 12:53 AM, Nicola Mometto  <mailto:brobro...@gmail.com>> wrote:
> This behaviour is known and there are a couple of tickets about it :
> 
> https://dev.clojure.org/jira/browse/CLJ-1583 
> <https://dev.clojure.org/jira/browse/CLJ-1583>
> https://dev.clojure.org/jira/browse/CLJ-1218 
> <https://dev.clojure.org/jira/browse/CLJ-1218>
> 
> On Wed, 18 Jul 2018, 08:28 Mark Engelberg,  <mailto:mark.engelb...@gmail.com>> wrote:
> I'm kind of surprised I haven't run across this before, but tonight I was 
> debugging a function that was doing an explosion of computation to return the 
> first value of a lazy sequence, and I was able to reduce the problem down to 
> this example:
> 
> > (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
> 1
> 2
> 3
> 4
> 1
> 
> The last 1 is the return value, but notice that it realized 4 values in order 
> to return the 1.  This has nothing to do with chunked sequences, by the way 
> -- a list is an unchunked sequence.  It appears to be that the way concat is 
> written, it realizes the first two elements, and then another two elements in 
> a recursive call before the lazy-seq kicks in.
> 
> In the function in question, the "apply concat" was part of a recursion, 
> causing that explosion of realizing values (four at each level of the 
> recursion, it would seem) to get at the first element.
> 
> Note that this affects mapcat as well, which relies on concat under the hood:
> > (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
> 1
> 2
> 3
> 4
> 1
> 
> I don't see a quick fix other than writing my own improved concat/mapcat.  Do 
> you?
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com 
> <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+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&qu

Re: concat and mapcat not sufficiently lazy

[Nicola Mometto]

This behaviour is known and there are a couple of tickets about it :

https://dev.clojure.org/jira/browse/CLJ-1583
https://dev.clojure.org/jira/browse/CLJ-1218

On Wed, 18 Jul 2018, 08:28 Mark Engelberg,  wrote:

> I'm kind of surprised I haven't run across this before, but tonight I was
> debugging a function that was doing an explosion of computation to return
> the first value of a lazy sequence, and I was able to reduce the problem
> down to this example:
>
> > (first (apply concat (map #(do (println %) [%]) (list 1 2 3 4 5
> 1
> 2
> 3
> 4
> 1
>
> The last 1 is the return value, but notice that it realized 4 values in
> order to return the 1.  This has nothing to do with chunked sequences, by
> the way -- a list is an unchunked sequence.  It appears to be that the way
> concat is written, it realizes the first two elements, and then another two
> elements in a recursive call before the lazy-seq kicks in.
>
> In the function in question, the "apply concat" was part of a recursion,
> causing that explosion of realizing values (four at each level of the
> recursion, it would seem) to get at the first element.
>
> Note that this affects mapcat as well, which relies on concat under the
> hood:
> > (first (mapcat #(do (println %) [%]) (list 1 2 3 4 5)))
> 1
> 2
> 3
> 4
> 1
>
> I don't see a quick fix other than writing my own improved concat/mapcat.
> Do you?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 is now available!

[Nicola Mometto]

The code that caused this issue is
https://github.com/clojure/clojure/commit/a1c3dafec01ab02fb10d91f98b9ffd3241e860c0?diff=unified#diff-03234b041c0917ec98f2ad9477a0a014R260
But this is not a bug in the clojure code nor a regression, in fact
you can reproduce this in any clojure version with the following code:

(defmacro m [] `[~@(keys )])
(defprotocol p (f [_]))
(deftype t [^int x] p (f [_] (m)))


This is happening for the same reason why (let [x (int 1)] (identity
^int x)) throws the same error, the fix in your case is to use (map
#(with-meta % {}) (keys ))

On Tue, Jan 2, 2018 at 11:03 PM, Luc  wrote:
> Hi,
>
> finally got some time to dig deeper. The minimal code to reproduce this has
> shrunk:
>
> (defprotocol Anonymous
>   (start-job! [this]))
>
> (defrecord NoopJob []
>   Anonymous
>   (start-job! [this]
> (yabug.services.logger/environment)))
>
> The environment macro was called by log/error but not by the other severity
> level macros.
> The error macro within a defrecord is the only case where it fails.
>
> This is the environment macro definition:
>
> (defmacro environment
>   "Expands to code that generates a map of locals: names to values"
>   []
>   (clojure.pprint/pprint (macroexpand `(zipmap '~(keys ) [~@(keys
> )])))
>   `(zipmap '~(keys ) [~@(keys )]))
>
> I added the macroexpand in the macro to get what it expands to in the
> context of the defrecord
> at compile time.
> Outside of the defrecord the compiler does not complain (let, ...)). The
> protocol by itself does not seem
> to be a significant factor. I got this at different places under different
> protocols.
>
> This is the 1.9 macro expansion outputted at compile time before ending up
> with exception while evaluating
> the resulting code:
>
> (clojure.core/zipmap
>  '(__hash __meta this __hasheq __extmap)
>  [__hash __meta this __hasheq __extmap])
>
> This is the 1.8 macroexpansion of this macro which is a bit shorter, there's
> seem to be less context generated by the defrecord macro
> expansion:
>
> (clojure.core/zipmap '(__meta this __extmap) [__meta this __extmap])
>
> The expansion of the defrecord context is slightly bigger but nothing hits
> me when I compare both expanded vectors at the end.
> I am assuming that this the expression that the compiler cannot evaluate in
> 1.9 since it the error originates from the VectorExpr
> class.
> Is there anything obvious on with the evaluation of the last vector in the
> 1.9 expansion that would explain this error ?
> I don't see it.
>
> Just to make things more puzzling the expansion literally works in the 1.9
> REPL:
>
> => (defrecord NoopJob []
>  impl/GatewayJob
>  (start-job! [this]
>(clojure.core/zipmap
>  '(__hash __meta this __hasheq __extmap)
>  [__hash __meta this __hasheq __extmap])))
> yabug.jobs.noop.NoopJob
>
> Grr...
>
> Will sleep on it and toy with it tomorrow by expanding a bit the test cases.
> It's nearly 22:00 Morocco time here.
> I need a break and some sleep.
>
> Luc P.
>
> On Saturday, 30 December 2017 01:00:05 UTC, Alex Miller wrote:
>>
>> On Fri, Dec 29, 2017 at 6:17 PM, Luc  wrote:
>>
>>>
>>> here it is, I did not get through the compiler source code yet, it might
>>> be obvious to you:
>>>
>>> java.lang.UnsupportedOperationException: Can't type hint a primitive
>>> local, compiling:(yabug/jobs/noop.clj:21:9)
>>> Exception in thread "main" java.lang.UnsupportedOperationException: Can't
>>> type hint a primitive local, compiling:(yabug/jobs/noop.clj:21:9)
>>
>>
>> What's the code here? ^^
>>
>>
>
> --
> 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 

Re: Help ship Clojure 1.9!

[Nicola Mometto]

Yes, clojurescript makes use of a previous experimental feature of 
tools.reader that allowed Infinity and -Infinity to be read as 
Double/POSITIVE_INFINITY and Double/NEGATIVE_INFINITY, without special 
casing how the compiler emitted infinity literals, as clojure previously 
printed them as "Infinity" and "-Infinity" which is the valid javascript 
code. Now that clojure has changed how infinities are printed, 
clojurescript broke and the compiler now explicitely has to handle how 
infinities are printed, rather than simply using the pr-str 
representation of numbers.



On 29/09/17 19:47, Stuart Halloway wrote:
And to maybe answer my own question, I guess it is 
https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L988-L990.


On Fri, Sep 29, 2017 at 1:45 PM, Stuart Halloway 
> wrote:


To be clear: we can certainly cut a new release of CLJS, I just
want to understand other options, if any.

On Fri, Sep 29, 2017 at 1:38 PM, Stuart Halloway
> wrote:

Hi Aleš, Mark,

Thanks for the reports! It isn't clear to me how a change to
tools.reader can fix a problem with the core hash function.
Can somebody point me to the place in the Clojurescript code
where this happens?

Stu

On Fri, Sep 29, 2017 at 11:13 AM, Aleš Roubíček
> wrote:

The Cljs problem is easily solvable by referencing latest
tools.reader:

[org.clojure/clojurescript "1.9.908" :exclusions
[org.clojure/tools.reader]] [org.clojure/tools.reader "1.1.0"]


On Thursday, September 28, 2017 at 8:37:11 PM UTC+2,
puzzler wrote:

And to be clear, it doesn't only affect people who try
to use ##Inf or ##NaN in their Clojurescript code. It
affects all existing Clojurescript code, because
running the Clojurescript compiler in a new version of
Clojure causes all Clojurescript code to emit these ##
characters directly into the javascript for its
definition of the core hash function, which is
nonsensical javascript.  So all Clojurescript code is
broken by running the new release.

On Thu, Sep 28, 2017 at 11:34 AM, Mark Engelberg
 wrote:

On Thu, Sep 28, 2017 at 11:02 AM, Jeaye
 wrote:

This has been the only issue we've run into
with 1.9.0-beta1 ( ticket is here
https://dev.clojure.org/jira/browse/CLJS-2352

). On our back-end, all tests are good, but we
can't currently use beta1 (or alpha20) on the
front-end, since this issue causes CLJS to
choke. I'm hoping that a new version of CLJS
comes out before Clojure 1.9.0 so that people
don't get the false impression that the latest
of each is compatible with the other.

J


Agreed.  It is currently not possible to use
Clojure 1.9.0 later than alpha19 with
Clojurescript. Clojurescript as it currently
stands can't handle the new ## tags like ##Inf,
##NaN.  Like a number of people, I got burned by
this when I tried to upgrade and spent some time
tracking it down, only to realize it was already a
known incompatibility. There will be a lot more
confused people if you release Clojure 1.9.0 prior
to releasing a new version of Clojurescript that
is compatible.


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

Re: [ANN] Clojure 1.9.0-alpha20

[Nicola Mometto]

That looks like a cljs issue, it shouldn't emit NaNs at all there, not
relevant to the clojure change around how they are printed.

On 8 Sep 2017 8:03 a.m., "Tommi Reiman"  wrote:

Hi.

The combo:

[org.clojure/clojure "1.9.0-alpha20"]
[org.clojure/clojurescript "1.9.660"]

seems to be emitting broken js:

return new cljs.core.PersistentVector(null, 2, 5,
cljs.core.PersistentVector.EMPTY_NODE, [##NaN,##NaN], null);

With 1.9.0-alpha19 it gives:

return new cljs.core.PersistentVector(null, 2, 5,
cljs.core.PersistentVector.EMPTY_NODE, [NaN,NaN], null);

regards,

Tommi

perjantai 8. syyskuuta 2017 0.48.51 UTC+3 Alex Miller kirjoitti:
>
> Clojure 1.9.0-alpha20 is now available.
>
> Try it via
>
> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-
> alpha20
> - Leiningen: [org.clojure/clojure "1.9.0-alpha20"]
>
> 1.9.0-alpha20 includes the following changes since 1.9.0-alpha19:
>
> - CLJ-1074 - (new) add new ## reader macro for symbolic values, and
>read/print support for double vals ##Inf, ##-Inf, ##NaN
> - CLJ-1454 - (new) add swap-vals! and reset-vals! that return both old and
> new values
> - CLJ-2184 - (errors) propagate meta in doto forms to improve error
> reporting
> - CLJ-2210 - (perf) cache class derivation in compiler to improve compiler
> performance
> - CLJ-2070 - (perf) clojure.core/delay - improve performance
> - CLJ-1917 - (perf) reducing seq over string should call String/length
> outside of loop
> - CLJ-1901 - (perf) amap - should call alength only once
> - CLJ-99   - (perf) min-key and max-key - evaluate k on each arg at most
> once
> - CLJ-2188 - (perf) slurp - mark return type as String
> - CLJ-2108 - (startup time) delay loading of spec and core specs (still
> more to do on this)
> - CLJ-2204 - (security) disable serialization of proxy classes to avoid
> potential issue when deserializing
> - CLJ-2048 - (fix) specify type to avoid ClassCastException when stack
> trace is elided by JVM
> - CLJ-1887 - (fix) IPersistentVector.length() - implement missing method
> - CLJ-1841 - (fix) bean - iterator was broken
> - CLJ-1714 - (fix) using a class in a type hint shouldn't load the class
> - CLJ-1398 - (fix) clojure.java.javadoc/javadoc - update doc urls
> - CLJ-1371 - (fix) Numbers.divide(Object, Object) - add checks for NaN
> - CLJ-1358 - (fix) doc - does not expand special cases properly (try,
> catch)
> - CLJ-1705 - (fix) vector-of - fix NullPointerException if given
> unrecognized type
> - CLJ-2170 - (doc) fix improperly located docstrings
> - CLJ-2156 - (doc) clojure.java.io/copy - doc char[] support
> - CLJ-2051 - (doc) clojure.instant/validated docstring - fix typo
> - CLJ-2104 - (doc) clojure.pprint docstring - fix typo
> - CLJ-2028 - (doc) filter, filterv, remove, take-while - fix docstrings
> - CLJ-1873 - (doc) require, *data-readers* - add .cljc files to docstrings
> - CLJ-1159 - (doc) clojure.java.io/delete-file - improve docstring
> - CLJ-2039 - (doc) deftype - fix typo in docstring
> - CLJ-1918 - (doc) await - improve docstring re shutdown-agents
> - CLJ-1837 - (doc) index-of, last-index-of - clarify docstrings
> - CLJ-1826 - (doc) drop-last - fix docstring
> - CLJ-1859 - (doc) zero?, pos?, neg? - fix docstrings
>
-- 
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: Bizzarre cond-> behavior

[Nicola Mometto]

correct

> On 21 Jul 2017, at 12:11, Peter Hull  wrote:
> 
> That was quick! So, if I understand it, the problem is not with cond->, it's 
> the chain of let-bindings it expands to?
> Pete
> 
> 
> --
> 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

Re: Bizzarre cond-> behavior

[Nicola Mometto]

Ticket with patch + explanation: https://dev.clojure.org/jira/browse/CLJ-2210 
<https://dev.clojure.org/jira/browse/CLJ-2210>

> On 21 Jul 2017, at 11:06, Nicola Mometto <brobro...@gmail.com> wrote:
> 
> I have a patch that fixes this, will open a ticket later today.
> 
>> On 21 Jul 2017, at 10:07, James Reeves <ja...@booleanknot.com 
>> <mailto:ja...@booleanknot.com>> wrote:
>> 
>> I can also confirm, tested on Clojure 1.8.0. The macro doesn't seem to take 
>> long at all; it's the expanded code that takes a significant time to compile.
>> 
>> On 21 July 2017 at 10:56, Peter Hull <peterhul...@gmail.com 
>> <mailto:peterhul...@gmail.com>> wrote:
>> On Friday, 21 July 2017 00:35:00 UTC+1, Milt Reder wrote:
>> Here's a simplified example:
>> 
>> I can confirm that pasting that defn into a CIDER repl does take a long time 
>> before the prompt comes back. I tried doing a "macro expand all" and it was 
>> pretty much instantaneous. The resulting expansion is quite long but not 
>> unreasonable (see below). Beyond that, I'm not sure how to analyse what 
>> Clojure's doing or time it. I'm using 1.9 alpha by the way.
>> Pete
>> 
>> (def wat
>>  (fn*
>>([& p__9335]
>>  (let*
>>[map__9336
>> p__9335
>> map__9336
>> (if (seq? map__9336)
>>   (. clojure.lang.PersistentHashMap create (seq map__9336))
>>   map__9336)
>> a
>> (get map__9336 :a)
>> b
>> (get map__9336 :b)
>> c
>> (get map__9336 :c)
>> d
>> (get map__9336 :d)
>> e
>> (get map__9336 :e)
>> f
>> (get map__9336 :f)
>> map-0
>> (get map__9336 :map-0)
>> map-1
>> (get map__9336 :map-1)
>> map-2
>> (get map__9336 :map-2)]
>>(let*
>>  [G__9337
>>   "foo"
>>   G__9337
>>   (if a (str G__9337 a) G__9337)
>>   G__9337
>>   (if b (str G__9337 b) G__9337)
>>   G__9337
>>   (if c (str G__9337 c) G__9337)
>>   G__9337
>>   (if d (str G__9337 d) G__9337)
>>   G__9337
>>   (if e (str G__9337 e) G__9337)
>>   G__9337
>>   (if f (str G__9337 f) G__9337)
>>   G__9337
>>   (if map-0
>> (let*
>>   [G__9338
>>G__9337
>>G__9338
>>(if (:a map-0) (str G__9338 (:a map-0)) G__9338)
>>G__9338
>>(if (:b map-0) (str G__9338 (:b map-0)) G__9338)
>>G__9338
>>(if (:c map-0) (str G__9338 (:c map-0)) G__9338)]
>>   (if (:d map-0) (str G__9338 (:d map-0)) G__9338))
>> G__9337)
>>   G__9337
>>   (if map-1
>> (let*
>>   [G__9339
>>G__9337
>>G__9339
>>(if (:a map-1) (str G__9339 (:a map-1)) G__9339)
>>G__9339
>>(if (:b map-1) (str G__9339 (:b map-1)) G__9339)
>>G__9339
>>(if (:c map-1) (str G__9339 (:c map-1)) G__9339)]
>>   (if (:d map-1) (str G__9339 (:d map-1)) G__9339))
>> G__9337)]
>>  (if map-2
>>(let*
>>  [G__9340
>>   G__9337
>>   G__9340
>>   (if (:a map-2) (str G__9340 (:a map-2)) G__9340)
>>   G__9340
>>   (if (:b map-2) (str G__9340 (:b map-2)) G__9340)
>>   G__9340
>>   (if (:c map-2) (str G__9340 (:c map-2)) G__9340)]
>>  (if (:d map-2) (str G__9340 (:d map-2)) G__9340))
>>G__9337))
>> 
>> 
>> 
>> --
>> 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=e

Re: Bizzarre cond-> behavior

[Nicola Mometto]

I have a patch that fixes this, will open a ticket later today.

> On 21 Jul 2017, at 10:07, James Reeves  wrote:
> 
> I can also confirm, tested on Clojure 1.8.0. The macro doesn't seem to take 
> long at all; it's the expanded code that takes a significant time to compile.
> 
> On 21 July 2017 at 10:56, Peter Hull  > wrote:
> On Friday, 21 July 2017 00:35:00 UTC+1, Milt Reder wrote:
> Here's a simplified example:
> 
> I can confirm that pasting that defn into a CIDER repl does take a long time 
> before the prompt comes back. I tried doing a "macro expand all" and it was 
> pretty much instantaneous. The resulting expansion is quite long but not 
> unreasonable (see below). Beyond that, I'm not sure how to analyse what 
> Clojure's doing or time it. I'm using 1.9 alpha by the way.
> Pete
> 
> (def wat
>  (fn*
>([& p__9335]
>  (let*
>[map__9336
> p__9335
> map__9336
> (if (seq? map__9336)
>   (. clojure.lang.PersistentHashMap create (seq map__9336))
>   map__9336)
> a
> (get map__9336 :a)
> b
> (get map__9336 :b)
> c
> (get map__9336 :c)
> d
> (get map__9336 :d)
> e
> (get map__9336 :e)
> f
> (get map__9336 :f)
> map-0
> (get map__9336 :map-0)
> map-1
> (get map__9336 :map-1)
> map-2
> (get map__9336 :map-2)]
>(let*
>  [G__9337
>   "foo"
>   G__9337
>   (if a (str G__9337 a) G__9337)
>   G__9337
>   (if b (str G__9337 b) G__9337)
>   G__9337
>   (if c (str G__9337 c) G__9337)
>   G__9337
>   (if d (str G__9337 d) G__9337)
>   G__9337
>   (if e (str G__9337 e) G__9337)
>   G__9337
>   (if f (str G__9337 f) G__9337)
>   G__9337
>   (if map-0
> (let*
>   [G__9338
>G__9337
>G__9338
>(if (:a map-0) (str G__9338 (:a map-0)) G__9338)
>G__9338
>(if (:b map-0) (str G__9338 (:b map-0)) G__9338)
>G__9338
>(if (:c map-0) (str G__9338 (:c map-0)) G__9338)]
>   (if (:d map-0) (str G__9338 (:d map-0)) G__9338))
> G__9337)
>   G__9337
>   (if map-1
> (let*
>   [G__9339
>G__9337
>G__9339
>(if (:a map-1) (str G__9339 (:a map-1)) G__9339)
>G__9339
>(if (:b map-1) (str G__9339 (:b map-1)) G__9339)
>G__9339
>(if (:c map-1) (str G__9339 (:c map-1)) G__9339)]
>   (if (:d map-1) (str G__9339 (:d map-1)) G__9339))
> G__9337)]
>  (if map-2
>(let*
>  [G__9340
>   G__9337
>   G__9340
>   (if (:a map-2) (str G__9340 (:a map-2)) G__9340)
>   G__9340
>   (if (:b map-2) (str G__9340 (:b map-2)) G__9340)
>   G__9340
>   (if (:c map-2) (str G__9340 (:c map-2)) G__9340)]
>  (if (:d map-2) (str G__9340 (:d map-2)) G__9340))
>G__9337))
> 
> 
> 
> --
> 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 
> .
> 
> 
> 
> --
> James Reeves
> booleanknot.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 

Re: [ANN] Primitive Operator

[Nicola Mometto]

Hi Phillip,

I've had a very quick look at the code and I've spotted a few issues, here's my 
feedback:

1- all your functions will cause input args and return value to be boxed. 
There's a few ways to avoid it, none of which are particularly pretty. If your 
library is not worried about performance but just about behaviour then this is 
not a problem, if it is, I can guide you through ways to avoid boxing 
(primitive type hinting of ints and floats is unfortunately not an option).

2- defining a var called &, while technically valid, is not a good idea. 
syntax-quote will not resolve vars named & to avoid collision with the & rest 
syntax in destructuring, so I'd consider using a different name

3- clojure/core encourages libraries to provide "sufficiently uniquely named 
data literals", p/i and p/f to me while convenient don't seem unique enough to 
be safely included in a library. This one could be detabatable

Nicola

> On 3 Jul 2017, at 10:44, Phillip Lord  wrote:
> 
> 
> 
> This is the first alpha release of my new library! Comments welcome.
> 
> Clojure has an extensive system for dealing with numbers, including
> error on overflow, or auto-promotion, defaulting to long and double data
> types.
> 
> This is all well and good, but irritating if you need to implement an
> algorithm which depends on ints overflowing for instance. While, clojure
> provides functions for operating over ints, the names tend to be long
> and wieldy, such as clojure.core/unchecked-int-add. Clojure is also
> rather inconsistent; for example, the bit-shifting operators in Java are
> not accessible in Clojure over ints.
> 
> This library provides accessible, easily named float and int functions
> for Clojure. Where possible, functions with the same name as the
> operators are provided as well as names (<< and left-shift). Three Java
> operators are not valid symbols in clojure (~, % and ^), so just have
> names. Short reader literals are also provided to simplify the creation
> of ints and float.
> 
> (require '[primititve.operator.integer :as i])
> 
> (i/+ 10 10)
> => 20
> 
> (type (i/+ 10 10))
> => java.lang.Integer
> 
> (i/add 10 10)
> => 20
> 
> (i/not 10)
> => -11
> 
> (i/+ #p/i 10 #p/i 10)
> => 20
> 
> 
> https://github.com/phillord/primitive-operator
> 
> --
> 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

Re: 'get' behaviors

[Nicola Mometto]

Issue #1 had been logged in CLJ-1242, but it was later decided to just 
focus on making equality not throw as contains/get throwing is 
consistent with java behaviour, see comments from Stu and Alex here 
https://dev.clojure.org/jira/browse/CLJ-1242?focusedCommentId=40612=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-40612


Issue #2 is logged as CLJ-700 and is currently on the roadmap for 1.9 
(altho it's been postponed for a few releases already so it might happen 
again)


I'm not aware of any previous discussion on Issue #3 but IMO this is 
consistent with clojure's GIGO behaviour


On 29/05/17 19:15, rebor...@gmail.com wrote:
I was wondering if the following 'get' behaviors are worth a chat. 
Apologies if this is known issue, but they don't seem impossible 
corner cases to me.


#1

This one looks read-only access to me and I'm not sure why a suitable 
comparator should be in place.


(get(sorted-map:a1:b2)"a""not found");; ClassCastException
#2
'get' is happy with other transients (namely vectors and maps) but 
fails silently on sets:

(get(transient#{012})1);; nil
#3 (.intValue x) can throw away bits with precision loss. Sufficiently 
large keys produce the following:

(get["a""b""c"]4294967296);; "a"
Thanks
Renzo
--
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: Destructing lists using -> Difference between '(:opt1 true) and [:opt1 true]

[Nicola Mometto]

AFAIK treating kv lists as maps in destructuring was only introduced to 
support kwargs destructuring, hence why it's not supported for vectors.


On 02/01/17 18:00, Sean Corfield wrote:


This one had me scratching my head a bit too… here’s what I _/think/_ 
is going on:


First off, note that the most usual way to use the :keys destructuring 
is with a map:


(let [{:keys [opt1]}  {:opt1 true}] [opt1]) ==> [true]

As you noted, the guide explicitly calls out “lists” and in this case 
you are passing a literal list:


(let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

You’d also get the same answer with:

(let [{:keys [opt1]} (list :opt1 true)] [opt1]) ==> [true]

But in this code, you have a vector, not a list:

(let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

If you turn your vector into a sequence, it _/does/_ work:

(let [{:keys [opt1]}  (seq [:opt1 true])] [opt1]) ==> 
[true]


So it allows lists and sequences but not vectors here.

I’d be interested to know why vector isn’t treated the same as list / 
sequence here...?


Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

On 1/2/17, 2:41 AM, "mattias w"  on behalf of matti...@gmail.com 
> wrote:


Could someone explain why the first doesn't work and the 2nd does?

(let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

(let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

According to http://clojure.org/guides/destructuring

"Associative destructuring also works with lists of key-value pairs 
for keyword-arg parsing."


If I read the definition literally, I see, it says "lists" and not 
"sequences", so the behaviour is correct, so maybe a better question 
is why the definitions isn't


"Associative destructuring also works with sequences of key-value 
pairs for keyword-arg parsing."


It this specific case, when you destructor the args, it looks like a 
vector, but internally it is a list, so it works.


Happy New Year!

--
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: Reducing non-Clojure maps may not behave as expected

[Nicola Mometto]

Something like what I proposed in 
http://dev.clojure.org/jira/browse/CLJ-1807 would help solve this ambiguity


On 21/12/16 15:22, Mike Rodriguez wrote:



On Wednesday, December 21, 2016 at 9:02:36 AM UTC-6, Alex Miller wrote:



On Wednesday, December 21, 2016 at 7:24:17 AM UTC-6, Mike
Rodriguez wrote:

That sounds like a good idea to me. I think the major
potential issue is that it creates ambiguity and
non-deterministic dispatch for Clojure maps in CollReduce (as
IPersistentMaps are both Iterable and Seqable). So that would
need to be resolved.


Yes, I thought of that and should have mentioned it in my post.  It 
seems I often run into this issue with extending protocols to types 
and causing non-determinism.
It'd be hard to pinpoint a "lower" type to cover these non-Clojure 
maps too.  I suppose java.util.AbstractMap would cover a large group, 
but that still seems a bit arbitrary.


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

[Nicola Mometto]

I've used `:alias` to alias clojure.core in the past, I've seen it being
used in more than one project

On 20 Aug 2016 8:32 a.m., "Colin Fleming" 
wrote:

> (ns ... (require ...) (import ...) )  instead of (ns ... (:require ...)
>> (:import ...) )
>
>
> Is this not intended to be allowed? The docstring implies no but it has
> always worked fine - I wouldn't call the code broken.
>
> Does the spec also limit the refs to 
> refer-clojure/require/use/import/load/gen-class
> rather than allowing, say, println? One not on that list that I have seen
> people using in the wild is refer.
>
> On 20 August 2016 at 06:35, Alex Miller  wrote:
>
>> One thing to note is that the new specs for clojure.core means that there
>> is a reasonable amount of (broken) code in the wild that now does not
>> compile.
>>
>> I have filed PRs in a number of commonly used projects and while those
>> were all merged, most have not yet been released into new versions yet. Any
>> project that uses any of those projects via dependencies will also have
>> issues. So, expect to see some breakage if using the latest alpha. In
>> particular, ClojureScript itself had a bad ns declaration through version
>> 1.9.93 so anything not on a fresh CLJS will likely see that.
>>
>> The three most common things I saw were:
>>
>> 1. (ns ... (require ...) (import ...) )  instead of (ns ... (:require
>> ...) (:import ...) )
>>
>> 2. (fn a.b [] ...) - fully-qualified symbol names in fn (these are pretty
>> much always the result of a sloppy macro that expands to fn)
>>
>> 3. (let [{ ... :or {:a 1}} {}] ... ) - :or keys that are not simple
>> symbols. There were some accidental cases where this did something for
>> fully-qualified keyword keys in the past, but those were not intended and
>> are no longer accepted as of Clojure 1.9.0-alpha8. All of the cases I found
>> were actually typos though where the keyword was used instead of the symbol.
>>
>>
>>
>>
>> On Friday, August 19, 2016 at 1:15:06 PM UTC-5, Alex Miller wrote:
>>>
>>> Clojure 1.9.0-alpha11 is now available.
>>>
>>> Try it via
>>>
>>> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alp
>>> ha11
>>> - Leiningen: [org.clojure/clojure "1.9.0-alpha11"]
>>>
>>> 1.9.0-alpha11 includes the following changes since 1.9.0-alpha10:
>>>
>>> Clojure now has specs for the following clojure.core macros: let,
>>> if-let, when-let, defn, defn-, fn, and ns. Because macro specs are checked
>>> during macroexpansion invalid syntax in these macros will now fail at
>>> compile time whereas some errors were caught at runtime and some were not
>>> caught at all.
>>>
>>> - CLJ-1914 - Fixed race condition in concurrent range realization
>>> - CLJ-1870 - Fixed reloading a defmulti removes metadata on the var
>>> - CLJ-1744 - Clear unused locals, which can prevent memory leaks in some
>>> cases
>>> - CLJ-1423 - Allow vars to be invoked with infinite arglists (also,
>>> faster)
>>> - CLJ-1993 - Added *print-namespace-maps* dynamic var that controls
>>> whether to use namespace map syntax for maps with keys from the same
>>> namespace. The default is false, but standard REPL bindings set this to
>>> true.
>>> - CLJ-1985 - Fixed with-gen of conformer losing unform fn
>>> - Fixed clojure.spec.test/check to skip spec'ed macros
>>> - Fixed regression from 1.9.0-alpha8 where type hints within
>>> destructuring were lost
>>> - Fixed clojure.spec/merge docstring to note merge doesn't flow
>>> conformed values
>>> - Fixed regex ops to use gen overrides if they are used
>>>
>> --
>> 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, 

Re: [ANN] Clojure 1.9.0-alpha9

[Nicola Mometto]

I'd say that's a bug with 1.8 rather than 1.9

> On 6 Jul 2016, at 13:01, Leon Grapenthin  wrote:
> 
> @Alex Miller: Please reconsider. What you state does not apply to 1.8, i. e. 
> the ns is required in :or and such code is broken in 1.9
> 
> 1.8/1.9 differences:
> (let [{:keys [a/b] :or {b 42}} {}]
>   b)
> =>
> 1.8: nil
> 1.9: 42(let [{:keys [a/b] :or {a/b 42}} {}]
>   b)
> =>
> 1.8: 42
> 1.9: nil
> 
> 
> 
> 
> On Wednesday, July 6, 2016 at 1:43:46 PM UTC+2, Alex Miller wrote:
> This is the correct behavior. The :or map keys are always the local names 
> being bound (not the keys being looked up in the map).
> 
> > On Jul 6, 2016, at 4:40 AM, Leon Grapenthin  wrote:
> >
> > Another small bug report:
> >
> > (let [{:keys [a/b] :or {a/b 42}} {}]
> >   b)
> >
> > Evaluates to nil, but should evaluate to 42
> >
> > (let [{:keys [a/b] :or {b 42}} {}]
> >b)
> >
> > Evaluates to 42, but should evaluate to nil.
> 
> --
> 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

Re: [ANN] Clojure 1.9.0-alpha5

[Nicola Mometto]

I commented about this in the #clojure-dev slack channel, I believe 
http://dev.clojure.org/jira/browse/CLJ-1874 to be the cause of this issue


> On 9 Jun 2016, at 14:32, Alex Miller  wrote:
> 
> I think it's quite likely that you have multiple copies of tools.analyzer 
> (and possibly other libs) on your classpath. Can you take a look at your deps 
> and see if that might be the case?
> 
> A particular thing to watch for is if any dep is AOT compiled and 
> transitively pulled in a dependency lib somehow.
> 
> "lein deps :tree" is a good place to start, but it doesn't tell you what's 
> actually inside the jars. There used to be a Maven plugin that would track 
> down multiple class definitions across the dependency classpath, can't 
> remember what it was called. It would be cool if such a thing also existed 
> for Lein that would find multiple .clj/.cljc/.class files for a ns on the 
> classpath. Or maybe someone has already written that, don't know.
> 
> 
> On Wednesday, June 8, 2016 at 5:13:20 PM UTC-5, Rangel Spasov wrote:
> Hey guys - getting this compiler exception when I tried alpha 5 (up to alpha 
> 4 it was all good).
> 
> WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
> clojure.tools.analyzer.utils, being replaced by: 
> #'clojure.tools.analyzer.utils/boolean?
> 
> WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
> clojure.tools.analyzer, being replaced by: 
> #'clojure.tools.analyzer.utils/boolean?
> 
> #error {
> 
>  :cause Attempting to call unbound fn: #'clojure.tools.analyzer.utils/boolean?
> 
>  :via
> 
>  [{:type clojure.lang.Compiler$CompilerException
> 
>:message java.lang.IllegalStateException: Attempting to call unbound fn: 
> #'clojure.tools.analyzer.utils/boolean?, 
> compiling:(manifold/stream/async.clj:62:16)
> 
>:at [clojure.lang.Compiler analyzeSeq Compiler.java 6890]}
> 
>   {:type java.lang.IllegalStateException
> 
>:message Attempting to call unbound fn: 
> #'clojure.tools.analyzer.utils/boolean?
> 
>:at [clojure.lang.Var$Unbound throwArity Var.java 43]}]
> 
>  :trace
> 
> 
> --
> 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

Re: [ANN] Clojure 1.9.0-alpha4

[Nicola Mometto]

How is this a regression?

It doesn't cause any code that used to work to stop working.

The fact that tail destructuring now causes non-sequential collections to be 
destructured by sequential destructuring should be just considered an instance 
of GIGO and an implementation detail.

> On 4 Jun 2016, at 07:33, Atamert Ölçgen  wrote:
> 
> 
> 
> 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.

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

Re: lazy-seq and somewhat greedy apply

[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

Re: clojure.spec

[Nicola Mometto]

Looks like it is, in the meanwhile this patch should fix it: 
http://sprunge.us/XTiA


> On 23 May 2016, at 23:03, Nicola Mometto <brobro...@gmail.com> wrote:
> 
> Possibly CLJ-1544 related?
> 
>> On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant 
>> <abonnaireserge...@gmail.com> wrote:
>> 
>> I'm having trouble calling `s/gen`, might be some sort of AOT compilation 
>> error.
>> (I'm guessing this line has something to do with it).
>> 
>> I'm using the latest master-SNAPSHOT.
>> 
>> (ns gen-load.core
>>  (:require [clojure.spec :as s]))
>> 
>> (s/gen integer?)
>> ;CompilerException java.lang.NoClassDefFoundError: 
>> clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1)
>> 
>> Thanks,
>> Ambrose
>> 
>> On Mon, May 23, 2016 at 5:33 PM, Ambrose Bonnaire-Sergeant 
>> <abonnaireserge...@gmail.com> wrote:
>> I see, thanks.
>> 
>> On Mon, May 23, 2016 at 5:29 PM, Rich Hickey <richhic...@gmail.com> wrote:
>> fdef will not add doc metadata (see rationale re: not putting more stuff in 
>> the namespaces/vars), but specs will be present when you call ‘doc’. That 
>> doc enhancement was in a push later in the afternoon.
>> 
>> https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9
>> 
>>> On May 23, 2016, at 5:26 PM, Ambrose Bonnaire-Sergeant 
>>> <abonnaireserge...@gmail.com> wrote:
>>> 
>>> Thanks Rich+team, this is awesome.
>>> 
>>> Instrumented vars via `fdef` do not seem to add :doc metadata yet
>>> (which is advertised in the docstring for `fdef`).
>>> 
>>> Am I missing something?
>>> 
>>> Thanks,
>>> Ambrose
>>> 
>>> On Mon, May 23, 2016 at 5:20 PM, Andrey Grin <andrey.g...@gmail.com> wrote:
>>> Thank you. Yes, it seems that for recursion I can use the same approach. As 
>>> for inheritance currently I just include all parent attributes in every 
>>> child schema. As for spec definition multi-spec, as I understand it, 
>>> requires "defmethod" for every class which is probably a problem for my 
>>> case since all inheritance hierarchies are also determined at run-time. I 
>>> will need to find some approach that is both dynamic and supports precise 
>>> error messages in case validation fails.
>>> 
>>> 
>>> Am Montag, 23. Mai 2016 22:38:24 UTC+2 schrieb Alex Miller:
>>> I think you could apply the same idea - use a regular translation between 
>>> Java class and registered name and then always refer to the registered name.
>>> 
>>> There are probably multiple approaches to modeling inheritance, so hard to 
>>> recommend something without knowing more. In general, attributes coming 
>>> from super classes can be modeled using the parent attribute name. And I 
>>> would recommend looking into multi-spec for doing validation of a number of 
>>> "types" that could be flowing into the same location by leveraging a 
>>> multimethod that conditionally provides the spec to use.
>>> 
>>> On Monday, May 23, 2016 at 3:09:46 PM UTC-5, Andrey Grin wrote:
>>> Thanks, Alex. I've taken random example from plumatic.schema wiki to 
>>> quickly illustrate the question. In my actual use case I dynamically 
>>> generate schemas based on hundreds of model Java classes (beans) with 
>>> mutual references so I need recursion (and also some way to model 
>>> inheritance, that was is achieved with "conditional" in plumatic). Will try 
>>> to implement the same with spec.
>>> 
>>> 
>>> --
>>> 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 th

Re: clojure.spec

[Nicola Mometto]

Possibly CLJ-1544 related?

> On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant 
>  wrote:
> 
> I'm having trouble calling `s/gen`, might be some sort of AOT compilation 
> error.
> (I'm guessing this line has something to do with it).
> 
> I'm using the latest master-SNAPSHOT.
> 
> (ns gen-load.core
>   (:require [clojure.spec :as s]))
> 
> (s/gen integer?)
> ;CompilerException java.lang.NoClassDefFoundError: 
> clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1)
> 
> Thanks,
> Ambrose
> 
> On Mon, May 23, 2016 at 5:33 PM, Ambrose Bonnaire-Sergeant 
>  wrote:
> I see, thanks.
> 
> On Mon, May 23, 2016 at 5:29 PM, Rich Hickey  wrote:
> fdef will not add doc metadata (see rationale re: not putting more stuff in 
> the namespaces/vars), but specs will be present when you call ‘doc’. That doc 
> enhancement was in a push later in the afternoon.
> 
> https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9
> 
> > On May 23, 2016, at 5:26 PM, Ambrose Bonnaire-Sergeant 
> >  wrote:
> >
> > Thanks Rich+team, this is awesome.
> >
> > Instrumented vars via `fdef` do not seem to add :doc metadata yet
> > (which is advertised in the docstring for `fdef`).
> >
> > Am I missing something?
> >
> > Thanks,
> > Ambrose
> >
> > On Mon, May 23, 2016 at 5:20 PM, Andrey Grin  wrote:
> > Thank you. Yes, it seems that for recursion I can use the same approach. As 
> > for inheritance currently I just include all parent attributes in every 
> > child schema. As for spec definition multi-spec, as I understand it, 
> > requires "defmethod" for every class which is probably a problem for my 
> > case since all inheritance hierarchies are also determined at run-time. I 
> > will need to find some approach that is both dynamic and supports precise 
> > error messages in case validation fails.
> >
> >
> > Am Montag, 23. Mai 2016 22:38:24 UTC+2 schrieb Alex Miller:
> > I think you could apply the same idea - use a regular translation between 
> > Java class and registered name and then always refer to the registered name.
> >
> > There are probably multiple approaches to modeling inheritance, so hard to 
> > recommend something without knowing more. In general, attributes coming 
> > from super classes can be modeled using the parent attribute name. And I 
> > would recommend looking into multi-spec for doing validation of a number of 
> > "types" that could be flowing into the same location by leveraging a 
> > multimethod that conditionally provides the spec to use.
> >
> > On Monday, May 23, 2016 at 3:09:46 PM UTC-5, Andrey Grin wrote:
> > Thanks, Alex. I've taken random example from plumatic.schema wiki to 
> > quickly illustrate the question. In my actual use case I dynamically 
> > generate schemas based on hundreds of model Java classes (beans) with 
> > mutual references so I need recursion (and also some way to model 
> > inheritance, that was is achieved with "conditional" in plumatic). Will try 
> > to implement the same with spec.
> >
> >
> > --
> > 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
> 

Re: clojure.spec

[Nicola Mometto]

Some minor feedback while reading through `clojure.spec`:

`clojure.spec/->sym`  has been implemented in a significant number of libraries 
already (see: https://crossclj.info/clojure/var->sym.html), I propose we 
include this in `clojure.core` under the name of `var->sym`



> On 23 May 2016, at 15:12, Rich Hickey  wrote:
> 
> Introducing clojure.spec
> 
> I'm happy to introduce today clojure.spec, a new core library and support for 
> data and function specifications in Clojure.
> 
> Better communication
> 
> Clojure is a dynamic language, and thus far we have relied on documentation 
> or external libraries to explain the use and behavior of functions and 
> libraries. But documentation is difficult to produce, is frequently not 
> maintained, cannot be automatically checked and varies greatly in quality. 
> Specs are expressive and precise. Including spec in Clojure creates a lingua 
> franca with which we can state how our programs work and how to use them.
> 
> More leverage and power
> 
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return you 
> get from making that effort. spec gives you tools for leveraging specs in 
> documentation, validation, error reporting, destructuring, instrumentation, 
> test-data generation and generative testing.
> 
> Improved developer experience
> 
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur.
> 
> More robust software
> 
> Clojure has always been about simplifying the development of robust software. 
> In all languages, dynamic or not, tests are essential to quality - too many 
> critical properties are not captured by common type systems. spec has been 
> designed from the ground up to directly support generative testing via 
> test.check https://github.com/clojure/test.check. When you use spec you get 
> generative tests for free.
> 
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage you 
> to read the spec rationale and overview  http://clojure.org/about/spec. Look 
> for spec's inclusion in the next alpha release of Clojure, within a day or so.
> 
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome.
> 
> I hope you find spec useful and powerful!
> 
> Rich
> 
> --
> 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

Re: Reflection warning: {} argument can’t be resolved as java.util.Map

[Nicola Mometto]

Actually s/constant/literal/
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3003-L3005
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3057-L3060
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3143-L3145
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3218-L3220


> It's because you can't (currently) override type hints on constant 
> collections, see:
> 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1950-L1960
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2962-L2972

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

Re: Reflection warning: {} argument can’t be resolved as java.util.Map

[Nicola Mometto]

On 16 May 2016, at 15:53, Alex Miller  wrote:
> 
> This is kind of an interesting case. From poking at it a bit, the {} is typed 
> as a IPersistentMap, and IPM does NOT extend java.util.Map (although the 
> implementations like PersistentArrayMap and PersistentHashMap do via 
> APersistentMap).
> 
> I think the interesting question is why the type hint is not taking effect as 
> you would expect that to work. That could be because {} is a constant empty 
> map. That needs some more investigation and if you wanted to file a jira 
> ticket, we could do so further.

It's because you can't (currently) override type hints on constant collections, 
see:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1950-L1960
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2962-L2972

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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

I generally agree with this suggestion, I just want to point out that, if 
incorporated with your previous suggestion of using `double` primitive type 
hints, using `.-x` vs `:x` to acess the field will make a difference: the 
former will access the primitive field while the latter will cause it to get 
boxed

> On 12 May 2016, at 21:23, Alex Miller  wrote:
> 
> In general, it is considered bad form to use the java interop features to 
> construct or access fields of a record. Preferred:
> 
> (defn rv+
>   [v1 v2]
>   (->v2r (+ (:x v1) (:x v2))
>  (+ (:y v1) (:y v2
> 

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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Fair enough, but in this case types wouldn't really have helped: the author did 
use `Double` type hints, mistakenly assuming that would make its code use 
primitive types, which it does not since `Double` is boxed and not primitive.
Clojure already has compile time warnings about boxed math that would've helped 
in this case if turned on, without any need for types: try compiling OP's code 
after running `(set! *unchecked-math* :warn-on-boxed)`


> On 12 May 2016, at 23:05, Raoul Duke <rao...@gmail.com> wrote:
> 
> On Thu, May 12, 2016 at 2:59 PM, Nicola Mometto <brobro...@gmail.com> wrote:
>> Static types wouln't have helped at all in this case. Types are about 
>> correctness, not performances. This comment was needless
> 
> Here I thought maybe knowing when something was or was not something
> could have been useful in, you know, making the code (benchmarks in
> this case) actually do what the author wanted it to be doing. Silly
> me.
> 
> I will always have my fingers crossed for core.typed. :-)
> 
> --
> 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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Static types wouln't have helped at all in this case. Types are about 
correctness, not performances. This comment was needless


> On 12 May 2016, at 22:52, Raoul Duke  wrote:
> 
> 
> y'know, if only there were something, i dunno, something static that
> could you know have some, i dunno, 'types' that would help annotate
> things such that at maybe compile time, we'd know if the things we're
> handling are lazy or boxed or whatever-else or not.
> 
> 
> --
> 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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Not necessarily, when combined with functions that take a variable number of 
arguments.
Example:

user=> (do (apply concat () (range)) nil)
nil

If apply did realize the range lazy sequence, that form would never terminate 
rather than returning nil.

In your case however memory failed me and I was mistaken: it actually *does* 
realize the sequence because `list` eagerly iterates over the argument list 
rather than constructing it lazily.

Ignore my point about the overhead of creating the *-list lazy sequences, 
everything else still stands

> On 12 May 2016, at 22:40, JvJ  wrote:
> 
> I was under the impression that the call to "apply list" would realize the 
> lazy sequences beforehand.
> 

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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Those benchmarks are flawed and you're not testing what you think you are.

The first benchmark is the slowest of all because it's:
- realizing the nums lazy sequence
- realizing the vpairs lazy sequence
- destructuring a vector
- creating and realizing a lazy sequene of record types
- only then benchmarking the reduce operation.

In the second benchmark you're still benchmarking the destructuring of vector 
pairs and the creation and realization of a lazy sequence of types
The third benchmark is like the second in that you're creating and realizing a 
lazy sequence but it's slightly faster than the second one because you're not 
including destructuring in the mix
The last benchmark is the fastest of all because you're just iterating over an 
already realized sequence.

In no benchmark you're actually using any primitive types, you're always using 
boxed Doubles

> On 12 May 2016, at 20:58, JvJ  wrote:
> 
> I've been doing some performance tests on various floating point operations.  
> In particular, I wanted to check what would be the fastest way to implement a 
> 2-d floating point vector in clojure.
> 
> Here's my tests:
> 
> ;;; V+ Tests
> ;;; Implementing floating-point vectors as:
> ;;; structs, deftype, vector
> (defrecord v2r
> [^Double x ^Double y])
> 
> (defn rv+
>   [^v2r v1 ^v2r v2]
>   (v2r. (+ (.x v1) (.x v2))
> (+ (.y v1) (.y v2
> 
> (deftype v2t
> [^Double x ^Double y])
> 
> (defn tv+
>   [^v2t v1 ^v2t v2]
>   (v2t. (+ (.x v1) (.x v2))
> (+ (.y v1) (.y v2
> 
> (defn vv+
>   [v1 v2]
>   (mapv + v1 v2))
> 
> 
> (defn testvecs
>   "Tests the vector add operations by reducing a
>   random list by each of the v+ operations on
>   identical sets of random vectors"
>   [n]
>   (let [nums (repeatedly (* 2 n) rand)
> vpairs (partition 2 nums)
> v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs))
> v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs))
> v2v-list (apply list (map vec vpairs))]
> (println "V2 Record:")
> (bench (reduce rv+ v2r-list))
> (println "V2 Type:")
> (bench (reduce tv+ v2t-list))
> (println "V2 Vector:")
> (bench (reduce vv+ v2v-list))
> (println "Just Doubles:")
> (bench (reduce + nums
> 
> 
>  Here's my output:
> 
> V2 Record:
> Evaluation count : 420 in 60 samples of 7 calls.
>  Execution time mean : 164.379725 ms
> Execution time std-deviation : 4.478128 ms
>Execution time lower quantile : 149.546749 ms ( 2.5%)
>Execution time upper quantile : 172.317132 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 8 outliers in 60 samples (13. %)
>   low-severe   4 (6.6667 %)
>   low-mild 3 (5. %)
>   high-mild1 (1.6667 %)
>  Variance from outliers : 14.2105 % Variance is moderately inflated by 
> outliers
> V2 Type:
> Evaluation count : 1860 in 60 samples of 31 calls.
>  Execution time mean : 32.238857 ms
> Execution time std-deviation : 2.331682 ms
>Execution time lower quantile : 26.769206 ms ( 2.5%)
>Execution time upper quantile : 35.318368 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 8 outliers in 60 samples (13. %)
>   low-severe   5 (8. %)
>   low-mild 3 (5. %)
>  Variance from outliers : 53.4940 % Variance is severely inflated by outliers
> V2 Vector:
> Evaluation count : 2040 in 60 samples of 34 calls.
>  Execution time mean : 30.175015 ms
> Execution time std-deviation : 3.870306 ms
>Execution time lower quantile : 21.877116 ms ( 2.5%)
>Execution time upper quantile : 37.668717 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 10 outliers in 60 samples (16.6667 %)
>   low-severe   5 (8. %)
>   low-mild 2 (3. %)
>   high-mild3 (5. %)
>  Variance from outliers : 78.9869 % Variance is severely inflated by outliers
> Just Doubles:
> Evaluation count : 20640 in 60 samples of 344 calls.
>  Execution time mean : 4.309871 ms
> Execution time std-deviation : 537.444033 µs
>Execution time lower quantile : 2.389294 ms ( 2.5%)
>Execution time upper quantile : 4.716009 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 8 outliers in 60 samples (13. %)
>   low-severe   5 (8. %)
>   low-mild 2 (3. %)
>   high-mild1 (1.6667 %)
>  Variance from outliers : 78.9282 % Variance is severely inflated by outliers
> 
> 
> The performance is amazingly better when using primitive doubles, even though 
> all operations are doing effectively the same thing: 2 floating point add 
> operations. I assume that the overhead of allocating a new vector2 object is 
> responsible for the decline in performance.
> 
> Did I use type hints correctly?  Is there a way to keep the "x and y" vector 
> abstraction and still get something 

Re: ^:const changes data type

[Nicola Mometto]

Using `^:const` can lead to some funky behaviour, like the one you're seeing.
AFAIK The only official documentation about it can be found in the clojure 1.3 
changelog, 
https://github.com/clojure/clojure/blob/master/changes.md#215-const-defs where 
it is described as "^:const lets you name primitive values with speedier 
reference.".

There are other values that I'd say are currently "safe" to be used with 
`^:const` other than primitive values, such as strings and keywords, but I 
wouldn't use it for anything else, since it was not designed to work with 
arbitrary values but just to speed up math operations.

Nicola


> On 19 Apr 2016, at 15:43, Michael Stalker  wrote:
> 
> Adding ^:const to a var seems to change the data type sometimes:
> 
> user> (def ^:const time1 (java.sql.Timestamp. 1)
> #'user/time1
> user> (def time2 (java.sql.Timestamp. 1)
> #'user/time2
> user> (type time1)
> java.util.Date
> user> (type time2)
> java.sql.Timestamp
> 
> The upshot is that while (= time1 time2) yields true, converting these two 
> vars to strings yields different results:
> 
> user> (str time1)
> "Thu Jan 01 22:46:40 EST 1970"
> user> (str time2)
> "1970-01-01 22:46:40.0"
> 
> Daniel Gregoire pointed out that this seems be because of how the compiler 
> quotes constant vars. He showed met that eval-ing two different methods of 
> quoting yields different types:
> 
> user> (type (eval (quote (java.sql.Timestamp. 1
> java.sql.Timestamp
> user> (type (eval (list 'quote (java.sql.Timestamp. 1
> java.util.Date
> 
> Chris Bui noted that rebinding the data readers, and then evaluating the 
> second form above, yields the same data type as the first form:
> 
> user> (prn default-data-readers)
> {inst #'clojure.instant/read-instant-date, uuid 
> #'clojure.uuid/default-uuid-reader}
> nil
> user> (binding [*data-readers* {'inst 
> #'clojure.instant/read-instant-timestamp}]
> (type (eval (list 'quote (java.sql.Timestamp. 1)
> java.sql.Timestamp
> 
> Here's a gist he made.
> 
> I didn't expect ^:const to change the var's data type, and there wasn't any 
> clear documentation on this behavior that I could find. Is this a bug that I 
> should file in JIRA, or is ^:const supposed to work like this?
> 
> --
> 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

Re: changes in logging in 1.8?

[Nicola Mometto]

Unlikely, as the default behaviour hasn't changed.

Nicola

> On 15 Mar 2016, at 12:27, Stuart Sierra  wrote:
> 
> Not sure, but possible related to http://dev.clojure.org/jira/browse/CLJ-1208 
> "Namespace is not loaded on defrecord class init"
> –S
> 
> On Friday, March 11, 2016 at 12:20:44 AM UTC-5, Andy L wrote:
> Hi,
> 
> I noticed that after upgrade to Clojure  1.8.0 (from 1.7.0) a weird 
> occurrence of logging, even during uberjar generation which looks like this, 
> using lein 2.5.3:
> 
> $ lein uberjar
> Compiling core
> 2016-03-10 22:11:23.030:INFO::main: Logging initialized @964ms
> 
> I believe that actual log is pegged from here 
> https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java#L186
>  , which gniazdo depend on.
> 
> I spend some time trying to better understand the underlying cause but failed 
> to do so. My questions are:
>  1) why client code would be executed during uberjar generation (provided my 
> assumption is valid)?
>  2) what changed in 1.8 to cause that?
> 
> Thanks in advance,
> Andy
> 
> 
> = sources 
> $ cat project.clj src/core.clj
> (defproject tmp "0.1.0-SNAPSHOT"
>   :dependencies [[org.clojure/clojure "1.8.0"] [stylefruits/gniazdo "0.4.1"]]
>   :profiles {:uberjar {:aot :all}})
> (ns core
>   (:require [gniazdo.core :as ws]))
> 
> --
> 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

Re: Understanding init (the zero arity function) for transducers.

[Nicola Mometto]

Looking at both the implementation for TransformerIterator (sequence),
transduce and eduction, it's clear that the 0-arg arity is never
invoked on a  transducer, while it's ever only used to provide the
reducing step function of transduce its init value, if not provided
explicitely.

I have to agree that I don't see a point in that 0-arity for transducers.

On Thu, Mar 10, 2016 at 2:42 AM, Philos Kim  wrote:
> I wrote the next example to trace the inner workings of transducer. I hope
> that this will help.
>
> The next filter-t(transducer), map-t(transducer) and conj-t(reducer)
> functions are excerpted from the filter, map and conj from clojure.core and
> then simplified and modified to focus on the understanding of the inner
> workings.
>
> (defn filter-t
>   [pred]
>   ;; The first fn is a transducer. It receives the reducer rf and returns
>   ;; the reducer(the second fn part of this code).
>   (fn [rf]
> (fn
>   ([]
>(let [r (rf)]
>  (println "filter-t [] post: result =" r)
>  r))
>   ([result]
>(println "filter-t [result] pre: result =" result)
>(let [r (rf result)]
>  (println "filter-t [result] post: result =" r)
>  r))
>   ([result input]
>(println "filter-t [result input] pre: result =" result ", input ="
> input)
>(let [r (if (pred input)
>  (rf result input)
>  result)]
>  (println "filter-t [result input] post: result =" r)
>  r)
>
> (defn map-t
>   [f]
>   (fn [rf]
> (fn
>   ([]
>(let [r (rf)]
>  (println "map-t [] post: result =" r)
>  r))
>   ([result]
>(println "map-t [result] pre: result =" result)
>(let [r (rf result)]
>  (println "map-t [result] post: result =" r)
>  r))
>   ([result input]
>(println "map-t [result input] pre: result =" result ", input ="
> input)
>(let [r (rf result (f input))]
>  (println "map-t [result input] post: result =" r)
>  r)
>
> (defn ^:static conj-t
>   []
>   ;; This is a reducer itself, not a transducer, because it doesn't receive
> the reducer
>   ;; and return a reducer as a transducer.
>   (fn
> ([]
>  (println "conj-t []: result =" [])
>  [])
> ([result]
>  (println "conj-t [result]: result =" result)
>  result)
> ([result input]
>  (println "conj-t [result input] pre: result =" result ", input ="
> input)
>  (let [r (. clojure.lang.RT (conj result input))]
>(println "conj-t [result input] post: retrun =" r)
>r) )))
>
>
> The oupput is edited to facilitate the understandings.
>
> (def xform  (comp (filter-t odd?) (map-t #(* % 10
>
> (transduce xform (conj-t) [1 2 3 4 5])
> ;>> conj-t []: result = []
> ;
> ;   filter-t [result input] pre: result = [] , input = 1
> ; map-t [result input] pre: result = [] , input = 1
> ;   conj-t [result input] pre: result = [] , input = 10
> ;   conj-t [result input] post: retrun = [10]
> ; map-t [result input] post: result = [10]
> ;   filter-t [result input] post: result = [10]
> ;
> ;   filter-t [result input] pre: result = [10] , input = 2
> ;   filter-t [result input] post: result = [10]
> ;
> ;   filter-t [result input] pre: result = [10] , input = 3
> ; map-t [result input] pre: result = [10] , input = 3
> ;   conj-t [result input] pre: result = [10] , input = 30
> ;   conj-t [result input] post: retrun = [10 30]
> ; map-t [result input] post: result = [10 30]
> ;   filter-t [result input] post: result = [10 30]
> ;
> ;   filter-t [result input] pre: result = [10 30] , input = 4
> ;   filter-t [result input] post: result = [10 30]
> ;
> ;   filter-t [result input] pre: result = [10 30] , input = 5
> ; map-t [result input] pre: result = [10 30] , input = 5
> ;   conj-t [result input] pre: result = [10 30] , input = 50
> ;   conj-t [result input] post: retrun = [10 30 50]
> ; map-t [result input] post: result = [10 30 50]
> ;   filter-t [result input] post: result = [10 30 50]
> ;
> ;   filter-t [result] pre: result = [10 30 50]
> ; map-t [result] pre: result = [10 30 50]
> ;   conj-t [result]: result = [10 30 50]
> ; map-t [result] post: result = [10 30 50]
> ;   filter-t [result] post: result = [10 30 50]
> ;=> [10 30 50]
>
> From the above output, my conclusion is that the init part(with no argument)
> of reducer is called only in the last reducer(conj-t in this case) and never
> called in the reducers within the transducers(filter-t and map-t).
>
> If you give the init value to the transduce function as follows,
>
> (transduce xform (conj-t) [] [1 2 3 4 5])
> ;>> filter-t [result input] pre: result = [] , input = 1
> ; map-t [result input] pre: result = [] , input = 1
> ;   conj-t [result input] pre: result = [] , input = 10
> ;   conj-t [result input] post: retrun = [10]
> ; map-t [result input] post: result = [10]
> 

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

Can you post the actual code you're compiling?

> On 24 Feb 2016, at 20:03, Michael du Breuil <wicked.shell.scri...@gmail.com> 
> wrote:
> 
> I posted the disassembly from the AOT'd result, so I'm pretty clearly still 
> seeing all the casting happening at runtime. I'm not sure why that is 
> different then no.disassemble...
> 
> On Wednesday, February 24, 2016 at 5:05:30 AM UTC-7, Nicola Mometto wrote:
> 
> > On 24 Feb 2016, at 11:58, Michael du Breuil <wicked.she...@gmail.com> wrote:
> >
> > That just performs a runtime cast to a variable then reference the variable 
> > later, which is even worse.
> >
> > float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
> >   
> > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
> >  x,
> >
> >   RT.uncheckedFloatCast(-32L));
> >
> 
> 
> No it doesn't.
> 
> having
> 
> (ns test)
> 
> (definterface Foo
>   (x [^float y]))
> 
> (let [a (float 1)]
>   (defn y [b]
> (.x ^Foo b a)))
> 
> This is the disassemble of y's invoke method:
> 
>   public java.lang.Object invoke(java.lang.Object);
> Code:
>  0: aload_1
>  1: aconst_null
>  2: astore_1
>  3: checkcast #18 // class test/Foo
>  6: aload_0
>  7: getfield  #14 // Field a:F
> 10: invokeinterface #22,  2   // InterfaceMethod 
> test/Foo.x:(F)Ljava/lang/Object;
> 15: areturn
> 
> No float cast involved there. The primitive float is closed over and used 
> directly.
> 
> > I definitely expected the compiler to pay attention to it, although I also 
> > discovered at the same time that the compilier doesn't actually resolve 
> > expressions like (+ (* 2 4) 1) to just be 9 at compile time either, even 
> > though all the values were constants. Both of these are a problem because 
> > they are inside the hot loop of the program. (There are some constant math 
> > expressions that are only expressions as it is easier to read/change 
> > ^:const named things then to just put one resultant number.
> >
> > Is it worth opening a Jira issue for resolving either or both of these at 
> > compile time? I looked a briefly at the definition for (float ) but I'm not 
> > at all familiar with how the byte code is generated and how to actually 
> > replace that with what I'm looking for.
> 
> Sure, although I don't think doing this kind of constant folding this is 
> going to be a priority.
> 
> >
> > On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto wrote:
> > Those are runtime casts, this is the expected behaviour (although one could 
> > argue that clojure should be able to optimize them away at compile time).
> >
> > If you want to avoid the runtime casting, you can do something like this:
> >
> > (let [x (float 123)]
> >   (defn y [..]
> > (.foo bar x)))
> >
> >
> > > On 24 Feb 2016, at 10:53, Michael du Breuil <wicked.she...@gmail.com> 
> > > wrote:
> > >
> > > The following (this is interop with libgdx if anyone is curious, 
> > > hud-corner-top-left is a delayed TextureRegion
> > >
> > > (.draw batch ^TextureRegion @hud-corner-top-left
> > >(float -199)
> > >(float -32))
> > >
> > > Which yields the following:
> > >       
> > > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
> > >   RT.uncheckedFloatCast(-199L),
> > >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
> > >
> > > Unless I'm missing something on how to interpret bytecode :) I can post 
> > > more source if you want but that is one interop call and its generated 
> > > code, the rest will look the same.
> > >
> > > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> > > Can you post the code?
> > >
> > > > On 24 Feb 2016, at 10:26, Michael du Breuil <wicked.she...@gmail.com> 
> > > > wrote:
> > > >
> > > > I have some interop code that I have carefully specified all the 
> > > > arguments to be in the correct type (IE the function signature takes 3 
> > > > floats, so I cast everything to float so that I can avoid reflection). 
> > > > What I'm surprised by is compile time constants such as (float -173) or 
> > > > (float 8.5) are not saved as the correct primitive type, using jd-gui I 
> > > > see th

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

> On 24 Feb 2016, at 11:58, Michael du Breuil <wicked.shell.scri...@gmail.com> 
> wrote:
> 
> That just performs a runtime cast to a variable then reference the variable 
> later, which is even worse.
> 
> float x = RT.uncheckedFloatCast(-199L);((SpriteBatch)batch)
>   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__42.getRawRoot()),
>  x,
> 
>   RT.uncheckedFloatCast(-32L));
> 


No it doesn't.

having

(ns test)

(definterface Foo
  (x [^float y]))

(let [a (float 1)]
  (defn y [b]
(.x ^Foo b a)))

This is the disassemble of y's invoke method:

  public java.lang.Object invoke(java.lang.Object);
Code:
 0: aload_1
 1: aconst_null
 2: astore_1
 3: checkcast #18 // class test/Foo
 6: aload_0
 7: getfield  #14 // Field a:F
10: invokeinterface #22,  2   // InterfaceMethod 
test/Foo.x:(F)Ljava/lang/Object;
15: areturn

No float cast involved there. The primitive float is closed over and used 
directly.

> I definitely expected the compiler to pay attention to it, although I also 
> discovered at the same time that the compilier doesn't actually resolve 
> expressions like (+ (* 2 4) 1) to just be 9 at compile time either, even 
> though all the values were constants. Both of these are a problem because 
> they are inside the hot loop of the program. (There are some constant math 
> expressions that are only expressions as it is easier to read/change ^:const 
> named things then to just put one resultant number.
> 
> Is it worth opening a Jira issue for resolving either or both of these at 
> compile time? I looked a briefly at the definition for (float ) but I'm not 
> at all familiar with how the byte code is generated and how to actually 
> replace that with what I'm looking for.

Sure, although I don't think doing this kind of constant folding this is going 
to be a priority.

> 
> On Wednesday, February 24, 2016 at 3:58:46 AM UTC-7, Nicola Mometto wrote:
> Those are runtime casts, this is the expected behaviour (although one could 
> argue that clojure should be able to optimize them away at compile time).
> 
> If you want to avoid the runtime casting, you can do something like this:
> 
> (let [x (float 123)]
>   (defn y [..]
> (.foo bar x)))
> 
> 
> > On 24 Feb 2016, at 10:53, Michael du Breuil <wicked.she...@gmail.com> wrote:
> >
> > The following (this is interop with libgdx if anyone is curious, 
> > hud-corner-top-left is a delayed TextureRegion
> >
> > (.draw batch ^TextureRegion @hud-corner-top-left
> >(float -199)
> >(float -32))
> >
> > Which yields the following:
> >   
> > .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
> >   RT.uncheckedFloatCast(-199L),
> >   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
> >
> > Unless I'm missing something on how to interpret bytecode :) I can post 
> > more source if you want but that is one interop call and its generated 
> > code, the rest will look the same.
> >
> > On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> > Can you post the code?
> >
> > > On 24 Feb 2016, at 10:26, Michael du Breuil <wicked.she...@gmail.com> 
> > > wrote:
> > >
> > > I have some interop code that I have carefully specified all the 
> > > arguments to be in the correct type (IE the function signature takes 3 
> > > floats, so I cast everything to float so that I can avoid reflection). 
> > > What I'm surprised by is compile time constants such as (float -173) or 
> > > (float 8.5) are not saved as the correct primitive type, using jd-gui I 
> > > see that these were actually turned into RT.uncheckedFloatCast(-173L), 
> > > and RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved 
> > > as a the correct primitive directly in the generated bytecode? This is 
> > > with clojure 1.8.0
> > >
> > > --
> > > 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 Googl

Re: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

Those are runtime casts, this is the expected behaviour (although one could 
argue that clojure should be able to optimize them away at compile time).

If you want to avoid the runtime casting, you can do something like this:

(let [x (float 123)] 
  (defn y [..]
(.foo bar x))) 


> On 24 Feb 2016, at 10:53, Michael du Breuil <wicked.shell.scri...@gmail.com> 
> wrote:
> 
> The following (this is interop with libgdx if anyone is curious, 
> hud-corner-top-left is a delayed TextureRegion
> 
> (.draw batch ^TextureRegion @hud-corner-top-left
>(float -199)
>(float -32))
> 
> Which yields the following:
>   
> .draw((TextureRegion)((IFn)const__5.getRawRoot()).invoke(const__41.getRawRoot()),
>  
>   RT.uncheckedFloatCast(-199L), 
>   RT.uncheckedFloatCast(-32L));null;((SpriteBatch)batch)
> 
> Unless I'm missing something on how to interpret bytecode :) I can post more 
> source if you want but that is one interop call and its generated code, the 
> rest will look the same.
> 
> On Wednesday, February 24, 2016 at 3:44:11 AM UTC-7, Nicola Mometto wrote:
> Can you post the code? 
> 
> > On 24 Feb 2016, at 10:26, Michael du Breuil <wicked.she...@gmail.com> 
> > wrote: 
> > 
> > I have some interop code that I have carefully specified all the arguments 
> > to be in the correct type (IE the function signature takes 3 floats, so I 
> > cast everything to float so that I can avoid reflection). What I'm 
> > surprised by is compile time constants such as (float -173) or (float 8.5) 
> > are not saved as the correct primitive type, using jd-gui I see that these 
> > were actually turned into RT.uncheckedFloatCast(-173L), and 
> > RT.uncheckedFloatCast(8.5D), respectively. Why isn't this just saved as a 
> > the correct primitive directly in the generated bytecode? This is with 
> > clojure 1.8.0 
> > 
> > -- 
> > 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: Compile time constants not generated with the appropriate type.

[Nicola Mometto]

Can you post the code?

> On 24 Feb 2016, at 10:26, Michael du Breuil  
> wrote:
> 
> I have some interop code that I have carefully specified all the arguments to 
> be in the correct type (IE the function signature takes 3 floats, so I cast 
> everything to float so that I can avoid reflection). What I'm surprised by is 
> compile time constants such as (float -173) or (float 8.5) are not saved as 
> the correct primitive type, using jd-gui I see that these were actually 
> turned into RT.uncheckedFloatCast(-173L), and RT.uncheckedFloatCast(8.5D), 
> respectively. Why isn't this just saved as a the correct primitive directly 
> in the generated bytecode? This is with clojure 1.8.0
> 
> --
> 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

Re: [GSoC idea] Pluggable back-ends architecture for ClojureScript compiler

[Nicola Mometto]

As the author of said libraries, I'd love to see somebody pick them up during 
GSoC and continue the work.

The reason why development seems to have stalled, is different for each library:
- tools.analyzer and tools.analyzer.jvm are pretty much done and stable, all 
that's left to do is fixing a couple of bugs around reflection and investigate 
performance enhancements
- tools.analyzer.js has stalled around a year and a half ago, I simply couldn't 
keep up with the development speed of clojurescript while also maintaining 5 
other contrib libraries
- tools.emitter.jvm has stalled around the same period, since I decided that my 
time would be best spent maintaining libraries that have actual real world use 
rather than an experimental compiler :) this is not to say that it's an 
abandoned project, just that it's now very low priority for me.

If anybody wants to pick up some work around tools.analyzer.js or related to 
tools.analyzer, I'd be more than happy to help them through, although I can't 
commit to the role of a proper GSoC mentor

Nicola

> On 22 Feb 2016, at 10:57, Thomas Heller  wrote:
> 
> Projects for this already exist but are somewhat dormant.
> 
> See:
> https://github.com/clojure/tools.analyzer
> https://github.com/clojure/tools.analyzer.jvm
> https://github.com/clojure/tools.analyzer.js
> https://github.com/clojure/tools.analyzer.clr
> https://github.com/clojure/tools.emitter.jvm
> 
> Neither Clojure or ClojureScript currently use them since they are either 
> incomplete or have performance issues compared to the default implementation. 
> The idea was however to have a pluggable solution that can share as much code 
> as possible. IIRC it all started as GSoC work, so it might be useful to 
> continue in this way. I'm not sure who was involved but authors are still 
> around I think.
> 
> Cheers,
> /thomas
> 
> 
> 
> On Sunday, February 21, 2016 at 9:20:18 AM UTC+1, Edward Knyshov wrote:
> Pluggable back-ends architecture for ClojureScript compiler
> 
> Brief explanation: There are a lot of ClojureScript script compiler forks 
> exist to provide different compilation targets other than js. Most of them 
> are currently stuck because of rapid ClojureScript development and 
> difficulties with keeping fork in sync with upstream. We could consider 
> refactoring ClojureScript to provide plugable backends architecture, 
> specifically to allow users replace code generation stage of compiler and 
> implement js generator as one of such backends.
> 
> Expected results: ClojureScript compiler is refactored to allow further 
> active development of plenty other backends to bootstrap Clojure in such 
> environments as c/c++, llvm, python, emacs lisp, lua, etc. Ability to use 
> clojure mostly everywhere.
> 
> Knowledge: ClojureScript, Clojure, JavaScript
> 
> Need to know, what do you think guys.
> 
> --
> 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

Re: record implementing interface with boolean signature, how to???

[Nicola Mometto]

you're missing the `this` argument in the argvec.

(compareAndSet [this oldv newv] ..)

the boolean type hint shoulnd't be necessary.

On Wed, Feb 3, 2016 at 8:18 PM, William la Forge  wrote:
> Having a bit of a problem implementing the IAtom interface in a record.
> Specifically, this is the signature giving me grief:
>
> boolean compareAndSet(Object oldv, Object newv);
>
> This isn't the answer:
>
> (^boolean compareAndSet [oldv newv] ... )
>
>
> I get "Can't define method not in interfaces: compareAndSet".
>
> Any ideas? 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: java.lang.NoSuchFieldError: __thunk__0__

[Nicola Mometto]

Can you log this issue in clojure's JIRA? 

On Friday, January 15, 2016 at 11:21:17 PM UTC, Ryan Fowler wrote:
>
> I've got a head-scratcher.
>
> A combination of aot compiling, ring-jetty, slf4j-timbre, timbre and 
> core.async causes "java.lang.NoSuchFieldError: __thunk__0__"
>
> I've created a repo that reproduces the problem for me, but I'm out of my 
> depth at this point. Unfortunately I couldn't seem to get rid of any more 
> dependencies.
>
> https://github.com/ryfow/weird-aot
>
> If anyone is interested in digging around with me on this, please say so. 
> Here's some stack trace to entice you:
>
> Exception in thread "main" java.lang.NoSuchFieldError: __thunk__0__, 
> compiling:(/private/tmp/weird-aot/compile.clj:1:1)
> at clojure.lang.Compiler.load(Compiler.java:7239)
> at clojure.lang.Compiler.loadFile(Compiler.java:7165)
> at clojure.main$load_script.invoke(main.clj:275)
> at clojure.main$script_opt.invoke(main.clj:337)
> at clojure.main$main.doInvoke(main.clj:421)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.lang.Var.invoke(Var.java:379)
> at clojure.lang.AFn.applyToHelper(AFn.java:154)
> at clojure.lang.Var.applyTo(Var.java:700)
> at clojure.main.main(main.java:37)
> Caused by: java.lang.NoSuchFieldError: __thunk__0__
> at clojure.tools.analyzer.jvm.utils__init.load(Unknown Source)
> at clojure.tools.analyzer.jvm.utils__init.(Unknown Source)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:340)
> at clojure.lang.RT.classForName(RT.java:2154)
> at clojure.lang.RT.classForName(RT.java:2163)
> at clojure.lang.RT.loadClassForName(RT.java:2182)
> at clojure.lang.RT.load(RT.java:436)
> at clojure.lang.RT.load(RT.java:412)
> at clojure.core$load$fn__5448.invoke(core.clj:5866)
> at clojure.core$load.doInvoke(core.clj:5865)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5671)
> at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
> at clojure.core$load_lib.doInvoke(core.clj:5710)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:632)
> at clojure.core$load_libs.doInvoke(core.clj:5749)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:632)
> at clojure.core$require.doInvoke(core.clj:5832)
> at clojure.lang.RestFn.invoke(RestFn.java:703)
> at 
> clojure.tools.analyzer.jvm$loading__5340__auto1169.invoke(jvm.clj:9)
> at clojure.tools.analyzer.jvm__init.load(Unknown Source)
> at clojure.tools.analyzer.jvm__init.(Unknown Source)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:340)
> at clojure.lang.RT.classForName(RT.java:2154)
> at clojure.lang.RT.classForName(RT.java:2163)
> at clojure.lang.RT.loadClassForName(RT.java:2182)
> at clojure.lang.RT.load(RT.java:436)
> at clojure.lang.RT.load(RT.java:412)
> at clojure.core$load$fn__5448.invoke(core.clj:5866)
> at clojure.core$load.doInvoke(core.clj:5865)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5671)
> at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
> at clojure.core$load_lib.doInvoke(core.clj:5710)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:632)
> at clojure.core$load_libs.doInvoke(core.clj:5749)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:632)
> at clojure.core$require.doInvoke(core.clj:5832)
> at clojure.lang.RestFn.invoke(RestFn.java:805)
> at 
> clojure.core.async.impl.ioc_macros$loading__5340__auto675.invoke(ioc_macros.clj:12)
> at clojure.core.async.impl.ioc_macros__init.load(Unknown Source)
> at clojure.core.async.impl.ioc_macros__init.(Unknown 
> Source)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:340)
> at clojure.lang.RT.classForName(RT.java:2154)
> at clojure.lang.RT.classForName(RT.java:2163)
> at clojure.lang.RT.loadClassForName(RT.java:2182)
> at clojure.lang.RT.load(RT.java:436)
> at clojure.lang.RT.load(RT.java:412)
> at clojure.core$load$fn__5448.invoke(core.clj:5866)
> at clojure.core$load.doInvoke(core.clj:5865)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5671)
> at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
> at clojure.core$load_lib.doInvoke(core.clj:5710)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)

Re: Destructuring seems to work with PersistentList and not with PersistentVector

[Nicola Mometto]

that's an implementation detail you should not rely on.
it only works to support keyword arguments to functions
On 23 Jan 2016 17:36, "Harold"  wrote:

> Hello,
>
> While destructuring yesterday, I encountered this difference:
>
> > (let [{:keys [:a :b]} '(:a 1 :b 2)] [a b])
> [1 2]
>
> > (let [{:keys [:a :b]} [:a 1 :b 2]] [a b])
> [nil nil]
>
> I have read some of the relevant documentation and some related blog
> posts, but I am still having trouble explaining this difference
> (destructuring seems to work with PersistentList and not with
> PersistentVector).
>
> Kind thanks in advance for any insight.
>
> Warmly,
> -Harold
>
> --
> 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 beyond Java 6 ?

[Nicola Mometto]

Do you have a link where we can read about those issues?

> On 21 Jan 2016, at 18:14, Sean Corfield  wrote:
> 
> Colin Fleming wrote on Wednesday, January 20, 2016 at 6:33 PM:
>>> I feel like a broken record here, but I'd like to protest again at this 
>>> characterisation. No-one cares more than me about getting off Java 6, but I 
>>> have no choice. Oracle refuse to fix serious Swing/AWT bugs in later 
>>> versions of the JVM, so many IntelliJ (and thus Cursive) users have no 
>>> choice but to use it.
> 
> And as another data point from another language community:
> 
> The Frege project (a Haskell for the JVM) is running into problems with the 
> Java 8 compiler (producing invalid JVM bytecode or just plain ol’ crashing), 
> which is making it impossible to move from Java 7 to Java 8. Given Java 9 
> builds are starting to appear, the likelihood of these Java 8 bugs getting 
> fixed is close to zero, and Java 9 is far too "bleeding edge" to force even 
> the contributors to the Frege project to jump to it. Which means Frege is 
> stuck with Java 7 at this point.
> 
> I’ve defended Clojure’s continued support for Java 6 on the grounds that it 
> makes new versions of Clojure accessible to companies that are still on older 
> versions of the JVM. As Colin says, and as seen in the Frege project, there 
> are many valid reasons why older versions of the JVM continue to be used.
> 
> Just because you are not affected by JVM issues doesn’t mean that other 
> people’s reasons for supporting older versions are invalid!
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> 
> 
> 
> -- 
> 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] Clojure 1.8.0-RC5

[Nicola Mometto]

Thanks for your reports Andy, useful and prompt as always :) 


> On 13 Jan 2016, at 16:32, Andy Fingerhut  wrote:
> 
> Results of some testing done on 1.8.0-RC5:
> 
> Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.  
> Reason: there have been (or still are) build or test failures with some of 
> them.  All JDKs listed below were 64-bit.
> 
> Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80: ok 3/3 trials
> Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_91: ok 3/3 trials
> Ubuntu 14.04.3 LTS + IBM JDK 1.7.0 (based on jdk7u75-b12): ok 10/10 trials, 
> as long as failing tests mentioned in 
> http://dev.clojure.org/jira/browse/CLJ-1678 are commented out
> Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for IBM 
> JDK 1.7.0
> Ubuntu 14.04.3 LTS + Oracle JDK 1.9.0-ea-b91: ok 3/3 trials
> Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 106/106 trials
> 
> Running Eastwood version 0.2.2 with Clojure 1.8.0-RC5 on 84 open source 
> Clojure projects and all namespaces within Clojure itself gives very similar 
> results as when using Clojure 1.7.0.
> 
> Differences in results are listed below.  All of them look benign to me.
> 
> One project that uses (throw) with no arguments, and thus Clojure 1.8.0-RC5 
> gives a compilation error that Clojure 1.7.0 did not.  This is an improvement 
> in error checking in 1.8.0-RC5: http://dev.clojure.org/jira/browse/CLJ-1456
> 
> Several reflection warnings in Clojure itself in namespace clojure.instant 
> are no longer there.  This is due to a performance improvement in 1.8.0-RC5: 
> http://dev.clojure.org/jira/browse/CLJ-1277
> 
> The following reflection warnings appear with Clojure 1.7.0 + Eastwood 0.2.2, 
> but not with Clojure 1.8.0-RC5 + Eastwood 0.2.2.  I haven't tried to dig into 
> exactly why this change occurred.  They are all for the same interop call in 
> clj-time.  I would be surprised if this was a bug.  Seems more likely to be 
> the result of an intentional change in Clojure method resolution.  I was 
> using JDK 1.8.0_11 on Mac OS X 10.11.2, in case it makes a difference.
> 
> In project Carmine:
> 
> == Linting taoensso.carmine.tundra.s3 ==
> jar:file:/Users/admin/.m2/repository/clj-time/clj-time/0.6.0/clj-time-0.6.0.jar!/clj_time/core.clj:577:10:
>  Reflection warning - reference to field getDayOfMonth on java.lang.Object 
> can't be resolved.
> 
> Project compojure:
> 
> == Linting compojure.handler ==
> jar:file:/Users/admin/.m2/repository/clj-time/clj-time/0.6.0/clj-time-0.6.0.jar!/clj_time/core.clj:577:10:
>  Reflection warning - reference to field getDayOfMonth on java.lang.Object 
> can't be resolved.
> 
> Project lib-noir:
> 
> == Linting noir.cookies ==
> jar:file:/Users/admin/.m2/repository/clj-time/clj-time/0.6.0/clj-time-0.6.0.jar!/clj_time/core.clj:577:10:
>  Reflection warning - reference to field getDayOfMonth on java.lang.Object 
> can't be resolved.
> 
> 
> On Mon, Jan 11, 2016 at 6:52 AM, Alex Miller  wrote:
> Clojure 1.8.0-RC5 is now available. 
> 
> This is likely the final "release candidate" for 1.8. Please test this build 
> with your libraries and applications and provide feedback as soon as 
> possible. If we have not heard any critical issues, we expect to make this 
> the final release in about a week.
> 
> Try it via:
>   • Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC5
>   • Leiningen: [org.clojure/clojure "1.8.0-RC5"]
> Below are the changes since 1.8.0-RC4. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>   • CLJ-1868 - Fixes regression in the error message returned in the case 
> of a bad return type class
>   • CLJ-1829 - Modifies the socket server to avoid an issue with the 
> locking macro in Android
> 
> -- 
> 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 

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Nicola Mometto]

Thanks for that, I've attached a possible fix to the ticket.

> On 5 Jan 2016, at 15:40, 'wparke...@yahoo.com' via Clojure 
> <clojure@googlegroups.com> wrote:
> 
> I have logged an issue at http://dev.clojure.org/jira/browse/CLJ-1874  
> 
> Thank you all for the responses.
> 
> On Wednesday, December 30, 2015 at 12:02:35 PM UTC-6, Nicola Mometto wrote:
> While it's true that AOT has many issues, it's getting better release after 
> release and this is definitely a bug. 
> I don't understand why you wouldn't expect this to work, you *should*. 
> 
> OP: can you open a ticket for this bug? I'd love to have a look at this and 
> try to fix it. 
> 
> > On 29 Dec 2015, at 17:28, Stuart Sierra <the.stua...@gmail.com> wrote: 
> > 
> > AOT-compilation breaks almost any code that tries to redefine Vars. I 
> > wouldn't expect this to work. 
> > —S 
> > 
> > 
> > On Monday, December 28, 2015, wparker30 wrote: 
> > I have found what appears to be a bug in AOT-compiled Clojure when ns-unmap 
> > is used.  I have the following reduced case: 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (def a :test-2) 
> > 
> > It turns out that a is not resolvable when this namespace is loaded.  When 
> > I looked at the compiled bytecode, 
> > it appears that the following operations occur: 
> > 
> > 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
> > bound to a constant. 
> >   This var is added to the namespaces's mapping during this call. 
> > 2. Same as 1. 
> > 3. The var from 1 is bound to :test-1. 
> > 4. ns-unmap is called. 
> > 5. The var from 2 is bound to :test-2. 
> > 
> > Disclaimer: This is the first time I have had occasion to look directly at 
> > bytecode and I could be missing something. 
> > 
> > The basic problem here is that the var is accessible from the load method, 
> > but when step 5 executes the var is no longer 
> > accessible from the namespace mappings.  Thus, the root of the Var is set 
> > to :test-2, but that Var is not mapped from the namespace. 
> > This works when there is no AOT compilation, as well as when I use 
> > 
> > (ns unmap-test.core) 
> > 
> > (def a :test-1) 
> > 
> > (ns-unmap 'unmap-test.core 'a) 
> > 
> > (intern 'unmap-test.core 'a :test-2) 
> > 
> > I realize that creating defs, unmapping them, and then recreating them is 
> > generally poor practice in Clojure. 
> > We have an odd case in that we need to have an interface and a Var of the 
> > same name in the same namespace.  Simply 
> > doing definterface and then def causes a compilation failure: 
> > 
> > user=> (definterface abc) 
> > user.abc 
> > user=> (def abc 1) 
> > CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> > mapped to interface user.abc, 
> > compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
> >  
> > 
> > Without going into too much detail, this is basically a hack to allow us to 
> > refactor our internal framework code 
> > without immediately changing a very large amount of downstream consumer 
> > code.  We get rid of the usage of the interface during macroexpansion, 
> > but it still needs to exist on the classpath so it can be imported by 
> > downstream namespaces.   
> > There are a number of other ways to accomplish this, so it isn't a 
> > particularly big problem for us, but I thought the issue was worth raising. 
> > This was just the first thing I tried and I was surprised when it didn't 
> > work. 
> > 
> > Note that I used the 1.8.0 RC4 version of Clojure in my sample project, but 
> > I had the same behavior on 1.7.0. 
> > 
> > Relevant links: 
> > 
> > 1. Bytecode for the load method of the init class: 
> > https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a 
> > 2. Bytecode for the init0 method: 
> > https://gist.github.com/WilliamParker/dc606ad086670915efd9 
> > 3. Decompiled Java code for the init class.  Note that this does not 
> > completely line up with the bytecode as far as I can tell, 
> > but it is a quicker way to get a general idea of what is happening than the 
> > bytecode. 
> > https://gist.github.com/WilliamParker/4cc47939f613d4595d94 
> > 4. A simple project containing the code above: 
> > https://github.com/WilliamParker/unmap-test 
> > Note that if you try it without AOT compilation the target folde

Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Nicola Mometto]

While it's true that AOT has many issues, it's getting better release after 
release and this is definitely a bug. 
I don't understand why you wouldn't expect this to work, you *should*.

OP: can you open a ticket for this bug? I'd love to have a look at this and try 
to fix it.

> On 29 Dec 2015, at 17:28, Stuart Sierra  wrote:
> 
> AOT-compilation breaks almost any code that tries to redefine Vars. I 
> wouldn't expect this to work.
> —S
> 
> 
> On Monday, December 28, 2015, wparker30 wrote:
> I have found what appears to be a bug in AOT-compiled Clojure when ns-unmap 
> is used.  I have the following reduced case:
> 
> (ns unmap-test.core)
> 
> (def a :test-1)
> 
> (ns-unmap 'unmap-test.core 'a)
> 
> (def a :test-2)
> 
> It turns out that a is not resolvable when this namespace is loaded.  When I 
> looked at the compiled bytecode,
> it appears that the following operations occur:
> 
> 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
> bound to a constant.
>   This var is added to the namespaces's mapping during this call.
> 2. Same as 1.
> 3. The var from 1 is bound to :test-1.
> 4. ns-unmap is called.
> 5. The var from 2 is bound to :test-2.
> 
> Disclaimer: This is the first time I have had occasion to look directly at 
> bytecode and I could be missing something.
> 
> The basic problem here is that the var is accessible from the load method, 
> but when step 5 executes the var is no longer
> accessible from the namespace mappings.  Thus, the root of the Var is set to 
> :test-2, but that Var is not mapped from the namespace.
> This works when there is no AOT compilation, as well as when I use 
> 
> (ns unmap-test.core)
> 
> (def a :test-1)
> 
> (ns-unmap 'unmap-test.core 'a)
> 
> (intern 'unmap-test.core 'a :test-2)
> 
> I realize that creating defs, unmapping them, and then recreating them is 
> generally poor practice in Clojure.
> We have an odd case in that we need to have an interface and a Var of the 
> same name in the same namespace.  Simply
> doing definterface and then def causes a compilation failure:
> 
> user=> (definterface abc)
> user.abc
> user=> (def abc 1)
> CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
> 
> Without going into too much detail, this is basically a hack to allow us to 
> refactor our internal framework code
> without immediately changing a very large amount of downstream consumer code. 
>  We get rid of the usage of the interface during macroexpansion,
> but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.  
> There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising.
> This was just the first thing I tried and I was surprised when it didn't work.
> 
> Note that I used the 1.8.0 RC4 version of Clojure in my sample project, but I 
> had the same behavior on 1.7.0.
> 
> Relevant links:
> 
> 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a
> 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9
> 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell,
> but it is a quicker way to get a general idea of what is happening than the 
> bytecode.
> https://gist.github.com/WilliamParker/4cc47939f613d4595d94
> 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test
> Note that if you try it without AOT compilation the target folder with any 
> previously compiled classes should be removed.
> 
> I may or may not be able to respond to any replies before next week; I 
> apologize for any delayed responses.
> 
> -- 
> 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

Re: [ANN] Clojure 1.8.0-RC3

[Nicola Mometto]

Before 1.8, clojure would accept wrong forms like (throw my-exception 1 2 3).

This is now an exception http://dev.clojure.org/jira/browse/CLJ-1456.


> On 8 Dec 2015, at 13:05, Noam Ben-Ari  wrote:
> 
> Hi,
> I have just tried 1.8.0-RC3 and saw a problem.
> 
> I have a project in which I run tests with `lein midje`, and this runs fine 
> with 1.7.0.
> 
> When I change the clojure dependency to 1.8.0-RC3 and run it I get this 
> exception:
> 
> ---
> 
> Exception in thread "main" java.lang.RuntimeException: Too many arguments to 
> throw, throw expects a single Throwable instance, 
> compiling:(reduce_fsm.clj:203:5)
> 
> ---
> 
> Let me know what other information I can give to help.
> 
> Thanks,
> Noam.
> 
> On Wednesday, December 2, 2015 at 6:03:31 PM UTC+2, Alex Miller wrote:
> Clojure 1.8.0-RC3 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. 
> 
> Try it via
>   • Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3
>   • Leiningen: [org.clojure/clojure "1.8.0-RC3"]
> Below are the changes since 1.8.0-RC2. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>   • CLJ-1845 / CLJ-1851 New ^:redef to mark vars that should not be 
> direct linked
>   • The metadata ^:redef can be used to mark function vars that 
> should not be direct linked
>   • clojure.core/load was previously marked with ^:dynamic for 
> this purpose, but is now marked ^:redef
>   • CLJ-1856 Direct linking breaks clojure.test location reporting for 
> failures
>   • CLJ-1854 Set line number in bytecode prior to invokeStatic call
>   • CLJ-1853 In socket server, require the ns of the accept-fn before 
> resolving it
> 
> -- 
> 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: Naming convention for atoms, refs, etc.?

[Nicola Mometto]

I seriously doubt that's ever going to happen. There's no good reason to do 
that.

> On 6 Dec 2015, at 21:00, Gregg Reynolds <d...@mobileink.com> wrote:
> 
> 
> On Dec 6, 2015 2:45 PM, "Nicola Mometto" <brobro...@gmail.com> wrote:
> >
> > 'foo@ is not a valid symbol name
> 
> Oops.  Maybe now is the time to make good on "other characters may be allowed 
> eventually" (from the Reader doc.)  I can't think of a good reason not to 
> allow @ in symbols.  Would it mess anything up?
> 
> > > On 6 Dec 2015, at 20:44, Gregg Reynolds <d...@mobileink.com> wrote:
> > >
> > > Ps.  Note the nice symmetry between *foo* and @foo@.
> > >
> > > On Dec 6, 2015 2:42 PM, "Gregg Reynolds" <d...@mobileink.com> wrote:
> > > Postfix @?  Haven't pondered this before but I like the idea.  Why should 
> > > perl have all the fun?
> > >
> > > On Dec 5, 2015 3:47 PM, "Mars0i" <marsh...@logical.net> wrote:
> > > &, $, and ! might be good to use as special naming characters for 
> > > atoms/refs/agents, either as an initial char, a final char, or both, but 
> > > I'm wondering whether anyone already has a naming convention that they 
> > > use.
> > >
> > > --
> > > 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 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: Naming convention for atoms, refs, etc.?

[Nicola Mometto]

'foo@ is not a valid symbol name

> On 6 Dec 2015, at 20:44, Gregg Reynolds  wrote:
> 
> Ps.  Note the nice symmetry between *foo* and @foo@.
> 
> On Dec 6, 2015 2:42 PM, "Gregg Reynolds"  wrote:
> Postfix @?  Haven't pondered this before but I like the idea.  Why should 
> perl have all the fun?
> 
> On Dec 5, 2015 3:47 PM, "Mars0i"  wrote:
> &, $, and ! might be good to use as special naming characters for 
> atoms/refs/agents, either as an initial char, a final char, or both, but I'm 
> wondering whether anyone already has a naming convention that they use.
> 
> -- 
> 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: [ANN] Clojure 1.8.0-RC3

[Nicola Mometto]

all the clojure contrib libraries are regularly tested against new clojure 
versions
http://build.clojure.org/

> On 2 Dec 2015, at 16:17, Sreenivas Reddy T  
> wrote:
> 
> I would love a project where the tool runs all  test cases of libraries 
> against new release candidate. 
> 
> On 2 Dec 2015 9:33 pm, "Alex Miller"  wrote:
> Clojure 1.8.0-RC3 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. 
> 
> Try it via
>   • Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3
>   • Leiningen: [org.clojure/clojure "1.8.0-RC3"]
> Below are the changes since 1.8.0-RC2. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>   • CLJ-1845 / CLJ-1851 New ^:redef to mark vars that should not be 
> direct linked
>   • The metadata ^:redef can be used to mark function vars that 
> should not be direct linked
>   • clojure.core/load was previously marked with ^:dynamic for 
> this purpose, but is now marked ^:redef
>   • CLJ-1856 Direct linking breaks clojure.test location reporting for 
> failures
>   • CLJ-1854 Set line number in bytecode prior to invokeStatic call
>   • CLJ-1853 In socket server, require the ns of the accept-fn before 
> resolving it
> 
> -- 
> 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: Extend ns macro?

[Nicola Mometto]

def interns the var at compile time, binding is a runtime operation

> On 2 Dec 2015, at 16:56, Gregg Reynolds  wrote:
> 
> 
> 
> On Wed, Dec 2, 2015 at 8:11 AM, gianluca torta  wrote:
> for some reason, it looks like the implementation of the ns macro assumes 
> that the macro itself is being defined in namespace clojure.core
> 
> try defining myns in the namespace clojure.core, and it should work
> 
> Thanks, Gianluca.  I tried that but def macros don't seem to respect 
> rebinding *ns*.
> 
> (ns foo)
> (println *ns*) ;; => #object[clojure.lang.Namespace 0x73eb2c69 foo]
> (binding [*ns* (create-ns 'clojure.core)]
>   (println *ns*) ;; => #object[clojure.lang.Namespace 0x255f1d1 clojure.core]
>   (def bar "i should be in clojure.core!")
>   (println (var bar))) ;; => #'foo/bar
> 
> I also tried in-ns and with-redefs to no avail.
> 
> Interning seems to work:
> 
> (ns foo)
> (defmacro co-ns
>   ... code from clojure.core/defmacro ns...)
> (intern 'clojure.core (with-meta 'co-ns {:macro true}) @#'co-ns)
> 
> This puts the co-ns macro in clojure.core, but I still have to qualify the 
> call: foo/co-ns or clojure.core/co-ns.  I haven't been able to get (co-ns 
> ...) to work at top of file, but maybe it's better to qualify it anyway.
> 
> In the end it's embarrasingly simple:
> 
> ;; foo.clj
> (ns foo)
> (defmacro co-ns
>   [name & references]
>   ;; customizing code here...
>   (doseq [ref references] (println ref))
>   `(ns ~name ~@references)
>   ;; ... and here
>   (println "hello CONS"))
> (intern 'clojure.core (with-meta 'co-ns {:macro true}) @#'co-ns)
> 
> and the interning bit isn't even necessary.  This makes it easy to add ref 
> keywords, e.g. (foo/co-ns (:require ...) (:my-ref ...))
> 
> Thanks,
> 
> Gregg
> 
> 
> 
> -- 
> 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] Clojure 1.8.0-RC2

[Nicola Mometto]

*clojure-version* is not a function, it's not affected by direct linking

> On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant 
>  wrote:
> 
> I'm missing something, alter-var-root'ing *clojure-version* works just fine 
> when calling (clojure-version).
> 
> (alter-var-root #'*clojure-version* assoc :qualifier "patched")
> (clojure-version)
> ;=> "1.8.0-patched"
> 
> Thanks,
> Ambrose
> 
> On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant 
>  wrote:
> I don't think CLJ-1845 had the intended effect.
> 
> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply f 
> args
> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6 
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> user=> (load)
> "patched"
> nil
> user=> (require 'clojure.core :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload-all)
> nil
> 
> I was expected "patched" to be printed with each call to `load` via `require`.
> 
> Do others observe this also?
> 
> Thanks,
> Ambrose
> 
> 
> On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller  wrote:
> Clojure 1.8.0-RC2 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. 
> 
> Try it via
>   • Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
>   • Leiningen: [org.clojure/clojure "1.8.0-RC2"]
> Below are the changes since 1.8.0-RC1. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>   • CLJ-1846 Fix VerifyError when primitive type hints are incorrect. 
> These cases now throw compiler errors.
>   • Example: (defn foo ^long [] 1)  (Integer/bitCount ^int (foo))
>   • In this example, foo returns a long but is type hinted 
> (incorrectly) as an int. This case will now throw a compilation error. The 
> correct way to do this is with a cast:  (Integer/bitCount (int (foo)))
>   • CLJ-1825 Fix compilation errors on direct linking of anonymous 
> recursive functions
> 
> -- 
> 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: [ANN] Clojure 1.8.0-RC2

[Nicola Mometto]

It doesn't, but direct linking only affects invocations


> On 20 Nov 2015, at 15:21, Ambrose Bonnaire-Sergeant 
> <abonnaireserge...@gmail.com> wrote:
> 
> Wait, how does the compiler know that *clojure-version* isn't a function?
> 
> On Fri, Nov 20, 2015 at 10:01 AM, Nicola Mometto <brobro...@gmail.com> wrote:
> *clojure-version* is not a function, it's not affected by direct linking
> 
> > On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant 
> > <abonnaireserge...@gmail.com> wrote:
> >
> > I'm missing something, alter-var-root'ing *clojure-version* works just fine 
> > when calling (clojure-version).
> >
> > (alter-var-root #'*clojure-version* assoc :qualifier "patched")
> > (clojure-version)
> > ;=> "1.8.0-patched"
> >
> > Thanks,
> > Ambrose
> >
> > On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant 
> > <abonnaireserge...@gmail.com> wrote:
> > I don't think CLJ-1845 had the intended effect.
> >
> > user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply f 
> > args
> > #object[user$eval1241$fn__1242$fn__1243 0x1c857e6 
> > "user$eval1241$fn__1242$fn__1243@1c857e6"]
> > user=> (load)
> > "patched"
> > nil
> > user=> (require 'clojure.core :reload)
> > nil
> > user=> (require 'clojure.tools.analyzer :reload)
> > nil
> > user=> (require 'clojure.tools.analyzer :reload-all)
> > nil
> >
> > I was expected "patched" to be printed with each call to `load` via 
> > `require`.
> >
> > Do others observe this also?
> >
> > Thanks,
> > Ambrose
> >
> >
> > On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller <a...@puredanger.com> wrote:
> > Clojure 1.8.0-RC2 is now available. This build is a "release candidate"! We 
> > would appreciate any and all testing you can do on your own libraries or 
> > internal projects to find problems.
> >
> > Try it via
> >   • Download: 
> > https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
> >   • Leiningen: [org.clojure/clojure "1.8.0-RC2"]
> > Below are the changes since 1.8.0-RC1. See the full 1.8 change log here: 
> > https://github.com/clojure/clojure/blob/master/changes.md.
> >   • CLJ-1846 Fix VerifyError when primitive type hints are incorrect. 
> > These cases now throw compiler errors.
> >   • Example: (defn foo ^long [] 1)  (Integer/bitCount ^int 
> > (foo))
> >   • In this example, foo returns a long but is type hinted 
> > (incorrectly) as an int. This case will now throw a compilation error. The 
> > correct way to do this is with a cast:  (Integer/bitCount (int (foo)))
> >   • CLJ-1825 Fix compilation errors on direct linking of anonymous 
> > recursive functions
> >
> > --
> > 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 subscrib

Re: Reflection warning on try/catch inside go block

[Nicola Mometto]

It's possibly a tools.analyzer issue, I'll take a look ASAP

> On 16 Nov 2015, at 12:41, Alice  wrote:
> 
> Sorry, I was having some copy & paste mistake, but I'm seeing the same 
> warning with .printStackTrace.
> 
> On Monday, November 16, 2015 at 9:25:06 PM UTC+9, Herwig Hochleitner wrote:
> The method is called .printStackTrace: 
> http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html#printStackTrace()
> 
> I can't speak to why the reflection warning disappears in some cases. Seems 
> fishy,
> ​
> 
> -- 
> 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] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

*mostly* works, and since 1.8 only.
The issue pre 1.8 is that since metadata on arglist is not evaluated, the type 
hint wasn't a fully qualified classname, forcing the user namespaces to import 
that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))
(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))
(.method (foo/foo))


> On 12 Nov 2015, at 19:49, Leon Grapenthin <grapenthinl...@gmail.com> wrote:
> 
> Does this mean putting it in the arglist always works and there is rarely a 
> practical reason to do anything else?
> 
> On Thursday, November 12, 2015 at 8:36:20 PM UTC+1, Nicola Mometto wrote:
> It.. depends :(
> 
> If your type hint is a *primitive* then you want to put it in the arglist. If 
> you put it in the Var, the best case scenario is that you'll get either 
> reflection warnings or boxed maths, and the worst case scenario is a 
> Compiler/bytecode error.
> 
> If your type hint is an array type hint (^objects, ^ints ..) you want to put 
> it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).
> 
> If your type hint is a non primitive class, you want to put it in the Var or 
> in the arglist as a fully qualified symbol (not necessary anymore since 1.8)
> 
> If your type hint is a string representing a class, you can safely put it in 
> either place.
> 
>> On 12 Nov 2015, at 19:28, Michael Blume <blume...@gmail.com > 
>> wrote:
>> 
>> Sorry, I'm confused now -- is the appropriate place to give a return type 
>> hint for a function the arg list and not the function name? I've always seen 
>> the function name hinted.
>> 
>> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto <brob...@gmail.com 
>> > wrote:
>> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
>> 
>>> On 12 Nov 2015, at 19:14, Nicola Mometto <brob...@gmail.com > 
>>> wrote:
>>> 
>>> 
>>> Depends on how you look at it.
>>> From my point of view, both examples are using an otherwise valid type 
>>> hint, at an invalid location, and in both cases the emitted code is 
>>> nonsensical.
>>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>>> with a compile time error, this one should too.
>>> 
>>> 
>>>> On 12 Nov 2015, at 16:47, Alex Miller <al...@puredanger.com > 
>>>> wrote:
>>>> 
>>>> Neither is acceptable, so I either misunderstand or disagree with your 
>>>> question. :) 
>>>> 
>>>> The code below is an invalid type hint at that location. Are you maybe 
>>>> saying this should throw an error on definition?
>>>> 
>>>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>>>> Which now throws an error.
>>>> 
>>>> 
>>>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>>> This is :rettag in action.
>>>> Any reason why this error should be acceptable while the CLJ-1846 one 
>>>> isn't?
>>>> 
>>>>> On 12 Nov 2015, at 12:55, Alex Miller <al...@puredanger.com 
>>>>> > wrote:
>>>>> 
>>>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>>>> double function object. You really want:
>>>>> 
>>>>> (defn timespi ^double [^double x] (* x 3.14))
>>>>> 
>>>>> 
>>>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebo...@gmail.com 
>>>>>  wrote:
>>>>> Hello,
>>>>> 
>>>>> the following stops executing on 1.8.0-rc1 or current master-head 
>>>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>>>>> CLJ-1846):
>>>>> 
>>>>> [/Users/reborg]$ repl
>>>>> Clojure 1.8.0-master-SNAPSHOT
>>>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>>>> #'user/timespi
>>>>> user=> (timespi 2)
>>>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; 
>>>>> is abstract  user/timespi (NO_SOURCE_FILE:-1)
>>>>> 
>>>>> It works if you enable direct linking (or if you use 1.7.0).
>>>>> 
>>>>> Renzo
>>>> 
>>>> 
>>>> -- 
>>>> 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 
&g

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

It.. depends :(

If your type hint is a *primitive* then you want to put it in the arglist. If 
you put it in the Var, the best case scenario is that you'll get either 
reflection warnings or boxed maths, and the worst case scenario is a 
Compiler/bytecode error.

If your type hint is an array type hint (^objects, ^ints ..) you want to put it 
in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).

If your type hint is a non primitive class, you want to put it in the Var or in 
the arglist as a fully qualified symbol (not necessary anymore since 1.8)

If your type hint is a string representing a class, you can safely put it in 
either place.

> On 12 Nov 2015, at 19:28, Michael Blume <blume.m...@gmail.com> wrote:
> 
> Sorry, I'm confused now -- is the appropriate place to give a return type 
> hint for a function the arg list and not the function name? I've always seen 
> the function name hinted.
> 
> On Thu, Nov 12, 2015 at 11:20 AM Nicola Mometto <brobro...@gmail.com 
> <mailto:brobro...@gmail.com>> wrote:
> Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8
> 
>> On 12 Nov 2015, at 19:14, Nicola Mometto <brobro...@gmail.com 
>> <mailto:brobro...@gmail.com>> wrote:
>> 
>> 
>> Depends on how you look at it.
>> From my point of view, both examples are using an otherwise valid type hint, 
>> at an invalid location, and in both cases the emitted code is nonsensical.
>> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
>> with a compile time error, this one should too.
>> 
>> 
>>> On 12 Nov 2015, at 16:47, Alex Miller <a...@puredanger.com 
>>> <mailto:a...@puredanger.com>> wrote:
>>> 
>>> Neither is acceptable, so I either misunderstand or disagree with your 
>>> question. :) 
>>> 
>>> The code below is an invalid type hint at that location. Are you maybe 
>>> saying this should throw an error on definition?
>>> 
>>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>>> Which now throws an error.
>>> 
>>> 
>>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>>> This is :rettag in action.
>>> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
>>> 
>>>> On 12 Nov 2015, at 12:55, Alex Miller <a...@puredanger.com 
>>>> <mailto:a...@puredanger.com>> wrote:
>>>> 
>>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>>> double function object. You really want:
>>>> 
>>>> (defn timespi ^double [^double x] (* x 3.14))
>>>> 
>>>> 
>>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>>>> <mailto:rebor...@gmail.com> wrote:
>>>> Hello,
>>>> 
>>>> the following stops executing on 1.8.0-rc1 or current master-head 
>>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>>>> CLJ-1846):
>>>> 
>>>> [/Users/reborg]$ repl
>>>> Clojure 1.8.0-master-SNAPSHOT
>>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>>> #'user/timespi
>>>> user=> (timespi 2)
>>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>>>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>>>> 
>>>> It works if you enable direct linking (or if you use 1.7.0).
>>>> 
>>>> Renzo
>>> 
>>> 
>>> -- 
>>> 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 group and stop receiving emails from it, send an 
>>> email to clojure+unsubscr...@googlegroups.com 
>>> <mailto:clojure+unsubscr...@googlegroups.com>.
>>&g

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Depends on how you look at it.
>From my point of view, both examples are using an otherwise valid type hint, 
>at an invalid location, and in both cases the emitted code is nonsensical.
So I'd say that if the decision for the CLJ-1846 issue was to handle that with 
a compile time error, this one should too.


> On 12 Nov 2015, at 16:47, Alex Miller <a...@puredanger.com> wrote:
> 
> Neither is acceptable, so I either misunderstand or disagree with your 
> question. :) 
> 
> The code below is an invalid type hint at that location. Are you maybe saying 
> this should throw an error on definition?
> 
> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
> Which now throws an error.
> 
> 
> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
> This is :rettag in action.
> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
> 
>> On 12 Nov 2015, at 12:55, Alex Miller <a...@puredanger.com 
>> <mailto:a...@puredanger.com>> wrote:
>> 
>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>> double function object. You really want:
>> 
>> (defn timespi ^double [^double x] (* x 3.14))
>> 
>> 
>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>> <mailto:rebor...@gmail.com> wrote:
>> Hello,
>> 
>> the following stops executing on 1.8.0-rc1 or current master-head 
>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>> CLJ-1846):
>> 
>> [/Users/reborg]$ repl
>> Clojure 1.8.0-master-SNAPSHOT
>> user=> (defn ^double timespi [^double x] (* x 3.14))
>> #'user/timespi
>> user=> (timespi 2)
>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>> 
>> It works if you enable direct linking (or if you use 1.7.0).
>> 
>> Renzo
> 
> 
> -- 
> 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.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8

> On 12 Nov 2015, at 19:14, Nicola Mometto <brobro...@gmail.com> wrote:
> 
> 
> Depends on how you look at it.
> From my point of view, both examples are using an otherwise valid type hint, 
> at an invalid location, and in both cases the emitted code is nonsensical.
> So I'd say that if the decision for the CLJ-1846 issue was to handle that 
> with a compile time error, this one should too.
> 
> 
>> On 12 Nov 2015, at 16:47, Alex Miller <a...@puredanger.com 
>> <mailto:a...@puredanger.com>> wrote:
>> 
>> Neither is acceptable, so I either misunderstand or disagree with your 
>> question. :) 
>> 
>> The code below is an invalid type hint at that location. Are you maybe 
>> saying this should throw an error on definition?
>> 
>> CLJ-1846 is instead a valid type hint that is in conflict with the call. 
>> Which now throws an error.
>> 
>> 
>> On Thursday, November 12, 2015 at 10:13:13 AM UTC-6, Nicola Mometto wrote:
>> This is :rettag in action.
>> Any reason why this error should be acceptable while the CLJ-1846 one isn't?
>> 
>>> On 12 Nov 2015, at 12:55, Alex Miller <a...@puredanger.com 
>>> <mailto:a...@puredanger.com>> wrote:
>>> 
>>> That's not a valid type hint. Var meta is evaluated, in this case to the 
>>> double function object. You really want:
>>> 
>>> (defn timespi ^double [^double x] (* x 3.14))
>>> 
>>> 
>>> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com 
>>> <mailto:rebor...@gmail.com> wrote:
>>> Hello,
>>> 
>>> the following stops executing on 1.8.0-rc1 or current master-head 
>>> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
>>> CLJ-1846):
>>> 
>>> [/Users/reborg]$ repl
>>> Clojure 1.8.0-master-SNAPSHOT
>>> user=> (defn ^double timespi [^double x] (* x 3.14))
>>> #'user/timespi
>>> user=> (timespi 2)
>>> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
>>> abstract  user/timespi (NO_SOURCE_FILE:-1)
>>> 
>>> It works if you enable direct linking (or if you use 1.7.0).
>>> 
>>> Renzo
>> 
>> 
>> -- 
>> 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 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.

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Given the number of bytecode/type hinting issues we've seen caused by direct 
linking and the lack of real benchmarks demonstrating its benefits, I'm also 
wondering what's the rationale between including it in the current release.


> On 10 Nov 2015, at 18:15, Ghadi Shayban  wrote:
> 
> Two points of feedback:
> 
> 
> 1) One of the reason tuples were disabled was that they polluted dispatch 
> paths.  Shouldn't we make sure that they are completely inactive?
> 
>Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still use 
> them.
> 
> 2) I get the rationale behind direct linking, but I'm lacking evidence that 
> the benefits are achieved.
> 
> 
> 
> 
> On Tuesday, November 10, 2015 at 12:30:47 PM UTC-5, Alex Miller wrote:
> Clojure 1.8.0-RC1 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. If no problems are found, we expect to 
> make this the 1.8.0 final release! 
> 
> Try it via
> Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1 
> 
> Leiningen: [org.clojure/clojure "1.8.0-RC1"]
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md 
> .
> CLJ-1845  Make clojure.core/load 
> dynamic so it can be redef'ed even with direct linking
> 
> 
> -- 
> 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] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

This is :rettag in action.
Any reason why this error should be acceptable while the CLJ-1846 one isn't?

> On 12 Nov 2015, at 12:55, Alex Miller  wrote:
> 
> That's not a valid type hint. Var meta is evaluated, in this case to the 
> double function object. You really want:
> 
> (defn timespi ^double [^double x] (* x 3.14))
> 
> 
> On Thursday, November 12, 2015 at 3:57:44 AM UTC-6, rebor...@gmail.com wrote:
> Hello,
> 
> the following stops executing on 1.8.0-rc1 or current master-head 
> (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for 
> CLJ-1846):
> 
> [/Users/reborg]$ repl
> Clojure 1.8.0-master-SNAPSHOT
> user=> (defn ^double timespi [^double x] (* x 3.14))
> #'user/timespi
> user=> (timespi 2)
> AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is 
> abstract  user/timespi (NO_SOURCE_FILE:-1)
> 
> It works if you enable direct linking (or if you use 1.7.0).
> 
> Renzo
> 
> -- 
> 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] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Here's a minimal repro case:

user=> (defn foo ^long [] 1)
#'user/foo
user=> (Integer/bitCount ^int (foo))
VerifyError (class: user$eval13, method: invokeStatic signature: 
()Ljava/lang/Object;) Expecting to find integer on stack  
java.lang.Class.getDeclaredConstructors0 (Class.java:-2)


> On 11 Nov 2015, at 07:46, Shantanu Kumar  wrote:
> 
> One of my libraries (https://github.com/kumarshantanu/asphalt) is failing to 
> compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:
> 
> $ lein do clean, with-profile dev,c18 test
> Exception in thread "main" java.lang.VerifyError: (class: 
> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
> Expecting to find integer on stack, compiling:(core.clj:201:1)
>   at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>   at clojure.lang.Compiler.eval(Compiler.java:6918)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$require.invokeStatic(core.clj:5798)
>   at clojure.core$require.doInvoke(core.clj)
>   at clojure.lang.RestFn.invoke(RestFn.java:457)
>   at 
> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>   at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>   at asphalt.test_util$eval198.invoke(test_util.clj)
>   at clojure.lang.Compiler.eval(Compiler.java:6913)
>   at clojure.lang.Compiler.eval(Compiler.java:6902)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$require.invokeStatic(core.clj:5798)
>   at clojure.core$require.doInvoke(core.clj)
>   at clojure.lang.RestFn.invoke(RestFn.java:457)
>   at 
> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>   at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>   at asphalt.core_test$eval192.invoke(core_test.clj)
>   at clojure.lang.Compiler.eval(Compiler.java:6913)
>   at clojure.lang.Compiler.eval(Compiler.java:6902)
>   at clojure.lang.Compiler.load(Compiler.java:7360)
>   at clojure.lang.RT.loadResourceScript(RT.java:372)
>   at clojure.lang.RT.loadResourceScript(RT.java:363)
>   at clojure.lang.RT.load(RT.java:453)
>   at clojure.lang.RT.load(RT.java:419)
>   at clojure.core$load$fn__5673.invoke(core.clj:5895)
>   at clojure.core$load.invokeStatic(core.clj:5894)
>   at clojure.core$load_one.invokeStatic(core.clj:5694)
>   at clojure.core$load_one.invoke(core.clj)
>   at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>   at clojure.core$load_lib.invokeStatic(core.clj:5738)
>   at clojure.core$load_lib.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:647)
>   at clojure.core$load_libs.invokeStatic(core.clj:5776)
>   at clojure.core$load_libs.doInvoke(core.clj)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at 

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

To be honest I'm not sure this should even be a valid use of type hints.
You're telling the compiler that the result of (foo) is an int, when it is 
infact a long.

The correct way to do this should be:
 (Integer/bitCount (int (foo))

Again, lack of specification on what the correct type hinting semantics should 
be make it hard to evaluate if this should be considered a bug or just an user 
error that previously just got ignored.

> On 11 Nov 2015, at 12:08, Shantanu Kumar <kumar.shant...@gmail.com> wrote:
> 
> Thanks, Nicola!
> 
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846 
> <http://dev.clojure.org/jira/browse/CLJ-1846>
> 
> Shantanu
> 
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
> Here's a minimal repro case:
> 
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack  
> java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
> 
> 
>> On 11 Nov 2015, at 07:46, Shantanu Kumar <kumar.s...@ <>gmail.com 
>> <http://gmail.com/>> wrote:
>> 
>> One of my libraries (https://github.com/kumarshantanu/asphalt 
>> <https://github.com/kumarshantanu/asphalt>) is failing to compile with 1.8 
>> (works fine with 1.6, 1.7); the stack trace is below:
>> 
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>>  at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>>  at clojure.lang.Compiler.eval(Compiler.java:6918)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>>  at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>>  at asphalt.test_util$eval198.invoke(test_util.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.l

Re: [ANN] Clojure 1.8.0-RC1 is now available

[Nicola Mometto]

Clojure has a history of adopting the GIGO approach


> On 11 Nov 2015, at 12:08, Shantanu Kumar <kumar.shant...@gmail.com> wrote:
> 
> Thanks, Nicola!
> 
> Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846 
> <http://dev.clojure.org/jira/browse/CLJ-1846>
> 
> Shantanu
> 
> On Wednesday, 11 November 2015 17:13:05 UTC+5:30, Nicola Mometto wrote:
> Here's a minimal repro case:
> 
> user=> (defn foo ^long [] 1)
> #'user/foo
> user=> (Integer/bitCount ^int (foo))
> VerifyError (class: user$eval13, method: invokeStatic signature: 
> ()Ljava/lang/Object;) Expecting to find integer on stack  
> java.lang.Class.getDeclaredConstructors0 (Class.java:-2)
> 
> 
>> On 11 Nov 2015, at 07:46, Shantanu Kumar <kumar.s...@ <>gmail.com 
>> <http://gmail.com/>> wrote:
>> 
>> One of my libraries (https://github.com/kumarshantanu/asphalt 
>> <https://github.com/kumarshantanu/asphalt>) is failing to compile with 1.8 
>> (works fine with 1.6, 1.7); the stack trace is below:
>> 
>> $ lein do clean, with-profile dev,c18 test
>> Exception in thread "main" java.lang.VerifyError: (class: 
>> asphalt/core$invoke_with_transaction, method: invokeStatic signature: 
>> (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) 
>> Expecting to find integer on stack, compiling:(core.clj:201:1)
>>  at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)
>>  at clojure.lang.Compiler.eval(Compiler.java:6918)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.test_util$eval198$loading__5565__auto199.invoke(test_util.clj:1)
>>  at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)
>>  at asphalt.test_util$eval198.invoke(test_util.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at clojure.lang.Compiler.load(Compiler.java:7360)
>>  at clojure.lang.RT.loadResourceScript(RT.java:372)
>>  at clojure.lang.RT.loadResourceScript(RT.java:363)
>>  at clojure.lang.RT.load(RT.java:453)
>>  at clojure.lang.RT.load(RT.java:419)
>>  at clojure.core$load$fn__5673.invoke(core.clj:5895)
>>  at clojure.core$load.invokeStatic(core.clj:5894)
>>  at clojure.core$load_one.invokeStatic(core.clj:5694)
>>  at clojure.core$load_one.invoke(core.clj)
>>  at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)
>>  at clojure.core$load_lib.invokeStatic(core.clj:5738)
>>  at clojure.core$load_lib.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:142)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$load_libs.invokeStatic(core.clj:5776)
>>  at clojure.core$load_libs.doInvoke(core.clj)
>>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>  at clojure.core$apply.invokeStatic(core.clj:647)
>>  at clojure.core$require.invokeStatic(core.clj:5798)
>>  at clojure.core$require.doInvoke(core.clj)
>>  at clojure.lang.RestFn.invoke(RestFn.java:457)
>>  at 
>> asphalt.core_test$eval192$loading__5565__auto193.invoke(core_test.clj:1)
>>  at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)
>>  at asphalt.core_test$eval192.invoke(core_test.clj)
>>  at clojure.lang.Compiler.eval(Compiler.java:6913)
>>  at clojure.lang.Compiler.eval(Compiler.java:6902)
>>  at cloju

Re: Newbie Question: Why is "reduced?" used in the reductions function?

[Nicola Mometto]

The `reduced?` check is there in case somebody returns a `reduced` as
acc value from the reducing function, as a way to terminate the
reduction early:

user=> (reductions (fn [_ x] (if (= 10 x) (reduced x) x)) (range))
(0 1 2 3 4 5 6 7 8 9 10)

deref is the way to retrieve the value of a reduced object:
user=> (deref (reduced 1))
1


Alex Eberts writes:

> Hi All,
>
> Could someone please explain why reduced? is being used in the reductions
> function (below)? From what I understand reduced? checks if there has been
> a call to reduced and I don't see where that might be happening.
>
> Also, why is the deref macro being used with init?
>
> thanks,
> Alex
>
>
> (defn reductions
>   "Returns a lazy seq of the intermediate values of the reduction (as
>   per reduce) of coll by f, starting with init."
>   {:added "1.2"}
>   ([f coll]
>  (lazy-seq
>   (if-let [s (seq coll)]
> (reductions f (first s) (rest s))
> (list (f)
>   ([f init coll]
>  (if (reduced? init)
>(list @init)
>(cons init
>  (lazy-seq
>   (when-let [s (seq coll)]
> (reductions f (f init (first s)) (rest s
>
> from:
> https://github.com/clojure/clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L6921

--

-- 
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: tools.analyzer help

[Nicola Mometto]

Hi Gregg,
tools.analyzer (specifically tools.analyzer.jvm) doesn't do any
evaluation of the forms by default if you're using the `analyze`
function, however there's an `analyze+eval` function that will do that
if you need.

Note that t.a.jvm is a *clojure* analyzer that will only be able to
analyze *valid clojure code*. It will not (out-of-the-box) support
analysis of forms containing invalid clojure expressions such as ones
where unbounded symbols appear.

However there are a number of extension points which effectively allow
that, assuming some (possibly non trivial) configuration.

If this is what you need, I'd look at passes-opts for the validate
pass and at the node spec for :local/:binding nodes. Take a look at
what the :env value is for bound locals, a possible solution could be
passing in an initial env map with constructed locals.


On Sun, Oct 11, 2015 at 9:36 PM, Gregg Reynolds  wrote:
> I'm trying to figure out how to use tools.analyzer.jvm but not getting very
> far.  My web searches didn't turn up much.  Anybody know of tutorials or
> howtos?
>
> Specifically, I can get the basic examples at
> https://github.com/clojure/tools.analyzer.jvm#ast-quickref to work, but not
> this:
>
> (pp/pprint (ana.jvm/analyze '(for [item items] (identity item
>
> I get "Could not resolve var: list-items", which puzzles me, since I thought
> the analyzer was just supposed to build an ast, not evaluate code.
>
> Anyway, I tried
>
> (def items ["a" "b" "c"]) => #'user/items
> (for [item items] (identity item)) => ("a" "b" "c")
> (pp/pprint (ana.jvm/analyze '(for [item items] (identity item => spew!
> an endless stream of ast output along the lines of:
>
> {:children [:bindings :body],
>  :bindings
>  [{:children [:init],
>:return-tag clojure.lang.LazySeq,
>:init
>{:children [:local :methods],
> :return-tag clojure.lang.LazySeq,
>... etc. ad infinitum ...
>
> Based on the API doc for analyze I think I need to pass an env map, but I
> have no idea what's supposed to go in it and only an educated guess about
> What It All Means.
>
> Background:  I'm experimenting with Polymer. I want to write a macro that
> analyzes its argument and possibly replaces some nodes, resulting in an ast
> that will emit Polymer stuff.  For example, for dom-repeat:
>
>   (for [item person-list] (h/li item))
>
> will be translated into something like
>
> 
>   {{item}}
> 
>
> Thanks,
>
> Gregg
>
> --
> 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 1.8 java.lang.VerifyError method: invokeStatic signature: Can only throw Throwable objects

[Nicola Mometto]

http://dev.clojure.org/jira/browse/CLJ-1809

Lars Rune Nøstdal writes:

> Hi,
> Anyone playing around with 1.8 from Git? It has problems compiling this for
> some reason:
>
> (defn blah []
>   (let [a (atom nil)
> b nil]
> (try
>   (println "hi")
>   (catch Throwable e
> (println e))
>   (finally
> (when (and (deref a) b)
>   (println "huh"))

--

-- 
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: Bug in DynamicClassLoader?

[Nicola Mometto]

See http://dev.clojure.org/jira/browse/CLJ-1663

András Pálinkás writes:

> Can anyone explain to me why do we call super.findClass here:
> https://github.com/clojure/clojure/blob/41af6b24dd5be8bd62dc2b463bc53b55e18cd1e5/src/jvm/clojure/lang/DynamicClassLoader.java#L69
>
> I believe, on this line, instead of super.findClass, it should call
> getParent().findClass, otherwise we'll get to the system classloader almost
> immediately (and the parent classloader will never be used).

--

-- 
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 type hints to optimize protocol invocation

[Nicola Mometto]

Protocol callsites are already optimized in clojure.
Here's the emitted bytecode for a protocol invocation:

 0: aload_0
 1: aconst_null
 2: astore_0
 3: dup
 4: invokestatic  #36 // Method 
clojure/lang/Util.classOf:(Ljava/lang/Object;)Ljava/lang/Class;
 7: getstatic #38 // Field 
__cached_class__0:Ljava/lang/Class;
10: if_acmpeq 27
13: dup
14: instanceof#40 // class test/p
17: ifne  42
20: dup
21: invokestatic  #36 // Method 
clojure/lang/Util.classOf:(Ljava/lang/Object;)Ljava/lang/Class;
24: putstatic #38 // Field 
__cached_class__0:Ljava/lang/Class;
27: getstatic #23 // Field 
const__0:Lclojure/lang/Var;
30: invokevirtual #44 // Method 
clojure/lang/Var.getRawRoot:()Ljava/lang/Object;
33: swap
34: invokeinterface #49,  2   // InterfaceMethod 
clojure/lang/IFn.invoke:(Ljava/lang/Object;)Ljava/lang/Object;
39: goto  47
42: invokeinterface #51,  1   // InterfaceMethod 
test/p.f:()Ljava/lang/Object;
47: areturn

Ignoring the class cache, as you can see there's an instanceof check
at offset 14 which results in a direct interface method invocation (at
offset 42) if the type of the target implements directly the interface
which backs the protocol, which is always the case when a deftype
implements a protocol inline rather than via extend.

Nathan Marz writes:

> My understanding is that invocation of protocol methods incurs about 30%
> overhead due to the need to look up the appropriate function for the type.
> I also learned recently that Clojure does not use static type information
> to do the lookup at compile-time and avoid the overhead. Given that Clojure
> already does do some type analysis (to optimize Java method invocations),
> why not do it for protocol invocation as well? Just trying to further my
> understanding of the Clojure compiler.

--

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

[Nicola Mometto]

There is some weirdeness going on with the new release.
Compare:

Clojure 1.7.0
user=  (def foo String)
#'user/foo
user= (defn ^{:tag foo} a [])
#'user/a

with

Clojure 1.8.0-master-SNAPSHOT
user= (def foo String)
#'user/foo
user= (defn ^{:tag foo} a [])
CompilerException java.lang.IllegalArgumentException: Unable to resolve
classname: foo, compiling:(NO_SOURCE_PATH:2:1)

It loooks like clojure is now trying to use a value that should be available at
runtime (after evaluation) at compile time (using the literal form).

I realize this might be necessary, clojure already does something
similar with :arglists (that causes some issues too) or even
inevitable but I fear this will start affecting more and more tools
writers.

Perharps this calls for an official clarification/specification of how
:tag (and :arglists) is evaluated in the different places it can be
used, what values are possible and what should be considered an
error/undefined behaviour.

Dragan Djuric writes:

 Clojure only supports long and double primitives as function hints. You are 
 using int; it didn't work with pre-1.8.0 clojure.

--

-- 
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: #{:rant} Questions about contribution policy and clojure compiler source.

[Nicola Mometto]

I take it you have never worked on a patch for clojure.
I have, and I can tell you that it's not the indentation style the
issue -- everybody likes his own and it's definitely in the
maintainer's rights to chose what indentation style should be used and
for contributors to adapt, I don't have a problem with that.
I have a problem with the fact that the indentation style is not
consistent even between lines of the same method, tabs and spaces are
mixed everywhere -- for every non trivial patch I submit I have to
spend non trivial amounts of time to reindent my code using spaces or
tabs where appropriate to be consistent with the surrounding code and
making sure I don't accidentally commit whitespace changes in my
patches.
It's certainly not the biggest issue (not even close to it) in the
contributing process, but it definitely is an issue and it doesn't
help making the overall contributing experience a pleasant one, or one
would want to repeat.

And the claim that no indentation fix can happen to avoid breaking
existing patches in jira is frankly laughable. With the amount of time
that usually passes between the writing of a patch and its application
to the code base, a lot of them already need to be rebased/rewritten
to apply cleanly, often multiple times.

On Sat, Jul 18, 2015 at 5:44 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
 Sure, indentation is what gets the code running on metal :))

 Not ranting here, just my abs dying from the pain as I laugh :))


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

[Nicola Mometto]

Fluid Dynamics writes:

 That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...).

It can be surprising behaviour, but it's not an inconsistency.
As per the documentation, metadata on the symbol being def'd *is*
evaluated, metadata on the argvec isn't.
Evaluating `String` produces the java.lang.String Class -- a valid tag,
evaluating `longs` produces the clojure.core/longs function -- not a
valid tag. OTOH 'longs is a valid tag that the compiler understands.

 It also doesn't negate the original bug report. That VerifyError means that
 the Clojure compiler emitted invalid bytecode, instead of either emitting
 valid bytecode or reporting a sensible error. Any way you slice it the
 compiler is buggy if it can quietly emit broken bytecode.

The reported exception is not all of what happens.
If you try to execute that code you'll see that you get two exceptions,
the first one being java.lang.IllegalArgumentException: Unable to
resolve classname: clojure.core$longs@3f91beef which tells you exactly
what I told you before -- clojure.core/long is not a valid type hint.

The VerifyError is thrown later and is caused by the fact that the
compiler emits partial bytecode as it gets interrupted by the
IllegalArgumentException.

Now, if you want to argue that the compiler should immediately throw an
error as soon as the wrong type hint is used rather than silently ignore
it and fail when the type-hinted form is used, I'll agree with you and
I've proposed to make the compiler stricter a number of times on the
clojure-dev ML and talked about it on IRC but I guess either it's not a
priority for the clojure/core team or they're simply not interested in
more compile-time checks.
Either way the reported issue was a user error, not a compiler bug.

--

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

[Nicola Mometto]

Alex Miller writes:

 On Fri, May 1, 2015 at 2:53 PM, Nicola Mometto brobro...@gmail.com wrote:


 Now, if you want to argue that the compiler should immediately throw an
 error as soon as the wrong type hint is used rather than silently ignore
 it and fail when the type-hinted form is used, I'll agree with you and
 I've proposed to make the compiler stricter a number of times on the
 clojure-dev ML and talked about it on IRC but I guess either it's not a
 priority for the clojure/core team or they're simply not interested in
 more compile-time checks.


 Is there a ticket?

There are a number of tickets reporting errors caused by the compiler
silently ignoring invalid type hints
http://dev.clojure.org/jira/browse/CLJ-1674
http://dev.clojure.org/jira/browse/CLJ-1232

or type hints inconsistencies
http://dev.clojure.org/jira/browse/CLJ-1577
http://dev.clojure.org/jira/browse/CLJ-1533

There are no open tickets open that I'm aware of about making the
compiler stricter on :tag values.

I would open one but there's this clojure-dev thread
https://groups.google.com/forum/#!msg/clojure-dev/hRZFuaiB_50/mzKLirgZWmUJ
where I ask what should be the allowed :tag values and I got no
clarification on it -- I see no point in spending my time working on a
patch/enhancement proposal that would break contrib libraries used by
clojure itself (there's no way to make the compiler throw on e.g. (defn
^doubles foo ..) and not throw on test.generative usages) until I know
for a fact that I would not be wasting my time

--

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

[Nicola Mometto]

The type-hint on init-state is wrong.

It has to be either

(defn {:tag 'longs} init-state [] (long-array 1))
or (preferred)
(defn init-state ^longs [] (long-array 1))


shlomivak...@gmail.com writes:

 I tried playing around with the new primitive type hints and got the
 following weird behavior on [org.clojure/clojure 1.7.0-beta2]:

 (defn ^longs init-state []  (long-array 1))

 (defn ^long store-state [^longs c ^long a] (aset c 0 a))

 running the following line resulted in an exception:

 (let [x (init-state)]
   (store-state x 5))

 1. Caused by java.lang.VerifyError
(class: clojure_7/core$eval13270, method: invoke signature:
()Ljava/lang/Object;) Unable to pop operand off an empty stack

 Class.java:   -2
  java.lang.Class/getDeclaredConstructors0
 Class.java: 2671
  java.lang.Class/privateGetDeclaredConstructors
 Class.java: 3075  java.lang.Class/getConstructor0
 Class.java:  412  java.lang.Class/newInstance
  Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval
  Compiler.java: 6791  clojure.lang.Compiler/eval
  Compiler.java: 7237  clojure.lang.Compiler/load
   REPL:1  reverse-index.main/eval13258
  Compiler.java: 6792  clojure.lang.Compiler/eval
  Compiler.java: 6755  clojure.lang.Compiler/eval
   core.clj: 3079  clojure.core/eval
   main.clj:  240  clojure.main/repl/read-eval-print/fn
   main.clj:  240  clojure.main/repl/read-eval-print
   main.clj:  258  clojure.main/repl/fn
   main.clj:  258  clojure.main/repl
RestFn.java: 1523  clojure.lang.RestFn/invoke
 interruptible_eval.clj:   58
  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
   AFn.java:  152  clojure.lang.AFn/applyToHelper
   AFn.java:  144  clojure.lang.AFn/applyTo
   core.clj:  628  clojure.core/apply
   core.clj: 1866  clojure.core/with-bindings*
RestFn.java:  425  clojure.lang.RestFn/invoke
 interruptible_eval.clj:   56
  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
 interruptible_eval.clj:  188
  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
 interruptible_eval.clj:  157
  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
   AFn.java:   22  clojure.lang.AFn/run
ThreadPoolExecutor.java: 1142
  java.util.concurrent.ThreadPoolExecutor/runWorker
ThreadPoolExecutor.java:  617
  java.util.concurrent.ThreadPoolExecutor$Worker/run
Thread.java:  745  java.lang.Thread/run

 while the following line worked just fine:

 (store-state (init-state) 5)

 and also this works fine:

 (def a (init-state))
 (store-state a 5)

 (aget a 0) ;; 5

 What do you think?

 On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote:

 Clojure 1.7.0-beta2 is now available.

 Try it via
 - Download:
 https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/
 - Leiningen: [org.clojure/clojure 1.7.0-beta2]

 Regression fixes since 1.7.0-beta1:

 1) CLJ-1711 - structmap iterator broken
 2) CLJ-1709 - range wrong for step != 1
 3) CLJ-1713 - range chunks are not serializable
 4) CLJ-1698 - fix reader conditional bugs

 Additional enhancements to new features since 1.7.0-beta1:

 1) CLJ-1703 - Pretty print #error and new public function Throwable-map
 2) CLJ-1700 - Reader conditionals now allowed in the REPL
 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj

 For a full list of changes since 1.6.0, see:
 https://github.com/clojure/clojure/blob/master/changes.md

 Please give it a try and let us know if things are working (or not)!

 - Alex



--

-- 
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: Meaning of part of the doc string for `ns-resolve`

[Nicola Mometto]

It's talking about fully qualified symbols that map to an actual var.
E.g
user= (ns-resolve *ns* 'clojure.string/join)
#'clojure.string/join


Brian Marick writes:

 The last sentence of the `ns-resolve` documentation reads:

Note that
if the symbol is fully qualified, the var/Class to which it resolves
need not be present in the namespace.

 What does that mean? I would expect something like the following to
 produce a non-nil value:

  user= (ns-resolve 'clojure.core 'fofofof)
  user= (ns-resolve 'clojure.core 'clojure.core/fofofof)
  user= (ns-resolve *ns* 'clojure.core/fofofof)


 ... to produce a non-nil value, but they're all nil.

 (Note: in the 1.6 API, it looks to me like the only other uses of fully
 qualified refer to classes.)

--

-- 
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: Strange behaviour of a callable record

[Nicola Mometto]

I've opened an enhancement ticket with a patch that changes this
behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715

Alexey Cherkaev writes:

 Hi,

 I have encountered the problem with Clojure 1.6.0, when I create the record
 that implements IFn.

 For example,

 (defrecord Foo [x]
 clojure.lang.IFn
 (invoke [_ f] (f x)))

 Than create an instance of this record:

 (def f (-Foo 10))

 And we can call it without a problem:

 user= (f inc)
 11

 Yet, if you try to define a value to keep the result, compiler throws an
 error:

 user= (def z (f inc))

 CompilerException java.lang.AbstractMethodError,
 compiling:(form-init4774307052978984831.clj:1:8)

 There is workaround: create local binding first and then assign the value
 to a global variable:

 user= (def z (let [temp (f inc)] temp))
 #'user/z
 user= z
 11

 Is this a bug or I don't fully understand why you can't do that?

 Cheers, Alexey

--

-- 
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: Strange behaviour of a callable record

[Nicola Mometto]

You're not implementing IFn.applyTo, you should.

Why applyTo is used in the second example while invoke is used in the
other cases has to do with implementation details of how def expressions
are compiled/evaluated.

Alexey Cherkaev writes:

 Hi,

 I have encountered the problem with Clojure 1.6.0, when I create the record
 that implements IFn.

 For example,

 (defrecord Foo [x]
 clojure.lang.IFn
 (invoke [_ f] (f x)))

 Than create an instance of this record:

 (def f (-Foo 10))

 And we can call it without a problem:

 user= (f inc)
 11

 Yet, if you try to define a value to keep the result, compiler throws an
 error:

 user= (def z (f inc))

 CompilerException java.lang.AbstractMethodError,
 compiling:(form-init4774307052978984831.clj:1:8)

 There is workaround: create local binding first and then assign the value
 to a global variable:

 user= (def z (let [temp (f inc)] temp))
 #'user/z
 user= z
 11

 Is this a bug or I don't fully understand why you can't do that?

 Cheers, Alexey

--

-- 
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.7.0-alpha6 released

[Nicola Mometto]

The recent changes to iterate come with an interesting consequence:
reducing an iterate multiple times will cause the entire chain of x, (f
x), (f (f x)) .. to be recalculated every time.

I'd argue that this is not desiderable and a regression (even though
probably one considered by design), and that this change in behaviour is
going to produce a degradation in performance when the function to
iterate actually does some computation rather than being a trivial
function like the one used in the benchmarks in the CLJ-1603 ticket
(inc) since its result won't be cached.

If changing the new behaviour is out of the question I'd suggest to at
least document this new behaviour. The docstring of iterate talks about
returning a lazy-seq while when used with reduce it is actually a
generator.

To show what I mean here's a silly example using Threa/sleep to simulate
computation:

Clojure 1.7.0-alpha5
user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0))
#'user/a
user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
Elapsed time: 106.385891 msecs
nil
user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
Elapsed time: 0.560275 msecs
nil

Clojure 1.7.0-master-SNAPSHOT
user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0))
#'user/a
user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
Elapsed time: 109.088477 msecs
nil
user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
Elapsed time: 109.51494 msecs
nil

-- 
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.7.0-alpha6 released

[Nicola Mometto]

Actaully caching makes a difference even with inc and a sequence of just
1000 elements:

Clojure 1.7.0-alpha5
user= (def a (iterate inc 0))
#'user/a
user= (time (reduce (fn [_ x]) nil (take 1000 a)))
Elapsed time: 4.170778 msecs
nil
user= (time (reduce (fn [_ x]) nil (take 1000 a)))
Elapsed time: 1.589569 msecs
nil

Clojure 1.7.0-master-SNAPSHOT
user= (def a (iterate inc 0))
#'user/a
user= (time (reduce (fn [_ x]) nil (take 1000 a)))
Elapsed time: 4.831726 msecs
nil
user= (time (reduce (fn [_ x]) nil (take 1000 a)))
Elapsed time: 4.058695 msecs
nil

Nicola Mometto writes:

 The recent changes to iterate come with an interesting consequence:
 reducing an iterate multiple times will cause the entire chain of x, (f
 x), (f (f x)) .. to be recalculated every time.

 I'd argue that this is not desiderable and a regression (even though
 probably one considered by design), and that this change in behaviour is
 going to produce a degradation in performance when the function to
 iterate actually does some computation rather than being a trivial
 function like the one used in the benchmarks in the CLJ-1603 ticket
 (inc) since its result won't be cached.

 If changing the new behaviour is out of the question I'd suggest to at
 least document this new behaviour. The docstring of iterate talks about
 returning a lazy-seq while when used with reduce it is actually a
 generator.

 To show what I mean here's a silly example using Threa/sleep to simulate
 computation:

 Clojure 1.7.0-alpha5
 user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0))
 #'user/a
 user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
 Elapsed time: 106.385891 msecs
 nil
 user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
 Elapsed time: 0.560275 msecs
 nil

 Clojure 1.7.0-master-SNAPSHOT
 user= (def a (iterate #(do (Thread/sleep 2) (inc %)) 0))
 #'user/a
 user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
 Elapsed time: 109.088477 msecs
 nil
 user= (time (reduce (fn [_ x] (if (= 50 x) (reduced nil))) nil a))
 Elapsed time: 109.51494 msecs
 nil

--

-- 
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.7.0-alpha6 released

[Nicola Mometto]

Not a bug imho, you're invoking reduce with no init arg so you're
forcing the realization of at least two elements in the coll, one for
init and one for step -- the step one causes the exception.

Ambrose Bonnaire-Sergeant writes:

 Here's some weird behaviour I found from 1.6.

 user= (take 1 (iterate zero? true))
 (true)
 user= (reduce (fn [l _] (reduced l)) (iterate zero? true))
 ClassCastException java.lang.Boolean cannot be cast to java.lang.Number
  clojure.lang.Numbers.isZero (Numbers.java:90)

 Is this a bug, and should this be fixed?

 Thanks,
 Ambrose

 On Wed, Apr 1, 2015 at 10:28 PM, Alex Miller a...@puredanger.com wrote:

 Thanks! If anyone wants to throw a patch, would love to have one. Must
 include test ...

 On Wednesday, April 1, 2015 at 8:14:52 PM UTC-5, Ambrose Bonnaire-Sergeant
 wrote:

 http://dev.clojure.org/jira/browse/CLJ-1692

 On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant 
 abonnair...@gmail.com wrote:

 Ok.

 On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller al...@puredanger.com
 wrote:

 I would love a jira for the iterate thIng.

 --
 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: [newbie] strange behaviour in self-referential primes lazy-seq attempt

[Nicola Mometto]

Clojure 1.5.1
user=  (def bar (cons 1 (map #(do (println %) (+ (nth bar %) %)) (range
#'user/bar
user= (take 10 bar)
(0
1
IndexOutOfBoundsException   clojure.lang.RT.nthFrom (RT.java:795)


It is possible that it is lein/REPLy that's causing the output not to
be print, I've seen it done a number of times.


On Fri, Feb 13, 2015 at 8:02 AM, Fluid Dynamics a2093...@trbvm.com wrote:
 And here's some really crazy behavior from 1.5.1!

 = (def bar (cons 1 (map #(do (println %) (+ #_(nth bar %) %)) (range
 #'user/bar
 = (take 10 bar)
 (0

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 1 0 1 2 3 4 5 6 7 8)
 = (def bar (cons 1 (map #(do (println %) (+ (nth bar %) %)) (range
 #'user/bar
 = (take 10 bar)
 IndexOutOfBoundsException   clojure.lang.RT.nthFrom (RT.java:795)

 Erm, what? There should have been at least one number printed by the
 (println %) before the (nth bar %) could possibly have blown up.
 Furthermore, the *first* round of prints shows that % was never out of range
 for an infinite lazy sequence, i.e. was never negative. So 1.5.1 is actually
 behaving *schizophrenically* here: a bare delay that recursively forces
 itself overflows the stack, but the delay for the next-part of a ChunkedSeq
 is instead apparently being seen as holding nil when forced inside its own
 evaluation. But a delay is a delay is a delay and the same behavior should
 occur consistently, nil or an exception, no matter where the delay is
 located!

 --
 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: [newbie] strange behaviour in self-referential primes lazy-seq attempt

[Nicola Mometto]

Clojure 1.6.0
user= (def foo (delay (str @foo)))
#'user/foo
user= @foo
StackOverflowError   clojure.lang.Delay.deref (Delay.java:37)
user=

same with Clojure 1.7.0-master-SNAPSHOT, I don't see it returning nil
as you said.

On Fri, Feb 13, 2015 at 7:53 AM, Fluid Dynamics a2093...@trbvm.com wrote:
 On Friday, February 13, 2015 at 12:47:17 AM UTC-5, Justin Smith wrote:

 I don't want to sound too brusque in my defense of Clojure. I'm a huge
 fan, so criticism of the language does get me a bit defensive.


 I am a fan as well. Constructive criticism is useful as it can lead to
 improvements.


 But preferring different behavior is actually reasonable here. There are
 other Lisps (and languages in the ML family) that are more internally
 consistent. I'll continue to prefer the better performance and easy access
 to host interop, even if it does violate the occasional abstraction. But of
 course there is no reason to begrudge someone else holding a different
 opinion, and choosing a language that aligns with those expectations.

 But I do hope you give Clojure a chance, it's been very rewarding for me
 and I expect you'd find the same if you take the time to get to know it and
 get a feel for what's idiomatic


 Actually, I've been using it for years. And I've never encountered behavior
 like this, until now. It is definitely wrong for a lazy sequence to either
 a) appear to have the wrong length or b) appear at different times to have
 different lengths. As long as the var isn't rebound, primes indisputably
 should appear to have a fixed, immutable value, whether parts of that value
 are lazy via delay/force or otherwise.

 It appears that there is a buggy corner case with self-referencing delays,
 where if you (delay code) and code has a reference to the delay and tries
 to force it, it sees the delay's value as nil rather than, as it probably
 should, throwing an exception. (Recursively calling the delay's code leading
 to an eventual StackOverflowError seems like the only other *sensible*
 alternative, but if you can detect that case and return nil instead you can
 detect it and throw an exception directly. Something straightforward, like
 an IAE with a message of Delay tried to force itself on evaluation or
 something. This would be far preferable to exposing visible mutation in a
 thing that is supposed to be semantically immutable, such as (rest x)
 changing from nil to non-nil, and also exceptions are far preferable to
 returning a logically-incorrect result without complaint.)

 Incidentally, I don't see the same behavior using my somewhat old copy of
 Clojure 1.5.1:

 = (def foo (delay (str @foo)))
 #'user/foo
 = @foo
 StackOverflowError   clojure.core/deref (core.clj:2114)

 This is what I'd expect a naive implementation to do. So it looks like in
 1.6 this must have changed to produce nil from the inner @foo, for lazy
 sequences to look like they terminate early from inside themselves, and in
 1.7 it *may* have changed again. I think clarification is needed here on
 what is going on. One thing already clear is the preference order of
 possible behaviors:

 nil  StackOverflowError  more specific exception such as delay tried to
 force itself.

 Which suggests that 1.5.1  1.6, in this particular area...

 --
 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: heaps in clojure vs SML

[Nicola Mometto]

If you set! *warn-on-reflection* to true, you'd see a lot of reflection
warnings from your code.

Type-hinting the code like this: http://sprunge.us/ATiV makes your
example execute in 120ms on my machine.

Maris writes:

 I implemented leftist heap (from Purely Functional Data Structures book)
  in clojure.

 https://gist.github.com/maruks/135fef92455578b61de2

 It takes 32 seconds to insert 10 elements in heap:

 (time  (peek   (reduce conj (empty-heap)  (range 1000 2000 100)
 )))
 Elapsed time: 32649.71438 msecs
 1000

 Why is it so much slower than SML NJ?  Something wrong with my code?


 Here is SML version:
 https://gist.github.com/maruks/c863eac9cf057a071307

 And function that inserts 10 elements in *54* milliseconds !

 fun test(n:int) : int  =
 let
 val r = List.tabulate(n, fn x = 1000 + 100 * x)
 val h = foldl ( fn (e, h) = IntHeap.insert(e , h) )  IntHeap.empty  r
 in
 IntHeap.findMin(h)
 end

--

-- 
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.7.0-alpha5 now available

[Nicola Mometto]

Jozef, I looked into this and opened a ticket with a proposed patch to
fix this issue: http://dev.clojure.org/jira/browse/CLJ-1650

Jozef Wagner writes:

 With CLJ-979 applied, lein may crash when doing :aot :all. This is caused
 when lein forces recompilation of already compiled classes. Not sure
 whether this should be considered a lein of clojure bug though.

 See https://github.com/wagjo/aotbug for contrived example.

 Jozef

 On Saturday, January 10, 2015 at 4:37:04 PM UTC+1, Alex Miller wrote:

 Clojure 1.7.0-alpha5 is now available.

 Try it via
 - Download:
 https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha5/
 - Leiningen: [org.clojure/clojure 1.7.0-alpha5]

 A few of the highlights in alpha5:

 1) New transducer arities for map-indexed, distinct, and interpose.
 The transducer versions are generally faster than the sequence versions.
 See CLJ-1601 for more details.

 2) The set and vec functions should now be faster in many cases. Some of
 the
 vec improvements will not kick in until CLJ-1499 is committed in the
 future.
 See CLJ-1546 and CLJ-1618 for more details.

 3) Two particularly troublesome AOT classloading bugs have been addressed
 -
 CLJ-979 and CLJ-1544. Many other tickets were found to be duplicates of
 one of
 these as well. Big thanks to Nicola Mometto for doing the hard work on
 debugging and providing fixes for these.

 For all changes new in alpha5, see the issues marked (alpha5) in the
 full changes below.

 
 Clojure 1.7.0-alpha5 has the changes below from 1.6.0:

 ## 1 New and Improved Features

 ### 1.1 Transducers

 Transducers is a new way to decouple algorithmic transformations from their
 application in different contexts. Transducers are functions that transform
 reducing functions to build up a recipe for transformation.

 Also see: http://clojure.org/transducers

 Many existing sequence functions now have a new arity (one fewer argument
 than before). This arity will return a transducer that represents the same
 logic but is independent of lazy sequence processing. Functions included
 are:

 * conj (conjs to [])
 * map
 * mapcat
 * filter
 * remove
 * take
 * take-while
 * drop
 * drop-while
 * cycle
 * take-nth
 * replace
 * partition-by
 * partition-all
 * keep
 * keep-indexed
 * map-indexed (alpha5)
 * distinct (alpha5)
 * interpose (alpha5)

 Additionally some new transducer functions have been added:

 * cat - concatenates the contents of each input
 * de-dupe - removes consecutive duplicated values
 * random-sample - returns items from coll with random probability

 And this function can be used to make completing transforms:

 * completing

 There are also several new or modified functions that can be used to apply
 transducers in different ways:

 * sequence - takes a transformation and a coll and produces a lazy seq
 * transduce - reduce with a transformation (eager)
 * eduction - returns a reducible/seqable/iterable seq of applications of
 the transducer to items in coll. Applications are re-performed with every
 reduce/seq/iterator.
 * run! - run the transformation for side effects on the collection

 There have been a number of internal changes to support transducers:

 * volatiles - there are a new set of functions (volatile!, vswap!,
 vreset!, volatile?) to create and use volatile boxes to hold state in
 stateful transducers. Volatiles are faster than atoms but give up atomicity
 guarantees so should only be used with thread isolation.
 * array iterators - added support for iterators over arrays

 Some related issues addressed during development:
 * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511)
 * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497)
 * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549)
 * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537)
 * [CLJ-1554](http://dev.clojure.org/jira/browse/CLJ-1554)
 * [CLJ-1601](http://dev.clojure.org/jira/browse/CLJ-1601) (alpha5)
 * [CLJ-1606](http://dev.clojure.org/jira/browse/CLJ-1606) (alpha5)
 * [CLJ-1621](http://dev.clojure.org/jira/browse/CLJ-1621) (alpha5)
 * [CLJ-1600](http://dev.clojure.org/jira/browse/CLJ-1600) (alpha5)

 ### 1.2 Keyword and Symbol Construction

 In response to issues raised in [CLJ-1439](
 http://dev.clojure.org/jira/browse/CLJ-1439),
 several changes have been made in symbol and keyword construction:

 1) The main bottleneck in construction of symbols (which also occurs
 inside keywords) was
 interning of the name and namespace strings. This interning has been
 removed, resulting
 in a performance increase.

 2) Keywords are cached and keyword construction includes a cache check. A
 change was made
 to only clear the cache reference queue when there is a cache miss.

 ### 1.3 Warn on Boxed Math

 One source of performance issues is the (unintended) use of arithmetic
 operations on
 boxed numbers. To make detecting the presence of boxed math easier, a
 warning will now
 be emitted

Re: Set equality bug?

[Nicola Mometto]

Looking at the PHM impl, this looks like it's caused by (float 0.5) and
(double 0.5) hashing differently.

user= (= (float 0.5) (double 0.5))
true
user= (map hash [(float 0.5) (double 0.5)])
(1056964608 1071644672)

Nicola Mometto writes:

 Looks like it's a bug in PersistentHashMap:
 user= (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)})
 false
 user= (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)})
 true

 Immo Heikkinen writes:

 (= (float 0.5) (double 0.5))
 = true
 (= #{(float 0.5)} #{(double 0.5)})
 = true
 (= {:a (float 0.5)} {:a (double 0.5)})
 = true
 (= #{{:a (float 0.5)}} #{{:a (double 0.5)}})
 = false


 Tested with both 1.6.0 and 1.7.0-alpha5.

--

-- 
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: Set equality bug?

[Nicola Mometto]

Looks like it's a bug in PersistentHashMap:
user= (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)})
false
user= (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)})
true

Immo Heikkinen writes:

 (= (float 0.5) (double 0.5))
 = true
 (= #{(float 0.5)} #{(double 0.5)})
 = true
 (= {:a (float 0.5)} {:a (double 0.5)})
 = true
 (= #{{:a (float 0.5)}} #{{:a (double 0.5)}})
 = false


 Tested with both 1.6.0 and 1.7.0-alpha5.

--

-- 
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: Set equality bug?

[Nicola Mometto]

Not sure if this is intended behaviour:
user= (= (float 1.6) (double 1.6))
false
user= (= (float 1.5) (double 1.5))
true

I.e. = (and ==) will return true when comparing floats with doubles IFF
the float's .doubleValue roundtrips to the same double it's comparing to.

user= (.doubleValue (float 1.6))
1.60023841858
user= (.doubleValue (float 1.5))
1.5

I'm not sure why floats are not handled specially in Numbers.java so
that hash/comparision is handled consistently with doubles (e.g. by
converting the floats to the fitting double via Double.parseDouble),
the current behaviour seems odd to me.

Jozef Wagner writes:

 More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036

 On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto brobro...@gmail.com wrote:


 Looking at the PHM impl, this looks like it's caused by (float 0.5) and
 (double 0.5) hashing differently.

 user= (= (float 0.5) (double 0.5))
 true
 user= (map hash [(float 0.5) (double 0.5)])
 (1056964608 1071644672)

 Nicola Mometto writes:

  Looks like it's a bug in PersistentHashMap:
  user= (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)})
  false
  user= (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)})
  true
 
  Immo Heikkinen writes:
 
  (= (float 0.5) (double 0.5))
  = true
  (= #{(float 0.5)} #{(double 0.5)})
  = true
  (= {:a (float 0.5)} {:a (double 0.5)})
  = true
  (= #{{:a (float 0.5)}} #{{:a (double 0.5)}})
  = false
 
 
  Tested with both 1.6.0 and 1.7.0-alpha5.

 --

 --
 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] Clojure 1.7.0-alpha5 now available

[Nicola Mometto]

There actually is a dependency cycle in manifold, it's just not in the
ns macro:

manifold.stream.graph depends on manifold.graph here:
https://github.com/ztellman/manifold/blob/master/src/manifold/stream/graph.clj#L5
maniphold.stream depends on manifold.stream.graph here:
https://github.com/ztellman/manifold/blob/master/src/manifold/stream.clj#L410

Whether or not this will be considered a regression or not, it's not up
to me to decide. I suggest opening a ticket in JIRA to discuss this
further.

Nicola

Andy Fingerhut writes:

 I can reproduce this.  I have also determined that the change in behavior
 is due to the patch applied for ticket CLJ-1544 [1] [2].  There doesn't
 appear to be an actual dependency cycle in the manifold lib, but I've only
 looked at this for a few mins.

 Andy

 [1] http://dev.clojure.org/jira/browse/CLJ-1544
 [2]
 https://github.com/clojure/clojure/commit/e5a104e894ed82f244d69513918d570cee5df67d

 On Wed, Jan 14, 2015 at 6:29 AM, Janne Lemmetti jlemme...@gmail.com wrote:

 I noticed that with alpha5, I can no longer build an uberjar with {:aot
 :all} if I depend on [gloss 0.2.4]:

 $ lein uberjar
 Compiling alpha5-test.core
 java.lang.Exception: Cyclic load dependency: [ /manifold/stream
 ]-/manifold/stream/graph-[ /manifold/stream
 ]-/byte_streams-/gloss/core/formats-/gloss/data/bytes-/gloss/core/codecs-/gloss/io-/alpha5_test/core,
 compiling:(manifold/stream/graph.clj:1:1)
 at clojure.core$throw_if.doInvoke(core.clj:5612)
 at clojure.lang.RestFn.invoke(RestFn.java:442)
 at clojure.core$check_cyclic_dependency.invoke(core.clj:5763)
 at clojure.core$load.doInvoke(core.clj:5860)
 ...

 Minimal project to reproduce with:

 project.clj:

 (defproject alpha5-test 0.1.0-SNAPSHOT
 :dependencies [[org.clojure/clojure 1.7.0-alpha5] [gloss 0.2.4]]
 :profiles {:uberjar {:aot :all}})

 src/alpha5_test/core.clj:

 (ns alpha5-test.core (:require [gloss.io :refer [decode-all]]))


 Br, Janne


 On Sunday, 11 January 2015 16:34:07 UTC+2, Alex Miller wrote:

 I would greatly appreciate hearing any feedback about this (or any other)
 alpha, even if it's just: everything looks ok.

 We've had a couple of regressions reported and that is hugely helpful as
 we can quickly turn around fixes for the next one.

 Interested particularly in: regressions, performance +/-, and for this
 alpha, AOT.

  --
 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] Clojure 1.7.0-alpha5 now available

[Nicola Mometto]

Can you try a custom version of clojure 1.7.0-alpha5 with commit
e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still
get the exception?

Nicola

Sean Corfield writes:

 Here’s what I see reproducing this in the REPL - this main project doesn't 
 use core.async (but does use a very small AOT'd library). I'm going to try to 
 cut this down to see if I can repro outside our main project 
 (worldsingles.cache is a thin wrapper over core.cache and core.memoize - 
 moving that exact same code to a fresh project, without any other 
 dependencies, works so it's something in combination with our other 
 dependencies):

 user= (require 'worldsingles.cache)
 nil
 user= (defn foo[n] (+ 13 n))
 #'user/foo
 user= (worldsingles.cache/memo foo site)
 #clojure.lang.AFunction$1@7090307d
 user= (*1 42)

 IllegalArgumentException No implementation of method: :has? of protocol: 
 #'clojure.core.cache/CacheProtocol found for class: 
 clojure.core.memoize.PluggableMemoization  clojure.core/-cache-protocol-fn 
 (core_deftype.clj:555)
 user= (pst *e)
 IllegalArgumentException No implementation of method: :has? of protocol: 
 #'clojure.core.cache/CacheProtocol found for class: 
 clojure.core.memoize.PluggableMemoization
   clojure.core/-cache-protocol-fn (core_deftype.clj:555)
   clojure.core.cache/eval2178/fn--2241/G--2167--2248 (cache.clj:20)
   clojure.core.cache/through (cache.clj:53)
   clojure.core.memoize/through* (memoize.clj:52)
   clojure.lang.Atom.swap (Atom.java:65)
   clojure.core/swap! (core.clj:2236)
   clojure.core.memoize/build-memoizer/fn--12665 (memoize.clj:134)
   clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
   user/eval2486 (form-init7972562298655212181.clj:1)
   clojure.lang.Compiler.eval (Compiler.java:6767)
   clojure.lang.Compiler.eval (Compiler.java:6730)
   clojure.core/eval (core.clj:3076)
 nil
 user= (clojure.stacktrace/print-stack-trace *e)
 java.lang.IllegalArgumentException: No implementation of method: :has? of 
 protocol: #'clojure.core.cache/CacheProtocol found for class: 
 clojure.core.memoize.PluggableMemoization
  at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:555)
 clojure.core.cache$eval2178$fn__2241$G__2167__2248.invoke (cache.clj:20)
 clojure.core.cache$through.invoke (cache.clj:53)
 clojure.core.memoize$through_STAR_.invoke (memoize.clj:52)
 clojure.lang.Atom.swap (Atom.java:65)
 clojure.core$swap_BANG_.invoke (core.clj:2236)
 clojure.core.memoize$build_memoizer$fn__12665.doInvoke (memoize.clj:134)
 clojure.lang.RestFn.applyTo (RestFn.java:137)
 clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
 clojure.lang.RestFn.invoke (RestFn.java:408)
 user$eval2486.invoke (form-init7972562298655212181.clj:1)
 clojure.lang.Compiler.eval (Compiler.java:6767)
 clojure.lang.Compiler.eval (Compiler.java:6730)
 clojure.core$eval.invoke (core.clj:3076)
 clojure.main$repl$read_eval_print__7311$fn__7314.invoke (main.clj:239)
 clojure.main$repl$read_eval_print__7311.invoke (main.clj:239)
 clojure.main$repl$fn__7320.invoke (main.clj:257)
 clojure.main$repl.doInvoke (main.clj:257)
 clojure.lang.RestFn.invoke (RestFn.java:1523)
 clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__876.invoke 
 (interruptible_eval.clj:67)
 clojure.lang.AFn.applyToHelper (AFn.java:152)
 clojure.lang.AFn.applyTo (AFn.java:144)
 clojure.core$apply.invoke (core.clj:626)
 clojure.core$with_bindings_STAR_.doInvoke (core.clj:1864)
 clojure.lang.RestFn.invoke (RestFn.java:425)
 clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke 
 (interruptible_eval.clj:51)
 
 clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__918$fn__921.invoke
  (interruptible_eval.clj:183)
 clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__911.invoke 
 (interruptible_eval.clj:152)
 clojure.lang.AFn.run (AFn.java:22)
 java.util.concurrent.ThreadPoolExecutor.runWorker 
 (ThreadPoolExecutor.java:1142)
 java.util.concurrent.ThreadPoolExecutor$Worker.run 
 (ThreadPoolExecutor.java:617)
 java.lang.Thread.run (Thread.java:745)
 nil
 user=

 On Jan 12, 2015, at 6:30 AM, Alex Miller a...@puredanger.com wrote:

 Do you have the full stack trace in the cases where you see this without 
 core.async?

--

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

Re: Potential bug in trampoline

[Nicola Mometto]

This looks like a serious bug in PersistentList, it has nothing to do
with trampoline.

Here's a minimal case:
user= ((fn [ args] (apply (fn [a  b] (apply list b)) args)) 1 2 3)
(1 2 3)


Hongseok Yang writes:

 Hi,

 While trying to use trampoline to optimise tail recursion in my Clojure
 project, I came across some strange behaviour of the trampoline function.

 = (defn f [g] (fn [k  args] #(k (apply g args
 ...
 = (trampoline (f list) println 1 2 3)
 (#core$println clojure.core$println@54e517f6 1 2 3)
 nil
 = (((f list) println 1 2 3))
 (1 2 3)
 nil

 I think that (trampoline (f list) ...) and ((f list) ...) should give the
 same result.

 In fact, I asked this question in Stackoverflow before. You can find some
 further discussion about this potential bug.

 https://stackoverflow.com/questions/27819418/strange-behaviour-of-clojure-trampoline

 Best wishes,
 Hongseok

--

-- 
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: Potential bug in trampoline

[Nicola Mometto]

I created http://dev.clojure.org/jira/browse/CLJ-1633 with a patch
implementing the proposed fix in the stackoverflow answer by the user 
d.j.sheldrick.

Hongseok Yang writes:

 Hi,

 While trying to use trampoline to optimise tail recursion in my Clojure
 project, I came across some strange behaviour of the trampoline function.

 = (defn f [g] (fn [k  args] #(k (apply g args
 ...
 = (trampoline (f list) println 1 2 3)
 (#core$println clojure.core$println@54e517f6 1 2 3)
 nil
 = (((f list) println 1 2 3))
 (1 2 3)
 nil

 I think that (trampoline (f list) ...) and ((f list) ...) should give the
 same result.

 In fact, I asked this question in Stackoverflow before. You can find some
 further discussion about this potential bug.

 https://stackoverflow.com/questions/27819418/strange-behaviour-of-clojure-trampoline

 Best wishes,
 Hongseok

--

-- 
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: reduced doesn't work inside reductions

[Nicola Mometto]

This has already been fixed, and reductions will support reduced in
1.7.0.
In the meantime you can use 1.7.0-alpha4.

Nicola

myguidingstar writes:



 (reduce (fn [acc x]
   (if ( acc 10)
 (reduced acc)
 (+ acc x)))
 0
 (range 100))
 ;; = 15
 (reductions (fn [acc x]
   (if ( acc 10)
 (reduced acc)
 (+ acc x)))
 0
 (range 100))
 ;; thows ClassCastException clojure.lang.Reduced cannot be cast to 
 java.lang.Number  clojure.lang.Numbers.gt (Numbers.java:227)
 Is it a bug or intended behavior?

--

-- 
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: thread-any macro %

[Nicola Mometto]

as- only binds the specified expression rather than each result in step
and only works from within -

Timothy Baldridge writes:

 That was added to clojure.core in 1.6 and is known as as-
 https://clojuredocs.org/clojure.core/as-%3E



 On Sat, Nov 15, 2014 at 6:55 AM, Krzysiek Herod krzysiek.he...@gmail.com
 wrote:

 Guys, what do you think about new thread macro (I would call it thread-any
 and represent it as %), that would require you to always specify the
 position of the argument you want to pass to the function?

 This code:

 (defn csv-line-sql-line [table, line]
   (- line
   (str  )
   (str/split separator)
   (#(map csv-field-sql-field %))
   (#(str/join ,  %))
   (str/replace strings-wrapper \)
   (#(str INSERT INTO , table,  VALUES( % );

 would become:

 (defn csv-line-sql-line [table, line]
   (% line
   (str %  )
   (str/split % separator)
   (map csv-field-sql-field %)
   (str/join ,  %)
   (str/replace strings-wrapper % \)
   (str INSERT INTO , table,  VALUES( % );)))

 Reasoning:
 - there are functions that are thread-first fiendly, and other that are
 thread-last friendly, by using thread-in you don't have to redefine
 functions only to change the order of the attributes
 - I find it easier to follow execution chain if the argument is passed
 explicitely

 PS. I'm a clojure newbie, still in the process of learning basics. For
 example I'm not sure how to implement such macro yet, so if you find
 something obviously wrong, or missing in my suggestion, please let me know.
 I'll be super happy to read about alternative solutions to achieve similar
 goal.

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




 --
 “One of the main causes of the fall of the Roman Empire was that–lacking
 zero–they had no way to indicate successful termination of their C
 programs.”
 (Robert Firth)

--

-- 
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: how clojure infers types.

[Nicola Mometto]

Actually `set` and a lot of other clojure.core functions are neither
inlineable nor have type hints.

Phillip Lord writes:

 I have a piece of code that looks like this

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (set classlist)
   (union-annotations classlist))

 The method signature is

 getOWLEquivalentClassesAxiom(Set,Set)

 On runing lein check I get


 Reflection warning, tawny/owl.clj:2219:6 - call to method
 getOWLEquivalentClassesAxiom on
 org.semanticweb.owlapi.model.OWLDataFactory can't be resolved (argument
 types: unknown, java.util.Set).

 which makes no sense. Surely, the return type of clojure.core/set is
 known to be java.util.Set? I have quite a few calls like this in my
 code, which is why I don't want to type hint the return of set
 individually.

 If I add a function like so:

 (defn ^java.util.Set hset [coll]
   (set coll))

 and call like this:

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (hset classlist)
   (union-annotations classlist))

 The reflection warning goes away.


 I've tried to reproduce this with simpler cases, like so:


 (defn one []
   (java.util.Collections/unmodifiableSet
(java.util.HashSet.)))


 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 But both of these pass lein check just fine. Which suggests that clojure
 knows set returns a java.util.Set object.

 Now, given that I can't give a simple test case, I realise that it's
 hard for anyone to work out what is happening. But, worse, I don't know
 how to debug this at all. So, how I find out what clojure things the
 return type of a function is? Or probe any further why this is failing?

 Phil

--

-- 
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: how clojure infers types.

[Nicola Mometto]

The reason why that call doesn't require reflection is that
Collection.unmodifiableSet has no overloaded methods, it only takes a
Set so the compiler doesn't have to disambiguate between different
signatures.

Phillip Lord writes:

 Yes, I checked the code.

 (defn set
   Returns a set of the distinct elements of coll.
   {:added 1.0
:static true}
   [coll] (clojure.lang.PersistentHashSet/create (seq coll)))

 And that was my first assumption. But if clojure doesn't know the return
 type, then why does this:

 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 Not require reflection? Clojure should not know which method to call.
 Unless it is just because unmodifiableSet has an arity of one and it's
 the only arity of one, so it doesn't try to disambiguate.

 I guess even if set was type hinted (to IPersistentSet) it would still
 not work since, IPersistentSet is not assignable from java.util.Set.

 Phil



 Nicola Mometto brobro...@gmail.com writes:

 Actually `set` and a lot of other clojure.core functions are neither
 inlineable nor have type hints.

 Phillip Lord writes:

 I have a piece of code that looks like this

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (set classlist)
   (union-annotations classlist))

 The method signature is

 getOWLEquivalentClassesAxiom(Set,Set)

 On runing lein check I get


 Reflection warning, tawny/owl.clj:2219:6 - call to method
 getOWLEquivalentClassesAxiom on
 org.semanticweb.owlapi.model.OWLDataFactory can't be resolved (argument
 types: unknown, java.util.Set).

 which makes no sense. Surely, the return type of clojure.core/set is
 known to be java.util.Set? I have quite a few calls like this in my
 code, which is why I don't want to type hint the return of set
 individually.

 If I add a function like so:

 (defn ^java.util.Set hset [coll]
   (set coll))

 and call like this:

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (hset classlist)
   (union-annotations classlist))

 The reflection warning goes away.


 I've tried to reproduce this with simpler cases, like so:


 (defn one []
   (java.util.Collections/unmodifiableSet
(java.util.HashSet.)))


 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 But both of these pass lein check just fine. Which suggests that clojure
 knows set returns a java.util.Set object.

 Now, given that I can't give a simple test case, I realise that it's
 hard for anyone to work out what is happening. But, worse, I don't know
 how to debug this at all. So, how I find out what clojure things the
 return type of a function is? Or probe any further why this is failing?

 Phil

 --

 --
 Phillip Lord,   Phone: +44 (0) 191 222 7827
 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
 School of Computing Science,
 http://homepages.cs.ncl.ac.uk/phillip.lord
 Room 914 Claremont Tower,   skype: russet_apples
 Newcastle University,   twitter: phillord
 NE1 7RU

--

-- 
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: Namespace metadata

[Nicola Mometto]

Might be an instance of http://dev.clojure.org/jira/browse/CLJ-130

Haim Ashkenazi writes:

 Sorry, I pressed send too soon :) Here it is from the start:


 When I first wrote ayler https://github.com/babysnakes/ayler/wiki (a
 simple namespace browser) I used to get the doc for namespace by running
 something like this:

 (:doc (meta (find-ns 'some.namespace)))

 It used to work on all namespaces (IIRC I was working on clojure 1.4).

 Lately I noticed that it doesn't get the metadata. e.g.:

 user= (require 'clojure.test)
 nil
 user= (meta (find-ns 'clojure.test))
 nil

 I'm not sure if it started on clojure 1.5 or 1.6, but the clojure.test
 source does contain metadata doc.

 Did something change in the way we access namespace metadata?

 Thanks in advance

 Haim Ashkenazi

 On Wed, Oct 29, 2014 at 2:38 PM, Haim Ashkenazi haim.ashken...@gmail.com
 wrote:

 Hi

 When I first wrote ayler https://github.com/babysnakes/ayler/wiki (a
 simple namespace browser) I used to get the doc for namespace by running
 something like this:

 (:doc (meta (find-ns 'some.namespace)))

 It used to work on all namespaces (IIRC I was working on clojure 1.4).

 Lately I noticed that it doesn't get the metadata. e.g.:

 user= (require 'clojure.test)
 nil
 user= (meta (find-ns 'clojure.test))
 nil

 I'm not sure if it started on clojure 1.5 or 1.6.

 --
 Haim




 --
 Haim

--

-- 
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: Namespace metadata

[Nicola Mometto]

I just tested for clojure.test and I'm getting nil with clojure
1.7.0-master-SNAPSHOT but the correct metadata when using master w/
clj-130 patch.

Haim Ashkenazi writes:

 Thanks Nicola,

 I don't think this is the reason. clojure.test is also explicitly adding
 docs. Also I encountered it in riemann in a namespace that is not AOT at
 all.


 On Wed, Oct 29, 2014 at 3:03 PM, Nicola Mometto brobro...@gmail.com wrote:


 Might be an instance of http://dev.clojure.org/jira/browse/CLJ-130

 Haim Ashkenazi writes:

  Sorry, I pressed send too soon :) Here it is from the start:
 
 
  When I first wrote ayler https://github.com/babysnakes/ayler/wiki (a
  simple namespace browser) I used to get the doc for namespace by running
  something like this:
 
  (:doc (meta (find-ns 'some.namespace)))
 
  It used to work on all namespaces (IIRC I was working on clojure 1.4).
 
  Lately I noticed that it doesn't get the metadata. e.g.:
 
  user= (require 'clojure.test)
  nil
  user= (meta (find-ns 'clojure.test))
  nil
 
  I'm not sure if it started on clojure 1.5 or 1.6, but the clojure.test
  source does contain metadata doc.
 
  Did something change in the way we access namespace metadata?
 
  Thanks in advance
 
  Haim Ashkenazi
 
  On Wed, Oct 29, 2014 at 2:38 PM, Haim Ashkenazi 
 haim.ashken...@gmail.com
  wrote:
 
  Hi
 
  When I first wrote ayler https://github.com/babysnakes/ayler/wiki (a
  simple namespace browser) I used to get the doc for namespace by running
  something like this:
 
  (:doc (meta (find-ns 'some.namespace)))
 
  It used to work on all namespaces (IIRC I was working on clojure 1.4).
 
  Lately I noticed that it doesn't get the metadata. e.g.:
 
  user= (require 'clojure.test)
  nil
  user= (meta (find-ns 'clojure.test))
  nil
 
  I'm not sure if it started on clojure 1.5 or 1.6.
 
  --
  Haim
 
 
 
 
  --
  Haim

 --

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




 --
 Haim

--

-- 
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: tools.analyzer.jvm clojure.lang.Var$Unbound cannot be cast to clojure.lang.DynamicClassLoader

[Nicola Mometto]

Hi Nick,
I looked into it, I'm not sure if this should be considered a clojure
bug, a lein bug or a t.a.jvm one (I'd expect Compiler/LOADER to always
be bound during compilation) but in the meantime I've pushed a
workaround that should fix this and a 0.6.2 version is on its way to
Maven Central.

It should be available in a couple of hours, please let me know if it
solved your issue or not.

Thanks,
Nicola

Nick Zbinden writes:

 Hallo,

 Im trying to use tools.analyzer to analyse some clojure code and compile
 it. I have used '(ana/analyze+eval form)' and it has worked nicely.

 Now I always called my compile function either directly inside of the code,
 or I would call it like this 'lein run test.clj'.

 Now I tried to use 'lein uberjar' and use it standalone, but then if fails
 for protocols.

 (defprotocol REST
   (GET [self]))

 Inside of the project, or with lein run it works correctly.

 When running the uberjar:

 Exception in thread main java.lang.ClassCastException:
 clojure.lang.Var$Unbound cannot be cast to clojure.lang.DynamicClassLoader
 at clojure.core$gen_interface.doInvoke(genclass.clj:722)
 at clojure.lang.RestFn.invoke(RestFn.java:521)
 at clojure.lang.Var.invoke(Var.java:409)
 at clojure.lang.AFn.applyToHelper(AFn.java:178)
 at clojure.lang.Var.applyTo(Var.java:700)


 Is this a bug in tools.analyzer.jvm or is it something with my project
 compilation?

 Thanks for your help

--

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