[protobuf] writing a rpc plugin

Hi folks, I am new to protocol buffer, but interested in writing a customized Java rpc lib. The new version recommend to write it in a plugin. However, I cannot find any tutorial on this. Could anybody give an example to help me start? Thanks! Wenhao -- You received this message because you a

[protobuf] ParseFromArray() failing

the function ParseFromArray() returns only a bool value - is there a way to get more details about the error? thanks, --peter -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegrou

Using Protocol Buffers in a MSVC++ 2008 DLL

RegisterServer method, but the debugger never breaks there. I don't understand why the C run- time startup code is being called just for DLL registration. Any and all comments aprpeciated! Regards, Peter K. SP14Translator.dll!google::protobuf::DescriptorBuilder::Build

Re: protobuf for embedded system

We've had some success with the protobuf-c implementation for embedded systems. I second Kenton's recommendation. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers&quo

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

ing. I may try compiling libprotobuf and libprotoc as DLLs and see if that changes the behavior. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to th

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

age, and using these .lib files and the associated headers with my project seems to avert the problem. Thanks! I look forward to the release; I realize these things are fraught with peril. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

On May 4, 7:57 pm, Kenton Varda wrote: > On Mon, May 4, 2009 at 11:12 AM, Peter K. wrote: > > OK, there seems to be projects called "gtest" and "gtest_main" that > > are in the solution file, but don't seem to be in the repo. > > Oh yeah, you&#x

More MSVC2008 Woes

ll pointers welcomed! Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, se

Re: Bit fields in protocol buffer

Hi, I'm not a PB expert, but I don't believe that the basic types support bitfields. One way to do it is to just expand each bitfield into a "uint32". Another way might be to just refer to all the bitfields as "bytes". We chose the first approach, but YMMV. Ciao

Re: More MSVC2008 Woes

D'oh. Hold that thought. It looks like the C runtimes were different, I'm just re-doing everything making sure they're the same. Watch this space. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to th

Re: 2.1.0 release candidate

the solution file. 2. cl : Command line warning D9035 : option 'Wp64' has been deprecated and will be removed in a future release Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "P

Re: More MSVC2008 Woes

OK. That didn't help. Working on generating more information. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe f

Re: Bit fields in protocol buffer

On May 8, 12:03 pm, Henner Zeller wrote: > fixed32 or fixed64 would be probably better. uint32 is encoded in > variable length which would make bitfields typically larger than > necessary. Cool! Thanks for the feedback. Ciao,

Re: More MSVC2008 Woes

but I'll need to come back to it with a fresh mind on Monday to analyze root cause. Thanks helps for the suggestions! Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers"

Re: Cross Compiling Protobuf

/protoc. Make again. Copy ./src/protoc.cross back to ./src/protoc. Then make install. As for configure, we use: ./configure --host=arm-linux--prefix=/srv/rootfs/usr/local/ where the gcc compiler is arm-linux-gcc. HTH, Peter K. --~--~-~--~~~---~--~~ You received

Re: Cross Compiling Protobuf

Thanks, Kenton, I'll try it out tomorrow and post the results. We're sticking with 2.0.3 for now, but will switch once 2.1 goes to full release. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Goo

Re: Cross Compiling Protobuf

worked. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to

Re: 2.1.0 release is up

Good job, Kenton! Thanks for your efforts. Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To u

Odd errors in protobuf-c

We are using protocol buffers in an embedded application. On the server side (protobuf-c), we are getting the error "too short after 64 bit wire type". On the client side (VC++, modified to read the protobuf-c implementation) we get a received packet, but it seems to be zero bytes long. The err

GzipOutputStream is slower than gziping the file by hand

Hi guys, I'm playing around with protocol buffers for a project at work and I'm coming across a possibly weird problem. I have the following setup in my main(): std::cerr << "creating file" << std::endl; int fd = open("blah.repo", O_WRONLY, O_CREAT); if ( fd == -1 ) { std::ce

Re: GzipOutputStream is slower than gziping the file by hand

urrently have a way > to control compression parameters?  If not, it probably should. > > > > On Wed, Jul 15, 2009 at 3:50 PM, Peter Keen wrote: > > > Hi guys, > > > I'm playing around with protocol buffers for a project at work and I'm > > coming a

Re: GzipOutputStream is slower than gziping the file by hand

ult matching > gzip's default.  Thanks. > > On Wed, Jul 15, 2009 at 4:27 PM, Peter Keen wrote: >> >> It doesn't look like it has an existing interface for setting zlib >> options. Reading through the source[1], it looks like it chooses >> Z_BEST_COMPRESSION

Re: Allow setting compression level on GzipOutputStream

On 2009/07/31 23:56:40, kenton wrote: This looks great, Kenton. Thanks for cleaning it up! The tests look pretty decent as well. With such a small golden message you're probably not going to see any difference between the different compression levels, and it is just passed through to zlib so th

RPM Spec File

Hi guys, I was wondering if anyone out there had built an RPM spec file for protobuf. I'll be needing to distribute the C++ runtime library to a set of machines and I'd like to be able to chuck something in a shared yum repo and be done with it, rather than having to copy around a tarball or some

Re: Error with has_field method in C++, protobuf 2.1.0

If I understand the docs correctly has_* will return false if the value is the same as the default, which in the case of numbers defaults to 0. --Pete On Tuesday, August 11, 2009, multijon wrote: > > Hi, > > I'm seeing a strange behaviour of the protobuf library in the > following situation: >

Re: RPM Spec File

es. > > On Wed, Aug 5, 2009 at 3:05 PM, Peter Keen wrote: >> >> Hi guys, >> >> I was wondering if anyone out there had built an RPM spec file for >> protobuf. I'll be needing to distribute the C++ runtime library to a >> set of machines and I

Re: RPM Spec File

pkgconfig files. Kenton, if you think this is worthwhile to include in the distribution I can make a patch with a Makefile target for the RPM. --Pete On Mon, Aug 17, 2009 at 5:47 PM, Peter Keen wrote: > That's a good point. I'm only going to be distributing a few binaries > that have

Re: Serialize with Length Prefix

You sort of have to roll your own. In my project I'm doing something like this: coded_output->WriteVarint32(message->ByteSize()); message->SerializeToCodedStream(coded_output); And then on the reading side: uint32_t size; if (! coded_input->ReadVarint32(&size)) { return NULL; // just an examp

Re: Serialize with Length Prefix

about: http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.coded_stream.html#CodedInputStream.Limit.details --Pete > > > On Aug 24, 4:05 pm, Peter Keen wrote: >> You sort of have to roll your own. In my project I'm doing something like

Re: Serialize with Length Prefix

n't C++ support the same > methods as C#?  The only document that I've seen that has list of > methods available is the message.h header file, installed into my > Linux usr directory. > > > On Aug 24, 4:05 pm, Peter Keen wrote: >> You sort of have to roll your own

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). This is sort of out of scope of what protobuf does. It should be handled by whatever RPC framew

Default Instances -> Memory Leaks?

t effect. Should I be worried? Is there something I'm not doing? Any and all pointers appreciated! (Except NULLs!). Ciao, Peter K. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Protocol Buffers&quo

Re: Default Instances -> Memory Leaks?

Matthew, Thanks! Looks like I should RTFM. :-( Ciao, Peter K. On Sep 30, 12:12 pm, Michael Matthews wrote: > I'm using VC++ 8.0+ with protobuf 2.2.0 and as long as I add the call > toShutdownProtobufLibrary() before > exiting I don't see any memory leaks. > > Mi

[protobuf] Re: Thoughts on protoc plugins

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 what version it's targeting. --Pete On Wed, Oct 28, 2009 a

[protobuf] Re: Thoughts on protoc plugins

On Wed, Oct 28, 2009 at 4:37 PM, Kenton Varda wrote: > The code generator should generate exactly the same code regardless of the > parser version, since newer parsers should never change the behavior of > existing features. Yup, I misunderstood that part of your original email. Makes perfect se

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

Is there a reason why you can't compile the message types into the message editor? It seems like they're pretty intimately tied together as it is. --Pete On Tue, Dec 1, 2009 at 10:27 AM, David McClurg wrote: > I'm trying to rebuild a message editor for a game engine using > protocol buffers.  Cu

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

message type in. --Pete On Tue, Dec 1, 2009 at 12:13 PM, Peter Keen wrote: > Is there a reason why you can't compile the message types into the > message editor? It seems like they're pretty intimately tied together > as it is. > > --Pete > > On Tue, Dec 1, 2009 at

[protobuf] How To Export Compiled Protobuf to Static Library C++

I want to make a static library containing .cc and .h files that are generated from protoc compiler to link with it from other project, I'm using C++ -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop r

[protobuf] Re: Protocol Buffers Compiler Maven Plug-In

I can find it but the latest version is 2.5.0 :-( On Friday, 12 September 2014 13:30:49 UTC+2, Sverre Moe wrote: > > I cannot find any Google Protobuf Maven Plugin in the Central Maven > Repository under com.google.protobuf > > kl. 19:10:18 UTC+1 mandag 2. februar 2009 skrev gak følgende: >> >> D

[protobuf] C++ modifying field without knowing field accessor at compile time

All I am trying to achieve is to modify a message on the fly with a set of fields that are supplied to the program at runtime. simple case: // message declared as - const google::protobuf::Message& message auto x = reflection->GetDouble(message, field); // do some modification to x reflection->Se

Re: [protobuf] C++ modifying field without knowing field accessor at compile time

Yah, after looking back over my problem I refactored and removed the const ref. Just need to take my eyes of the problem for a bit. Thanks for the help. On Monday, October 27, 2014 11:15:32 AM UTC-6, Oliver wrote: > > On 24 October 2014 17:28, Peter Hubner > > wrote: > >

[protobuf] tests.exe deleted random files on my computer (Win7 + VS2013)

Hello, I am not a professional programmer, use Windows 7 and Visual Studio 2013 to program and I use my PC for everything, not just programming. So it has all kinds of stuff installed. Not sure if this matters and if this is even the right place to ask (if not, please tell me where to go), but

[protobuf] tests.exe deletes random files on my computer (win7 vs2013)?!

Hello, I am not a professional programmer, use Windows 7 and Visual Studio 2013 to program and I use my PC for everything, not just programming. So it has all kinds of stuff installed. Not sure if this matters. I'm also not 100% sure if this is the correct place to ask for help (if not, please

Re: [protobuf] tests.exe deleted random files on my computer (Win7 + VS2013)

ndleSehExceptionsInMethodIfSupported(testing::internal::UnitTestImpl > > * object, bool (void) * method, const char * location) Zeile 1981C++ > > > tests.exe!testing::internal::HandleExceptionsInMethodIfSupported(testing::internal::UnitTestImpl > > * object, bool

Re: [protobuf] tests.exe deleted random files on my computer (Win7 + VS2013)

No problem, at least I'm glad it was not a virus and nothing too important got deleted. Windows was able to restore most but not all files. Could have been worse. Thanks for looking into it. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.

[protobuf] GoogleOnceInit template arguments differ with GOOGLE_PROTOBUF_NO_THREAD_SAFETY

GoogleOnceInit takes a function taking a T*, and a T*. Should the GOOGLE_PROTOBUF_NO_THREAD_SAFETY version of GoogleOnceInit be altered to take T*? Thanks, Peter Pimley -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from thi

[protobuf] Re: lazy load http script inside https

...and the relation of your question to Protocol Buffer is? You posted to wrong group. On Tuesday, 30 June 2015 00:34:15 UTC+2, Jake K. wrote: > > > Hello, > > I am trying to lazy load a script using the the following inside my > website which has the protocol set as HTTPS: > > $.getScript('http

Re: [protobuf] Re: Streaming Serialization - Suggestion

This exact suggestion has been up for discussion long time ago(years?, before proto2?) When it comes to taking suggestions I'm only a 3rd party implementer but my understanding is that the design process of protocol buffers and its goals are internal to Google and they usually publish new versions

[protobuf] protobuf and fragmentation

I was wondering what is the proper solution when you try to send a payload of arbitrary size while dealing with the possibility of fragmentation? For example, if I serialize a struct of the following form: struct a { int buffer_len; char* buf; } When I pack it, say my resulting byte a

Re: [protobuf] protobuf and fragmentation

I am actually using protobuf-c from here <https://github.com/protobuf-c/protobuf-c>. On Mon, Aug 15, 2016 at 4:29 PM, Feng Xiao wrote: > > > On Sat, Aug 13, 2016 at 5:14 PM, Peter Chen > wrote: > >> I was wondering what is the proper solution when you try to send a &

[protobuf] MATLAB and protocol buffers

Can anyone verify that this Protocol buffer generator for MATLAB https://github.com/farsounder/protobuf-matlab works with the current protocol buffer 3.2 version. The protobuf-matlab library says it supports protocol buffer versions 2.4.1 which makes me weary. I have been able to send/receive p

[protobuf] How to convert message to it's extend message?

o foo; Baz* baz = foo.MutableExtension(Baz::foo_ext); FillInMyBaz(baz); But how to get the foo object by baz? Best Regards, Peter -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, s

[protobuf] How to convert message to its extend message?

o foo; Baz* baz = foo.MutableExtension(Baz::foo_ext); FillInMyBaz(baz); But how to get the foo object by baz? Best Regards, Peter -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, s

[protobuf] Compilation error in example for the documentation for Timestamp

Here in the documentation https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/timestamp it is says in example 4 there is an error Incorrect: Timestamp.*newBuilder*().setSeconds(millis / 1000) .setNanos((int) ((millis % 1000) * 100)).b

[protobuf] Re: Compilation error in example for the documentation for Timestamp

Cant edit the post so and you have to use seconds() and nanos() On Wednesday, 11 July 2018 16:36:13 UTC+2, Peter Isberg wrote: > > Here in the documentation > https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/timestamp > >

[protobuf] Difficulty compiling C++ with proto files from different directories

e include path is incorrect. I am wondering if anybody can point me to an example of a protobuf project that uses multiple proto files in different directories? How does protoc need to be configured to compile this? How does the maven plugin need to be configured? thanks! Peter -- You rec

Re: [protobuf] How to deal with "File already exists in database:" error correctly?

protobuf+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/protobuf/274860bb-6027-4324-9674-4ac9d21d1ca2%40googlegroups.com >> <https://groups.google.com/d/msgid/protobuf/274860bb-6027-4324-9674-4ac9d21d1ca2%40googlegroups.com?ut

Re: [protobuf] How to deal with "File already exists in database:" error correctly?

e including > the code, because I can imagine that some or all of the symbols could get > stripped depending on how they're built. If the string "ContentMetaInfo" > appears in multiple binaries then they might all be including the generated > code for that .proto file. >

Re: [protobuf] How to deal with "File already exists in database:" error correctly?

#x27;re dynamically loading these dylibs then it will happen at that loading > time as well. > > On Thu, Jul 25, 2019 at 4:01 PM Peter Gusev wrote: > >> Thanks for your insights! >> It may also gets complicated with the environment I'm testing it in. >> Hence, I&#x

Re: [protobuf] How to deal with "File already exists in database:" error correctly?

On Thu, 25 Jul 2019 at 16:21, Adam Cozzette wrote: > If the generated code appears in two dylibs then there will be two of > those static variables performing the same initialization. > > On Thu, Jul 25, 2019 at 4:20 PM Peter Gusev wrote: > >> This makes me think of wha

[protobuf] Security concerns for Any fields?

rity risks (or other significant) problems with this approach? Thanks in advance! Peter -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email

[protobuf] Re: Security concerns for Any fields?

object could end up as a bloated multi-tenant maintenance problem. The goal of the Any would be to reduce these complexities. On Wednesday, May 20, 2020 at 10:13:35 AM UTC-7, Peter JL wrote: > > Hello, group - > > I'm considering using an Any field in a service-to-service reques

[protobuf] Generate code from generated code?

Hey guys, I have an idea of generating code from already generated protobuf code (i.e. golang). I have read up on the documentation on how to write a plugin, but that doesn't seem like something I want to get into. What would be the best solution? Kindly, Peter. -- You received

Re: [protobuf] Python protobuf speed and latest Protobuf version

it yet. 2.3.0 was released earlier this year I believe (based on the release dates of the files). -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To uns

Re: [protobuf] Protobuf for client/server messaging?

On Wed, Jul 14, 2010 at 1:36 AM, bwp wrote: > Our protocol consists of a big number of possible messages but I can't > seem to find a way for protobuf to help me decide which message was > sent. > Writing and parsing messages is really easy when I know what exact > message is being sent but this w

[protobuf] Re: Issue 270 in protobuf: Precompiled protoc binary for OS X

I have OSX 10.6 and built with Xcode 3 and 4 with no problems. Did you readme.txt? -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to

[protobuf] My Protocol Buffers implementation in C#

Hello I have been working on this c# code generating Protocol Buffers implementation for a while and now I dare to announce it. https://silentorbit.com/protobuf/ It is a command line tool that generates standalone c# code from a .proto file. My goal was to have simple serializing code in c

[protobuf] J2ME

Hi, I think i like the idea of this. but can it be used in a J2ME project? -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protob

Re: [protobuf] Extending wrap

On 2012-07-23 08:57, Daniel Krikun wrote: > Hello, > > I would like to define a message wrap with some enum field that will > tell which specific message is wrapped inside (as described in > 'Techniques > Union Types' > section). > La

[protobuf] Should @PTHREAD_LIBS@ also be listed under Libs.private?

Looking at #387 [1], it seems to me that @PTHREAD_LIBS@ should also be listed as private. Does anyone know any reason it shouldn't be? [1] http://code.google.com/p/protobuf/issues/detail?id=387 -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" grou

Re: [protobuf] Re: Why to reinvent the wheel ?

Well, you hit the nail, with that note about M$ Wheel(tm) :D -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post t

[protobuf] Protocol Buffers Specification and the syntax keyword.

Hello Today I received a pull request on my implementation of protocol buffers to support the "syntax" keyword. This got me puzzled since I had not read it anywhere before. My main source has been this document https://developers.google.com/protocol-buffers/docs/proto Which does not mention the s

[protobuf] Re: Issue 599 in protobuf: Fails to compile for Intel Phi

If accepted, please attribute the patch to my work address: peter dot burka at twosigma dot com On Tuesday, January 21, 2014 2:27:06 PM UTC-5, prot...@googlecode.com wrote: > > Status: New > Owner: liu...@google.com > Labels: Type-Defect Priority-Medium > > New issue 599

Re: [protobuf] Re: Issue 599 in protobuf: Fails to compile for Intel Phi

er before its store. /peter On Thursday, January 23, 2014 11:33:44 AM UTC-5, stephentu wrote: > > I think you might actually want two memory barriers, something like > > MemoryBarrier(); > *ptr = value; > MemoryBarrier(); > > your current solution prevents compiler reord

Re: [protobuf] ProtoBuf file larger than CSV

That could be the case. A string value is encoded with the overhead of a type(1byte) and length(1 byte or more) Compared to csv you have one byte, the "," character, if your string also is quoted that adds 2 bytes, 3 in total. Now if the string is longer that 127 bytes the protobuf prefix will gro

[protobuf] bazel build :protoc :protobuf - pkg_files.bzl:407:12: name 'json' is not defined

ps://github.com/protocolbuffers/protobuf.git cd protobuf git submodule update --init --recursive bazel build :protoc :protobuf Thank you -- Peter -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop re