Re: ProtocolBuffer crash before program execution

gt; when linking, instead of random crash when executing). > > Thanks for the quicks answer. > Regards, > rodrigob. > > On Jun 30, 1:01 am, Kenton Varda wrote: > > Sorry, I don't see what the problem could be. > > Make sure that you are compiling libprotobuf and you

Re: Java jar - downloadable? or only compilable?

In order to *use* the Java implementation, you need to build that same C++ code -- the protocol compiler. The Java protobuf runtime is mostly useless without it. However, you can get a prebuilt copy of protoc.exe for windows here: http://code.google.com/p/protobuf/downloads/detail?name=protoc-2.1

Re: output streams

You have to flush the CodedOutputStream. You should just do this instead: byte[] data = person.build().toByteArray(); On Thu, Jul 2, 2009 at 12:44 AM, J.V. wrote: > > I'm trying to get the following to work but nothing is being written to > the output stream. > any ideas? > >private void

Re: encode to binary stream example

Just call writeTo(): void writeToStream(Message message, OutputStream out) { message.writeTo(out); } On Thu, Jul 2, 2009 at 7:47 AM, J.V. wrote: > > Which class in the ProtoBuf Java api would be used to encode to a binary > stream? > Is there a short example or tutorial on how to encode (usi

Re: Protoc and line endings

Protoc treats \r as plain whitespace, so it should have no problem with Windows line endings. I just tested this and sure enough, protoc works fine with .proto files that use Windows-style line endings. Mac pre-OSX line endings (\r with no \n) won't work if the file contains any comments. What ki

Re: output streams

> if desired. > > thanks > > jrv > > Kenton Varda wrote: > > You have to flush the CodedOutputStream. > > > > You should just do this instead: > > > > byte[] data = person.build().toByteArray(); > > > > On Thu, Jul 2, 2009 at 12:44 AM, J.

Re: Protoc and line endings

protoc actually expects its input to be UTF-8 (though non-ASCII characters are only allowed in default values for string fields). It just doesn't like the BOM. On Thu, Jul 2, 2009 at 12:44 PM, Marc Gravell wrote: > > My bad... it isn't the line endings - it is the UTF8 BOM; when I > switched one

Re: Protoc and line endings

If you want to write up a patch to recognize a UTF8 BOM and ignore it, go ahead. You can just modify the Tokenizer class to recognize and discard a BOM appearing at the beginning of the input. On Thu, Jul 2, 2009 at 1:31 PM, Marc Gravell wrote: > > OK... is there any way it /could/ silently ign

Re: ThirdPartyAddOns

Done and done. I didn't know protobuf-net had RPC or I would have listed it on the RPC implementations page some time ago. On Thu, Jul 2, 2009 at 1:47 PM, Marc Gravell wrote: > > I notice the replacement ThirdPartyAddOns page; can you please also > include protobuf-net in the RPC section? It pro

Re: ThirdPartyAddOns

What's the difference between all these links? On Thu, Jul 2, 2009 at 4:08 PM, Chris Kuklewicz wrote: > > Kenton, > > Could you change the link on the > > http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns > > page for Haskell from > > http://darcs.haskell.org/packages/protocol-buffers/ > >

Re: error when using nested and packed in python

Yeah, I think it's broken. In reflection.py there is a line: return decoder.Position() - content_start I think (untested) that it should actually be: return decoder.Position() - initial_position I have no idea how this got past testing and I have asked the people responsible to fix it. Surpr

Re: libprotobuf.lib, 29mb?

On Thu, Jul 2, 2009 at 5:33 PM, Alex Black wrote: > I'm on windows, using Visual Studio 2008 SP1, compiling a Release x64 > build of libprotobuf. The lib file is 29,570KB big, is that > expected? I was going to say "no way", but sure enough, the 32-bit release build is 18,154k, so 64-bit could

Re: how to use protobuf with Google App Engine?

You'd have to ask the AppEngine people. Someone from that team submitted the input_stream.py change. The problem is that both protocol buffers and AppEngine place themselves in the "google" package. Protocol Buffers has, from day one, declared the package as a "namespace package" using setuptools

Re: Don't understand the purport of default values

The purpose of default values is to define what the getter methods for those fields return when the field is not set. This is really the only purpose. We do not serialize default values because it would be a waste of space. On Sat, Jul 4, 2009 at 1:47 PM, Zl D wrote: > > Hi, > I define a messag

Re: GoogleOnceType showing up as a memory leak

Yes, this is a known bug resulting from the fact that I developed the shutdown code on Linux rather than Windows -- this bug only exists on Windows. It's still not a real leak unless you are dynamically loading and unloading the protobuf library as a DLL. In any case, this has been fixed in SVN a

Re: zero_copy_stream_unittest.cc doesn't compile with msvc 7.1/2003

This is with MSVC 7.1? Which version of Visual Studio does that correspond to? I can never keep these straight. On Mon, Jul 6, 2009 at 7:27 AM, Cosmin Cremarenco < cosmin.cremare...@gmail.com> wrote: > > Hi > > When compiling zero_copy_stream_unittest.cc from the last version > 2.1.0 msvc compl

Re: Parser fails silently if first numeric field has value zero.

This is most likely a bug in your code -- you probably aren't transmitting the message correctly. Please make sure that the bytes you give to the protobuf parser on the receiving end are exactly the same bytes that were produced by the serializer at the sending end -- both the size and contents mu

Re: zero_copy_stream_unittest.cc doesn't compile with msvc 7.1/2003

What's the _MSC_VER for that version? On Mon, Jul 6, 2009 at 10:37 AM, Cosmin Cremarenco < cosmin.cremare...@gmail.com> wrote: > > It is Visual Studio 2003 - Version 7.1.6030. > I think the .1 minor comes from the installation of sp1 over 7.0 > > Cosmin > > On Jul

Re: Maximizing fixed size buffer without losing the whole message

Sorry, there is no magic solution here. The best suggestions I have are either: 1) Use SerializeToString() instead, which will always allocate a string large enough to hold the message. 2) Build your message, then call ByteSize(), and if it is too large, remove some fields and try again. Once it

Re: Protocol buffers extensions getting lost on the way?

The javadoc for ExtensionRegistry discusses the reasons why we didn't take the auto-populated approach as was done in C++. In fact, I sort of wish we had done something like ExtensionRegistry in C++ as well, as I get a lot of messages from people who are confused why their program behaves differen

Re: zero_copy_stream_unittest.cc doesn't compile with msvc 7.1/2003

OK, I'll make the #if check the version number in the next release. On Tue, Jul 7, 2009 at 12:15 AM, Cosmin Cremarenco < cosmin.cremare...@gmail.com> wrote: > > It is 1310 > > On Jul 6, 7:49 pm, Kenton Varda wrote: > > What's the _MSC_VER for that version? &

Re: Heuristic for getting a particular message type from a FileDescriptorSet

FileDescriptorSet is itself a protocol message, so we can't add methods to it. One way you might make things simpler is by just adding *all* the FileDescriptorProtos in the set to the DescriptorPool, then use pool->FindMessageTypeByName(). This is actually more correct if some or all of the files

Re: Howto build protobuf not as library, but directly linking object files?

You can skip the "compiler" subdirectory and anything which has "test" in the name. You will need to provide your own config.h -- if you use MSVC then you can copy the one in the vsprojects directory. On Thu, Jul 9, 2009 at 11:44 AM, bart van deenen wrote: > > Hi this question is stupid I know :

Re: intermittent issue with encode (version 2.0.3)

Run in a debugger and set a breakpoint at wire_format_inl.h:289. On Thu, Jul 9, 2009 at 1:56 PM, Rizzuto, Raymond wrote: > I think I have an error in my code (C++) that only occurs when I have > multiple threads, and a lot of message volume. Even then, I can run the > same test many times, but

Re: intermittent issue with encode (version 2.0.3)

----- > > *From:* Kenton Varda [mailto:ken...@google.com] > *Sent:* Thursday, July 09, 2009 5:02 PM > *To:* Rizzuto, Raymond > *Cc:* protobuf@googlegroups.com > *Subject:* Re: intermittent issue with encode (version 2.0.3) > > > > Run in a debugger and set a breakpoin

Re: intermittent issue with encode (version 2.0.3)

{ > > if (it != errors.begin()) > > error += ", "; > > error += *it; > > } > > throw SPException(error.c_str()); > > } > > > > It might not be somethi

Re: intermittent issue with encode (version 2.0.3)

Sorry, I think I misread your message. You just want there to me a method like IsInitialized() that you can call to validate UTF-8 stuff. I'll think about that. On Thu, Jul 9, 2009 at 2:32 PM, Kenton Varda wrote: > This is something you can do in your own code -- just call your va

Re: intermittent issue with encode (version 2.0.3)

hat make that safe. I > don’t know if that is something that can be relied on in all compilers, > however. > > > > Ray > > > -- > > *From:* Kenton Varda [mailto:ken...@google.com] > *Sent:* Thursday, July 09, 2009 5:08 PM > > *To:* Rizzuto, Raymond > *Cc:* protobuf@g

Re: Howto build protobuf not as library, but directly linking object files?

On Fri, Jul 10, 2009 at 3:12 AM, bart van deenen wrote: > However, when I try to build my application with -L"path/to/ > libprotobuf.a" I get hundreds of linker errors, complaining about > undefined references to any of the google protocol functions. You need to use: -Lpath/to/lib/dir -lproto

Re: intermittent issue with encode (version 2.0.3)

happen before I’ve spun off multiple threads? Currently I spin up threads, > which then start making calls to fill in and then encode google > protobuffers. > > > ------ > > *From:* Kenton Varda [mailto:ken...@google.com] > *Sent:* Thursday, July 09,

Re: Protobuf "Lite"

I've pretty much finished the refactoring. Ideally I'd like to get it into SVN this week, but realistically it will probably happen next week or the week after since I will be out of town from the 16th to the 22nd. An official release will hopefully follow a week or two after that. Stay tuned to

Re: DescriptorPool in python

I don't think that's currently implemented in Python, unfortunately. On Mon, Jul 13, 2009 at 8:28 AM, Ferenc Szalai wrote: > > Hi > > There is any plan to implement DescriptorPool class in python? > Especially, I missing easy way to transform FileDescriptorProto to > Descriptor in python. > > --

Re: Compiling on AIX 5.3 using xlC 3.55 compiler

gcc still has hash_map > as well, but it throws a deprecated warning. > > Might not be a terrible idea to go ahead and shift to unordered_map and > then put in a mapping/typedef for hash_map if something doesn't have u_m? > > (Kenton - would you be interested in a patch doing

Re: Compiling on AIX 5.3 using xlC 3.55 compiler

And yes, I'd love a patch. :) On Mon, Jul 13, 2009 at 5:22 PM, Kenton Varda wrote: > google/protobuf/stubs/hash.h already contains some hacks for hash_map. To > support unordered_map, all we'd have to do is add another hack there which > defines hash_map to be a subcla

Re: Performance: Sending a message with ~150k items, approx 3.3mb, can I do better than 100ms?

Speed varies a lot depending on the precise content. My benchmarks generally show serialization performance somewhere between 100 MB/s and 1 GB/s, whereas you're seeing 33MB/s, but my benchmarks do not include any kind of I/O. Maybe you could separate the serialization step from the I/O (by seria

Re: Performance: Sending a message with ~150k items, approx 3.3mb, can I do better than 100ms?

Oh, I didn't even know you were including composition in there. My benchmarks are only for serialization of already-composed messages. But this still doesn't tell us how much time is spent on network I/O vs. protobuf serialization. My guess is that once you factor that out, your performance is pr

Re: Performance: Sending a message with ~150k items, approx 3.3mb, can I do better than 100ms?

currentBatchSize++; > >if ( currentBatchSize == BatchSize ) >{ >// Flush out this batch >//stream << getNeighborsResponse; >getNeighborsResp

Re: Cannot resolve InternalDescriptorAssigner?

It looks like your protobuf library and protocol compiler binary are from different releases. This won't work. Please make sure both are upgraded to 2.1.0, the latest release. On Tue, Jul 14, 2009 at 8:52 AM, Michael Stapleton < mike.staple...@echostar.com> wrote: > > Hi All, > I am using relea

Re: com.google.protobuf.Descriptors.FileDescriptor.InternalDescriptorAssigner cannot be resolved to a type

Answered in the other thread -- you need to use matching protoc and protobuf library versions. On Tue, Jul 14, 2009 at 2:57 PM, Mike wrote: > > I am getting the error > > com.google.protobuf.Descriptors.FileDescriptor.InternalDescriptorAssigner > cannot be resolved to a type > > when Eclipse com

Re: Performance: Sending a message with ~150k items, approx 3.3mb, can I do better than 100ms?

data being sent is: 3,959,368 bytes in 158,045 messages > (composed in batches of 1000). > > - Alex > > -- > *From:* Kenton Varda [mailto:ken...@google.com] > *Sent:* Tuesday, July 14, 2009 3:26 AM > *To:* Alex Black > *Cc:* Protocol Buffers >

Re: Compiling on AIX 5.3 using xlC 3.55 compiler

t; ".google.protobuf.UninterpretedOption" is not defined. > libprotobuf ERROR google/protobuf/descriptor.cc:2218] > google.protobuf.EnumOptions.uninterpreted_option: > ".google.protobuf.UninterpretedOption" is not defined. > libprotobuf ERROR google/protobuf/descriptor.

Re: assertion crash with debug build on windows

Did you make sure to compile your debug build against a debug build of libprotobuf? MSVC fails miserably when trying to mix and match debug vs. release, apparently because the STL classes have different representations between the two. On Wed, Jul 15, 2009 at 7:38 AM, Mr Moose wrote: > > Hi the

Re: Writing a router tha can route messages

On Wed, Jul 15, 2009 at 10:56 AM, jasonh wrote: > Foo f = Foo.newBuilder().mergeFrom(...).setCookie(newCookieVal).build > (); There's actually a shortcut for this: the toBuilder() method of the Message interface returns a Builder that is pre-initialized as a copy of that message. --~--~--

Re: GzipOutputStream is slower than gziping the file by hand

Hmm, probably GzipOutputStream is not setting the same compression parameters as gzip itself uses by default. I'm happy to accept a patch fixing this. Does the interface (to GzipOutputStream) currently have a way to control compression parameters? If not, it probably should. On Wed, Jul 15, 200

Re: GzipOutputStream is slower than gziping the file by hand

oks like it chooses > Z_BEST_COMPRESSION (-9 to the gzip command line program) whereas gzip > defaults to -6. I'll work up a patch to pass the compression value > through as another option to the constructor. > > --Pete > > On Jul 15, 4:09 pm, Kenton Varda wrote: > > Hmm

On vacation through July 22nd.

Hi all, I will be on vacation and not checking e-mail through July 22nd. I've asked fellow protobuf dev Jason to help answer questions in the meantime, but if you see a question that isn't answered and you know the answer, please feel free to jump in. (That goes for when I'm not on vacation, too.

Re: Performance: Sending a message with ~150k items, approx 3.3mb, can I do better than 100ms?

If you can find a way to make it faster, please send a patch! :) On Wed, Jul 15, 2009 at 4:46 PM, Alex Black wrote: > Thanks, yes performance seems really good, though I wouldn't mind seeing > the java deserialization faster. > > -- >

Re: Java deserialization - any best practices for performances?

On Fri, Jul 17, 2009 at 8:13 PM, Alex Black wrote: > > When I write out messages using C++ I'm careful to clear messages and > re-use them, is there something equivalent on the java side when > reading those same messages in? No. Sorry. This just doesn't fit at all with the Java library's des

Re: Compiling on AIX 5.3 using xlC 3.55 compiler

dentifier. > google/protobuf/unittest.proto:455:47: Expected identifier. > google/protobuf/unittest.proto:460:46: Expected identifier. > gmake: *** [unittest_proto_middleman] Error 1 > > So I guess it wont even compile with unordered_map provided on Linux . > Please provide some in

Re: Java deserialization - any best practices for performances?

On Thu, Jul 23, 2009 at 12:32 AM, alopecoid wrote: > > Hi, > > I haven't actually used the Java protobuf API, but it seems to me from > the quick occasional glance that this isn't entirely true. I mean, > specifically in response to the code snippet posted in the original > message, I would possi

Re: Java deserialization - any best practices for performances?

On Thu, Jul 23, 2009 at 7:15 PM, alopecoid wrote: > Hmm... that strikes me as strange. I understand that the Message > objects are immutable, but the Builders are as well? I thought that > they would work more along the lines of String and StringBuilder, > where String is obviously immutable and

Re: java string literal too long when initializing java.lang.String descriptorData

How annoying. I'll make sure this or something like it gets into the next release -- which I'm going to try to push next week. On Wed, Jul 22, 2009 at 8:36 AM, anonymous wrote: > > Hello, > > I was not able to compile a Java file generated by protoc 2.10 from a > rather big .proto file. > It se

Re: Compiler for the Android Protocol Buffers implementation?

That implementation was written completely independently of the protocol buffers team at google, and is not maintained by us. I've heard that it is buggy, and it doesn't support many of the newer language features, though since I've never used it myself or looked at the code I'm not sure if that's

Re: compile errors when building against protobuf headers

What compiler flags are you using? It looks like you have an excessively pedantic warning mode enabled, with -Werror to make warnings into errors, and it is applying even to system headers (usually warnings in system headers aren't reported). On Mon, Jul 27, 2009 at 6:27 PM, achap wrote: > > fo

Re: compile errors when building against protobuf headers

, but I am using "-W -pedantic", which > apparently is the problem. > > what is the likely hood that this will work with the pedantic warning > enabled? My build system forces pendant... I can override it, but I'd > rather not if I don't have too. > > >

"Lite" mode is in SVN -- mostly

I just committed the new "lite mode" refactoring for C++ and Java to SVN. To use the new feature, add this line to your .proto file: option optimize_for = LITE_RUNTIME; This will cause protoc to generate code which is just as fast as with optimize_for = SPEED, but lacks descriptors, reflection, U

Re: "Lite" mode is in SVN -- mostly

On Wed, Jul 29, 2009 at 2:14 AM, ijuma wrote: > On Jul 29, 3:50 am, Kenton Varda wrote: > > I just committed the new "lite mode" refactoring for C++ and Java to SVN. > > Thanks, that sounds useful. I noticed another change in the > Changes.txt: > > "Put Bu

Re: upgrade to latest release

On Wed, Jul 29, 2009 at 4:14 AM, Sushil Shelly wrote: > I need to upgrade a linux installation of protocol buffers. I have 2.0.3 > and need to move up to use 2.1.0 - is there a set procedure to do this? > You can just install it normally. You may also want to recompile any apps based on it, but

Re: How to sort the repeated element?

In C++, you can use the standard STL sort() function: http://www.sgi.com/tech/stl/sort.html RepeatedPtrField supports iterators, so you can do something like: #include struct StudentOrdering { inline operator()(const Student* a, const Student* b) {

Re: upgrade to latest release

ou uninstall the old and then re-install the new (just re-run "make install") then everything should be good. > > > thanks > > > > On Wed, Jul 29, 2009 at 2:22 PM, Kenton Varda wrote: > >> On Wed, Jul 29, 2009 at 4:14 AM, Sushil Shelly wrote: >> >

Re: upgrade to latest release

On Wed, Jul 29, 2009 at 11:49 AM, Monty Taylor wrote: > A little off-topic - but do you have a cutoff date for patches to get in > to that? I've still got some Sun Studio issues I've been working on a > patch for that I'd love to be in 2.2.0... There's no official schedule, so I can wait. Can

Re: Installation using cygwin fails

On Wed, Jul 29, 2009 at 11:56 AM, Javier wrote: > Warning: This system can not link to static lib archive > libprotobuf.la. i have the capability to make that librar > automatically link in when you link to this library. But I cna only do > htis if you have a shared versino of the library, which y

Re: Installation using cygwin fails

Odd. Here's a longshot idea: Try compiling from inside the Cygwin tree, e.g. create a /src directory and unpack the protobuf package there. This would avoid any possible confusion between "C:/" vs. "/cygdrive/c". But I don't know if it will actually help. On Wed, Jul 29, 2009 at 12:27 PM, Javie

Re: "Lite" mode is in SVN -- mostly

On Tue, Jul 28, 2009 at 7:50 PM, Kenton Varda wrote: > C++, as measured by the "size" command on Linux: > libprotobuf.so: 948k > libprotobuf-lite.so: 148k > libprotobuf-lite.so with extension_set.cc removed: 91k > I just shaved another 23k off the lite libr

Re: possible bug?

Probably you are treating the bytes as a NUL-terminated string somewhere, and so the message is being cut short at the zero. Protocol messages can contain NUL (zero-value) bytes, so you cannot pass an encoded protocol message as a plain char* -- you must keep track of the size. On Wed, Jul 29, 20

Re: possible bug?

Also, in all likelihood the ParseFrom*() call is failing, but you aren't checking the return value. On Wed, Jul 29, 2009 at 4:54 PM, Kenton Varda wrote: > Probably you are treating the bytes as a NUL-terminated string somewhere, > and so the message is being cut short at the zero

Re: Installation using cygwin fails

even tried changing the protoc.exe file for the one that's > available for download but it gave me the same error. > > On Jul 29, 3:28 pm, Kenton Varda wrote: > > Odd. Here's a longshot idea: Try compiling from inside the Cygwin tree, > > e.g. create a /src dire

Re: ExtensionRegistry usage.

The Builder interface has a method setField() which takes a FieldDescriptor and a value. You can pass the FieldDescriptor for an extension to set an extension, and pass the message object as the value. You can get the FieldDescriptor from ExtensionRegistry or from GeneratedExtension.getDescriptor

Re: Add a protobuf-config script like the old gtk-config

On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote: > *sigh* It looks like the version at appspot.com isn't GA+ enabled, so I > sign in and it thinks I'm not signed in. > Anyhow, a few comments: > > Since it's generated by configure.ac, do you need it in bin_SCRIPTS? I > think that might cause

Re: Add a protobuf-config script like the old gtk-config

(New patch set uploaded.) On Thu, Jul 30, 2009 at 8:59 AM, Kenton Varda wrote: > > > On Wed, Jul 29, 2009 at 6:34 PM, Jeff Bailey wrote: > >> *sigh* It looks like the version at appspot.com isn't GA+ enabled, so I >> sign in and it thinks I'm not si

Re: Message type scope resolution

In other words, the scoping semantics are just like C++ namespaces, but we use . rather than :: as the scope separator. On Thu, Jul 30, 2009 at 1:50 AM, Constantinos Michael wrote: > Try doing this: > message foo { > message X { } > message bar { > message X { } > message abc { >

Re: Installation using cygwin fails

till tries to execute > them and fails. I have also tried to find out what make Error 127 > means but I still haven't had any luck with that. And to think I did > all of this on my Mac on the first try *sigh... > > On Jul 30, 10:14 am, Kenton Varda wrote: > > I don'

Re: Add a protobuf-config script like the old gtk-config

part of their own configure script. > > Provide an example with PKG_CONFIG or something like that. > > Otherwise, looks good. Thanks! > > Jeff Bailey >|< Google, Inc. >|< +1 514 670-8754 > > > On Thu, Jul 30, 2009 at 12:00 PM, Kenton Varda wrote: > >>

Re: problem with the previous version

I need a lot more information to even begin speculating about this, such as what language you are using and any error messages that were printed when it "crashed". A stack trace would also be nice. On Thu, Jul 30, 2009 at 9:46 AM, muka wrote: > > Hi, > > I have a problem with the previous versi

Re: Add a protobuf-config script like the old gtk-config

t; +1 514 670-8754 > > > On Thu, Jul 30, 2009 at 12:12 PM, Kenton Varda wrote: > >> Yeargh, I'm behind the times. pkg-config? I guess I should be >> integrating with that rather than writing my own script? >> >> >> On Thu, Jul 30, 2009 at 9:05 AM, Jeff

Re: "Lite" mode is in SVN -- mostly

On Wed, Jul 29, 2009 at 3:41 PM, ijuma wrote: > Is there a way to disable this behaviour? As you say, it doesn't seem > particularly useful for sophisticated JVMs and unless I am missing > something, the queue is currently unbounded so it could end up > retaining quite a bit of memory for some us

Re: Allow setting compression level on GzipOutputStream

Yeah, the test only compares "default compression" to "no compression" -- even with the small message, default compression manages to compress a little bit. Committed as rev 170. On Fri, Jul 31, 2009 at 5:08 PM, wrote: > On 2009/07/31 23:56:40, kenton wrote: > > This looks great, Kenton. Thanks

Re: "text relocation" inside libprotoc.so.4.0.0

I think "text relocation" has something to do with the way a dynamic library is compiled and/or loaded. This is not something which Protocol Buffers asks for specifically -- either libtool, your linker, or your binary loader chose to use this feature without being asked for it. It seems that SELi

Re: "Lite" mode is in SVN -- mostly

On Sat, Aug 1, 2009 at 4:42 AM, Jon Skeet wrote: > Out of interest Kenton, does this make the bootstrapping code simpler? > I'd imagine that can be built with just a "lite" version. It would be > nice to get rid of some of the nastiness that's involved in C# just to > get the PB-specific types to

Re: Field of Class type

Protocol message classes can only contain other protocol message classes, not arbitrary Java classes. Otherwise, what would happen when you compile the same .proto file in C++ or another language? On Mon, Aug 3, 2009 at 1:14 PM, Tai wrote: > > Hi, > > I guess this is a simple question. I have a

Re: Field of Class type

builder.build(); >message.writeTo(out); >} > >private void readObject(java.io.ObjectInputStream in) >throws ClassNotFoundException, IOException { >MyClassMessage.MyClass message = > MyClassMessage.MyClass.parseFrom(in); >anotherClass

Re: Subclass of a Proto Message

Your approach actually won't work (at least, as you've written the code) because if you write two messages to a stream without any sort of delimiter, it's impossible to figure out later where one message ends and the other starts. But I suggest doing this instead: message A { ... } message B {

Re: Using Other Message Types using import - "message" is not defined

BTW, the proto package name is meant to correspond to C++ namespaces, not Java packages. I recommend using the java_package option to specify the Java package, then set the proto package to something shorter, like: package qnamic.base.agent; option java_package = "com.qnamic.base.agent"; But

Re: java class name different from proto file name

It looks like your problem is that your file name actually has a space tacked on to the end of it. That is, the name is "MyClass.proto " <- note the last space. You should get rid of that space. On Tue, Aug 4, 2009 at 9:54 AM, Tai wrote: > > I got a strange behaviour when compiling a protofile

Re: java class name different from proto file name

> > > > > The argument was: > value="Platform/dev/config/protocolbuffers/ > ADMObjectHandleMessage.proto " > and not: > value="Platform/dev/config/protocolbuffers/ > ADMObjectHandleMessage.proto" > > Tai > > On 4 Aug., 2

Changing {parse,merge}DelimitedFrom()

In Java I introduced methods called writeDelimitedTo(), parseDelimitedFrom(), and mergeDelimitedFrom() in version 2.1.0. These read and write messages which are prefixed with the message size, thus allowing multiple messages to be written to one stream without any external delimiter. As one or tw

Re: 'Search this group' isn't very helpful

What were you searching for? Are you sure there should be results? On Tue, Aug 4, 2009 at 3:07 PM, yellen wrote: > > I'm finding that the search function provided by the group is > returning much less than I expect. Is anyone else having similar > trouble? > > > --~--~-~--~~---

Re: java class name different from proto file name

ces are accepted when > doing a file lookup. I further assume when protoc takes the argument > it uses the filename including the white space to generate the class > name. Maybe that was the reason why the class was called > "MyClassProto" and not "MyClass". > >

Re: 'Search this group' isn't very helpful

Interesting. I'll file a bug against google groups. On Tue, Aug 4, 2009 at 3:25 PM, Adam wrote: > > On Aug 4, 5:16 pm, Kenton Varda wrote: > > What were you searching for? Are you sure there should be results? > > I originally searched for 'rpc' which I'

Re: list member containing sub classes

Can you just have the OParameter message contain optional fields of type string and int64, where only one of the two is ever set? Then don't have specific types corresponding to OStringParameter and OLongParameter. On Tue, Aug 4, 2009 at 5:07 PM, Tai wrote: > > Hi, > > I have an (abstract) clas

Re: list member containing sub classes

m since the value is either of type String > or Quantity (depending on the subclass of OParameter)? Probably I have > to define different member names. > > Tai > > > On 5 Aug., 03:05, Kenton Varda wrote: > > Can you just have the OParameter message contain optional fi

Re: python custom options

Sorry, they are not implemented, but feel free to submit a patch. On Wed, Aug 5, 2009 at 6:13 AM, jacobgladish wrote: > > Does anyone know the current state of custom options with python? Are > they functional? > > > --~--~-~--~~~---~--~~ You received this message

Re: Java: class visibility

Currently there's no way to do that. You could add an option to descriptor.proto, and update the Java code generator to honor it. Or you could just use a postprocessing step like: sed -i 's/^public class/class/' MyProto.java On Wed, Aug 5, 2009 at 6:41 AM, v6ak wrote: > > How can I achieve p

Re: How to add unmanage point to message instance?

You have to make a copy instead, e.g.: path.add_element()->CopyFrom(ele); delete ele; On Thu, Aug 6, 2009 at 3:21 AM, 李海波 wrote: > Path path; > Element* ele = new Element(); > if( condition ){ >delete ele; > }else{ >//add ele to path,how can I do? > } If your code really looks like

2.2.0 release candidate

http://groups.google.com/group/protobuf/files Please test it out and let me know if you have any problems. http://protobuf.googlecode.com/svn/trunk/CHANGES.txt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protoco

Re: How to add unmanage point to message instance?

ing s1,s2; > e1.SerializeToString(&s1); > e2.SerializeToString(&s2); > if( s1 == s2 ){ >//do something > } > -- > But i think it does not have good performance. > > On 8月7日

Re: 2.2.0 release candidate

What kind of issues? On Fri, Aug 7, 2009 at 4:42 AM, Holger Hoffstaette < holger.hoffstae...@googlemail.com> wrote: > > On Thu, 06 Aug 2009 17:50:57 -0700, Kenton Varda wrote: > > > http://groups.google.com/group/protobuf/files Please test it out and let > > me kn

Re: TextFormat and optional fields.

Protobuf 2.1.0 throws NPE when you try to set a field to null. So, this has been long fixed. On Fri, Aug 7, 2009 at 4:30 AM, Brice Figureau > wrote: > > Hi, > > Oops, sorry, I was plain wrong. > It turns out the code was setting the nonce parameter to null. > Anyway, maybe it should be necessar

Re: 2.2.0 release candidate

et another release candidate out. 2009/8/7 Holger Hoffstätte > > Kenton Varda wrote: > > What kind of issues? > > Unless the ThreadLocals are explicitly cleared, the classloader can not be > unloaded/GCed and jars redeployed. The retained memory is not so much an > issue f

Re: 'Search this group' isn't very helpful

The groups people are working on fixing this. On Fri, Aug 7, 2009 at 12:51 PM, Scott Stafford wrote: > > I'm having zero results too, searching for "DescriptorPool" for > instance. > > On Aug 4, 7:54 pm, Kenton Varda wrote: > > Interesting. I

<    2   3   4   5   6   7   8   9   10   11   >