Calling proxy without reflection

2018-07-30 Thread Mark Engelberg
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.


Re: Calling proxy without reflection

2018-07-30 Thread 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: Calling proxy without reflection

2018-07-30 Thread Mark Engelberg
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  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  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.
>

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

2018-07-30 Thread 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  > 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 > > 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 
> .
> 
> 
> -- 
> You 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 moderate

Re: Calling proxy without reflection

2018-07-30 Thread Mark Engelberg
I'm using 1.9.0.  Is this a behavior that recently changed?

On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto  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  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 
> 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 
>> 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.
>>
>
>
> --
> You 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

2018-07-30 Thread 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  > 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 > > 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 > > 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 >> > 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 
>> .
>> 
>> 
>> -- 
>> You 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 
>> 

Re: Calling proxy without reflection

2018-07-30 Thread Mark Engelberg
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  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  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 
> 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 
>> 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 
>> 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 
>>> 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.
>>>
>>
>>
>> --
>> You 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 grou

Re: Calling proxy without reflection

2018-07-30 Thread 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  > 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 > > 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 > > 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 >> > 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 >> > 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 >>> > 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 
>

Re: Calling proxy without reflection

2018-07-30 Thread Mark Engelberg
OK, I just pushed the repo (work in progress) to github.
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



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

Re: Calling proxy without reflection

2018-07-30 Thread 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 
> 
> 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
>  
> 
> 
> 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 
> 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  > 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 > > 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 > > 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 >> > 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 >> > 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 >>> > 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 >>> > 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, Ma

Re: Rusts Upgrades

2018-07-30 Thread Nathan Fisher
If it’s run on CircleCI or Travis and has readonly access to github, I
wouldn’t be too concerned.

The most frequent downloads API in Clojars is a good idea. Could use it as
a basis for the hand rolled site for now and target it for automation in
the future. I’m wondering how amenable/suitable it would be for the data to
live in Clojars.

On Mon, Jul 30, 2018 at 02:17, Alan Moore 
wrote:

> Has anyone looked for vulnerabilities exposed by pulling random libraries
> from github.com (or gitlab.com?) and building them? Macros come mind
> (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code.
>
> Also instead of choosing "top-N projects on Github" I would begin with
> the "most used projects on clojars" (# downloads in the last 12 months?) as
> that might be a better metric/signal for prioritizing which libraries to
> include. #RememberLeftPad
>
> Don't get me wrong, I like the idea. I'm just trying to think through the
> possible hazards.
>
> Alan
>
>
> On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote:
>>
>> Hi Folks,
>>
>> Reading up the recent blog post “What is Rust 2018” and happened upon
>> this;
>>
>> “We put in a lot of work to make upgrades painless; for example, we run a
>> tool (called “crater”) before each Rust release that downloads every
>> package on crates.io and attempts to build their code and run their
>> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
>>
>> Seems an interesting idea and with Travis and other CI services providing
>> free builds for OSS it doesn’t need to put a heavy financial/operational
>> burden on a single entity. The main benefit for this is for people could
>> get a quick centralised overview of compatibility of various projects and
>> impending releases of Clojure.
>>
>> The main idea would be to have a grid view of the latest Clojure projects
>> and their status against HEAD of Clojure (are snapshots pushed to a maven
>> repo automatically as a result of a commit build?). Travis allows periodic
>> builds so that could be used to trigger verification even when changes
>> haven’t occurred.
>>
>> In terms of initial focus targeting the top-N projects on Github makes
>> the most sense to me. The bit I’m still thinking through is providing some
>> form of dashboard/aggregation without requiring a large investment in
>> changes, infrastructure, etc. Might fit in nicely with something like
>> clojars? Was thinking initially having a Github page with a table of
>> projects and their build badges and talking to maintainers about
>> configuring periodic builds with the latest Clojure snapshot.
>>
>> Thoughts?
>>
>> Cheers,
>> Nathan
>> --
>> - sent from my mobile
>>
> --
> You 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.
>
-- 
- sent from my mobile

-- 
You 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: What Happened to "java -jar clojure.jar hosehead.clj" ?

2018-07-30 Thread Payter Versteegen
Right, but the disadvantage is that you're releasing something that's now 
incomplete on its own.

I'd've hoped that clojure wouldn't have become as tightly-coupled with spec 
(for instance), but maybe I just need to read the Rationale page more 
deeply. Dependency hell blows, especially if your work environment is 
disconnected from the global internet.

Cheers,
Payter.

On Tuesday, July 24, 2018 at 3:46:43 PM UTC-4, Alex Miller wrote:
>
> We have begun the process of breaking Clojure into more fine-grained 
> modules. There is no timeline for this work but we expect this to become 
> more common in the future so we have no plans to change this aspect of 
> packaging.
>
> The major benefit is that the modules can be released independently and at 
> a faster rate than core itself. For example, newer versions of spec and the 
> core specs libs have already been released and can be used now with Clojure 
> 1.9. The new clj tool and its tool.deps lib exist to help you put these 
> pieces together.
>
>

-- 
You 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: Rusts Upgrades

2018-07-30 Thread Alan Moore
Nathan,

I wasn’t concerned with Github per se but the CI server compiling/running
arbitrary code should some library’s repo get pwnd in some way or that a
rogue library could make it into the list of repos to build in the proposed
system. A hand curated list of repos would mitigate this last concern.

I suppose CircleCI/Travis have this figured out (sandboxes?) given that
they already run arbitrary code via tests. I’ve not used any of the
cloud-based CI services, just in-house installations that are tightly
controlled.

Never mind... I think I’ve left my paranoia dial set to 11 after reading
about remote Spectre attacks.

Alan

On Jul 30, 2018, at 1:01 PM, Nathan Fisher  wrote:

If it’s run on CircleCI or Travis and has readonly access to github, I
wouldn’t be too concerned.

The most frequent downloads API in Clojars is a good idea. Could use it as
a basis for the hand rolled site for now and target it for automation in
the future. I’m wondering how amenable/suitable it would be for the data to
live in Clojars.

On Mon, Jul 30, 2018 at 02:17, Alan Moore 
wrote:

> Has anyone looked for vulnerabilities exposed by pulling random libraries
> from github.com (or gitlab.com?) and building them? Macros come mind
> (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code.
>
> Also instead of choosing "top-N projects on Github" I would begin with
> the "most used projects on clojars" (# downloads in the last 12 months?) as
> that might be a better metric/signal for prioritizing which libraries to
> include. #RememberLeftPad
>
> Don't get me wrong, I like the idea. I'm just trying to think through the
> possible hazards.
>
> Alan
>
>
> On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote:
>>
>> Hi Folks,
>>
>> Reading up the recent blog post “What is Rust 2018” and happened upon
>> this;
>>
>> “We put in a lot of work to make upgrades painless; for example, we run a
>> tool (called “crater”) before each Rust release that downloads every
>> package on crates.io and attempts to build their code and run their
>> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
>>
>> Seems an interesting idea and with Travis and other CI services providing
>> free builds for OSS it doesn’t need to put a heavy financial/operational
>> burden on a single entity. The main benefit for this is for people could
>> get a quick centralised overview of compatibility of various projects and
>> impending releases of Clojure.
>>
>> The main idea would be to have a grid view of the latest Clojure projects
>> and their status against HEAD of Clojure (are snapshots pushed to a maven
>> repo automatically as a result of a commit build?). Travis allows periodic
>> builds so that could be used to trigger verification even when changes
>> haven’t occurred.
>>
>> In terms of initial focus targeting the top-N projects on Github makes
>> the most sense to me. The bit I’m still thinking through is providing some
>> form of dashboard/aggregation without requiring a large investment in
>> changes, infrastructure, etc. Might fit in nicely with something like
>> clojars? Was thinking initially having a Github page with a table of
>> projects and their build badges and talking to maintainers about
>> configuring periodic builds with the latest Clojure snapshot.
>>
>> Thoughts?
>>
>> Cheers,
>> Nathan
>> --
>> - sent from my mobile
>>
> --
> You 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.
>
-- 
- sent from my mobile

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

-- 
You received this message because you are subscribed to the Goog

RE: What Happened to "java -jar clojure.jar hosehead.clj" ?

2018-07-30 Thread Sean Corfield
Right, but the disadvantage is that you're releasing something that's now 
incomplete on its own.

Every non-trivial Clojure program has dependencies so you’re going to be using 
either `clj`/`clojure` shell scripts and `deps.edn`, or else Leiningen or Boot. 
And if you use any of those, the clojure.jar/spec/etc issue is completely 
hidden (and taken care of).

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


From: clojure@googlegroups.com  on behalf of Payter 
Versteegen 
Sent: Monday, July 30, 2018 2:08:12 PM
To: Clojure
Subject: Re: What Happened to "java -jar clojure.jar hosehead.clj" ?

Right, but the disadvantage is that you're releasing something that's now 
incomplete on its own.

I'd've hoped that clojure wouldn't have become as tightly-coupled with spec 
(for instance), but maybe I just need to read the Rationale page more deeply. 
Dependency hell blows, especially if your work environment is disconnected from 
the global internet.

Cheers,
Payter.

On Tuesday, July 24, 2018 at 3:46:43 PM UTC-4, Alex Miller wrote:
We have begun the process of breaking Clojure into more fine-grained modules. 
There is no timeline for this work but we expect this to become more common in 
the future so we have no plans to change this aspect of packaging.

The major benefit is that the modules can be released independently and at a 
faster rate than core itself. For example, newer versions of spec and the core 
specs libs have already been released and can be used now with Clojure 1.9. The 
new clj tool and its tool.deps lib exist to help you put these pieces together.

--
You 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: What Happened to "java -jar clojure.jar hosehead.clj" ?

2018-07-30 Thread Mark Derricutt
On 31 Jul 2018, at 9:08, Payter Versteegen wrote:

> I'd've hoped that clojure wouldn't have become as tightly-coupled with spec 
> (for instance), but maybe I just need to read the Rationale page more deeply. 
> Dependency hell blows, especially if your work environment is disconnected 
> from the global internet.

Welcome to source based dependencies/languages. That's one downside, ideally 
(in my world) spec would be a compile/test time dependency - esp. since AFAIK 
it's not recommended to turn it on at run-time for day-to-day operation.

I wonder if it'd be possible to have no-op versions of spec APIs in clojure.jar 
that are replaced with implementations if you include the actual... 
implementation.

I hit this recently with clojure.osgi and the move to the latest clojure, I had 
to include spec - which, as Sean mentions - is just part of the build process ( 
Maven in this case ), but I did feel dirty about it - since clojure.jar depends 
on an alpha, when that comes out of alpha, we'll need patch releases of Clojure 
core.

Mark
Lover/Loather of static types, and build/deps systems :)

---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time." — 
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

-- 
You 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: OpenPGP digital signature


RE: What Happened to "java -jar clojure.jar hosehead.clj" ?

2018-07-30 Thread Sean Corfield
That's one downside, ideally (in my world) spec would be a compile/test time 
dependency - esp. since AFAIK it's not recommended to turn it on at run-time 
for day-to-day operation.

We use clojure.spec extensively in production code so that certainly isn’t 
true. You might not turn on instrumentation for production but spec is far more 
than instrumentation and far more than generative testing.

In addition, clojure.core.specs.alpha leverages clojure.spec.alpha to provide 
“compile-time” specs for macros, which you can argue is not “production” if you 
argue for AOT only – which I’d strongly push back on.

since clojure.jar depends on an alpha, when that comes out of alpha, we'll need 
patch releases of Clojure core.

Not true. You can specify the version of clojure.spec(.alpha) independently of 
the version of Clojure itself. The same is true for clojure.core.specs.alpha. 
That’s part of why spec was split out from Clojure itself: so that it could 
evolve on a separate timeline. It’s how Clojure 1.9.0 went to release without 
spec coming out of alpha and how Clojure 1.10.0 has continued to evolve without 
lock-step against clojure.spec versions.

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

From: Mark Derricutt
Sent: Monday, July 30, 2018 6:48 PM
To: Clojure
Subject: Re: What Happened to "java -jar clojure.jar hosehead.clj" ?


On 31 Jul 2018, at 9:08, Payter Versteegen wrote:

I'd've hoped that clojure wouldn't have become as tightly-coupled with spec 
(for instance), but maybe I just need to read the Rationale page more deeply. 
Dependency hell blows, especially if your work environment is disconnected from 
the global internet.

Welcome to source based dependencies/languages. That's one downside, ideally 
(in my world) spec would be a compile/test time dependency - esp. since AFAIK 
it's not recommended to turn it on at run-time for day-to-day operation.

I wonder if it'd be possible to have no-op versions of spec APIs in clojure.jar 
that are replaced with implementations if you include the actual... 
implementation.

I hit this recently with clojure.osgi and the move to the latest clojure, I had 
to include spec - which, as Sean mentions - is just part of the build process ( 
Maven in this case ), but I did feel dirty about it - since clojure.jar depends 
on an alpha, when that comes out of alpha, we'll need patch releases of Clojure 
core.

Mark
Lover/Loather of static types, and build/deps systems :)


"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time." — Mark 
Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
--
You 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.