On Sun, 18 Oct 2009 11:32:11 -0500
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> > Okay, I just took a quick look at them and am looking at Anthony's
> > right now.
> >
> > Anyway, my brainstorm on this would be to have to_string() and have
> > default methods on all types to return a simpl
On Sun, Oct 18, 2009 at 12:32 PM, Vincent Hanquez wrote:
> Anthony Liguori wrote:
>>
>> Here's a first pass. I'll clean up this afternoon and post a proper
>> patch. It turned out to work pretty well.
>
> It doesn't seems to validate anything ?? or is it just a lexer ?
That's just a lexer. I p
On 10/18/2009 06:32 PM, Anthony Liguori wrote:
What's the value of integrating into the objects verses having a
separate function that can apply it to the objects?
That's just different style. Of course you could do a
switch(qobject_type(qobject)) instead of using polymorphism. It would
be
On 10/18/2009 06:46 PM, Vincent Hanquez wrote:
care to explain what's a single quoted string and varargs support means
in your context ? (just a simple example you do maybe ?)
single-quoted string: Being able to parse 'name' in addition to "name",
which is convenient because in C the latter wo
Anthony Liguori wrote:
Here's a first pass. I'll clean up this afternoon and post a proper
patch. It turned out to work pretty well.
It doesn't seems to validate anything ?? or is it just a lexer ?
you're also including ' as a string escape value (is that the single
quote thing you were talki
Luiz Capitulino wrote:
I can't think of any reason why integration with qobject would take more
than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious reason),
you get callback entering/leaving object/array
and callback for every value
Anthony Liguori wrote:
Vincent Hanquez wrote:
I can't think of any reason why integration with qobject would take
more than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious
reason), you get callback entering/leaving object/array
and
Luiz Capitulino wrote:
Okay, I just took a quick look at them and am looking at Anthony's
right now.
Anyway, my brainstorm on this would be to have to_string() and have
default methods on all types to return a simple string representation.
What's the value of integrating into the objects
Vincent Hanquez wrote:
I can't think of any reason why integration with qobject would take
more than 50 lines of C on the user side of the library.
since the API is completely SAX like (i call it SAJ for obvious
reason), you get callback entering/leaving object/array
and callback for every value
Anthony Liguori wrote:
Paolo Bonzini wrote:
On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder
on top
On Sun, 18 Oct 2009 17:25:47 +0200
Paolo Bonzini wrote:
>
> >> I'd strongly suggest making the JSON encoder live outside of QObject.
> >> There are many possible ways to represent a QObject. Think of JSON as a
> >> view of the QObject model. The human monitor mode representation is a
> >> diff
On 10/18/2009 05:35 PM, Luiz Capitulino wrote:
(no
extensions however since you're obviously loosing the benefit of using
JSON if you create extensions).
This is already settled, I hope.
I think he's referring to things such as putting things such as
single-quoted strings, or % escapes fo
On Sun, 18 Oct 2009 16:06:29 +0100
Vincent Hanquez wrote:
> Luiz Capitulino wrote:
> >> it got a raw/pretty printer, an interruptible parser (on the same idea
> >> as JSON_parser.c), it's faster than JSON_parser.c [1],
> >> it's completely generic (more like a library than an embedded thing),
>
I'd strongly suggest making the JSON encoder live outside of QObject.
There are many possible ways to represent a QObject. Think of JSON as a
view of the QObject model. The human monitor mode representation is a
different view.
My rationale was that since QObject is tailored over JSON, we mi
On Sun, 18 Oct 2009 09:49:55 -0500
Anthony Liguori wrote:
> Paolo Bonzini wrote:
> > On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
> >> Integration with QObjects is a killer feature, I think it's the
> >> stronger argument against grabbing one from the internet.
> >
> > Yeah, I'd say let's go
Luiz Capitulino wrote:
it got a raw/pretty printer, an interruptible parser (on the same idea
as JSON_parser.c), it's faster than JSON_parser.c [1],
it's completely generic (more like a library than an embedded thing),
fully JSON compliant (got a test suite too), support
user supplied alloc func
Paolo Bonzini wrote:
On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder
on top of it soonish (I still t
On 10/18/2009 04:06 PM, Luiz Capitulino wrote:
Integration with QObjects is a killer feature, I think it's the
stronger argument against grabbing one from the internet.
Yeah, I'd say let's go with Anthony's stuff. I'll rebase the encoder on
top of it soonish (I still think it's best if JSON
On Sat, 17 Oct 2009 11:01:33 +0100
Vincent Hanquez wrote:
> Anthony Liguori wrote:
> > Paolo Bonzini wrote:
> >> On 10/16/2009 11:37 PM, Anthony Liguori wrote:
> >>>
> >>> I already am :-) Stay tuned, I should have a patch later this
> >>> afternoon.
> >>
> >> Was it a race? (Seriously, sorry
Anthony Liguori wrote:
Paolo Bonzini wrote:
On 10/16/2009 11:37 PM, Anthony Liguori wrote:
I already am :-) Stay tuned, I should have a patch later this
afternoon.
Was it a race? (Seriously, sorry I didn't notice a couple of hours
ago).
This one is ~5% slower than the "Evil" one, but h
On 10/17/2009 03:50 AM, Anthony Liguori wrote:
Paolo Bonzini wrote:
On 10/16/2009 11:37 PM, Anthony Liguori wrote:
I already am :-) Stay tuned, I should have a patch later this afternoon.
Was it a race? (Seriously, sorry I didn't notice a couple of hours ago).
This one is ~5% slower than th
21 matches
Mail list logo
