Would you care to add some tests to the unit test to check for these bugs?
Otherwise, I'll do that when I apply these patches.
On Mon, Oct 20, 2008 at 2:13 PM, <[EMAIL PROTECTED]> wrote:
>
> Sorry, I did some reading, and this should the format I send patch in:
>
>
> Index: src/google/protobuf/i
Oh, and thanks for catching these!
On Mon, Oct 20, 2008 at 2:38 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Would you care to add some tests to the unit test to check for these bugs?
> Otherwise, I'll do that when I apply these patches.
>
>
> On Mon, Oct 20, 2008 at
y
> default?
>
>
>
> On Sep 30, 1:45 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > Just before building the 2.0.2 release candidate, I submitted a change to
> > make static linking the default for the protobuf libraries under MSVC.
&
Yeah, protocol buffers were designed for servers where we often have absurd
binary sizes already and don't mind that much. I'm certainly open to the
idea of creating a stripped-down implementation -- though this isn't
something I'd have time to work on myself.
It might also help to look for uses o
For the first case, the problem is that the build is trying to run protoc as
part of the build process, and it's trying to use the cross-compiled protoc.
I think you can fix this by editing src/Makefile.am at line 201 to change
this:
unittest_proto_middleman: protoc$(EXEEXT) $(protoc_inputs)
./$
You could always have your class implement ZeroCopyInputStream and *contain*
an implementation of CopyingInputStream, like:
class MyStream : public ZeroCopyInputStream {
public:
MyStream();
virtual ~MyStream();
CopyingInputStream* AsCopyingInputStream() {
return ©ing_stream_
Yeah, Frank's approach is the one I'd use.
I did not add a Flush() because I was worried that its meaning would be
completely ambiguous. For example, when you flush a stream which is writing
to disk, should it do an fsync() to make sure that the data actually reaches
the physical device before it
I believe this was fixed in 2.0.2. What version are you using?
On Tue, Oct 21, 2008 at 11:21 AM, <[EMAIL PROTECTED]> wrote:
>
> I have a protoc file named UniqueID.proto that is compiled into and
> exported from Communication.dll.
> I have a protoc file named Base.proto that is compiled into and
On Tue, Oct 21, 2008 at 12:13 PM, <[EMAIL PROTECTED]> wrote:
> Would simply changing FileGenerator::GenerateHeader to output the
> dllexport_decl in the forward declaration of BuildDescriptors function
> work?
Yes, that is the fix.
--~--~-~--~~~---~--~~
You recei
There is no built-in support for this, but there's nothing stopping you from
applying whatever compression you want to the serialized data.
On Tue, Oct 21, 2008 at 1:08 PM, GDR <[EMAIL PROTECTED]> wrote:
>
> I noticed the protocol buffers store strings in their uncompressed
> form. Is there any p
[+petar]
I believe this is a known issue with 64-bit systems, and you can ignore it
(it's only the test that is broken).
On Tue, Oct 21, 2008 at 2:40 PM, <[EMAIL PROTECTED]> wrote:
>
> I just ran into some test errors before installing the python tools
> and after installing the protocol buffer l
On Wed, Oct 22, 2008 at 7:23 AM, Niclas Blomgren <
[EMAIL PROTECTED]> wrote:
> Solaris:
>
I'm guessing this was a sparc system, not x86? Was it 32-bit or 64-bit? I
think someone else reported the same problem but we were not able to track
it down.
> Cygwin:
>
Can you include the text of the ac
Google's RPC system is huge and bloated, and designed explicitly for our
hardware and data center configurations. So, I don't think publishing our
protocol would be very helpful, and it would take a lot of work just to
document it properly. I'm not even sure if our protocol makes sense for use
ov
The "Partial" serialize and parse routines actually do something completely
unrelated: they allow the message to be missing required fields. So, that
doesn't help you.
I'm afraid protocol buffers are not designed for storing very large
collections in a single message. Instead, you should be thin
t;, generator->parameter_);
> }
>
> At a quick glance it seems like the code tries to access C:.
> In cygwin however the path to C: is /cygdrive/c.
>
> BR / N
>
>
> --
> *From:* Niclas Blomgren
> *Sent:* den 23 oktober 2008 09:50
> *To:* 'Kenton Varda&#x
We do not provide a pre-compiled library because it is important that you
use a version of the library compiled with the same compiler version which
you will be using with your own code. Even on Windows, different versions
of MSVC have slightly different STL implementations. Since the protocol
bu
>From the command line, you can do:
protoc --decode_raw < data_file
This will give you as much information as can be determined without a type
definition, to give you an idea of what's there. In C++, you can use the
UnknownFieldSet class to parse and inspect a message of unknown type.
On Wed,
STL strings never shrink. When they're cleared, they keep their memory
around for reuse. So, you could take advantage of that to accomplish what
you want by setting all your string fields to values of the maximum size and
then clearing them. For example:
StaticSizeMsg msg;
msg.set_message(st
In general, protocol buffers can be used to encode individual chunks within
a stream, but representing the entire stream as a protocol buffer won't work
very well.
On Thu, Oct 23, 2008 at 8:14 PM, sureshkk <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am looking at a use case where one needs to transf
On Fri, Oct 24, 2008 at 8:34 AM, <[EMAIL PROTECTED]> wrote:
> I have a similar problem... we try to do our own memory management
> for events that we publish/subscribe with some fixed sized pools. I
> don't
> suppose there is a way to pass a block of memory to a message upon
> construction so it
The reasoning for unknown enums being treated as unknown fields goes
something like this:
We cannot simply use an unknown numeric value since many languages do not
allow enum types to represent numeric values other than the set of values
explicitly defined for them. Furthermore, even if they did,
Oh, the implicit default for enums is the first defined value, not zero.
On Fri, Oct 24, 2008 at 3:03 PM, Marc Gravell <[EMAIL PROTECTED]>wrote:
>
> Makes sense - it just seems a little odd that the optional enums don't
> have a valid default...
>
> Marc
> >
>
--~--~-~--~~---
That is, the first value defined in the .proto file. So if you have:
enum Foo {
A = 123;
B = 6;
C = 900;
D = 0;
}
The default is A.
On Fri, Oct 24, 2008 at 5:33 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Oh, the implicit default for enums is the first defined v
Added to my todo list.
On Sat, Oct 25, 2008 at 1:19 AM, Marc Gravell <[EMAIL PROTECTED]>wrote:
>
> Ah! Right. That makes more sense. Could that perhaps be added to the
> language guide "Optional Fields And Default Values"?
>
> Marc
> >
>
--~--~-~--~~~---~--~~
You
Can you give a specific example of a complete protoc command and the error
it produces? protoc should not care about spaces in file names as long as
they are properly quoted.
On Mon, Oct 27, 2008 at 6:49 AM, sdx <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> While trying to invoke the protoc compiler on
It would be pretty easy to write code that serializes or parses java
protocol message objects in JSON format using the protobuf reflection
interface (see the Message and Builder interfaces). I don't know of any
existing implementations, though.
On Sun, Oct 26, 2008 at 2:11 PM, Richard <[EMAIL PRO
The protocol buffer format expects you to remember where the message ends;
it cannot figure out for itself. So, you need to write the size of each
message to your file before you write the message itself.
On Mon, Oct 27, 2008 at 11:42 AM, Amit Gupta <[EMAIL PROTECTED]> wrote:
>
> I have message
[+petar]
On Mon, Oct 27, 2008 at 10:47 AM, andres <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I would like to use protocol buffers in my python code but currently
> the serialization and parsing methods are too slow compared to
> cPickle. I've read several posts stating that this is because the
> pyth
I'm not sure I understand. What would you expect the import line importing
a_pb2 to look like? My understanding is that Python imports are absolute,
not relative to the importing file.
On Sat, Oct 25, 2008 at 7:11 PM, Alan Kligman <[EMAIL PROTECTED]>wrote:
>
> I'm having a problem with protoc w
I don't really have a stake in the design of a protobuf-based RPC format.
However, I'd like to point out that the design philosophy we tend to prefer
at Google is to keep each layer of the system as simple as possible, and
implement orthogonal features using separate layers. Authentication is a
g
00.
>
> I think this is probably worth fixing. The workaround is to do some
> post-processing on the output from protoc, which could get nasty.
>
> On Oct 27, 5:44 pm, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > I'm not sure I understand. What woul
On Tue, Oct 28, 2008 at 6:35 AM, Moonstruck <[EMAIL PROTECTED]> wrote:
>
> you mean we should write the file like this?
> (sizeof a message) | (serialized message) | (sizeof another message)
> | (another serialized message) || so on and so forth
>
> while reading, we'd first read the message s
Ever notice how practically no one uses HTTP auth? :)
On Tue, Oct 28, 2008 at 1:16 AM, Paul P. Komkoff Jr <[EMAIL PROTECTED]>wrote:
>
> On Oct 28, 2:02 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > I don't really have a stake in the design of a proto
On Tue, Oct 28, 2008 at 1:28 PM, Jon Skeet <[EMAIL PROTECTED]> wrote:
> Two issues have arisen:
> 1) (Fairly simple to resolve, probably) - I think it would be worth
> creating a repository of "known" extensions for descriptor.proto.
Or at least a list of who has reserved what field numbers. No
The protoc code is licensed under the New BSD license, which is extremely
permissive. You will have to include a copyright notice but that's about
it. Read COPYING.txt for the full license -- it's quite short.
On Fri, Oct 31, 2008 at 2:30 PM, Marc Gravell <[EMAIL PROTECTED]>wrote:
>
> (probably
The version with a single repeated field (which presumably you expect to
always have size 16) will be slightly more efficient on the wire and
significantly more efficient in-memory (assuming you're using C++).
I think you'll find the single repeated field version more usable, too --
you can actuall
[cc'ing Petar]
On Tue, Nov 4, 2008 at 11:23 PM, DVusBoy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have a couple of questions regarding the Python implementation.
>
> 1. There is a discrepancy between the function signatures of the
> prototype in google.protobuf.message.Message.ListFields(self,
> f
Hi all,
I finally got time to install Fedora 9 and track down the bug that causes
protoc v2.0.2 to crash on that platform. I've submitted a fix to SVN (rev
70). The underlying problem is actually a compiler bug in GCC 4.3.0,
although arguably the code in question was not as robust as it could hav
You would have to define each message in a separate .proto file.
On Thu, Nov 6, 2008 at 1:37 AM, <[EMAIL PROTECTED]> wrote:
>
> Hi guys!
>
> I'm a new user.
>
> Can somebody kindly tell me how do I generate classes in separate
> files (h' and cpp' files for each message)?
>
> Thanks!
> Omer
> >
>
Hi Jeff,
I've read your message a few times now and I have to admit I don't really
understand what you're getting at. Can you give a small example of each of
the approaches you're considering?
On Wed, Nov 5, 2008 at 12:06 AM, codeazure <[EMAIL PROTECTED]> wrote:
>
> Does anyone have any thoughts
ottom line is, there's no definitive answer, and you'll need to weigh the
trade-offs in the context of your application.
On Thu, Nov 6, 2008 at 2:44 PM, codeazure <[EMAIL PROTECTED]> wrote:
>
> On Nov 7, 7:14 am, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > I'v
I just submitted revision 72, which fixes the bug that caused the tests to
crash on 64-bit sparc machines. It turns out DynamicMessage computed some
byte offsets incorrectly leading to alignment problems. The new code should
be more robust.
I'll probably do a 2.0.3 release within the next week or
me any
> trouble then.
>
> Thanks for your support.
>
> BR / N
>
> --
> *From:* Kenton Varda [mailto:[EMAIL PROTECTED]
> *Sent:* den 23 oktober 2008 22:31
>
> *To:* Niclas Blomgren
> *Cc:* protobuf@googlegroups.com
> *Subject:* Re: Make check reports error
>
> Cygwin
The Python implementation currently does not require any non-Python
libraries at runtime. You'll probably have to try it to see if it works on
Symbian, though. :)
On Fri, Nov 7, 2008 at 5:15 AM, Maximilian <[EMAIL PROTECTED]>wrote:
>
> Hi,
>
> Is it possible, to use Protobuf for python on Pytho
I don't know Python very well. Petar, can you verify this is correct? (I
tried it and the tests still pass.)
On Thu, Nov 6, 2008 at 11:43 PM, Pavel Shramov <[EMAIL PROTECTED]> wrote:
>
> In 2.4, 2.5 and 2.6 superclass constructor call don't need self as first
> arg
> but 2.6 raises error if it'
Thanks. Incidentally, I think I submitted a nearly-identical change to SVN
yesterday, but forgot to mention it. :)
On Fri, Nov 7, 2008 at 10:04 AM, Dave Wolfe <[EMAIL PROTECTED]> wrote:
>
> FYI, in case anyone else is stuck using VC++ 7.1, I had to apply the
> patch below to get protobuf 2.0.2
Yes, I believe you. We just have a policy of reviewing all changes. :)
On Fri, Nov 7, 2008 at 11:19 AM, Pavel Shramov <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 07, 2008 at 10:04:27AM -0800, Kenton Varda wrote:
> > I don't know Python very well. Petar, can you verify th
On Fri, Nov 7, 2008 at 5:14 PM, code_monkey_steve <
[EMAIL PROTECTED]> wrote:
>
> After playing with protobuf for the last few months, I've decided that
> it's not quite suitable for my purposes, due to some design decisions
> (which I'm sure seemed the like a good idea at the time). As much as
>
On Mon, Nov 10, 2008 at 9:12 AM, Chris Kuklewicz <[EMAIL PROTECTED]>wrote:
> BUG * The user-defined options have the wrong value for some 32 bit
> value.
Looks like you figured this out. Yeah, the idea is that 32-bit varints and
64-bit varints should always be compatible. So, if you write a 32
I don't see anything wrong with your code. What kind of error are you
seeing? Are you sure that the bytes you passed in to the parser on the
receiving end are exactly the same as what came out of the serializer on the
sending side?
On Sun, Nov 9, 2008 at 6:40 AM, <[EMAIL PROTECTED]> wrote:
>
>
t_name( this->name->GetValue() );
> LoginInfos->set_password( this->password->GetValue() );
>
> std::string Tmp;
> Msg.SerializeToString(&Tmp);
>
> this->fParent->Socket.Send( Tmp.c_str(), sizeof( Tmp.c_str() ) );
>
> On 10 Nov, 20:40, Kenton Varda <[EMAIL
On Tue, Nov 11, 2008 at 7:46 AM, ChJees <[EMAIL PROTECTED]> wrote:
> I managed to solve my problem now. I used the blah.Bytesize() function
> instead of sizeof( blah.c_str() ) when sending the message size :3.
Ah, yes, don't use c_str() with serialized protobufs because they may
contain zeros be
On Tue, Nov 11, 2008 at 10:41 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Either blah.ByteSize() or blah.size() would be valid things to use.
>
I mean, message.ByteSize() or str.size().
--~--~-~--~~~---~--~~
You received this message because you ar
I actually don't know. You'd have to try compiling it and running the tests
and tell me what happens.
On Mon, Nov 10, 2008 at 9:43 PM, mpprasad <[EMAIL PROTECTED]> wrote:
>
> Is the Protocol Buffers supports WinCE platform?
>
> Thanks
> Prasad.
> >
>
--~--~-~--~~~---
You don't have to worry about the uninterpreted_option field. It's an
internal implementation detail of the parser. You should pretend it isn't
there.
The comment is saying that the uninterpreted_option field must have the name
"uninterpreted_option" in all *Options messages because the parser us
Sorry, the docs are not actually stored in HTML form. They are EZT
templates, so if we did make them downloadable you'd have to run an EZT web
server to view them. The best we could do otherwise would be to spider them
ourselves. So I don't think there's much worth doing here.
On Wed, Nov 12, 2
You're using the java_multiple_files option, I take it?
The outer class is still necessary to store the file's descriptor and any
top-level extension definitions. I suppose the descriptor could be moved
into the first class defined in the file but it will take some work and
seems like a low priori
BTW, you didn't have to rename your .proto file. You could have just used
the java_outer_classname to make it produce a different class name.
On Thu, Nov 13, 2008 at 11:40 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> You're using the java_multiple_files option, I take it?
&
I agree, the setters should either throw NPE or should treat setFoo(null)
the same as clearField().
On Thu, Nov 13, 2008 at 7:39 AM, bivas <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I'm using the Java output feature of protobuf for my app.
> I found that protobuf doesn't handle null values as well as i
Copying strings by value is rather inefficient, so the idea is to discourage
it.
That said, there is a patch outstanding that implements
a SerializeAsString() method which does what you want.
On Fri, Nov 14, 2008 at 11:07 AM, <[EMAIL PROTECTED]> wrote:
>
> Can we please have a ToString that retu
Yes, the compiler fix was pushed upstream.
On Sat, Nov 15, 2008 at 5:38 AM, Greg Copeland <[EMAIL PROTECTED]> wrote:
>
> On Nov 5, 10:39 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > I finally got time to install Fedora 9 and track down the bug th
I think LD_LIBRARY_PATH is the magic environment variable.
You could also try installing to /usr instead of /usr/local by invoking
configure like:
./configure --prefix=/usr
On Sat, Nov 15, 2008 at 10:07 AM, <[EMAIL PROTECTED]> wrote:
>
> I apologize if this is a stupid question, but I have not
I would call it a ListBuilder or a RepeatedFieldBuilder, but it sounds like
a reasonable idea.
On Sun, Nov 16, 2008 at 5:40 AM, bivas <[EMAIL PROTECTED]> wrote:
>
> use case (written in Java):
>
> public class MyService {
>
>private final ServiceDAO serviceDAO;
>
>// constructor,
Yes, use the TextFormat class to do this from code, or use protoc's --encode
or --decode option to do it from the command line. For example:
protoc myproto.proto --decode=MyMessageType < encoded_data >
human_readable.txt
Replace --decode with --encode to convert back from text to binary. You can
Good news: There was a patch for this submitted to the internal version of
the code which should make its way to SVN today or tomorrow, and will be in
the 2.0.3 release.
On Wed, Nov 19, 2008 at 1:29 AM, Jerry Cattell <[EMAIL PROTECTED]>wrote:
>
> I'm trying to use a custom EnumValueOption:
>
>
>
I'm not sure I understand. There's nothing stopping you from spreading your
definitions out among multiple .proto files which import each other, and
there's nothing stopping you from exporting multiple services from a single
server. You'll need to design a protocol that allows it, but protocol
bu
y a server when constructing an
RpcChannel.
On Wed, Nov 19, 2008 at 5:06 PM, codeazure <[EMAIL PROTECTED]> wrote:
>
> On Nov 20, 7:58 am, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > I'm not sure I understand. There's nothing stopping you from spreading
> your
imes, but the overview of how it works hasn't clicked.
>
> Thanks,
> Jeff
>
> On Nov 20, 12:54 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > RpcController objects are per-request, not per-server or per-service.
> For
> > every RPC request you make, you
This is a bug that has been fixed in SVN and will be fixed in the 2.0.3
release, which should happen soonish. If you don't use DynamicMessage you
don't need to worry about it.
On Thu, Nov 20, 2008 at 11:34 AM, Nimisha Mishra <
[EMAIL PROTECTED]> wrote:
> Hello,
>
>
>
> I have installed protocol
I just committed SVN revision 76 which integrates a bunch of changes from
our internal codebase (see below). 2.0.3 will probably be released next
week.
protoc
* Enum values may now have custom options, using syntax similar to field
options.
* Fixed bug where .proto files which use custom option
added for this:
> http://code.google.com/p/protobuf/issues/detail?id=57
> and a potential patch was submitted.
>
> Any chance for this in 2.0.3?
>
> On Nov 13, 1:43 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > I agree, the setters should either throw NPE or should treat setFo
Are you building the Java code using Maven or by some other method?
On Tue, Nov 25, 2008 at 6:02 AM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
>
> Hi,
> I down loaded protobuf-2.0.2.zip, installed mvn onto Ubuntu 8.04
> installation with OpenJDK Java.
>
> The c++ build is fine, but I get th
cc'ing Dave Benson, who maintains the only C port I'm aware of.
On Tue, Nov 25, 2008 at 8:54 AM, <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm using the protocol buffers package for c. It's very useful and
> handy. However I've encountered a problem when trying to use a message
> with a nested repea
I just put a release candidate here:
http://groups.google.com/group/protobuf/files
Test and tell me what's broken.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send
How are you initializing the listOfCapacityTypes pointer?
On Mon, Dec 1, 2008 at 5:02 PM, Grohotanie <[EMAIL PROTECTED]> wrote:
>
> When I use the following code with protobuff listOfCapacityTypes:
>
> int dataFile = open("capacityTypes", O_RDONLY);
> taskingElement_sim::CapacityTypes listOfCap
I was waiting for Petar to verify, then forgot. I just poked him and he
said it looks good so I'm submitting this.
On Mon, Dec 1, 2008 at 6:08 PM, Alek Storm <[EMAIL PROTECTED]> wrote:
>
> How come the patch hasn't made it into the release yet? I'm still
> seeing the problem in 2.0.3rc1.
> >
>
metaclass bases
type.__new__(X): X is not a type object (str)
On Mon, Dec 1, 2008 at 6:23 PM, Petar Petrov <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 7, 2008 at 10:04 AM, Kenton Varda <[EMAIL PROTECTED]> wrote:
>
>> I don't know Python very well. Petar, can you ve
Sorry, I'm dumb and made the change in the wrong place. :)
On Mon, Dec 1, 2008 at 6:29 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Unfortunately, the change doesn't work:
> Traceback (most recent call last):
> File "setup.py", line 131, in ?
>
Fix submitted. Sorry for the delay and false alarm.
On Mon, Dec 1, 2008 at 6:32 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Sorry, I'm dumb and made the change in the wrong place. :)
>
>
> On Mon, Dec 1, 2008 at 6:29 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
&
On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED]> wrote:
> message Person
> java_implement_interface = com.domain.Name;
> required string name;
> required int32 age;
> }
>
More precisely:
message Person {
option java_implement_interface = "com.domain.Name";
required string name
An instance of a message can be used like a factory:
Message prototype = Person.getDefaultInstance();
Message message = prototype.newBuilderForType().mergeFrom(data).build();
It doesn't have the generics-based type-safety, though.
On Mon, Dec 1, 2008 at 10:11 PM, Trustin Lee <[EMAIL PROTECTED]> w
PROTECTED]> wrote:
> Kenton Varda wrote:
>
>> On Mon, Dec 1, 2008 at 6:46 PM, aantono <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote:
>>
>>message Person
>> java_implement_interface = com.domain.Name <http://com.domain.Name>;
>>
On Tue, Dec 2, 2008 at 8:11 AM, Chris <[EMAIL PROTECTED]> wrote:
> Will "unittest_custom_options.proto" by updated in 2.0.3 to test
> EnumValueOptions, or will there be a new proto file?
Apparently the person who implemented this only put a test in
parser_unittest.cc, not in unittest_custom_opti
Cool! Can you send this to me and Petar (cc'd) via codereview.appspot.com?
On Tue, Dec 2, 2008 at 1:22 AM, Alek Storm <[EMAIL PROTECTED]> wrote:
> There was already a remove() method for repeated scalars, but not for
> composites. I added one without any difficulty. Did I miss something? In
>
ce, which may be very useful for doing
> things like streaming messages. Also, protocol-buffer fields could be
> used outside the context of protocol-buffer messages, which may or may
> not be valuable. Does this capability already exist?
>
>
>
> Thanks,
> Shane
>
>
>
C++ compatibility matters because eventually we want to be able to generate
Python code which just wraps C++ code for efficiency. C++ isn't garbage
collected, so append() can't easily be implemented in this case without
having ownership problems. Slice assignment has the same problem.
Also note t
red file: ../src/google/protobuf/descriptor.proto
>
> On 11月26日, 上午10时32分, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > I just put a release candidate here:
> http://groups.google.com/group/protobuf/files
> >
> > Test and tell me what's broken.
> >
>
--~--~-~
(And I accidentally replied only to Alek...)
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
> those be wrappers around C++, while let object handling (reflection.py and
> friends) be pure-python?
On Wed, Dec 3, 2008 at 12:02 AM, Alek Storm <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 11:17 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
>
>> Well, the generated serializing and parsing code in C++ is an order of
>> magnitude faster than the dynamic (refle
ed" option for repeated fields? Is this
> still intended for a future protobuf release? I searched for "packed"
> and the last post in this group about it was in August.
>
> many thanks!
> Gregg
>
> On Jul 8, 10:13 am, "Kenton Varda" <[EMA
tation falls short, the next step would be to fill out the
> > > contributor agreement [1] and we'll integrate the two implementations.
> >
> > > In any event, I'll send you an email as soon as something is publicly
> > > available. Sound good?
> >
&g
iley <[EMAIL PROTECTED]> wrote:
> > On Dec 2, 10:49 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> >
> > > C++ compatibility matters because eventually we want to be able to
> generate
> > > Python code which just wraps C++ code for efficiency. C++ isn
if thread safety wasn't an issue?
>
> -dave
>
> On Dec 3, 2:41 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > Ehhh... Reference counting is slow (assuming it needs to be
> thread-safe),
> > and I think even adding it as an option would add an excessive amount o
Hi all,
There have been a lot of small patches in the last few days, and I'm
paranoid, so I decided to create a second release candidate for 2.0.3, which
you can find here as usual:
http://groups.google.com/group/protobuf/files
Assuming there aren't any problems I'm going to do the actual release
This is covered on the "techniques" page:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
On Thu, Dec 4, 2008 at 5:22 PM, <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I did not see any mechanism for identifying received message type.
> Is that something we need to handle by mes
It's quite easy to write a helper function that reads/writes delimited
messages (delimited by size or by end tag).
For example, here's one for writing a length-delimited message:
bool WriteMessage(const Message& message, ZeroCopyOutputStream* output) {
CodedOutputStream coded_out(output);
retu
http://code.google.com/p/protobuf/downloads/list
Hopefully less buggy than last time. :)
protoc
* Enum values may now have custom options, using syntax similar to field
options.
* Fixed bug where .proto files which use custom options but don't actually
define them (i.e. they import
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 misunderstood. The C++ parsers generated by protoc
>> (with optimize_for = SPEED) are an orde
Please use the Makefile to build. In this case, your problem is that you
are not linking addressbook.pb.cc into the binary.
On Sun, Dec 7, 2008 at 11:07 AM, Rodrigo_Dias_Ferreira
<[EMAIL PROTECTED]>wrote:
>
> Hi,
>
> I was trying to run the example which it comes with the src of the
> protobuf (
On Sun, Dec 7, 2008 at 3:45 AM, nightwalker leo <[EMAIL PROTECTED]>wrote:
>
> when I try to parse an addressbook file which has 2^20 records of
> person , my program complains like this:
> libprotobuf WARNING D:\protobuf-2.0.2\src\google\protobuf\io
> \coded_stream.cc:459] Reading dangerously larg
101 - 200 of 1581 matches
Mail list logo
