I think what you want is lazy parsing, which unfortunately isn't available
yet. You could always read bytes off the stream in chunks, or write your
own CodedInputStream to skip to the end of each message every time it sees a
length.
Alek
On Fri, Jul 17, 2009 at 8:13 PM, Alex Black wrote:
>
> W
Google uses its own internal RPC implementation, and I don't think we can
endorse a particular third-party one as better than the others. I'd tell
you which one I personally found most beneficial, but I have no experience
with any of them.
Cheers,
Alek
On Wed, Jul 1, 2009 at 10:18 AM, J.V. wrot
s/
>
> (this is one of many unofficial independent implementations - not
> google's; don't blame them ;-p)
>
> Marc
> >
>
--
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
>
> Instead, it would be relatively inexpensive to calculate just the
> number of following elements that make the embedded message before
> starting to encode it.
>
> This would enable streaming of PB or encoding and sending the elements
> right as they are encoded.
>
&g
ersions.
>
> I would like to study the matter a little more, preferably not directly
> related to PB, but in a neutral background (even XML could be).
>
> Can enyone send some reference about this topic?
>
> Thanks,
> Alain Mouette
>
> >
>
--
Alek Storm
-
ch gets keyed to 1010, or decimal 10, when encoded, then
followed by the field's value. And who knows, that value could contain
newlines :)
--
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&qu
ld be faster anyway,
since it encodes directly to native types.
--
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@goog
On Jan 27, 1:17 pm, Topher Brown wrote:
> I'm not writing a finished program- I'm trying to write a tool for our
> use while we are developing. We are working with large arrays (stored
> in protobuf) in C++ and want to plot them, using various python tools,
> while we are developing- to find bugs
I'd love to help, but I need more detail about exactly what each
program does. Is the C++ the backend, while Python is the frontend?
What are any inputs/outputs? Because right now I don't see any need
to do inter-process communication, or have separate processes at all -
it seems like one just n
into FIFOs. However, if they don't have to be independent processes,
you could try calling the Python code from C++ and passing message
objects between them.
Cheers,
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
I agree with Shane. Wrapping the data is a great way to separate the
business logic from the data. Actually, if you're using Python,
you're not allowed to subclass generated message types (though there's
no 'sealed' modifier) - it screws with the metaclass machinery.
Cheers,
Alek
--~--~
> Right. That way we can use the "length-delimited" wire type for this, so
> old parsers will be able to skip it.
Cool, that's exactly what I was thinking.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol B
Just to clarify (because I can't find this addressed anywhere else),
the length delimeter for repeated fields will be the byte count of the
whole array, not the count of its elements, right? So an array of 3
fixed32's would have length 12, not 3.
--~--~-~--~~~---~--~--
I'm for changing it. Command line flags get deprecated in software
all the time.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.co
On Jan 9, 1:32 am, chongyc wrote:
> I defined proto by following .
>
> message Ch {
> required int32 offset = 1;
>
> }
>
> message Foo {
> required string cmd = 1;
>
> extensions 1000 to max;
>
> }
>
> message Bar {
> extend Foo {
> required Ch ck = 1000;
> }
>
> }
>
> Then I
On Jan 7, 8:18 pm, Kenton Varda wrote:
> IMO, there's not much reason to use the protobuf wire format unless you
> explicitly intend for some users to read/write the format using actual
> protocol buffers.
Not entirely sure what you mean. This will probably get a lot clearer
once we get Mike's
I thought they were kind of like an extension range. I guess I see
why now.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To
This seems almost too insignificant to bring up, but why aren't
kFirstReservedNumber and kLastReservedNumber a
Descriptor::ExtensionRange?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To p
Right, I guess I didn't explain why they don't work in this case.
Generating .proto files from C++ headers is obviously the reverse of
the normal sequence. In the PB method of versioning, the
original .proto is written and deployed. The next version then writes
an extension of the original. If
Mike, what exactly are you trying to accomplish? Do you just want to
persist a C++ class? If so, you don't need to generate a .proto file,
because other languages won't need to read it, and you know your own
encoding layout. So you could still use the Protocol Buffers wire
format.
--~--~---
On Jan 7, 4:21 pm, Kenton Varda wrote:
> SWIG translates C/C++ APIs into other programming languages. Protocol
> Buffers is not a programming language, so I don't see the analogy. What
> would be the protocol buffer equivalent of a C function or a C++ class?
Technically, SWIG generates wrapper
Thanks! This is great. Should come in handy for my Javascript
implementation.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
On Fri, Dec 19, 2008 at 1:17 PM, Petar Petrov wrote:
> Looks like we are still keeping append, insert, remove and __setitem__?
>
Forgot those. Okay, fixed in the latest patch.
Cheers,
Alek Storm
--~--~-~--~~~---~--~~
You received this message because y
On Sat, Dec 13, 2008 at 5:09 PM, Petar Petrov wrote:
> On Mon, Dec 8, 2008 at 5:36 PM, Alek Storm wrote:
>
>> Okay, then we just need to cache the size only during serialization. The
>> children's sizes are calculated and stored, then added to the parent's
>>
On Mon, Dec 8, 2008 at 1:16 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 6, 2008 at 1:03 AM, Alek Storm <[EMAIL PROTECTED]> wrote:
>
>> Is it really that useful to have ByteSize() cached for repeated fields?
>> If it's not, we get everything I menti
On Sat, Dec 6, 2008 at 12:42 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 5, 2008 at 10:59 PM, Alek Storm <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Dec 3, 2008 at 5:32 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
>>
>>> Sorry, I think you
omposite to two different repeated composite
> fields. The .add() method guarantees that this never happens.
>
Is there anything wrong with having a list of parents? I'm guessing I'm
being naive - would speed be affected too much by that?
> I think protobuf's repeated comp
Hi Kenton and Petar,
Sorry I haven't been able to reply for a few days; I've been so
swamped this week. Hopefully I'll be able to conjure up an
intelligent reply tomorrow :)
Cheers,
Alek Storm
--~--~-~--~~~---~--~~
You received this message
(Okay, back on track)
On Tue, Dec 2, 2008 at 11:17 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 11:08 PM, Alek Storm <[EMAIL PROTECTED]> wrote:
>
>> I would think encoding and decoding would be the main bottlenecks, so
>> can't thos
it doesn't even have to be useful for repeated composites. The
fact that repeated scalars have it means it's automatically included for
repeated composites, because they should have the exact same interface.
Polymorphism is what we want here.
Cheers,
Alek Storm
--~--~-~--~~
if you can't do
something with a list simply based on the types it contains. This is why I
included a comment in the add() method saying it should be deprecated - the
functionaly is superseded by append(), and there's no corresponding method
in the repeated scalar class.
Cheers,
Alek Storm
'm not sure how useful it would be - if you're streaming a
message, you just need (tag, value) pairs, which is what a full
message is anyway, so there's no extra overhead. However, streaming
messages definitely needs to be implemented.
Cheers,
Alek Storm
--~--~-~--~~---
ssage, you just need (tag, value) pairs, which is what a full
message is anyway, so there's no extra overhead. However, streaming
messages definitely needs to be implemented.
Cheers,
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are s
't on the wiki, so I can't add anything about this. Are there
plans to move it to the wiki, by any chance?
Thanks,
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" gro
I'm getting this when running the Python test suite in r81:
==
FAIL: testReadScalars
(google.protobuf.internal.decoder_test.DecoderTest)
--
Traceback (most recen
How come the patch hasn't made it into the release yet? I'm still
seeing the problem in 2.0.3rc1.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobu
3}/
charEscape ::= /\\[abfnrtv\\\?'"]/
Though it might have changed by now.
--
Alek Storm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send em
On Sep 22, 5:23 am, Chris <[EMAIL PROTECTED]> wrote:
> Many things are wrong. I stopped using the EBNF that was posted to the
> list when making my lexer.
>From your comments below, I can see you're using an old version.
There's a warning hidden deep in my original post on that thread to
scroll
38 matches
Mail list logo
