helps we could probably at
> least try to refactor things to minimize the complexity of maintaining that
> behavior difference.
>
That would be super-helpful. I'll have to catch up on the current state of
protobuf library code and figure out how to allow convenient interception.
Zellyn
--
You
is to provide a related set of minimal patches to (a)
protoc, (b) the C protobuf implementation, (c) the Java implementation and
(d) the Go implementation, supporting sensitive fields.
Unfortunately I just haven't found the time to do all that.
Zellyn
On Fri, Apr 19, 2019 at 5:12 PM Josh Humphries
Yeah, it's precisely the fact that protoc populates that field regardless
of whether it was specified that I consider
bad. https://github.com/protocolbuffers/protobuf/issues/5587
I'm probably way too late to get it fixed, though: it looks like 3.1.0
introduced that behavior :-(
Zellyn
as-is,
unless an explicit json_name was specified.
Or am I understanding it wrong?
Zellyn
On Tuesday, January 15, 2019 at 12:47:31 PM UTC-5, Zellyn wrote:
>
> Hey folks,
>
> We're trying to update the version of protoc we use for compiling our Go
> protobufs. It appears that at som
, could anyone help
me track down the commit that did it?
Thanks,
Zellyn
--
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...@google
ent/d/18WI8zN7rk6R0jXW1iC8LDYz7LJ0OrUOTKMGD7nyEnFs>
.
Zellyn
On Wednesday, February 22, 2017 at 12:10:14 PM UTC-5, Adam Cozzette wrote:
>
> Hi Zellyn, this sounds like a reasonable idea. As the next step could you
> perhaps write up a short proposal with more details on what exactly i
/github.com/google/protobuf/issues/1160> a while back, but it
didn't go anywhere. I reached out to the protobuf team, and Damien Neil
suggested that this group was the appropriate place to propose such changes.
Bikeshed away!
Zellyn
--
You received this message because you are subscribed to the Goog
native would be for protoc to understand Go
> vendor directories, but that would require putting some Go-specific logic
> in protoc itself.
>
> On Tue, Jul 12, 2016 at 8:00 AM, Zellyn Hunter <zel...@gmail.com
> > wrote:
>
>> Yeah I can do anything with a wrapper. But to the
Yeah I can do anything with a wrapper. But to the extent that our concerns
and structure are normal, it would be a shame to need a wrapper.
On Tue, Jul 12, 2016, 8:54 AM Ross Light <li...@google.com> wrote:
> Zellyn and I talked a little bit at Gophercon about this. I think so
.
Zellyn
On Fri, Jul 8, 2016, 6:52 PM 'Josh Haberman' via Protocol Buffers <
protobuf@googlegroups.com> wrote:
> I don't know the background of the Go import system or go_package option.
> However this statement concerns me a little:
>
> > We have to use go_package to reorganize
: as GRPC sees an increase
in use as a cross-language RPC mechanism, everyone else is going to
struggle with the same things.
Zellyn
On Fri, Jul 1, 2016 at 7:32 PM Ross Light <li...@google.com> wrote:
> Sorry for the delayed response! I've written about 3-4 draft replies over
> this we
protos are also gaining "Well-known Types", some of which are "boxed"
(Message) versions of the primitive
types:
https://developers.google.com/protocol-buffers/docs/reference/google.protobuf
I believe the actual docs on well-known types are currently Google-internal
:-(
ence/google.protobuf,
includes all sorts of things like Struct, Method, Mixin, etc. that are
entirely unclear.
Is there a conversation happening somewhere that I'm missing, or is it
Google-internal but not documented outside yet?
Thanks,
Zellyn
ps - the reintroduction of message types f
protoc-gen-go/ that could be imported just to link the grpc plugin, but
that seems silly: would it be reasonable to elide the /internal/
subdirectory?
Zellyn
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from
14 matches
Mail list logo
