On Tue, Oct 11, 2011 at 8:47 AM, Sean Corfield 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 Architect's View -- ht
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
wrote:
> This re
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 gro
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 unsubs
On Mon, Oct 10, 2011 at 11:19 AM, Lars Nilsson wrote:
> On Fri, Oct 7, 2011 at 4:20 PM, Stuart Halloway
> 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 refle
On Fri, Oct 7, 2011 at 4:20 PM, Stuart Halloway
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 (... (let [c (char i
seems like that could be added to Intrinsics.java
On Fri, Oct 7, 2011 at 1:20 PM, Stuart Halloway
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
> 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 t
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
On Fri, Oct 7, 2011 at 12:08 PM, Tal Liron wrote:
> (I know, I should open a bug)
http://dev.clojure.org/jira/browse/DJSON :)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://ww
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 the
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 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 pr
> 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 t
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
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 th
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 rec
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 ne
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 top-mos
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 of
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.
O
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 kn
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, t
On Thu, Oct 6, 2011 at 5:07 PM, Tal Liron 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 already based on
clj-json uses Jackson and so does https://github.com/dakrone/cheshire
On Thu, Oct 6, 2011 at 8:07 PM, Tal Liron 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 it
> create Cloj
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 t
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:
(dotim
26 matches
Mail list logo
