Re: Strange Eclipse compiler error.

Doesn't make any sense to me. Let me know if you find a solution. On Mon, Sep 7, 2009 at 8:16 AM, Brice Figureau > wrote: > > Hmm, more information on the issue below: > > On Mon, 2009-09-07 at 16:52 +0200, Brice Figureau wrote: > > I'm using eclipse (3.5) on a large project using protobuf v2.1

Re: protoc feature question

On Thu, Sep 10, 2009 at 4:59 PM, George Georgiev wrote: > So you suggest if I change the java package in a proto file, I to update > the makefile too? > That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would c

Re: protoc feature question

> My personal opinion is that the best place to handle all this is the protoc > itself. > > -G > > -- > *From:* protobuf@googlegroups.com [mailto:proto...@googlegroups.com] *On > Behalf Of *George Georgiev > *Sent:* Thursday, September 10, 2009 6

Re: protoc feature question

On Fri, Sep 11, 2009 at 1:51 PM, Monty Taylor wrote: > Well, the build-if-newer is handled by either Make or VisualStudio, not > by the compiler in either case. > Right, the link is to a build system plugin. I'm all for build system plugins for protocol buffers but those wouldn't involve changi

Re: Out of sources cross-compiling

Good call. I've committed this as rev 226. Thanks. On Fri, Sep 11, 2009 at 7:21 AM, pierreK wrote: > > Hello, > > [I'm using protobuf-2.2.0] > I would to suggest a minor modification to the file src/Makefile.am > > Currently an out-of-source build works only for native build. > When trying to

Re: RPM Spec File

2009 at 3:40 PM, Kevin Deldycke wrote: > > On Wed, Aug 19, 2009 at 20:35, Kenton Varda wrote: > > Well, I haven't observed this problem on other platforms or distros. > What > > happens if you write a very basic program that uses pthread_once, then > try > &

Re: 2.2.0 "make check" failures on Solaris 10 sparc32 (problems with zlib?)

I expanded on your patch a bit. Can you take a look? http://codereview.appspot.com/117047 On Fri, Aug 28, 2009 at 10:24 AM, Kenton Varda wrote: > I'm planning to submit this when I get a free moment (it's been a very busy > week). In the meantime, have you signed

Re: protoc feature question

On Fri, Sep 11, 2009 at 3:25 PM, George Georgiev wrote: > How exactly this will handle the problem with the different output files? > It won't -- like I said, it's not what you were asking for. We're still saying that your issue is the responsibility of the build system. Sorry. --~--~---

Re: protoc feature question

On Fri, Sep 11, 2009 at 4:22 PM, George Georgiev wrote: > I think that protoc already has a compromise with pure compiler > functionality - namely placing the java class in the package subfolder. > Since you have so strong fillings not to make another compromise you > probably will consider to r

Re: Protocol Buffers on Wikipedia

On Sat, Sep 12, 2009 at 2:14 AM, Cyber Cobra wrote: > Here's the info I'm looking for: > > 1. Is there a specification document more formal/detailed than > http://code.google.com/apis/protocolbuffers/docs/encoding.html ? > No. AFAIK there are no details missing from that document, though I can

Re: SIGBUS alignment issue with ZeroCopyStreams on Solaris/Sparc

Hi Monty, Can you test the attached patch and verify that it fixes the problem? (Kind of hard to test here because we only have x86 machines which happily execute unaligned reads.) On Wed, Sep 9, 2009 at 12:18 AM, Monty Taylor wrote: > > Hey guys, > > I just filed an issue: > > http://code.goog

Re: 2.2.0 "make check" failures on Solaris 10 sparc32 (problems with zlib?)

Can you review the diff, too? At Google we have a policy of reviewing all changes. Just tell me if it looks OK to you, or if there's anything you'd recommend changing (probably not since it's quite short). On Mon, Sep 14, 2009 at 5:30 PM, Oliver Jowett wrote: > Kenton

Re: Protocol Buffers for Python 3.1

Does Python 3.x implement metaclasses the same way? It looks to me like the metaclass may not be getting applied. On Mon, Sep 14, 2009 at 5:21 PM, cjimison wrote: > > Hi all, > > Our application has an embedded python 3.1 interpreter and we would > really like to use protocol buffers. I have s

Re: 2.2.0 "make check" failures on Solaris 10 sparc32 (problems with zlib?)

Committed as rev 228. Thanks. On Mon, Sep 14, 2009 at 7:46 PM, Oliver Jowett wrote: > > Kenton Varda wrote: > > Can you review the diff, too? At Google we have a policy of reviewing > > all changes. Just tell me if it looks OK to you, or if there's anything >

Re: SIGBUS alignment issue with ZeroCopyStreams on Solaris/Sparc

Did your "Absolutely!" mean "Absolutely, I'll test it!" or "Absolutely, it worked!"? On Mon, Sep 14, 2009 at 4:35 PM, Monty Taylor wrote: > Kenton Varda wrote: > > Hi Monty, > > > > Can you test the attached patch and verify that it fixes

Re: ActiveMQ implementation of protobuf

So, his implementation is a little bit faster in two of the benchmarks, and impossibly faster in the other one. I don't really believe that it's possible to improve parsing time by as much as he claims, except by doing something like lazy parsing, which would just be deferring the work to later on

Re: Success story & issue with reading limited number of bytes from a stream

That Refresh() call should only block if there are no bytes at all available on the stream. But if you're about to read a message, then you expect there to be some bytes, right? Or is it that you're actually receiving a message of zero size? In that case, you could check if the message size is z

Re: serialize message to UDP socket

You want to serialize your message to an array first (use SerializeToString() or SerializeToArray()), then write that using send(). Don't use FileOutputStream -- it is meant for stream-based I/O, not UDP. On Fri, Sep 18, 2009 at 12:19 PM, jayt0...@gmail.com wrote: > > Hello all, > > I am having

Re: ActiveMQ implementation of protobuf

ibility with your existing users. > > If you have any suggestions of how we can integrate better please > advise. > > Regards, > Hiram > > On Sep 18, 12:34 pm, Kenton Varda wrote: > > So, his implementation is a little bit faster in two of the benchmarks, > and > &

Re: ActiveMQ implementation of protobuf

r > hand, the server would use deferred decoding. It's definitely a > performance versus consistency trade-off. > > I think that once you make 'free encoding', and deferred decoding an > option, users that have high performance use cases will design their > applica

Re: ActiveMQ implementation of protobuf

x27;m not sure why you're stressing about me rolling this out as new > implementation. > > Bottom line, is I would LOVE IT if the google implementation achieves > feature parity with mine. That way it's one less code base I need to > maintain! Best of luck and if you do cha

Re: ActiveMQ implementation of protobuf

Since protocol messages are value objects, it's generally not necessary to mock them. The problem with interfaces is that they cannot make any guarantee of immutability. On Mon, Sep 21, 2009 at 3:24 AM, Brice Figureau > wrote: > > On Fri, 2009-09-18 at 15:15 -0700, hi...@hiramchirino.com wrote:

Re: ActiveMQ implementation of protobuf

AM, Holger Hoffstaette < holger.hoffstae...@googlemail.com> wrote: > > > If I may.. > > On Fri, 18 Sep 2009 23:16:03 -0700, Kenton Varda wrote: > > > Regarding maven plugins -- why can't the plugin just invoke protoc using > > Runtime.exec()? What's the

Re: Protocol Buffers for Python 3.1

presumably we'll also want in the Python 3 version, but it would probably be easier to re-do the port than to try to integrate the change into what you have. So I'm not sure what we should do with this... On Mon, Sep 14, 2009 at 10:46 PM, Monty Taylor wrote: > Monty Taylor wrote: >

Re: ActiveMQ implementation of protobuf

; On Tue, Sep 22, 2009 at 5:57 AM, Kenton Varda wrote: > >> So Java users don't like relying on C++ code in their build process. On >> the other hand, most C++ users would not accept Java in their build process >> either. But if we wrote the C++ code generator in C++ and

Re: Protobuf with MSVC: how to export generated Message

If you invoke protoc like: protoc --cpp_out=dllexport_decl=MY_EXPORT_MACRO:path/to/output/dir myproto.proto then it will generate code with MY_EXPORT_MACRO in all the right places. However, this option is incomplete -- currently there is no way to force the generated .pb.h to #include a header

Re: mutable

The different accessor functions for C++ protobuf classes are documented in detail here: http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html Message objects can be large, so you should avoid copying them if possible. Instead, you should use the mutable_() accessor to ge

Re: Python C Implementation

ll be part of the next release. On Wed, Sep 23, 2009 at 1:44 AM, Orbby Chang wrote: > > Just curious is the Python C/C++ implementation is on its way? > > Kenton Varda > Wed, 03 Jun 2009 11:34:35 -0700 > > The plan is to modify the current Python implementation so that >

Re: Ability to iterate a descriptor pool.

On Tue, Sep 22, 2009 at 4:35 PM, Exaurdon wrote: > In my particular case I am working with teams from 10+ different > projects. Each project is generating dozens to hundreds of messages. I > imagine that trying to get all of those messages into a single message > would result in a pretty bloated

Re: open jdk

I run Open JDK and it works for me. Care to post more detail on the errors you're seeing? On Thu, Sep 24, 2009 at 8:49 AM, Christopher Piggott wrote: > > I have been having a lot of problems getting things to compile - the > java protobuf library, to begin with; and even after getting that to > c

Re: deserialized fixed length message into a contiguous memory buffer?

On Thu, Sep 24, 2009 at 8:38 AM, am wrote: > > Hello, > > I am working with scalar values and fixed-length arrays. I need to > deserialize the entire message into a contiguous raw buffer in memory > such that all members of the data structure can be accessed by using > offsets against a pointer t

Re: Warnings compiling MessageLite.java in protobuf-2.2.0

I'm told that a new version of the JDK enforces some things more strictly than slightly older versions did, which may be leading to these errors. The solution presented to me was to cast the value returned by internalGetResult() to ExtendableMessage. Note that through generics, we *already know* t

Re: can not build check code in AIX

Unfortunately, it appear the error message is "helpfully" cutting short the names of the functions which it is complaining about, making it impossible to tell what they are. If you could send a patch fixing the problem, that would be great. On Fri, Sep 25, 2009 at 6:44 AM, alex wrote: > > hi, >

Re: Java generated code: faster equals() and hashCode()

On Fri, Sep 25, 2009 at 6:41 AM, Daniel Augustin Pavel < daniel.pa...@gmail.com> wrote: > Hello, > > I've worked a bit on improving the perfomance of equals() and > hashCode() for the generated message clases. > Cool! Unfortunately, increasing the generated code size really is a big problem. Pr

Re: extension_set.h can not be resolved by xlc + + properly

Maybe your system headers #define Free as a macro? Try adding "#undef Free" before that line. On Fri, Sep 25, 2009 at 7:25 AM, alex wrote: > > hi > > when i #include > > the xlc++ always show an error message: > > "/home/soft/include/google/protobuf/extension_set.h", line 378.10: > 1540-0063 (S

Re: extension_set.h can not be resolved by xlc + + properly

Jinx. :) On Fri, Sep 25, 2009 at 10:04 AM, Henner Zeller wrote: > > Maybe 'Free' is a macro defined in that compiler environment ? (would > be bad, but these things happen). > > What happens if you do an #undef Free in front of that > > On Fri, Sep 25, 2009 at 07:25, alex wrote: > > > > hi > >

Re: question on the 'configure' script when using a cross compiler

The configure script is generated by autoconf based on configure.ac. If you can't trace your problems back to something wrong in configure.ac (or in the m4 subdirectory) then you will probably need to talk to the autoconf maintainers instead. That said, cross compiling is supported, and I've used

Re: import problem

On Mon, Sep 28, 2009 at 9:44 AM, Michi wrote: > > Hello, > > I have defined the following messages: > > package myapp.proto.modules.diagnostics; > > message DiagnosticsConfigMessage { >optional bool watchdog_enabled = 1; >optional uint32 watchdog_timeout = 2; > } > > package myapp.proto;

Re: Options prefixing length and message type information

On Fri, Sep 25, 2009 at 1:28 PM, dound wrote: > 1) An option to prefix a length field to each message. This would > make it possible to serialize/deserialize a stream of bytes (e.g., a > TCP socket). > We consider it the responsibility of the transport to maintain the message's size. Almost al

Re: A Working Common Lisp Implementation

I've added this to the list of implementations: http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns Looks like we have two other Common Lisp implementations already, but neither one appears to be maintained. :/ On Sat, Sep 26, 2009 at

Re: XML to Protocol Buffers converter

Interesting. Another way to do this would be to write code based on protobuf reflection and custom options, so you could have a proto like: message Foo { optional int32 i = 1 [(xml_disposition) = ATTRIBUTE]; optional Bar bar = 2 [(xml_disposition) = ELEMENT]; } On Mon, Sep 28, 2009 at

Re: WinCE memory issues

Have you looked at protobuf-c at all? Maybe it comes closer to your needs? On Mon, Sep 28, 2009 at 3:48 PM, Andrzej Zawadzki wrote: > I think safe WinCE protobuf usage is currently impossible due to two > main reasons: > 1. Assumption done in protobuf implementation that memory allocation > will

Re: XML to Protocol Buffers converter

sim wrote: > > Cool. New syntax I didn't know about! I think this would be useful > for converting the other way around (Proto-to-XML). > > On Sep 28, 6:05 pm, Kenton Varda wrote: > > Interesting. > > > > Another way to do this would be to write code based on prot

Re: Can serialized messages be used reliably as keys?

On Tue, Sep 29, 2009 at 12:22 PM, alopecoid wrote: > > Hi, > > Can serialized messages be used reliably as keys? > > In other words, is it guaranteed that... > > - Two equal messages will always generate equal byte sequences? > (Are fields always written in the same order?) > Only if: 1) The im

Re: Can serialized messages be used reliably as keys?

On Tue, Sep 29, 2009 at 12:41 PM, alopecoid wrote: > But, as in my example, that doesn't seem to be the case (necessarily). > Again, for example, let's say you have two messages, both of the same > type. The proto defines two optional fields, both of type variable > int64. > > Say message A poopu

Re: printing utf-8 string

This has been discussed before but no one has gotten around to doing it. I'd be happy to accept a patch which adds a method DontEscapeUtf8(bool) to TextFormat::Printer. Of course, unprintable ASCII characters should still be escaped. On Wed, Sep 30, 2009 at 2:06 AM, Dmitry Ermolov wrote: > > Hi

Re: Maven plugin to create proto files

[cc Gregory Kick] On Wed, Sep 30, 2009 at 11:28 AM, rajesh wrote: > > > Hi, > I was searching if there are any existing plugins which will , > create proto files from the message files given the location and > stumbled across this . > > > http://groups.google.com/group/protobuf/browse_thre

Re: protobuf-c compilation errors

I don't know if the author of protobuf-c frequents this discussion group. You might try e-mailing him directly. On Tue, Sep 29, 2009 at 7:48 AM, zavi wrote: > > Hello, > > I'm trying to compile protobuf-c and keep getting errors I didn't when > I tried compiling on other machines. > Obviously t

Re: Runtime import proto (with extensions) fails with DLL use

(You figured this part out already, but I'm answering for the record.) On Thu, Oct 1, 2009 at 12:46 AM, Carlo Medas wrote: > > Dears, > > we have rpc.proto with a base message, then mathpeer.proto with > messages that extend the base RpcMessage. > > The rpc.proto is built and compiled inside a c

Re: Runtime import proto (with extensions) fails with DLL use

On Thu, Oct 1, 2009 at 3:39 AM, Carlo Medas wrote: > I would like to manually enumerate the available extensions to my > RpcMessage. This is easily done by using an ExtensionFactory in Java > code. > What's ExtensionFactory? Do you mean ExtensionRegistry? But it doesn't allow you to enumerate

Re: Could I use Protocol Buffers for IDMEF

You can try protobuf-c: http://code.google.com/p/protobuf-c/ On Wed, Sep 30, 2009 at 12:55 PM, Hassan.jemmali wrote: > > Hi everybody, > I was doing some researches and i found this new language Protocol > Buffers.After reading some documentations,i thought that this language > Can help me in ser

Re: get all enum fields and their possible values

using google::protobuf::Descriptor; using google::protobuf::FieldDescriptor; using google::protobuf::EnumDescriptor; using google::protobuf::EnumValueDescriptor; const Descriptor* descriptor = message.GetDescriptor();for (int i = 0; i < descriptor->field_count(); i++) { const FieldDescriptor* fi

Re: get all enum fields and their possible values

en recurse, but would I have to handle single and repeatble > message fields differently? > field->is_repeated() returns true or false. There's nothing else different about the descriptors (though the resulting messages are obviously pretty different). > Thanks > > On Oct 2, 1

Re: A Working Common Lisp Implementation

ame on > Google Code, I'd be happy to reset the project and transfer it to you. > > - Dave > > On Mon, Sep 28, 2009 at 7:00 PM, Kenton Varda wrote: > > I've added this to the list of implementations: > > http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns &

Re: C++ - Most efficient way to remove an element from a Message's repeated array

On Mon, Oct 5, 2009 at 10:33 AM, jaypipes wrote: > I'm wondering what is the most efficient method to remove an element > from a Message's vector of repeated elements? I looked at the > RepeatedFieldPtr API but would appreciate some example code on how to > do this in the most efficient way. I

Re: Protobuf-net preserves object references?

The protobuf encoding does not provide any built-in way to represent object references -- all protobuf messages are trees, not graphs. You can implement references at a higher level, e.g. using integer indexes to refer to other objects in a repeated field, but this is not built-in. On Mon, Oct 5,

Re: Save multiple messages to a single file C++

The easiest solution is to create an outer message like: message NodeList { repeated Node node = 1; } then write a single NodeList to the file, and read it back again as a single NodeList. If you really need to read/write individual messages separately (because the file is too big to read

Re: Large data sets

On Tue, Oct 6, 2009 at 9:34 AM, Brenden Matthews wrote: > it specifies that "if you are dealing in messages larger than a > megabyte each, it may be time to consider an alternate strategy". > > My question is: does this apply to messages which are large because > they themselves contain many (i.e.

Re: Somehow protoc --proto_path does not understand any relative paths

What is your exact protoc command line? I see this in your XML: protoc --proto_path=./src --java_out=./src src/com/wsl/CardioTrainer/track/*.proto This may unfortunately confuse protoc, as it doesn't know that "src/" and "./src/" mean the same thing. Canonicalizing paths is surprisingly hard (e

Re: Protocol Buffers: Protocol message end-group tag did not match expected tag.

Can you verify that the bytes you are sending from the server match the ones you receive on the client? E.g. compute a checksum and print it out on both sides so that you can compare visually. (You may need to serialize to a byte array first in order to compute the checksum, and read into a byte

Re: Message forwarding and partial parsing

On Wed, Oct 7, 2009 at 5:46 AM, villintehaspam wrote: > I am wondering about the best way of forwarding received protocol > buffer messages from one entity to another without having to parse the > entire message just to serialize it again. > It looks like you've figured out all the major options.

Re: Somehow protoc --proto_path does not understand any relative paths

proto// then if foo/bar is a symbolic link, foo/bar/baz.proto > will canonicalize// to a path which does not appear to be under foo, and > thus the compiler// will complain that baz.proto is not inside the > --proto_path. > > > Thanks for the help, > Artem > > On Tue, Oc

Re: Message::ByteSize() wrong

ByteSize() definitely returns the right value -- if it didn't, tons of stuff would be broken. Can you provide a complete example program that demonstrates your problem? On Wed, Oct 7, 2009 at 4:01 PM, Brenden Matthews wrote: > > The value returned by Message::ByteSize() does not match the actuall

Re: Message::ByteSize() wrong

at 5:33 PM, Brenden Matthews wrote: > >> Here you go...attached is an example that fails quite reliably (for me). >> Compile like so: >> >> mkdir build >> cd build >> cmake ../ >> make >> ./test-pb >> >> On Wed, Oct 7, 2009 at 4:49 PM,

Re: arrays??

On Thu, Oct 8, 2009 at 10:57 AM, sergei175 wrote: > 1) After event 500, even 200MB memory is not enough. > 2) It's slower by factor ~5 compare to the java serialization with > the >compression. > Protocol Buffers do not include compression, so to make this comparison fair you would need to

Re: Generating.proto files from java source file

Yikes. That's kind of like someone left you with just .class files without the .java files. If you look at the code, though, you will notice that there are comments in it defining each field, like: // optional int32 i = 1; These should be the exact field definitions as they might appear in the

Re: Generating.proto files from java source file

Hmm, that's true. Although I'm not sure if there's actual code for writing the .proto file in Java. In C++, descriptors have a DebugString() method which returns a compilable .proto file. On Thu, Oct 8, 2009 at 11:41 AM, Henner Zeller wrote: > On Thu, Oct 8, 2009 at 11:32, K

Re: Java compiler warning

Unfortunately, we (read: I) don't really have time to chase warnings. If you want it fixed, submit a patch. Otherwise, ignore it -- the code does the right thing. On Fri, Oct 9, 2009 at 1:16 AM, Jesper wrote: > > The Eclipse Java compiler issues a warning about a raw type: > > Description

Re: j2me object serialisation using Protocol Buffers

Cool! Is there an appropriate landing page discussing your protobuf features which I could link to? I don't like linking people directly to source code, but your home page does not mention protocol buffers, so linking there could be confusing. On Sun, Oct 11, 2009 at 7:19 AM, yura wrote: > > iv

Re: is this possible?

This is a common pattern. Currently the only solution is to declare a bunch of optional fields. On Mon, Oct 12, 2009 at 12:48 PM, dukeFan wrote: > > I would like to define a message that include a couple of fields and > then a message, which comes from a list of available messages, like. > > me

Re: XML to Protocol Buffers converter

am, sim wrote: > > Cool. New syntax I didn't know about! I think this would be useful > > for converting the other way around (Proto-to-XML). > > > > On Sep 28, 6:05 pm, Kenton Varda wrote: > > > > > Interesting. > > > > > Another

Re: j2me object serialisation using Protocol Buffers

Thanks, I've added this to the list: http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns On Tue, Oct 13, 2009 at 1:40 PM, Yura Mamyrin wrote: > hello > ive made a page about it :D > http://swingme.sourceforge.net/encode.shtml > thanks > -YURA > http://yura.net/

Re: Compatibility between protobuf ports with different languqges

Yes, that's the whole point. :) On Tue, Oct 13, 2009 at 6:22 PM, jae wrote: > > Hi, > > I have a quick question. So, between two protobuf ports with different > languages, are they compatible? In other words, Can I serialize things > with protobuf-net and deserialize it back using protobuf-objc

Re: generating repeated messages dynamically

What language are you using? In C++: Object obj; for (int i = 0; i < array1_size; i++) { obj.add_pair()->set_key(array1[i]); } if (obj.pair_size() == array2_size) { for (int i = 0; i < array2_size; i++) { obj.mutable_pair(i)->set_value(array2[i]); } } else { // error } On Wed, Oct 14

Re: Protocol Buffers Lite for Borland C++

Can you send a patch? Assuming the changes are not intrusive I'd be happy to merge this back into the main distribution. (Although I can't guarantee that it won't break again over time since we don't test on this platform.) On Tue, Oct 13, 2009 at 9:53 PM, Dazza wrote: > > I have ported Protoc

Re: generating repeated messages dynamically

repeated in the > message? > > On Oct 14, 4:51 pm, Kenton Varda wrote: > > What language are you using? > > In C++: > > > > Object obj; > > for (int i = 0; i < array1_size; i++) { > > obj.add_pair()->set_key(array1[i]); > > > > } > >

Re: Why I get inconsistent values with serialization ?

Can you send me a minimal self-contained example program which I can compile and debug? Should be just one (small) .cc file and one .proto file. On Thu, Oct 15, 2009 at 8:40 AM, The_Glu wrote: > > Hello, > > I use the following prototype : > > message Find { > required uint64 tag = 1; > req

Re: Support Symbian, ideas, questions

On Thu, Oct 15, 2009 at 11:45 AM, Mika Raento wrote: > I have the protobuf lite code running on Symbian. Neat. > It's around 100k > which although large by the platform standards, I can live with. > Is this the lite library or the full one? I'd suggest focusing on the lite library only. Yo

Re: Protocol Buffers Lite for Borland C++

Can you upload your patch to codereview.appspot.com regardless? I'd like to see what changes are required, and other Borland users could reuse your patch. On Thu, Oct 15, 2009 at 2:54 AM, Dazza wrote: > > It turns out that the namespace "internal" causes problems for the > Borland C++ compiler,

Re: Any progress on the Maven plugin?

t; it's out in the world and has gotten some real use. > > On Sep 3, 12:58 pm, Kenton Varda wrote: > > [+gak] > > > > > > > > On Thu, Sep 3, 2009 at 1:47 AM, Bjorn Borud wrote: > > > > > hi, > > > > > someone checked in a mave

Re: Any progress on the Maven plugin?

about the one from activemq (it generates different source) > >> >> Forget about the damn unit tests. Just get the plugin out into the >> wild and end the suspense. It's good to go as is, at least in my >> experience. You'll undoubtedly get more exposure and tes

Re: Any progress on the Maven plugin?

Oops, I forgot:- Lots of Google software parses .proto files at runtime, and most of it is written in C++. Java (or Python) dependencies probably would not be workable. On Fri, Oct 16, 2009 at 7:34 PM, Kenton Varda wrote: > This has come up before. There are several reasons why a Java port

Re: byte array compare

You can implement arbitrary comparison algorithms using reflection (protobuf reflection, not Java reflection -- see the Message interface). On Sat, Oct 17, 2009 at 10:34 AM, Michael wrote: > > Thanks for the suggestion but unfortunately equals with not tell me GT > or LT. Furthmore the encoding

Re: UTF-8 vs 7-bit ASCII in strings

On Sun, Oct 18, 2009 at 1:07 PM, jakob.v...@gbv.de wrote: > The Language Guide describes the "string" scalar data type as "A > string must always contain UTF-8 encoded or 7-bit ASCII text." does > this include the ASCII control character below 0x20? At least XML does > not allow these characters

Re: RpcController.setFailed: Need to call the callback?

You must still call the callback after calling setFailed(), but the message passed to the callback may be ignored. Unfortunately this interface is kind of messed up right now. We'd like to change it so that the callback has two methods: one for normal return and one for failure. On Wed, Oct 14,

Re: Unable to read from concatenated zip's using GzipInputStream in protobuf-2.2.0 with zlib-1.2.3

It sounds like you know what the problem is, so can you send a patch that fixes this? Remember to add a test to zero_copy_stream_test.cc. On Sun, Oct 18, 2009 at 9:27 AM, Jacob Rief wrote: > > I use protobuf to write self delimited messages to a file. When I use > FileOutputStream, I can close

New moderation rules to fight spam

Due to spam getting bad on this group lately, I have changed the settings such that the first message from a new user will be held for moderation. Each user will only have to go through moderation once. Please let me know how you feel about this -- we can change it back if people think it is a bad

[protobuf] Re: Compiling a Static Library for IPhone OS 3.0

It looks like it is looking for x86 header files, which suggests that the compiler thinks you are trying to compile for x86 rather than ARM. On Mon, Oct 19, 2009 at 2:37 PM, JavaGuru wrote: > > Im trying to build a static protobuff library to use with iPhone and > Im running into problems. > Ive

[protobuf] Re: Compiling a Static Library for IPhone OS 3.0

I have never built anything for iPhone. So, I would not know. On Mon, Oct 19, 2009 at 5:55 PM, JavaGuru wrote: > > Can you recommend a fix for this? > > On Oct 19, 4:52 pm, Kenton Varda wrote: > > It looks like it is looking for x86 header files, which suggests that the &

[protobuf] Re: New moderation rules to fight spam

So it appears that some spammers have been grandfathered onto the unmoderated list simply because they had spammed here before. Ugh. I will ban them as I see them, but it may take a bit to flush them out. On Mon, Oct 19, 2009 at 9:12 AM, Kenton Varda wrote: > Due to spam getting bad on t

[protobuf] Re: Java and Dynamic messages

There is no .proto parser in Java. However, you can use protoc's --descriptor_set_out flag to generate a FileDescriptorProto representing the file (or use FileDescriptor::CopyTo() in C++). This is a protocol buffer representation of everything defined in the .proto. In Java, you can then: 1) Par

[protobuf] Re: PB string into another PB?

First, change A.user to have the type "bytes" instead of "string". Then do this: b.SerializeToString(a.mutable_user()); But why not declare "user" to be of type A instead? Like: message A { required B user = 1; } On Wed, Oct 21, 2009 at 1:11 AM, SuKai wrote: > Hi All! > > SerializeToString

[protobuf] Re: cross compile blackfin: problems linking - pthreads

When you compile a program against libprotobuf, you need to use pkg-config to find out what additional cflags and libs are necessary. Example: g++ -c my_prog.cc `pkg-config --cflags protobuf` g++ -o my_prog my_prog.o `pkg-config --libs protobuf` Your specific problem is probably that you are

[protobuf] Re: Segfault - ideas please!?

It looks like you are calling exit() from a signal handler. Lots of stuff is not safe to do in signal handlers. You should perhaps use _exit() instead to bypass destruction of global variables. On Wed, Oct 21, 2009 at 6:04 AM, edan wrote: > I have a bizarre and not very reproducible segfault /

[protobuf] Re: cross compile blackfin: problems linking - pthreads

x27;-lpthread'. Not sure why the > protobuf requires this when nothing else does... but regardless, > thanks for the pointer to pkg-config... it helped solve the problem > for me! :) > > Thanks again! > > -Rob > > On Oct 21, 11:13 am, Kenton Varda wrote: > &

[protobuf] Re: cross compile blackfin: problems linking - pthreads

t; GeneratedMessageTest.CopyFrom >> >> [ OK ] GeneratedMessageTest.CopyFrom (1 >> ms) >> >> [ RUN ] >> GeneratedMessageTest.SwapWithEmpty >> >> [ OK ] GeneratedMessageTest.SwapWithEmpty (2 >> ms) >> [ RUN ] >> GeneratedMessageTest.SwapWithSe

[protobuf] Re: cross compile blackfin: problems linking - pthreads

27;t even see the 'Abort'. It must be related to the uClinux's > lack of 'fork()'. Maybe use 'vfork()' as a drop in replacement? > > http://docs.blackfin.uclinux.org/doku.php?id=living_without_forks > > Would you recommend sticking to the 'lite

[protobuf] Re: PB string into another PB?

On Wed, Oct 21, 2009 at 6:04 PM, SuKai wrote: > Because A_instance.user stored with different type of PB. > > Fill A_instance.user with B, C, or D , these are diff PB objects. > Then you should have three different fields: message A { optional B user_b = 1; optional C user_c = 2; optional

[protobuf] Re: PB string into another PB?

er_c = 2; > optional E user_d = 3; > optional F user_e = 4; > } > > So , I want use R1's proto instance to encode this message on R2' proto > instance. > Can I get the true value for the same colums (user_b & user_c) value? > > Thanks. > > > Ke

[protobuf] Re: Segfault - ideas please!?

al destruction would only cause a problem in > protobuf if protobuf was interrupted by the signal, but not otherwise? > Any other ideas? > Thanks > --edan > > > On Wed, Oct 21, 2009 at 8:16 PM, Kenton Varda wrote: > >> It looks like you are calling exit() from a signal

<    4   5   6   7   8   9   10   11   12   13   >