Re: [go-nuts] Re: Upcoming Go protobuf release

Hi Joe, Thats, great to know! Thanks!! Regards dharani On Fri, May 4, 2018 at 10:40 AM Joe Tsai wrote: > The merge has happened on pull request #591 > . > > JT > > On Thu, May 3, 2018 at 4:01 PM Tharaneedharan Vilwanathan < >

Re: [go-nuts] Re: Upcoming Go protobuf release

The merge has happened on pull request #591 . JT On Thu, May 3, 2018 at 4:01 PM Tharaneedharan Vilwanathan < vdhar...@gmail.com> wrote: > Hi All, > > Can someone share some details on this code merge? Has this happened? How > can I play with it? > >

Re: [go-nuts] Re: Upcoming Go protobuf release

Hi All, Can someone share some details on this code merge? Has this happened? How can I play with it? Thanks dharani ** *Hello gophers,* *This is an announcement that we will be merging the dev branch of github.com/golang/protobuf into

Re: [go-nuts] Re: Upcoming Go protobuf release

I'm hugely in favor of bringing the gogoproto enhancements into golang/protobuf, as a spectator to this discussion. I'm not sure what requirements would put generated binary size over marshalling speed, but maybe I haven't worked on large enough projects yet. We have used gogoproto for about 2

Re: [go-nuts] Re: Upcoming Go protobuf release

I cannot recall that I have experienced these problems. The generated code has also been far easier to maintain than the runtime reflected code that is repeatedly patched by golang/protobuf. Except for import paths, this is probably one of the easiest projects a developer will get to work on. It

Re: [go-nuts] Re: Upcoming Go protobuf release

Surely these issues already exist in gogo-protobuf? How are they handled there? On Thu, Feb 1, 2018, 08:28 'Jisi Liu' via golang-nuts < golang-nuts@googlegroups.com> wrote: > This is not Java specific. I just used Java as an example. For most > protobuf implementations, there is a contract

Re: [go-nuts] Re: Upcoming Go protobuf release

This is not Java specific. I just used Java as an example. For most protobuf implementations, there is a contract between the runtime and generated code which is not meant to be public. e.g. In go-protobuf, runtime expects the generated classes define some internal fields, like XXX_unrecognized,

Re: [go-nuts] Re: Upcoming Go protobuf release

Could we perhaps get a code snippet example that non java programmers can follow. PS When I previously referred to java programmers as real software developers, I didn't add some much needed context. Sometimes in this java dominated world I personally don't feel like a real software developer.

Re: [go-nuts] Re: Upcoming Go protobuf release

On Wednesday, January 31, 2018 at 11:20:31 AM UTC-8, Walter Schulze wrote: > > Hi JT please see my inline replies. > > On Wed, 31 Jan 2018 at 19:05 wrote: > >> Thank you, Walter, for your support. >> >> > gogo/protobuf is disappointed that golang/protobuf still thinks

Re: [go-nuts] Re: Upcoming Go protobuf release

Hi JT please see my inline replies. On Wed, 31 Jan 2018 at 19:05 wrote: > Thank you, Walter, for your support. > > > gogo/protobuf is disappointed that golang/protobuf still thinks that > runtime reflection is an efficient way of serializing structures. > > The

[go-nuts] Re: Upcoming Go protobuf release

Thank you, Walter, for your support. > gogo/protobuf is disappointed that golang/protobuf still thinks that runtime reflection is an efficient way of serializing structures. The table-driven implementation avoids reflect in the fast and common path. Instead, are you referring to the fact that

[go-nuts] Re: Upcoming Go protobuf release

gogo/protobuf is happy to be acknowledged by Google as an entity in the golang protobuf space. gogo/protobuf welcomes golang/protobuf to the community and is extremely happy to see this kind of transparency. gogo/protobuf will also merge these changes and as usual try to stay as close as

[go-nuts] Re: Upcoming Go protobuf release

Done. I tagged v1.0.0. When we perform the merge in the future, it will be tagged as v1.1.0. On Tuesday, January 30, 2018 at 9:37:23 AM UTC-8, Alexey Palazhchenko wrote: > > Hi, > > Can you please add tags to the repository before that? SemVer or even tags > with _any_ semantic would greatly

[go-nuts] Re: Upcoming Go protobuf release

Awesome! Looking forward to try it out. El lunes, 29 de enero de 2018, 19:47:40 (UTC-3), Joe Tsai escribió: > > (If you don't use Go protocol buffers, you can stop reading) > > Hello gophers, > > This is an announcement that we will be merging the dev branch of > github.com/golang/protobuf

[go-nuts] Re: Upcoming Go protobuf release

Hi, Can you please add tags to the repository before that? SemVer or even tags with _any_ semantic would greatly help to rollback to the latest working version when things break. –-– Alexey «AlekSi» Palazhchenko -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: Upcoming Go protobuf release

Yes, although not as much as for proto3. The limiting factor for proto2 is the pervasive use of pointers to primitive fields. In order to improve that further, we will likely have to change the generated API for proto2. JT On Monday, January 29, 2018 at 10:45:55 PM UTC-8, Lee Armstrong wrote: