Re: [protobuf] Re: How to obtain the file libprotobuf.a?

How are you invoking CMake? I ran cmake . && make -j12 just now and confirmed that it produced libprotobuf.a. On Wed, Mar 27, 2024 at 11:53 PM Claus Volko wrote: > My problem is that when I compile a project using Visual C++, no archive > file (file with extension .a) is created. But I would

Re: [protobuf] Disable Protobuf In Audit Logs?

Hi Aaron, sorry but this is a bit outside our expertise as we only support the protocol buffers project on this list. This sounds like a question for cloud support. On Tue, Mar 26, 2024 at 9:05 AM Aaron Celestin wrote: > Anybody know a way to disable protobuf fields in GCP Audit Logs? Couldn't

Re: [protobuf] Location of proto files in protobuf-kotlin JAR changed to src directory in version 3.25

Thank you for the heads-up. That sounds like a real bug we should make sure to fix in the upcoming release. Would you mind filing a GitHub issue for this so that we can track it? On Mon, Jan 8, 2024 at 2:17 PM Wesley Hartford wrote: > Starting with version 3.25.0 the protobuf-kotlin jar

Re: [protobuf] Re: Python Protobuf Serialization Performance In 2023

Starting with 4.21.0, the default Python implementation is now based on upb (see here ), and this should be faster than the older Python C++ implementation. Python-C++ is actually deprecated, and we are

Re: [protobuf] Re: serialize message to UDP socket

I think in this case it would help to first make sure that you're able to successfully get the raw bytes from one side to the other over UDP (i.e. log the byte arrays on the sending side and receiving side and make sure they are the same length and are identical). This seems like the part that is

Re: [protobuf] set numerci_range and read numeric_range

You can reference Person::kDayFieldNumber to get the field number, and then look up the field descriptor with something like Person::descriptor()->FindFieldByNumber(Person::kDayFieldNumber). On Tue, Jul 11, 2023 at 12:51 AM Shahab Nassiri wrote: > Hi > > I want to set numeric_range on protobuf

Re: [protobuf] Re: Wrong SourceCodeInfo Location for options?

I'm not sure what's going wrong, but I agree with you that those spans in red don't look right. This might be a bug in the code that generates the source code info. On Mon, May 22, 2023 at 7:54 PM Clément Jean wrote: > Also to be complete, I use the following command to turn the proto file >

Re: [protobuf] Re: FAIL: Structured exception occurred [Access Violation].

Can you narrow this down to a reproducible example? If the parent message is created using something like Arena::CreateMessage() then it's allocated on an arena, but otherwise it's allocated on the heap. I wouldn't necessarily trust the stack trace to tell you how it's allocated, because in some

Re: [protobuf] Re: FAIL: Structured exception occurred [Access Violation].

It's hard to know the answer to those questions without knowing how protobufEventName was created. If it was allocated on the stack then it will be automatically destroyed once it goes out of scope, but if it was allocated on the heap then you may need to explicitly delete it. If it was allocated

Re: [protobuf] Re: FAIL: Structured exception occurred [Access Violation].

The code you have posted looks fine as far as I can tell, so if there is a memory leak then I think the problem is elsewhere. I suspect that the TelemetryProtobuf::EventName proto passed to PopulateEventName() is not getting destroyed. Or if you're using an arena, then the arena that proto was

[protobuf] Protocol Buffers Version 22.5 is Released!

This version includes the following non-breaking changes: C++ Fix: avoid warnings on MSVC (#12697) (4483f10) Fix: avoid warnings on Windows (#12701) (a1435ad) Add missing cstdint header (9daf5fb) Fix: missing -DPROTOBUF_USE_DLLS in pkg-config (#12700) (18fae1c) Avoid using

Re: [protobuf] Cannot build in CMake with FetchContent

I think the include directory ${Protobuf_SOURCE_DIR}/third_party/abseil-cpp/absl should be just ${Protobuf_SOURCE_DIR}/third_party/abseil-cpp. On Tue, Apr 25, 2023 at 3:48 AM 'Gabriele Baldoni' via Protocol Buffers < protobuf@googlegroups.com> wrote: > Hi all, > > I'm experiencing some issue

Re: [protobuf] Re: Generating code via protoc plugin without resolving indirect imports

As far as I know, the direct deps should be sufficient for parsing .proto files and generating descriptors from them. The one thing I'm not sure about is parsing of custom options; I don't know if we allow proto files to set custom options and reference fields that aren't in the direct deps. For

Re: [protobuf] Re: Generating code via protoc plugin without resolving indirect imports

Getting protoc to work with only direct dependencies is an interesting idea because it has the potential to meaningfully speed up builds, but as Josh said, protoc is not currently set up to be able to do that. I think the way to do this would be to start by calling AllowUnknownDependencies

Re: [protobuf] Better plugin support for cmake builds

Thanks for the suggestion and sorry for taking so long to reply. It's an interesting idea but I guess I'm skeptical of whether it's worth the effort to avoid an extra protoc invocation, since in my experience protoc invocations are not usually the bottleneck in build performance. I would also be

Re: [protobuf] Re: Using google proto as a on wire data format

I think you probably want to use an RPC framework such as gRPC which will handle all this for you. On Sun, Feb 26, 2023 at 9:14 AM Sumit Patil wrote: > Note - lang = CPP > > On Sunday, 26 February, 2023 at 10:38:40 pm UTC+5:30 Sumit Patil wrote: > >> Hii everyone, >> I am

Re: [protobuf] Protocol message tag had invalid wire type.

Once you have the DynamicMessage, you can use the JsonFormat API the same way you would use it with ordinary messages. On Fri, Feb 24, 2023 at 1:52 PM ritesh singh wrote: > Thanks, any leads on generating json at run time using dynamicMessage. Any > existing api util if you can point me to. > >

Re: [protobuf] Protocol message tag had invalid wire type.

I think DynamicMessage is the right approach since you need to work with proto files that are only known at run time. This will also allow you to generate JSON. On Fri, Feb 24, 2023 at 11:19 AM ritesh singh wrote: > > Or if there's a better different approach instead of relying on >

Re: [protobuf] Proto File not found while running protoc

Probably the cleanest solution would be to cd to the directory containing com/ and run protoc from there: protoc -I . --include_imports --descriptor_set_out=/dev/stdout com/google/samples/apps/nowinandroid/data/user_preferences.proto On Fri, Feb 24, 2023 at 11:11 AM ritesh singh wrote: > If i

Re: [protobuf] Proto File not found while running protoc

What do the import lines in user_preferences.proto look like? In your case the import paths should point to files relative to the current directory. On Fri, Feb 24, 2023 at 9:40 AM ritesh singh wrote: > I have 3 proto files in the current directory. > > user_preferences.proto imports other

Re: [protobuf] Protocol message tag had invalid wire type.

A serialized protocol buffer doesn't include any type information, so before you can parse one you have to know in advance which type you're expecting. If you want to be prepared to accept either A or B, then a good solution is to put both types inside a oneof in a parent message, and then just

Re: [protobuf] Protocol message tag had invalid wire type.

I suspect that your code is getting an error because it's trying to parse a .proto file as a serialized protocol buffer. (This won't work since .proto files use a text representation very different from the standard protobuf binary format.) Probably the best way to fix this problem would be to

Re: [protobuf] arena_impl.h:584:19: error: standard attributes in middle of decl-specifiers

Would you mind trying again at head? There have been a lot of changes recently to arena_impl.h, so I wouldn't be surprised if the problem has already been fixed. On Thu, Dec 15, 2022 at 3:27 PM 'Lars Olsson' via Protocol Buffers < protobuf@googlegroups.com> wrote: > When compiling a c++ program

Re: [protobuf] Compatibility error on adding sub message type in existing proto file

I don't think we maintain any code that returns that kind of error. Do you know where that error is coming from? Is it from some external protobuf compatibility checker? On Thu, Dec 1, 2022 at 4:21 AM Komal Kamble wrote: > > Hello Adam Cozzette, > We are getting Found incompatibility change

Re: [protobuf] how to ignore some fields when serialize object in proto3

No, there is no built-in support for serializing a message while ignoring particular fields. Probably the easiest way to do that would be to just make a copy of the message that excludes the fields you want to skip. On Thu, Nov 3, 2022 at 8:16 PM 哈 wrote: > just like > protected void init(Kryo

Re: [protobuf] Protobuf 3 optional vs FieldMasks

>From a protobuf perspective, either approach should work, so I think it is mostly a matter of preference. I think you are right that FieldMasks predate proto3 optional fields and were originally designed to accommodate the lack of optional fields in proto3. Now that proto3 has optional fields,

Re: [protobuf] protogen golang - finding source line for diagnostics?

Things like comments and line numbers from the .proto file are represented in the SourceCodeInfo message here . Unfortunately I'm not familiar enough with Go protos

Re: [protobuf] Clarifying for Sharing Messages Between Python and C++

Yes, you are right. Serializing a message and parsing it back on the other side will always work, but starting from 4.21.0, Python apps won't be able to share messages directly without that step. On Wed, Nov 2, 2022 at 10:32 PM No AnyLove (NoAnyLove) wrote: > Protobuf Python has switched to upb

Re: [protobuf] Can I build libprotobuf without using bazel?

We have actually removed support for the autotools build, and 3.21 was the last release that supported it. If you want to avoid Bazel then I would recommend using CMake, since we will continue supporting CMake in future releases. On Wed, Nov 2, 2022 at 12:29 PM Davorin Mista wrote: > Since I

Re: [protobuf] Compatibility error on adding sub message type in existing proto file

Adding more message types to the proto file is fine and has no compatibility issues. Can you say more about the error you're getting? On Wed, Nov 2, 2022 at 7:03 AM Komal Kamble wrote: > Hello ProtocolBufferSupport team, > > If I have a proto file with multiple sub-message types defined and If

Re: [protobuf] Re: Dynamic message schema verification

What you're trying to do should work in the sense that it will determine whether the message is parsable as the type given in the descriptor. However, you are correct that a message of one type can very often be parsed successfully as a completely different type. This is indeed by design, since

[protobuf] Protocol Buffers Version 21.9 is Released!

This version includes the following non-breaking changes: C++ - Update zlib to 1.2.13 (#10819) Python - Target MacOS 10.9 to fix #10799 (#10807) Ruby - Replace libc strdup usage with internal impl to restore musl compat (#10818) You can view the release on GitHub

[protobuf] Protocol Buffers Version 21.3 is Released!

This version includes the following non-breaking changes: *C++* - Add header search paths to Protobuf-C++.podspec (#10024) - Fixed Visual Studio constinit errors (#10232) - Fix #9947: make the ABI compatible between debug and non-debug builds (#10271) *UPB* - Allow empty

Re: [protobuf] How to use reflection of Protobuf to modify a Map

For the purposes of reflection, maps are treated like a repeated field of messages, where each message has a key in field 1 and a value in field 2. The Descriptor type has map_key()

Re: [protobuf] Re: Passing protobuf message from Javascript to C++ WebAssembly module

If only UTF-8 messages are being parsed successfully, then that sounds like a clue to me that you probably need to base64-encode the serialized message. I have only limited experience with JavaScript, but from what I understand, JavaScript strings can only represent Unicode and not raw binary

Re: [protobuf] Transfering large dataset

I think this part of the documentation is a bit out of date because we now routinely use messages much larger than 1 MB in size. The only enforced requirement is that serialized messages have to be strictly less than 2 GiB in size. It's probably still not a great idea to use huge messages hundreds

Re: [protobuf] Nested Value() and adding data to it

There is no built-in support for nested maps, so for example map> is not a valid field type. However you can accomplish something roughly equivalent by using something like map where MyMap is just a message containing a map. On Thu, Jan 13, 2022 at 12:11 PM Calicoder wrote: > Howdy, been

Re: [protobuf] GeneratedMessageV3#isStringEmpty(Object) method not found

This indicates that somehow the project is using Java generated code that is too new for the protobuf runtime. GeneratedMessageV3.isStringEmpty was added relatively recently, so if the runtime library is too old then it won't be present. Version 3.19.2 is quite recent, so that should be fine, but

Re: [protobuf] JsonStreamParserTest.ObjectValues test failure

I don't think we actively test on any big-endian machines, so it wouldn't be surprising if there are a few bugs that come up in that environment. We would welcome any pull requests with bug fixes. On Mon, Nov 15, 2021 at 8:40 AM ravisa...@gmail.com wrote: > > Facing issue with test

Re: [protobuf] Protobuf struct field numbering

I would recommend continuing to add new fields with sequential numbering, since you can always reorder the fields in your file to group together related fields. There is no requirement for fields to appear in field number order in the file, so you could write something like this for example: //

Re: [protobuf] Protobuf imports in Java

This is supposed to refer to the "import public" feature a little bit further down the page, but it looks like the warning is in the wrong place. Thank you for letting us know. I'm working on a fix for this. On Mon, Oct 11, 2021 at 3:01 PM Venkat Duddu wrote: > This section >

Re: [protobuf] Python fails to parse protobuf structure in http body

You can just parse the containing message normally and then use the usual accessors to access the elements inside the oneof. On Tue, Sep 28, 2021 at 12:15 PM Irad K wrote: > I believe the extra 2 bytes where related to the fact that HttpRequest > Protobuf struct is in fact part union object

Re: [protobuf] allow_alias true

No, there is no flag to disable this check. On Mon, Sep 27, 2021 at 1:55 AM hy kam wrote: > Hi, > > I got proto file from other team but they defined as below > enum Aaa{ > *option allow_alias = true;* > MAX_NUMBER = 400; > } > > and I got error during compile > > *"ppp.proto:17:1:

Re: [protobuf] Python fails to parse protobuf structure in http body

I think something is wrong with that serialized proto. There may be a valid proto in there somewhere, but at least the first few bytes seem to be wrong. I starts with 0x32 which would indicate field number 6 and wire type 2 (see encoding details here

Re: [protobuf] Deserialization of large message (> 64MB) slient-ly fails randomly.

I would guess that there is a problem on the serialization side. Any of the WithCachedSizes serialization methods rely on the cached sizes, which means that you need to have called ByteSizeLong() or ByteSize() right before serializing. If the cached sizes are stale then things will most likely not

Re: [protobuf] Issue with extends

Extensions are not quite like inheritance. The way I think of an extension is that it is like an ordinary field except with the dependency inverted, so that the field depends on the message rather than the message depending on the field. I haven't worked with the C# implementation, but as I

Re: [protobuf] Missing commits

The google/protobuf repo is supposed to redirect to our new location of protocolbuffers/protobuf, but I believe there was some kind of mixup and the redirect broke yesterday. It should be fixed now, but let us know if you still have any issues. On Wed, Jul 28, 2021 at 9:13 AM Mark Fine wrote: >

Re: [protobuf] Re: Protoc v3. 15 and v3.17 creates undefined variables in pb.cc files

The only things I can think of that would cause this sort of error would be things like: - Mixing generated code from multiple protoc versions - Rebuilding the generated code for one .proto file but not other closely-related .proto files If you rebuild all the generated code using a single

Re: [protobuf] STL container of messages

It's fine to put protobuf messages in STL containers, so if you're seeing segfaults then those must be caused by some other issue. On Mon, Jul 12, 2021 at 5:02 AM jobroe wrote: > > Hi, > > is it safe to use a STL container of messages ? > > I'm doing it and I seeing rare segmentation faults

Re: [protobuf] Enumerating a variable's fields and setting them

Here's how you could set that nested field in your example (this code is untested so may not work exactly, but should be pretty close): const FieldDescriptor* health_report_field = parent.GetDescriptor()->FindFieldByName("healthreport"); Message* health_report =

Re: [protobuf] Enumerating a variable's fields and setting them

I think the reason this is getting tricky is because you're trying to traverse the descriptors first and then look at the message tree afterward. I would expect it to be much easier if you traverse the message and look at the descriptors at the same time. On Tue, Jun 22, 2021 at 10:58 AM J G

Re: [protobuf] Enumerating a variable's fields and setting them

I think the easiest thing would be that wherever you're now storing a google::protobuf::FieldDescriptor*, you can also store a google::protobuf::Message* pointing to the parent message. On Tue, Jun 22, 2021 at 10:41 AM J G wrote: > Hi Adam, > > Yes, the HealthReport variable is the parent, and

Re: [protobuf] Enumerating a variable's fields and setting them

So is it correct that HealthReport is the top-level message type and HardwareComponent is nested somewhere within that? I think what you're trying to do is doable, but when you call reflection->SetString(), you have to pass the immediate parent message containing the field, not the top-level

Re: [protobuf] Enumerating a variable's fields and setting them

It looks to me like r->report points to a vafmsg.HealthReport but the field descriptor refers to a field in another message (vafmsg.HardwareComponent). On Tue, Jun 22, 2021 at 7:42 AM J G wrote: > Hello Adam, > > OK, I understand, so I've tried this, but I get an error. > > void my_set_value(

Re: [protobuf] Re: Visual Studio 2015 compiler issue

I would guess that there is some kind of mismatch in your protobuf generated code. This kind of thing might happen if perhaps you added a new field and updated the pb.cc file but not the pb.h file (or vice versa). On Sat, Jun 12, 2021 at 1:27 PM Bill Leisge wrote: > Looking back on my post, I

Re: [protobuf] Bytes type limit of 4 GB

Actually protobuf messages must be strictly less than 2 GiB in size. It looks like you're using protobuf-c and perhaps that implementation will allow somewhat larger sizes, but the implementations maintained by Google enforce a 2 GiB limit. There is no real workaround except to break up the data

Re: [protobuf] Enumerating a variable's fields and setting them

Each descriptor describes part of the schema (e.g. a message type, enum type, etc.) but is unrelated to any particular instance of it. As a result, if you have a descriptor by itself then you can't really modify anything because you separately need an instance of the thing you want to modify. The

Re: [protobuf] Use of symbol database in python when api version is 2

My understanding is that api_implementation.Type() is supposed to indicate whether the pure-Python or Python-C++ implementation is being used, and will always return either 'python' or 'cpp'. Are you finding that it is returning something else and thereby causing the symbol registration to be

Re: [protobuf] Firestore document reference & protobuf

We're not really affiliated with the Firestore project so I'm afraid we don't have the expertise to answer your question. You might want to try this mailing list instead: https://groups.google.com/g/firebase-talk On Wed, May 26, 2021 at 9:47 AM Gil Salomon wrote: > Firestore currently have

Re: [protobuf] Programmatically work with .proto file

You can parse the .proto file into a serialized FileDescriptorSet like this: protoc --include_source_info --descriptor_set_out=descriptors.pb The --include_source_info flag will cause the descriptors to include more information about the original .proto file, including the locations of

Re: [protobuf] Is there a plan for protobuffer to support lua?

Google has no plans to add Lua support, but there are some Lua implementations written by others and listed here for example: https://github.com/protocolbuffers/protobuf/blob/master/docs/third_party.md On Fri, Apr 2, 2021 at 12:35 AM clive cw wrote: > I am a game developer. > I use lua+c# and

Re: [protobuf] Protobuf-c usage for 16bit microcontroller

The protobuf-c project is actually a separate implementation that we don't control, but you could try asking this on the protobuf-c mailing list here: https://groups.google.com/g/protobuf-c On Mon, Apr 5, 2021 at 9:11 PM patanjali nayak wrote: > Hello, > > I am using R5F101GC, 16bit

Re: [protobuf] have there been any changes to the canonical syntax for option?

I think for better or worse, "what protoc implements" takes precedence over whatever the spec says. The spec came later and as far as I know we have not put a lot of effort into ensuring that it comprehensively matches the format that protoc expects. I believe the syntax you are looking at is

Re: [protobuf] C++ link error when using "repeated" with a custom message

I suspect that your build is somehow mixing multiple protobuf versions. For C++, the version of protoc used to generate code must exactly match the libprotobuf library version, and it's also important that the headers you compile against are the same version as the library you link against.

Re: [protobuf] Using Protobuf Without Serialize/Deserialize Part

You could certainly do this, but I don't think the generated types meet the technical definition of POJO, etc. For example, in C++ the types are not technically POD (plain old data). That doesn't sound like it would be a problem, though. It sounds like you plan to just use protobuf JSON

Re: [protobuf] Re: Are minor versions of protobuf supposed to be ABI compatible?

For C++ we don't maintain ABI compatibility between minor versions. On Sat, Mar 6, 2021 at 12:13 AM Puya Daravi wrote: > To clarify. It is not just that one symbol that has changed between those > two versions. That is just one example. > > On Saturday, March 6, 2021 at 12:07:58 AM UTC-8 Puya

Re: [protobuf] Parsing of .desc fails for message with custom option

I don't think this necessarily has anything to do with the custom option. FileDescriptorSet is itself just a protocol buffer message, so parsing it doesn't involve interpreting the meaning of its contents. It's just like parsing any other proto, so if it's failing then either the descriptors were

Re: [protobuf] Is the change from Enum to int32 compatible?

The answer to this is a little bit complicated and depends on whether you're using proto2 or proto3. Enums and int32 do share the same wire format, but you have to be careful with unknown enum values. In proto2, if you parse an unknown enum value then it will end up in the unknown field set and

Re: [protobuf] Communication between plugins

Custom options feel like the natural place to store data for consumption by another plugin. I'm not sure if the plugin interface will let you do this all in one protoc invocation, but maybe it would make sense to split up

Re: [protobuf] does MessageToJsonString give special treatment to struct.proto messages?

The Struct type is similar to some of the other well-known types like Timestamp and Duration which have their own custom JSON representation (see here ). I'm afraid there is no easy way to replicate that functionality with a type

Re: [protobuf] How to Run protobuf-test:IoTest test cases

At the moment we support three different build systems for C++, so it depends on what build system you're using. Bazel: bazel test //:protobuf_test Autotools: ./autogen.sh && ./configure && make check CMake: cd cmake && cmake . && make check On Sun, Dec 13, 2020 at 10:19 PM Abhishek Jain wrote:

Re: [protobuf] pod 'Protobuf', '~> 3.14.0' Pod not found

You are right, I did the 3.14.0 release but forgot to publish the artifact for Objective-C. +Bo Yang released the 3.14.0 pod just now. On Wed, Dec 2, 2020 at 12:16 AM Long MA wrote: > I try to do pod install in my Objective-C project, seeing the error 3.14.0 > not found, and I have also done

Re: [protobuf] Looking to install Google Protobuf 3.5

3.14.0 is indeed the newest version. I suspect you might be thinking of the versions as if they're decimal numbers, but that is not quite how they work. It goes 3.9, 3.10, 3.11, etc. I'm not sure about RPMs but I would guess most Linux distros provide a package at least as recent as 3.5. On Thu,

Re: [protobuf] Protobuf 3 for C

I'm not sure of the answer to that because I have not worked with upb much myself. You might have to experiment and see which files you need. On Sun, Nov 1, 2020 at 11:44 PM Luke Galea wrote: > Hi Adam, I am using Segger Embedded Studio for my embedded implementation. > Which files can I use

Re: [protobuf] Protobuf 3 for C

Actually upb is supported by Google, though we have not mentioned it very prominently in our docs. We have mostly used upb as the underlying implementation for other languages like PHP and Ruby, but you could also use it in a plain C codebase. On Fri, Oct 30, 2020 at 9:57 AM Luke Galea wrote: >

Re: [protobuf] Protobuf 3 for C

There are a bunch of C implementations but I think the most common ones are upb , protobuf-c , and nanopb . On Fri, Oct 30, 2020 at 3:45 AM Luke Galea wrote: > I'm new to the world of

Re: [protobuf] Shared memory

That could work but I suspect it would be a fair amount of work to implement. I think at that point you would almost be implementing an alternative serialization format for protocol buffers. Would it make sense to just store the plain binary format in shared memory? On Wed, Oct 28, 2020 at 11:29

Re: [protobuf] Shared memory

You are right that C++ protos are not POD and therefore might not be a good fit for your use case. You could try looking at other protobuf implementations such as UPB and protobuf-c. Since they are written in C I think they meet the POD requirement. On Thu, Oct 22, 2020 at 8:56 PM Mario Not64

Re: [protobuf] How to serialize in C++ for parsing in Python

I think if you have to work with C types then you will need to provide both a char* and an integer length. That Python error makes it sound like the Python code is probably trying to parse beyond the end of the serialized message. On Wed, Oct 14, 2020 at 3:55 PM Randy Nuss wrote: > I am

Re: [protobuf] Re: Handling multiple messages in Java

Serialized protocol buffers don't contain any metadata to indicate what type they are, so you have to have some other mechanism to know what the type is. I would guess that your .proto file probably has a parent message containing the other messages, and the parent is probably the one that is

Re: [protobuf] [Roadmap] - Is custom-option in the roadmap?

We have no plans to deprecate or remove custom options, so you can count on them to stick around. For that matter we are also continuing to maintain proto2 and plan to keep doing so for the foreseeable future. On Fri, Oct 9, 2020 at 6:45 AM Artusi wrote: > Hi all, > > I am planning to use

Re: [protobuf] Moderator action required (too much spam in the Protobuf group)

Hi everyone, sorry about the spam. We lost track of who owned the group and it took some time to sort that out. I just now blocked the spammer, so that should solve the immediate problem and we will be able to address any future spam much more quickly. On Thu, Oct 8, 2020 at 8:28 PM The V wrote:

Re: [protobuf] Finding the starting point of a PB block in a file that contains noise at the beginning.

The protobuf binary format doesn't provide any mechanism for determining where a message begins or ends, so I don't think this is possible. Maybe the only way to do it would be to introduce your own metadata header spaced out at regular intervals (e.g. every 1 GiB), and have this special header

Re: [protobuf] what is M4?

Those are used for the autotools build. If you're concerned about them you could just delete them all from your local repo and build with CMake or Bazel instead. On Fri, Oct 2, 2020 at 3:34 PM hons...@gmail.com wrote: > Hi Guys, > I am trying to get the minimum set of protobuf runtime code that

Re: [protobuf] Dynamically load .proto / .pb.go files

On Thu, Oct 1, 2020 at 3:48 PM Gary Lucas wrote: > That makes sense and that's where I looked first. However I didn't find > the faculty to load a proto / pb.go file in that library. It assumes you already have the descriptor you need (see below for how to get that). > As far as I can tell

Re: [protobuf] Dynamically load .proto / .pb.go files

I'm not very familiar at all with the Go protobuf implementation but in other languages we usually call this feature DynamicMessage. This lets you operate on a message type whose descriptor you access at runtime, without having to know about it at build time. I think this is probably the Go

Re: [protobuf] A chicken and egg issue when building Protobuf

That is true that there is a cyclical dependency between protoc and some generated code such as descriptor.pb.cc. The way we get around this is that we check the generated pb.cc and pb.h files into version control, and the generate_descriptor_proto.sh

Re: [protobuf] Wrapping Protobuf in an extra namespace

I think this will work if you change the namespace everywhere, but the one caveat is that protobuf messages won't be interchangeable between the two protobuf versions. I.e. if you try to take a proto based on your myNamespace version and pass it to code that works with the version used by your

Re: [protobuf] Shall I put protobuf message in unique_ptr to avoid copy?

That sounds like a reasonable way to do it. Another thing you could do is that if you know how big the vector will be, you can call indexVector.reserve() to reserve the correct size, then add each element with indexVector.emplace_back() and initialize its fields in place. That would let you use

Re: [protobuf] Can I create the c++ generate class instance with default value.

With some effort you can do this using the reflection API, but if possible it would be even better to avoid using required fields. On Tue, Sep 8, 2020 at 6:44 PM 童虎 wrote: > I have a protobuf like this: > > ``` > syntax = "proto2"; > message Foo { > required int foo1 = 1; > required int foo2 =

Re: [protobuf] Strings and Arenas

Our StringPiece type has been made obsolete by the std::string_view type introduced in C++17, so we will eventually get rid of StringPiece and replace it with std::string_view (or absl::string_view, which has the same API but is available in C++11). So if you are making a local modification to

Re: [protobuf] Getting NULL character in string when using SerializeToString

There is no practical way to avoid having zero bytes in the serialized message. For example, zero-valued integer fields will show up as zero bytes in the serialized message. If you need the serialized form to contain only printable characters, you could try base64-encoding it as an additional

Re: [protobuf] Protobuf version confusion.

It looks like you have an enum value named NULL, which conflicts with the NULL macro in C++. I haven't looked into this but it is possible that we added some workaround for this somewhere between 3.6.1 and 3.13.0. There is no reason for your Java and C++ to have the same protobuf version, though,

Re: [protobuf] Can an enum value be composed of another enum value?

I'm afraid this is not possible, because enum values can't reference other enum values. On Sun, Aug 30, 2020 at 11:42 PM Phani Deepak Parasuramuni < phani...@gmail.com> wrote: > i have a use case where a first level of proto file declares a set of enum > values and the secondary proto file that

Re: [protobuf] How to model protobuf proto file

If you're using proto2 then you can use extensions to allow clients to extend the base message with their own fields. The one caveat is that you have to figure out a scheme to ensure that each client chooses a unique extension

Re: [protobuf] Segfault when parsing data.

Actually a "make install" will not override the headers and library installed by your distro's package manager. The package manager will put those files in /usr/lib and /usr/include, whereas a "make install" will install into /usr/local. On Tue, Aug 25, 2020 at 12:19 PM Test Last wrote: > Yes I

Re: [protobuf] Segfault when parsing data.

I still suspect that multiple protobuf versions are being mixed somehow. Are you sure that your virtualbox installation didn't install protobuf? On Tue, Aug 25, 2020 at 1:03 AM Test Last wrote: > Hi > > To try and minimise this sort of thing I installed a brand new virtual box > and compiled it

Re: [protobuf] Segfault when parsing data.

I suspect that your build is mixing your downloaded 3.12.3 protobuf source with a different protobuf version installed by your distro's package manager. I would recommend making sure that your project is only compiling against one version of protobuf. Also, I don't think this is related but you

Re: [protobuf] Problem with timestamp data format while migrating to protoc4 from protoc 3.6.1

That problem is a little bit surprising because the Go code generator is implemented as a plugin in a separate repo, and shouldn't therefore be affected by a protoc upgrade. Did you upgrade your Go protoc plugin at the same time? As a side note, sorry for the confusion but we decided not to

Re: [protobuf] Protobuf support for custom allocator ??

No, unfortunately C++ protobuf does not support custom allocators. The closest you can get is to use Arena allocation and give your Arena an initial block of memory to use, but not everything will be allocated on the arena.

  1   2   3   4   5   >