date:20160804

Re: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

2016-08-04 Thread Colin Fleming

The JVM does retain some generic information (see for example Neil Gafter's
Super Type Tokens), in particular Type instances can retain generic info
which is what the linked code is using. It might be possible to recreate
this in pure Clojure but IMO it's likely to be more difficult than it's
worth - all the reflective Type code is very fiddly. YMMV, of course.

On 5 August 2016 at 11:18, Timothy Baldridge  wrote:

> I'd dig into it a bit more, since the JVM doesn't support generics either.
> So if there's an api looking for some marker interfaces, it might be
> possible to implement those interfaces as well. There's probably a way to
> do this in pure Clojure.
>
> On Thu, Aug 4, 2016 at 4:55 PM, Colin Fleming  > wrote:
>
>> Hi Jakub,
>>
>> Yes, that is correct - Clojure interop only deals with raw classes, it
>> has no concept of generics. Java is the way to go here.
>>
>> Cheers,
>> Colin
>>
>> On 5 August 2016 at 09:28, Jakub Holý  wrote:
>>
>>> I need to implement the interface javax.websocket.
>>> MessageHandler.Whole - the type parameter is important since
>>> the Java code uses reflection to check
>>> 
>>> whether the result is instanceof java.lang.reflect.ParameterizedType.
>>>
>>> I believe I cannot use proxy or any other available Clojure mechanism
>>> as they do not support generics. Is that correct?
>>>
>>> I believe that the only (and best) solution is to implement the
>>> interface in Java and then possibly extend the resulting class:
>>>
>>> public class TextMessageHandler implements 
>>> javax.websocket.MessageHandler.Whole
>>> {
>>> public void onMessage(String message) {
>>> }
>>> }
>>> 
>>> (proxy [TextMessageHandler] []
>>> (onMessage [msg]
>>>   (println "received message(" (.getClass msg) "):" msg)))
>>>
>>>
>>> Correct?
>>>
>>> Thank you!
>>>
>>> Cheers, Jakub Holý
>>>
>>> --
>>> You 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.
>>
>
>
>
> --
> “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.
>

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

Do you use any Clojars data feeds?

2016-08-04 Thread Toby Crawley

Clojars provides a few static data feeds[1]:

- a list of poms in the repo (all-poms.txt.gz)
- a list of all releases in the repo (all-jars.clj.gz)
- an expanded list of releases, including more metadata from the poms
(feed.clj.gz)

We're evaluating our bandwidth usage in anticipation of moving the
repository to a CDN to improve availability, and noticed some odd
request patterns for these feeds.

There are sites/services out there that make (sometimes heavy) use of
these feeds, so I want to point out that they are only updated hourly,
so requesting them more often gives you no benefit. Even though it's
only 1.4MB in size, feed.clj.gz alone accounted for ~20% (~200GB) of
Clojars' bandwidth usage for the past month, with one client
requesting it 30 times *per minute*.

So if you (or someone you love) uses one of these feeds, can you
confirm that you are caching a copy for at least an hour before
retrieving the latest version?

Thanks!
Your Friendly Neighborhood Clojars Staff

[1]: https://github.com/clojars/clojars-web/wiki/Data

-- 
You 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: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

2016-08-04 Thread Timothy Baldridge

I'd dig into it a bit more, since the JVM doesn't support generics either.
So if there's an api looking for some marker interfaces, it might be
possible to implement those interfaces as well. There's probably a way to
do this in pure Clojure.

On Thu, Aug 4, 2016 at 4:55 PM, Colin Fleming 
wrote:

> Hi Jakub,
>
> Yes, that is correct - Clojure interop only deals with raw classes, it has
> no concept of generics. Java is the way to go here.
>
> Cheers,
> Colin
>
> On 5 August 2016 at 09:28, Jakub Holý  wrote:
>
>> I need to implement the interface
>> javax.websocket.MessageHandler.Whole - the type parameter is
>> important since the Java code uses reflection to check
>> 
>> whether the result is instanceof java.lang.reflect.ParameterizedType.
>>
>> I believe I cannot use proxy or any other available Clojure mechanism as
>> they do not support generics. Is that correct?
>>
>> I believe that the only (and best) solution is to implement the interface
>> in Java and then possibly extend the resulting class:
>>
>> public class TextMessageHandler implements
>> javax.websocket.MessageHandler.Whole {
>> public void onMessage(String message) {
>> }
>> }
>> 
>> (proxy [TextMessageHandler] []
>> (onMessage [msg]
>>   (println "received message(" (.getClass msg) "):" msg)))
>>
>>
>> Correct?
>>
>> Thank you!
>>
>> Cheers, Jakub Holý
>>
>> --
>> You 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.
>



-- 
“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: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

2016-08-04 Thread Colin Fleming

Hi Jakub,

Yes, that is correct - Clojure interop only deals with raw classes, it has
no concept of generics. Java is the way to go here.

Cheers,
Colin

On 5 August 2016 at 09:28, Jakub Holý  wrote:

> I need to implement the interface javax.websocket.
> MessageHandler.Whole - the type parameter is important since the
> Java code uses reflection to check
> 
> whether the result is instanceof java.lang.reflect.ParameterizedType.
>
> I believe I cannot use proxy or any other available Clojure mechanism as
> they do not support generics. Is that correct?
>
> I believe that the only (and best) solution is to implement the interface
> in Java and then possibly extend the resulting class:
>
> public class TextMessageHandler implements 
> javax.websocket.MessageHandler.Whole
> {
> public void onMessage(String message) {
> }
> }
> 
> (proxy [TextMessageHandler] []
> (onMessage [msg]
>   (println "received message(" (.getClass msg) "):" msg)))
>
>
> Correct?
>
> Thank you!
>
> Cheers, Jakub Holý
>
> --
> You 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.

Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

2016-08-04 Thread Jakub Holý

I need to implement the interface 
javax.websocket.MessageHandler.Whole - the type parameter is 
important since the Java code uses reflection to check 

 
whether the result is instanceof java.lang.reflect.ParameterizedType.

I believe I cannot use proxy or any other available Clojure mechanism as 
they do not support generics. Is that correct?

I believe that the only (and best) solution is to implement the interface 
in Java and then possibly extend the resulting class:

public class TextMessageHandler implements 
javax.websocket.MessageHandler.Whole {
public void onMessage(String message) {
}
}

(proxy [TextMessageHandler] []
(onMessage [msg]
  (println "received message(" (.getClass msg) "):" msg)))


Correct?

Thank you!

Cheers, Jakub Holý

-- 
You 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: Is this behavior of clojure.core/pr a bug?

2016-08-04 Thread Herwig Hochleitner

2016-08-04 13:56 GMT+02:00 Timothy Baldridge :

> The problem is that many do not understand that Clojure data is a superset
> of EDN. The two were never meant to be completely compatible. There are
> many things, especially when dealing with keywords and symbols, where its
> possible to have data that doesn't properly round-trip.
>

Then fressian and transit are supersets of edn as well. Are those, at
least, meant to be the same set as clojure data?
Also, reader tags are a fantastic opportunity to make arbitrary data
round-trippable.

An added problem when dealing with EDN is that there is only really one or
> two languages that properly parse it: Clojure and Clojurescript. So it's
> also a poor choice to use in cases where you desire any sort of interop.
>

There many edn libraries for various languages:
https://github.com/edn-format/edn/wiki/Implementations
It is true, that there is a lack of compatibility, especially in the
handling of symbols and keywords and the community is hurting for it (I
remember a couple of tedious discussions on the matter)

see http://dev.clojure.org/jira/browse/CLJ-1527
https://github.com/edn-format/edn/issues/67 ...

Add on top of all that that EDN parsing is really slow compared to other
> approaches, and you have a lot of compelling reasons to, as Herwig put it,
> "abandon edn, except for hand-written data".
>

My view is, that those reasons should be eliminated, starting with
interoperability concerns. I still think edn is a fantastic idea and to me
it still holds the promise of being a replacement for json and xml, but
only if we can get our act together and develop it towards that goal.

Please note, that my "except for hand-written data" was meant to be
hyperbole. Every data is eventually machine-written.

Abandoning edn would send a fatal signal not just to people in the
community. Especially if we let it slowly die instead of declaring it a
failed experiment in data exchange.

Imagine if pr wouldn't handle embedded " quotes in strings and the
inofficial recommendation would be to just avoid that use case or use a
different encoding.

And yes, the original problem that caused the creation of Transit was "how
> do we get data from language A to language B while still staying fast, not
> implementing a ton of code, and keeping rich data (dates should be dates,
> not strings)."
>

I like the idea of having various encodings for different uses, but we
should strife towards compatibility.

-- 
You 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: Is this behavior of clojure.core/pr a bug?

2016-08-04 Thread Timothy Baldridge

The problem is that many do not understand that Clojure data is a superset
of EDN. The two were never meant to be completely compatible. There are
many things, especially when dealing with keywords and symbols, where its
possible to have data that doesn't properly round-trip.

An added problem when dealing with EDN is that there is only really one or
two languages that properly parse it: Clojure and Clojurescript. So it's
also a poor choice to use in cases where you desire any sort of interop.

Add on top of all that that EDN parsing is really slow compared to other
approaches, and you have a lot of compelling reasons to, as Herwig put it,
"abandon edn, except for hand-written data".

And yes, the original problem that caused the creation of Transit was "how
do we get data from language A to language B while still staying fast, not
implementing a ton of code, and keeping rich data (dates should be dates,
not strings)."

On Thu, Aug 4, 2016 at 3:55 AM, Herwig Hochleitner 
wrote:

> 2016-08-04 1:41 GMT+02:00 Timothy Baldridge :
>
>> I highly suggest using transit. It's much faster and formally specified.
>> https://github.com/cognitect/transit-format
>>
>> It's issues like this that caused the creation of transit in the first
>> place.
>>
>
>  I thought transit was created to take advantage of fast JSON parsers.
> I've never understood it as a "more correct" edn. People reasonably expect
> transit (and fressian) to be on par with edn.
>
> Are you suggesting we abandon edn, except for hand-written data?
>
> --
> You 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: Is this behavior of clojure.core/pr a bug?

2016-08-04 Thread Herwig Hochleitner

2016-08-04 1:41 GMT+02:00 Timothy Baldridge :

> I highly suggest using transit. It's much faster and formally specified.
> https://github.com/cognitect/transit-format
>
> It's issues like this that caused the creation of transit in the first
> place.
>

 I thought transit was created to take advantage of fast JSON parsers. I've
never understood it as a "more correct" edn. People reasonably expect
transit (and fressian) to be on par with edn.

Are you suggesting we abandon edn, except for hand-written data?

-- 
You 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: Is this behavior of clojure.core/pr a bug?

2016-08-04 Thread Daniel Compton

> Can anyone think of a good reason why pr should *not* throw an exception
on
> (pr (keyword “foo bar"))
> since there’s no way of expressing that keyword as valid EDN?

This would break backwards compatibility, something Clojure rarely does.

On Thu, Aug 4, 2016 at 1:16 PM Blake Miller  wrote:

> Er, I mean "built-in reader macro dispatch".
>
>
> On Thursday, August 4, 2016 at 1:14:16 AM UTC, Blake Miller wrote:
>>
>> You're right, Dan. Having mulled it over a little more, it's not clear to
>> me why there ought to be any pure Clojure data (no Java objects) that
>> cannot be serialized as EDN. Emitting a #keyword reader literal for this
>> edge case would make sense to me.
>>
> --
> You 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.
>
-- 
—
Daniel

-- 
You 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: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

Do you use any Clojars data feeds?

Re: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

Re: Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

Implementing a generic parameterized Java interface so that it satisfies (instance? ParameterizedType)

Re: Is this behavior of clojure.core/pr a bug?

Re: Is this behavior of clojure.core/pr a bug?

Re: Is this behavior of clojure.core/pr a bug?

Re: Is this behavior of clojure.core/pr a bug?

9 matches

Site Navigation

Mail list logo

Footer information