[protobuf] Re: Protocol Buffers Lite for Borland C++

well. This > is fast both in performance and developer productivity, and is so much > easier than trying to work with COM directly. > > On Oct 16, 9:32 am, Kenton Varda wrote: > > Can you upload your patch to codereview.appspot.com regardless? I'd > like to >

[protobuf] Re: Problems with windows headers

There's a hack at the top of message.h to deal with this. I suppose it should have been moved to message_lite.h when lite mode was introduced. On Thu, Oct 22, 2009 at 2:41 AM, villintehaspam wrote: > > Hi, > > I am having some troubles with protocol buffers 2.2.0 together with > the windows head

[protobuf] Re: Java CodedOutputStream performance: buffer size and OutputStream

Hey, it's great that you're trying things. I think there's room for improvement in the Java implementation (as opposed to C++), and it tends to take some trial-and-error. You note that small messages seem faster with smaller buffer sizes, but larger messages are slower. I am guessing that by "sma

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

; MiscTest.DefaultValues >> >> [ FAILED ] >> DatabaseBackedPoolTest.UnittestProto >> >> > > Some Actual errors: > > [ RUN ] ParseDecriptorDebugTest.TestAllDescriptorTypes >> google/protobuf/compiler/parser_unittest.cc:1215: Failure >> Value of

[protobuf] Re: New moderation rules to fight spam

I had to further set things so that non-members cannot post at all. But joining only takes a couple clicks and doesn't require you to receive e-mail, so it should be OK. On Tue, Oct 20, 2009 at 11:44 AM, Kenton Varda wrote: > So it appears that some spammers have been grandfathered

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

On Fri, Oct 23, 2009 at 5:16 PM, Rob wrote: > Hi Kenton, > > I was able to reproduce the problem with the code you provided below. I > have also hooked up a remote debugger and stepped through the code. > > Apparently the line causing the problem is in FastInt64ToBuffer() as you > said before.

[protobuf] Re: protobuf javame

It looks like there are two Java ME implementations listed here: http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns But if neither one works for you, you may have to work on one of them until it does. (I'm not too familiar with Java ME, but I assume that it can't handle the official Java i

[protobuf] Re: CodedInputStream.getTotalBytesRead

Seems reasonable. Want to send me a patch? Don't forget to update the unit test. On Sat, Oct 24, 2009 at 1:46 PM, Michael wrote: > > This would be a really useful method on CodedInputStream > public int getTotalBytesRead() { > return totalBytesRetired + bufferPos; > } > > It good becuase it

[protobuf] Re: Does anybody compile protobuf successfully on HP-UX?

It appears that your system lacks strtoll(). You'll need to replace it somehow. Is your system 64-bit? If so, strtol() should work fine. There's actually an #ifdef near the top of strutil.h which deals with this for other systems. As for the "iter has already been declared" problem, it looks l

[protobuf] Thoughts on protoc plugins

Hi all, I just had an idea for making protoc more extensible: Currently, it is possible to write custom code generators and link against libprotoc to build custom protoc-like binaries. This allows third-party implementations to reuse the protoc front-end while keeping development independent. T

[protobuf] Re: Thoughts on protoc plugins

On Wed, Oct 28, 2009 at 3:52 PM, Peter Keen wrote: > This sounds great! Communicating using a well-defined JSON spec sounds > like a better idea than trying to communicate using protobufs. One > thing I would suggest is having a protocol version number in there > somewhere so the generator knows

[protobuf] Re: Thoughts on protoc plugins

mplication of injecting a middleman may not be a problem. I like the last idea because it is the most modular. Any other ideas? On Wed, Oct 28, 2009 at 8:24 PM, Neil T. Dantam wrote: > > Kenton Varda wrote: > >> Also, writing third-party code generators in languages ot

[protobuf] Re: File already exists in database: abort trap

I'm not familiar with R. But, the error means that you've attempted to load two different copies of rexp.pb.cc into the same process. The protobuf runtime requires that all compiled-in .proto files have unique names. Note that if you have two files with the same name, but in different directorie

[protobuf] Re: Protocol Buf Compliation Problem

I would guess that the GCC version is the problem. If you can find a work-around, submit a patch! On Thu, Oct 29, 2009 at 1:32 AM, eggxp wrote: > > OS & Version: > [r...@localhost root]# cat /proc/version > Linux version 2.4.20-8smp (bhcomp...@porky.devel.redhat.com) (gcc > version 3.2.2 > 20

[protobuf] Re: why protobuf optional field does not take null

Protocol buffers has no concept of null. Fields cannot be set to null. You can *clear* a field, like: builder.clearParamCountry(); This sets the field back to its default value (the empty string, unless you declared some other default). Also, hasParamCountry() will return false until you set

[protobuf] Re: How to create attributes for a element in proto file

On Thu, Oct 29, 2009 at 10:05 AM, Makulik wrote: > Don't know if this is realized as an intrinsic protobuf language > feature. > No, it's not. Protocol Buffers are completely independent of XML. However, you could write an XML<->Protobuf converter by taking advantage of protobuf reflection. --

[protobuf] Re: Java: how to use protobuf to send messages quickly over sockets?

It sounds plausible. There's no fundamental reason why protocol buffers should be faster than Java serialization, at least for simple objects like yours composed of a set of primitive values. Since Java serialization is implemented by the VM, it can probably optimize better than protobufs can. H

[protobuf] Re: g++4.4 fix

Are you sure the problem isn't simply that you've enabled certain pedantic warnings? I strongly doubt that GCC 4.4 actually requires explicit initialization of superclasses as this would break lots and lots of code. On Fri, Oct 30, 2009 at 10:13 AM, Oleg Smolsky wrote: > Hey Kenton, I've attach

[protobuf] Re: protocol buffers lite on Windows Mobile

The linker errors look like they have more to do with stlport than with protocol buffers. It seems like any .cc file which uses std::string is likely to have the same problems. On Fri, Oct 30, 2009 at 12:19 PM, PaulH wrote: > > I've found that if I don't use STLPort, it works fine. Which is > u

[protobuf] Re: Concatenation of adjacent strings in text-formated protobuf message (Java API)

In theory that should work. In practice the Java parser may have a bug. Feel free to submit a patch fixing it. (I believe the C++ parser does support this style.) On Fri, Oct 30, 2009 at 11:35 AM, alopecoid wrote: > > Hi, > > Using the Java API, when attempting to parse a text-formatted proto

[protobuf] Re: Compilation fromprotobuf on Windows CE (ARM4I)

On Fri, Oct 30, 2009 at 10:36 AM, PaulH wrote: > > OPTIONAL is already defined in windef.h. At the top of > extension_set.cc, add this: > > #ifdef UNDER_CE > #ifdef OPTIONAL > #undef OPTIONAL > #endif > #endif > Or you can just simply write: #undef OPTIONAL since it's going to be a problem o

[protobuf] Re: g++4.4 fix

Well, this is certainly not a protobuf issue, as it is my code that uses > -Wextra. The option brings many good checks, but one of them is completely > retarded. Arg!... > > Thanks! > Oleg. > > > On 10/30/2009 10:32 AM, Kenton Varda wrote: > > Are you sure the pro

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

There's not much we can do with this without a reproducible demo. On Fri, Oct 30, 2009 at 4:04 PM, Saptarshi Guha wrote: > > Hello, > I have a byte array which I'd like to deserialize, it is about 3K > bytes. > On RHEL 5, 64 bit machine, protobuf 2.2 my deserialization works. > On Leopard 10.5.7

[protobuf] Re: Java: how to use protobuf to send messages quickly over sockets?

Ah. So Java Serialization has no good reason to be slower... but apparently it is! Hah! :) On Fri, Oct 30, 2009 at 7:24 PM, jta23 wrote: > > I'm a bit embarrassed :) > > The protobuf version of my code uses about 950MB of memory (the Java > Serializable version is only using around 650MB) an

[protobuf] Re: Java: how to use protobuf to send messages quickly over sockets?

On Sat, Oct 31, 2009 at 7:52 AM, Evan Jones wrote: > Hm. It is a little interesting that it would use so much more memory > than using Java serializable ... > Protocol buffers need to keep track of which fields are set. Currently this is done using a bool for each field. Perhaps it would be mo

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

seems unlikely to me. My guess is that the Apple release of GCC actually sets this flag correctly by default, but you are actually using some other GCC, perhaps from MacPorts or some such. Could this be the case? On Sat, Oct 31, 2009 at 5:58 PM, Saptarshi Guha wrote: > > > On

[protobuf] Re: enumerate message types of a DescriptorPool

No. A DescriptorPool is simply a cache in front of a DescriptorDatabase. A DescriptorDatabase can be arbitrarily large -- perhaps infinitely large -- therefore we do not provide a way to enumerate it. You should find a design which does not require enumerating the entire pool. 2009/11/1 Romain

[protobuf] Re: Java and generic conversion

What you want to do is create a Map which maps from descriptors to default instances of each of your generated classes. For example: Map myMap = new ...; myMap.put(FooMessage.getDescriptor(), FooMessage.getDefaultInstance()); myMap.put(BarMessage.getDescriptor(), BarMessage.getDefaultInstan

[protobuf] Re: documentation within proto files

There's no convention for this currently. If you want to see how Google documents things, look at descriptor.proto: http://protobuf.googlecode.com/svn/trunk/src/google/protobuf/descriptor.proto But it's not very excit

[protobuf] Re: documentation within proto files

Nov 2, 2009 at 9:17 AM, Evan Jones wrote: > > On Nov 2, 2009, at 12:14 , Kenton Varda wrote: > > There's no convention for this currently. > > It would be pretty nice to have the parser parse some form of doc > comments. Then the language backends could output them ap

[protobuf] Re: Contract-First ProtoBug-Net client does not serialize as ProtoBuf

[+Marc] On Tue, Nov 3, 2009 at 9:09 AM, Loy wrote: > > Client code seems to ignore the attribute ProtoBehavior, while server > respect it > Is there a sample code for the following scenario? > I write dotnet (C#)client > Try to connect to WCF service > The service interface have [ProtoBehavior]

[protobuf] Re: Contract-First ProtoBug-Net client does not serialize as ProtoBuf

Ah, I just use reply-all in gmail to make sure the group gets CC'd on stuff. On Thu, Nov 5, 2009 at 4:44 AM, Marc Gravell wrote: > > My apologies; I thought I had already replied to this. It turns out > gmail and google-groups look too similar, but only one gets back to > the group. Sorry. > > M

[protobuf] Re: Protobuf for binary data

Protobuf does not do compression (though you can, of course, apply compression on top of protobufs). If you are just looking to transmit a large blob of bytes with no structure, then protobufs won't help you. On Sun, Nov 8, 2009 at 8:45 AM, sansun08 wrote: > > I have written a client server appl

[protobuf] Re: how to generate proto file from binary file?

The protobuf encoding does not contain enough information to generate a schema. For example, field names do not appear in the encoded messages at all. On Sun, Nov 8, 2009 at 12:02 PM, rap wrote: > > Hi, > > I want to know how to generate .proto file from a binary file, > something like generati

[protobuf] Re: Streaming Dynamic Messages

You want: com.google.protobuf.Descriptors.FileDescriptor.buildFrom() On Mon, Nov 9, 2009 at 5:25 PM, Dan wrote: > > Im trying to write the following client/server exchange using the Java > Protobuf API: > > 1) Client makes a request to the server > 2) Server creates a series of Messages all of

[protobuf] Re: How to use Protobuf with existing ORM(torque)?

Add this to your .proto file: option java_multiple_files = true; Note that the outer class is still generated, it just doesn't contain the other classes. You can still change the outer class name with: option java_outer_classname = "Whatever"; On Mon, Nov 9, 2009 at 6:47 PM, sansun08 wrote

[protobuf] Re: Difference between protobuf implementations

On Tue, Nov 10, 2009 at 7:28 AM, rahul prasad wrote: > Hi, > > May i ask whats the difference between these two protobuf implementations? > > com.google.common.io.protocol.ProtoBuf.java > I've never heard of this. Where does it come from? > com.google.protobuf package classes > This is the o

[protobuf] Re: Retrieving data with field number and wire type

On Tue, Nov 10, 2009 at 6:25 AM, rahul prasad wrote: > Hi, > > Is there a facility in protobuf library to retrieve data if the field > numbers and wire types are known? > Write a .proto file with that information. Then you can compile it, or you can use protoc's --decode flag. If you need some

[protobuf] Re: Difference between protobuf implementations

any problems mid way due to this switch? Any feedback would be > greatly appreciated. > > Regards, > Rahul > > > On Tue, Nov 10, 2009 at 3:56 PM, Henner Zeller wrote: > >> Seems to be part of Android >> >> http://www.google.com/codesearch?q=com.google.common.io.p

[protobuf] Re: Difference between protobuf implementations

Yes, the tag numbers have to be the same. If you have code that was generated from the original .proto file, look inside it for comments that look like proto field definitions -- they should include the tag number. Otherwise you're out of luck. On Tue, Nov 10, 2009 at 4:00 PM, rahul prasad wrot

[protobuf] Re: Difference between protobuf implementations

oto: Import "TestimportProto.proto" was not found or had > errors. > src/java/Test.proto:19:12: "TestimportInfo" is not defined. > src/java/Test.proto:30:12: "Testimportstate" is not defined. > > Anyone can help? Greatly appreciate it. > > Regards,

[protobuf] Re: How do I approach Issuing Protocol Buffers with a Java Product?

DescriptorProtos.java (which is generated from descriptor.proto) is not platform-specific. It is build as part of the overall build process because it is an auto-generated file -- ideally the source code package should only contain hand-written files. On Wed, Nov 11, 2009 at 9:06 AM, Paddy W wro

[protobuf] Re: Understanding RPC in PB

On Wed, Nov 11, 2009 at 1:05 PM, Noel Fegan wrote: > I'm trying to understand the RPC mechanism in PB. I can understand the > concept of separation of the interface of an RPC from any concrete > definition, which is actually great for us, as we would like to be > able to implement an IPC mechanis

[protobuf] Re: On SnowLeopard, EXC_CRASH (SIGABRT)

> On Nov 1, 6:35 am, Saptarshi Guha wrote: > > Hello, > > Your explanation sounds right. Neither do I have Snow Leopard, so will > > have to ask the user. > > Personally, I would never (unless absolutely forced to) install > > another GCC. Tried it once, and so ma

[protobuf] Re: Compilation issue on Solaris 9 with CC version 5.9

The warnings look harmless (it's complaining about the trailing comma after the last value in an enum). The errors suggest that your compiler is not very good with templates. The line of code is: return ::google::protobuf::internal::ParseNamedEnum( Apparently your compiler doesn't recognize t

[protobuf] Re: Error when trying to compile the exampe proto

The error indicates that the first byte of the file is a non-whitespace character with ASCII value < 0x20. You need to remove this invalid byte from the file. On Thu, Nov 12, 2009 at 11:36 AM, Tommi Laukkanen < tommi.s.e.laukka...@gmail.com> wrote: > > Hello > > I am getting a bit desperate beca

[protobuf] Re: Error when trying to compile the exampe proto

your system, UTF-8 chars will be consider to be control characters (because they are thus negative and therefore < 0x20). So maybe that is the issue. I'd be happy to accept a patch which makes protoc ignore UTF-8 BOMs. On Thu, Nov 12, 2009 at 1:45 PM, Kenton Varda wrote: > The error in

[protobuf] Re: Error when trying to compile the exampe proto

There should be a setting somewhere in visual studio to make it not use BOMs. On Thu, Nov 12, 2009 at 6:10 PM, Tommi Laukkanen < tommi.s.e.laukka...@gmail.com> wrote: > Hi > > Thank you for the information. I use visual studio which seem to be root of > the problem. Now I created the file with no

[protobuf] Re: Does anybody compile protobuf successfully on HP-UX?

on of "std::pair<_TypeT, _TypeU>::pair(const > std::pair<_TypeT, _TypeU>::first_type &, const std::pair<_TypeT, > _TypeU>::second_type &) [with _TypeT=char [1], _TypeU=char [2]]" at > line 181 >instantiation of "std::pair<_TypeT, _TypeU>

[protobuf] Re: Performance Decrease in Java

A 67-byte message should take a couple microseconds to serialize. If you are writing 61 of them a minute, I have a hard time imagining that any significant amount of time is being spent on protobufs. If the time *is* going into protobufs, you should see it in the profiles. On Fri, Nov 13, 2009 a

[protobuf] Re: 'Delta' Protocol Buffers

What do you mean by "represented with their index"? I don't understand the problem. Why do repeated fields pose a challenge for diffing? On Fri, Nov 13, 2009 at 1:11 AM, Paddy W wrote: > > I am working on an application that compares two protocol buffers of > the same type for differences and

[protobuf] Re: 'Delta' Protocol Buffers

e meta-format that specified that a repeated > field in the inputs would result in a repeated field in the output > containing a nested message with an index field and a difference field. > > -- > Jeremy Leader > jlea...@oversee.net > > Kenton Varda wrote: > >> What d

[protobuf] Re: Code for reading a base 128 varint

Yep, that's it, and it's heavily optimized. On Fri, Nov 13, 2009 at 1:09 PM, Fishtank wrote: > > Hello, > I think i rushed. I think this is it > > io/coded_stream.h: bool ReadVarint32(uint32* value); > > Thanks > Sapas > > On Nov 13, 4:06 pm, Fishtank wrote: > > Hello, > > I have some code th

[protobuf] Re: Code not worked

ParseFromString() does not return a value. On Fri, Nov 13, 2009 at 12:53 PM, Alexander Komkov wrote: > > Hi, all! > > This code: > > c = Cellbook.objects.get(id = 4767) > c_pb = c.toProtoBuf(Contact()) > print c_pb > > print: > phone: "79529603429" > name: "Komkov Alexander" > comment: "\2043\207

[protobuf] Re: Regd: "Z" occuring between protobufs

I don't understand. What are you trying to output to the logs? If you're writing binary-format protobufs, then yes, they will contain binary data, which may correspond to characters like "Z". On Sat, Nov 14, 2009 at 7:50 AM, rahul prasad wrote: > If I try to grab and read the protocol buffer I

[protobuf] Re: Code not worked

On Sat, Nov 14, 2009 at 3:39 AM, Francisco wrote: > > Alexander, > > if you take a look at the API reference: > > static bool ParseFromString(const string & input, Message * output) > > you have to pass the output variable as the second parameter. > The question appeared to be about Python, not

[protobuf] Re: Want to port a library to iPhone 3.1.2

This mailing list is for discussion about protocol buffers, which your question doesn't seem to be about. You should probably ask your question on a mailing list for libpcap or iPhone development. On Sat, Nov 14, 2009 at 3:04 PM, Ram wrote: > > Hi, > > I want to port libpcap library to iPhone O

[protobuf] Re: unexpected result from TextFormat::PrintToString in c++

The output is correct. You have not initialized the "header" field. You need to call mutable_header() once to initialize it. On Mon, Nov 16, 2009 at 1:45 AM, edan wrote: > > I have the following class: > > package PB_SimpleMessage; > > message SimpleMessage > { > required Roo

[protobuf] Re: question about creating message classes dynamically (known at runtime)

On Mon, Nov 16, 2009 at 11:35 AM, JC-MAD-SP wrote: > ConcreteMessage* concreteMessage = reinterpret_cast > (mesage->New()); > This line is invalid. Here, *message is a DynamicMessage, and New() also returns a DynamicMessage, not a ConcreteMessage. DynamicMessage is a class which implements the

[protobuf] Re: question about creating message classes dynamically (known at runtime)

your own code. On Mon, Nov 16, 2009 at 11:44 AM, Kenton Varda wrote: > On Mon, Nov 16, 2009 at 11:35 AM, JC-MAD-SP wrote: > >> ConcreteMessage* concreteMessage = reinterpret_cast >> (mesage->New()); >> > > This line is invalid. Here, *message is a DynamicMe

[protobuf] Re: Regd: Resolving Wire type ambiguities

It sounds like you actually have the message class available, not just a serialized instance of the message. In that case, you can derive the original type by reading the generated code. If you only have a compiled copy of the class, you can derive the type from its descriptor -- use MessageType.

[protobuf] Re: Does anybody compile protobuf successfully on HP-UX?

On Sun, Nov 15, 2009 at 8:12 PM, Jackie wrote: > > Yes, it works! Thank you, Kenton :) > > And I got another error report: > >./ -I. --cpp_out=. > sh: ./: Execute permission denied. > *** Error exit code 126 > This can also be fixed by using GNU make instead of your system's make. > BT

Re: [protobuf] Compiling on Solaris 9 - stdint.h

I'm pretty sure several people have compiled on Solaris 9. Perhaps it is your particular compiler that is lacking this? stdint.h was introduced by C99 -- can you use a compiler that is less than 10 years old? Does your system have inttypes.h? If so, you could perhaps symlink stdint.h to it. On

[protobuf] 2.2.0a release -- fixes SONAME

Hi all, The 2.2.0 release had a problem: I forgot to bump the binary interface version number, so the installed libprotobuf.so would overwrite the 2.1.0 libprotobuf.so. This would break any binaries on your system that depended on the old version; you'd have to recompile them. Bumping the SONAM

Re: [protobuf] 2.2.0a release -- fixes SONAME

You may have to forgo pkg-config. Or maybe post-process its output. Bleh. On Wed, Nov 18, 2009 at 9:47 PM, Oliver Jowett wrote: > On Thu, Nov 19, 2009 at 2:07 PM, Kenton Varda wrote: > > > (Unless you are a Linux distribution maintainer, I'd strongly recommend > st

Re: [protobuf] Getting all fields of Message through the java reflection api

Use getDescriptor() to get the descriptor, then iterate through descriptor.fields(). Note that this will not cover extensions. BTW, I believe m.toBuilder() is equivalent to m.newBuilderForType().mergeFrom(m). On Fri, Nov 20, 2009 at 8:25 AM, Thibaut wrote: > Hi, > > I can't find a method how I

[protobuf] Re: 2.2.0a release -- fixes SONAME

I've made this release live on the main site. On Wed, Nov 18, 2009 at 5:07 PM, Kenton Varda wrote: > Hi all, > > The 2.2.0 release had a problem: I forgot to bump the binary interface > version number, so the installed libprotobuf.so would overwrite the 2.1.0 > libprot

Re: [protobuf] Installation/usage - Java version

What version of Java are you using? It looks like the regular expression API is missing some methods. On Fri, Nov 20, 2009 at 5:03 PM, dp wrote: > Hi, > > I needed some help with the Java version. Followed the steps in the > README(s) [C++/Java], but got some errors with the test step. Have > a

Re: [protobuf] Truncated messages

If you use Builder.mergeFrom() and catch the exception, the builder will be left containing whatever data was parsed before the problem was detected. However, a better solution would be to encode your data in multiple messages, such that each packet you send contains one message. That way, if one

Re: [protobuf] Compiling .proto files with scons

Actually, most of Google does not use scons. I've never used it myself. We mostly use an in-house build system full of Google-specific hacks -- like how to build protocol buffers. But it can't be that hard to get scons to run a shell command, can it? On Mon, Nov 23, 2009 at 2:14 AM, Thomas John

Re: [protobuf] comparison of rpc implementations

If you want something that's likely to work with other languages, I'd just implement RPC over HTTP. Assuming you have HTTP support in R already it should be pretty straightforward. Otherwise you'll have to look very carefully at the third-party RPC implementations to figure out which ones are wel

Re: [protobuf] Add another option to support java_implement_interface

The main problem with this is logistical: By declaring that a protobuf class should implement a Java interface, you are making protoc-generated code depend on hand-written, app-specific code. This means that the build system must support declaring such dependencies, and that the .proto files alon

Re: [protobuf] dependency issue?

Need more information: - What language are you using? - What is the full error message and stack trace? On Mon, Nov 23, 2009 at 6:01 PM, suja...@gmail.com wrote: > I get the following error on initialization of one of My protos. as > far as I can tell the dependedncies are all correct but the the

Re: Re: [protobuf] dependency issue?

m.google.protobuf.Descriptors.FileDescriptor[] { > com.ebay.idp.proto.IssuerProto.getDescriptor(), > com.ebay.idp.proto.SubjectProto.getDescriptor(), > com.ebay.idp.proto.ConditionsProto.getDescriptor(), > }, assigner); > > sujata > > > > > > On Nov 23, 2009 6:1

Re: Re: [protobuf] dependency issue?

BTW, I don't know what could cause a stack trace to be null. Are you catching the exception somewhere and then replacing the stack trace? On Mon, Nov 23, 2009 at 6:55 PM, Kenton Varda wrote: > Is it possible that you passed a different --proto_path when you were > compiling I

Re: [protobuf] Re: Add another option to support java_implement_interface

Google's build system requires all dependencies to be explicitly declared and enforces this. This is needed in order for the system to scale to very large code trees: when we want to compile a particular program or test, we want to compile only the things it depends on, not the whole tree. The b

Re: [protobuf] Invalid free() / delete / delete[]

I can't tell anything from that stack trace, sorry. On Tue, Nov 24, 2009 at 10:10 AM, Vlad wrote: > When I link protobuf library on linux suse to empty program valgrind > starts to complain about: > > ==26306== Invalid free() / delete / delete[] > ==26306==at 0x4A1F99E: free (vg_replace_mall

Re: [protobuf] Re: Installation/usage - Java version

wrote: > [...@lothlorien ~]$ java -version > java version "1.6.0_0" > OpenJDK Runtime Environment (IcedTea6 1.6) (fedora-21.b16.fc10-i386) > OpenJDK Server VM (build 14.0-b16, mixed mode) > [...@lothlorien ~]$ > > > On Nov 20, 6:01 pm, Kenton Varda wrote: > > What ver

Re: [protobuf] Re: Protocol Buffers and asynchronous sockets

Yes, use std::string. The only potential problem is if your messages are very large -- allocating large contiguous blocks of memory (as std::string does) could lead to memory fragmentation. But for small and medium-sized messages, there's no reason not to use std::string as the buffer. Parsing f

Re: [protobuf] [De]serialization of messages to java strings

Strings contain text, not arbitrary bytes. Encoded protocol buffers are arbitrary bytes, not text. So, they aren't compatible. You would need to do something like base-64 encode the data in order to put it in a String. On Tue, Nov 24, 2009 at 3:16 PM, Will Morton wrote: > Hello all; > > I nee

Re: [protobuf] Re: Add another option to support java_implement_interface

On Mon, Nov 23, 2009 at 7:50 PM, Alex Antonov wrote: > Kenton, > > Those are all good points, I agree with you that this kinda coupling > could be dangerous and cause trouble if mismanaged. > I'm trying to think of a way to keep this protoc safe but at the same > time provide the kind of function

Re: [protobuf] [De]serialization of messages to java strings

You can use TextFormat but it is probably *less* efficient than base64. On Tue, Nov 24, 2009 at 4:14 PM, Will Morton wrote: > 2009/11/25 Adam Vartanian : > >> What am I doing wrong? What's the best way to do java string > >> serialization of protobuf messages? > > > > If you absolutely have to

[protobuf] Re: Fix for Protobuf issue 136: memoized serialized size of packed fields was invalid (issue157169)

I guess it's technically the case that a packed field always has non-zero size, but maybe we should initialize the cached sizes to -1 anyway to make it more clear when they haven't been initialized? On Tue, Nov 24, 2009 at 7:04 PM, wrote: > Reviewers: kenton, > > Description: > Fix Issue 136: th

[protobuf] Re: Fix for Protobuf issue 136: memoized serialized size of packed fields was invalid (issue157169)

On Tue, Nov 24, 2009 at 7:40 PM, Kenton Varda wrote: > I guess it's technically the case that a packed field always has non-zero > size, but maybe we should initialize the cached sizes to -1 anyway to make > it more clear when they haven't been initialized? That was a

Re: [protobuf] Re: Add another option to support java_implement_interface

On Tue, Nov 24, 2009 at 6:45 PM, Alex Antonov wrote: > > Rewriting the protocol compiler to use some sort of template system is > not > > something we really have resources for. That said, the plugins thing I'm > > working on may be useful to similar ends. > > Oh, the plugins stuff sounds intere

[protobuf] Re: Fix for Protobuf issue 136: memoized serialized size of packed fields was invalid (issue157169)

t; fields. > > > On 2009/11/25 03:42:18, kenton wrote: > >> On Tue, Nov 24, 2009 at 7:40 PM, Kenton Varda >> > <mailto:ken...@google.com> wrote: > > > I guess it's technically the case that a packed field always has >> > non-zero >

Re: [protobuf] install - installing to a local folder instead of /usr/local/...

When you configured with --prefix, was it in a clean directory, or one in which you had done previous builds? My guess is that you had already built with a different prefix and this confused libtool. Make sure to do "make clean" after you change the prefix. On Wed, Nov 25, 2009 at 5:25 PM, elenz

Re: [protobuf] Error parsing from InputStream

Looks like libprotobuf.jar is missing. The code generated by protoc depends on this library. On Fri, Nov 27, 2009 at 5:06 AM, Hershiv Haria wrote: > I am trying out protocol buffers for the first time, and have written > a simple client and servlet to send and receive the PB. It will run on > Ap

Re: [protobuf] Re: Error parsing from InputStream

tion? > > I have them in the build path, and they work on the java tutorial > project from the protobuf site. > Is there any other reason it wouldn't find the class? > > On Nov 28, 5:48 am, Kenton Varda wrote: > > Looks like libprotobuf.jar is missing. The code gene

Re: [protobuf] comparison of rpc implementations

protobuf implementation and RPC implementation as one package, you don't even need to worry about plugins. Just design your RPC API however you want and write the code generator to generate appropriate code. 2009/11/30 Romain François > On 11/23/2009 06:27 PM, Kenton Varda wrote: > >

Re: [protobuf] FileDescriptorSet mania

I'd be open to a class like: class DescriptorSetBuilder { // Adds the file and all its dependencies, if they have not been added already. // Returns this. public DescriptorSetBuilder add(FileDescriptor file); // Returns a FileDescriptorSet containing all files added with add() and // th

Re: [protobuf] Re: why protobuf optional field does not take null

Foo(); might be > a bit cluttersome sometimes. OTOH, it is pretty straightforward and > quick to read. > > Maybe you can hack up some dynamic proxy that wraps around the setters > (haven't done Java for some time, probably this only works with > interfaces). Or alternatively you

Re: [protobuf] generic message editor? parse .proto files?

To parse protos at runtime you will either need to use C++, or you will need to invoke protoc as a subprocess and have it output a FileDecsriptorSet which you can use in Java or other languages. I'll assume C++. Be sure to get familiar with the API documentation here: http://code.google.com/apis

Re: [protobuf] Why do I see “cannot import name de scriptor_pb2” error?

As I posed there, you have to actually install the protobuf library as directed in the readme. Part of the installation process is building descriptor_pb2.py. On Tue, Dec 1, 2009 at 11:39 AM, Nick Bolton wrote: > Hi all, > > I'm having some trouble using our generated Python class... I posted >

Re: [protobuf] [ Question ] Protocol Buffers Maven Plugin

[+gak] On Tue, Dec 1, 2009 at 1:37 AM, Borys Marcelo wrote: > Hi, Folks. > > We are just wondering if is there a Protocol Buffers Maven Plugin in a > Maven repository elsethere where we can point our pom to so we don't > need to compile the Brach code fron Protocol Buffers SVN? If a .jar > exists

Re: [protobuf] generic message editor? parse .proto files?

snippet? Even an un-tested one would > get me going in the right direction. > > > On Tue, Dec 1, 2009 at 1:34 PM, Kenton Varda wrote: > >> To parse protos at runtime you will either need to use C++, or you will >> need to invoke protoc as a subprocess and have it output

Re: [protobuf] [ Question ] Protocol Buffers Maven Plugin

;s finally time to get this plugin out into > the world. Kenton, are you ok with merging the plugin into the trunk > and getting it into the next release? > > On Tue, Dec 1, 2009 at 3:38 PM, Kenton Varda wrote: > > [+gak] > > > > On Tue, Dec 1, 2009 at 1:37 AM,

Re: [protobuf] [ Question ] Protocol Buffers Maven Plugin

> plugin and including it to http://repo1.maven.org/ or > http://repo2.maven.org/ so we can easily use the plugin by pointing to > these repos. > > > Regards, > > > Borys Marcelo > > > > > On Tue, Dec 1, 2009 at 7:01 PM, Kenton Varda wrote: > >> You

Re: [protobuf] Re: Java -using GPB -which type of stream should I be using over sockets?

It doesn't matter what kind of stream you use. Protobufs just read and write bytes. You'll get the exact same result with any kind of stream. On Wed, Dec 2, 2009 at 12:13 PM, Nigel Pickard wrote: > Thanks for the reply Adam -I did a simple sub into my code with your > suggestion, but it doesn't

Re: [protobuf] Re: Java -using GPB -which type of stream should I be using over sockets?

Well ok, using gzip streams would obviously give you something different (the bytes would come out gzipped). But none of the stream types you listed make a difference. On Wed, Dec 2, 2009 at 12:25 PM, Kenton Varda wrote: > It doesn't matter what kind of stream you use. Protobufs just

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