Nice! This will let me remove some workarounds for reflection warnings
I was getting and probably give me better performance too :)
I'll try to run tests against 1.4.0-master-SNAPSHOT today (that'll
have this change, right?).
Sean
On Fri, Oct 7, 2011 at 1:20 PM, Stuart Halloway
On Tue, Oct 11, 2011 at 8:47 AM, Sean Corfield seancorfi...@gmail.com wrote:
I'll try to run tests against 1.4.0-master-SNAPSHOT today (that'll
have this change, right?).
I get a NPE from the 1.4 compiler on Congomongo. Details reported on
clojure-dev.
--
Sean A Corfield -- (904) 302-SEAN
An
On Fri, Oct 7, 2011 at 4:20 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
leiningen project, enabled warn on reflection, and found that several
cases of
On Mon, Oct 10, 2011 at 11:19 AM, Lars Nilsson chamael...@gmail.com wrote:
On Fri, Oct 7, 2011 at 4:20 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
I think I got the permissions fixed...
-S
--
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
Patch welcome... ;)
-S
--
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
Clutch was mentioned a couple of times, so I figured I'd chime in. :-)
As for why clutch uses c.c.json — I don't think there's any particular reason.
Tunde chose it before I got involved, but I'm sure I probably would have done
the same thing, mostly because JSON en/decoding speed isn't
There was no particular reason to mention clutch. It was just the example
that seemed to be in the discussion.
Dave
--
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
Sure, I wasn't attempting to be defensive or whatever. Just thought the
perspective might be worthwhile.
- Chas
On Oct 7, 2011, at 12:55 AM, Dave Sann wrote:
There was no particular reason to mention clutch. It was just the example
that seemed to be in the discussion.
Dave
--
You
My 2 cents:
1. JSON transformation is of fundamental importance to many Clojure
applications.
2. Having the standard solution be blown away by a factor of 140x
for the sake of purity is not pragmatic.
If the user experience with contrib is to use it, realize its not
ready for prime time, and
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
leiningen project, enabled warn on reflection, and found that several
cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure
deciding it needs to perform
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
leiningen project, enabled warn on reflection, and found that several
cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure
deciding it needs to
That would be http://dev.clojure.org/jira/browse/DJSON-1 which I
opened at the end of July...
On Fri, Oct 7, 2011 at 11:10 AM, Lars Nilsson chamael...@gmail.com wrote:
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it
As long as we're fixing d.c.json... it would be nice to add
support for encoding sequences and maps.
(I know, I should open a bug)
On 10/07/2011 02:04 PM, Sean Corfield wrote:
That would be http://dev.clojure.org/jira/browse/DJSON-1 which I
opened at
I get the following, trying to follow that link.
Login Required
You are not logged in.
You cannot view this URL as a guest. You must log in or sign up for an account .
If you think this message is wrong, please consult your administrators
about getting the necessary permissions.
Lars Nilsson
On
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
leiningen project, enabled warn on reflection, and found that several
cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure
deciding it needs to
seems like that could be added to Intrinsics.java
On Fri, Oct 7, 2011 at 1:20 PM, Stuart Halloway
stuart.hallo...@gmail.com wrote:
Trying to be a little bit constructive here, in case I come across as
complaining, I took the source for c.d.json and put it into a
leiningen project, enabled warn
The clojure.contrib.base64 discussion has inspired me (sorry!) to
write this.. I would very much like to see a faster JSON parser be in
contrib. clj-json can beat clojure.data.json by up to a factor of 140x
when reading/parsing and 5x when creating a JSON string.
clojure.data.json reading:
An excellent JVM library to use as base is Jackson:
http://jackson.codehaus.org/
It would be wonderful to see a Clojure-friendly version of it: having it
create Clojure-specific structures from JSON, and also recognizing Clojure
deftypes for serialization. The streaming API is friendly enough
clj-json uses Jackson and so does https://github.com/dakrone/cheshire
On Thu, Oct 6, 2011 at 8:07 PM, Tal Liron tal.li...@gmail.com wrote:
An excellent JVM library to use as base is Jackson:
http://jackson.codehaus.org/
It would be wonderful to see a Clojure-friendly version of it: having
On Thu, Oct 6, 2011 at 5:07 PM, Tal Liron tal.li...@gmail.com wrote:
An excellent JVM library to use as base is Jackson:
http://jackson.codehaus.org/
It would be wonderful to see a Clojure-friendly version of it
Both clj-json and cheshire (https://github.com/dakrone/cheshire) are
actually
Cheshire looks great, thanks for the tip!
I wonder, then, what's the OP's problem? I think it's good to have a
lightweight, 100% Clojure version of JSON in contrib. A lighter weight is
often a higher priority than performance. I think both approaches have their
place.
In the Java world, too,
As I mentioned in my previous email, my problem isn't really picking a
JSON implementation for my own needs, but rather when I use a library
that uses a slower implementation. If I wanted to use clutch for
couchdb access and didn't pay too much attention as to what leiningen
pulls in, I wouldn't
In my opinion, the situation is not clear cut:
I might want a slower but more portable library if porting clutch to
clojurescript.
(I read that someone has this working...)
I might just want a lib that works if moving to .net in the short term but
optimise with a faster library later.
Hi,
slf4j comes to mind. Have a standard API which is provided by the different
libraries. If you were targeting clojurescript you'd specify the portable
library. For a server application running on the JVM you'd specify a fast
Jackson-based implementation. This leaves the choice to the user
25 matches
Mail list logo
