profile
viewpoint

google/go-cmp 2036

Package for comparing Go values in tests

cybrcodr/go-cloud 0

A library and tools for open cloud development in Go.

cybrcodr/protobuf 0

Go support for Google's protocol buffers

cybrcodr/txttools 0

Command line tools for processing text files

issue commentgolang/protobuf

[Question] Setup in Mac OSX

It looks like you’re trying to generate grpc code, which is no longer managed as a plugin to the protoc-gen-go binary, but rather is handled by a standalone google.golang.org/grpc/cmd/protoc-gen-go-grpc binary.

scheung38

comment created time in 3 hours

PR closed golang/protobuf

feat: rm omitempty
+46760 -2

2 comments

174 changed files

lpxxn

pr closed time in 7 hours

pull request commentgolang/protobuf

feat: rm omitempty

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

<!-- need_author_cla -->

lpxxn

comment created time in 7 hours

pull request commentgolang/protobuf

feat: rm omitempty

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

<!-- need_author_cla -->

lpxxn

comment created time in 7 hours

PR opened golang/protobuf

feat: rm omitempty
+46760 -2

0 comment

174 changed files

pr created time in 7 hours

issue commentgolang/protobuf

Documentation is a little misleading and it should be updated

This is because of the option --proto_path=src, which tells the compiler to consider filenames under src as relative to that directory.

The documentation here could probably be clearer.

yehudamakarov

comment created time in 8 hours

issue openedgolang/protobuf

Documentation is a little misleading and it should be updated

(Was redirected here at https://github.com/protocolbuffers/protobuf/issues/8090#issue-750929662)

See https://developers.google.com/protocol-buffers/docs/reference/go-generated#invocation

If the --go_opt=paths=source_relative flag is given to protoc, the output file is placed in the same relative directory as the input file. For example, the file protos/foo.proto results in a file named protos/foo.pb.go. When you run the proto compiler like this: protoc --proto_path=src --go_out=build/gen --go_opt=paths=source_relative src/foo.proto src/bar/baz.proto the compiler will read the files src/foo.proto and src/bar/baz.proto. It produces two output files: build/gen/foo.pb.go and build/gen/bar/baz.pb.go.

The problem here is

the output file is placed in the same relative directory as the input file

and then

It produces two output files: build/gen/foo.pb.go and build/gen/bar/baz.pb.go.

Why are the new files not placed where the docs say they should be placed i.e. src/ and are instead placed where the flag --go_out=build/gen dictates? It seems if both flags are provided there is special behavior where the compiler doesn't guess the output directory based on the package name, but it doesn't necessarily put the output files where --go_opt=paths=source_relative dictates they should go. Seems like the special behavior is when both are provided just use --go_out to calculate the output directory from the root.

Either way, can we please make this more clear? I can't find the repo for the google-developers documentation as it is probably not open.

created time in 11 hours

issue closedgolang/protobuf

How to import package in *.proto if project version is v2 with go mod

Hi,

I have upgraded my project to v2, but i meet unexpected result from *.protoc. In my go.mod file has defined:

module github.xxx/bbb/ccc/v2

go 1.13

*.proto

syntax = "proto3";

package pb;

import "google/api/annotations.proto";
import "github.xxx/bbb/ccc/v2/service/pb/types.proto";   <-- It's not working

Error message:

github.xxx/bbb/ccc/v2/service/pb/types.proto: File not found.

But!!! if i remove the version(v2) from import string, it works!

*.proto

syntax = "proto3";

package pb;

import "google/api/annotations.proto";
import "github.xxx/bbb/ccc/service/pb/types.proto";   <-- It's works.

Is there a better way to solve this?

closed time in 12 hours

bailantaotao

issue commentgolang/protobuf

How to import package in *.proto if project version is v2 with go mod

Thank you very much!

bailantaotao

comment created time in 12 hours

issue closedgolang/protobuf

No documentation about go_package option

Hi, I tried to understand what protobuf option option go_package = ".;types" do. But seems like protobuf have no documentation about it. Maybe we need to add?

We have only an old issue explaining this https://github.com/golang/protobuf/issues/139

closed time in 18 hours

komly

issue commentgolang/protobuf

No documentation about go_package option

@neild Big thanks for documenting, this is just what I needed.

komly

comment created time in 18 hours

issue openedgolang/protobuf

[Question] Setup in Mac OSX

Getting

.zshrc file:

export GOPATH=$HOME/golib export PATH=$PATH:$GOPATH/bin export GOPATH=$GOPATH:$HOME/go

which go: /usr/local/bin/go

go version: go version go1.15.5 darwin/amd64

Mac OSX: Big Sur 11.0.1

messages.proto:

syntax = "proto3";

option go_package = "github.com/ps/hellogrpc/messages";

message HelloRequest { string Name = 1; }

message HelloResponse { string Message = 1; }

service HelloService { rpc SayHello (HelloRequest) returns (HelloResponse) {} }

protoc pb/messages.proto --go_out=plugins=grpc:go/src

--go_out: protoc-gen-go: Plugin failed with status code 1.

so tried:

➜ code protoc pb/messages.proto --go_out=plugins=grpc:go/src

created time in a day

issue commentgolang/protobuf

How to import package in *.proto if project version is v2 with go mod

The import paths for protoc and go differ in this regard. Since protoc has to accommodate all languages, not just Go, protoc is unaware of any go module pseudo-path-elements introduced by versioning.

In short, you’re not importing this file through go, so go module versioning is irrelevant to the import path.

bailantaotao

comment created time in a day

issue commentgolang/protobuf

No documentation about go_package option

I just updated the documentation at https://developers.google.com/protocol-buffers/docs/reference/go-generated#package with a bit more detail on go_package.

The go_package option should contain the full import path of the Go package which contains the generated code for the .proto file. The Go package name will be derived from the last path component of the import path. The package name may be overridden by appending ;<package_name> to the go_package option, but this should be seldom, if ever used, since Go package names should almost always be directly related to the package import path.

option go_package = ".;types" states that the Go import path is "." and the Go package name is types. Since an import path of "." is clearly incorrect, this is not a reasonable value for the go_package option.

If a tutorial is suggesting that value for the go_package option, the tutorial should be fixed.

komly

comment created time in a day

issue openedgolang/protobuf

How to import package in *.proto if project version is v2 with go mod

Hi,

I have upgraded my project to v2, but i meet unexpected result from *.protoc. In my go.mod file has defined:

module github.xxx/bbb/ccc/v2

go 1.13

*.proto

syntax = "proto3";

package pb;

import "google/api/annotations.proto";
import "github.xxx/bbb/ccc/v2/service/pb/types.proto";   <-- It's not working

Error message:

github.xxx/bbb/ccc/v2/service/pb/types.proto: File not found.

But!!! if i remove the version(v2) from import string, it works!

*.proto

syntax = "proto3";

package pb;

import "google/api/annotations.proto";
import "github.xxx/bbb/ccc/service/pb/types.proto";   <-- It's works.

Is there a better way to solve this?

created time in a day

issue commentgolang/protobuf

No documentation about go_package option

Screenshot 2020-12-02 at 02 51 21

komly

comment created time in 2 days

issue commentgolang/protobuf

No documentation about go_package option

@dsnet in this docs no mention about the meaning of first and second part of option value "first;second". But if you will just follow any tutorial you will see the hint while generating: please add option go_package = ".;types"

komly

comment created time in 2 days

issue commentgolang/protobuf

No documentation about go_package option

It's documented at https://developers.google.com/protocol-buffers/docs/gotutorial#defining-your-protocol-format and https://developers.google.com/protocol-buffers/docs/reference/go-generated#invocation.

The godoc package page for protoc-gen-go has little documentation for how it operates since it points to https://developers.google.com/protocol-buffers/ which has more comprehensive documentation about the invocation of protoc and the meaning of .proto options.

I should note that go_package = ".;types" is a non-sensible value since it should be set to the Go import path for the Go package that is generated for that .proto file. An import path of . is pretty meaningless.

komly

comment created time in 2 days

issue openedgolang/protobuf

No documentation about go_package option

Hi, I tried to understand what protobuf option option go_package = ".;types" do. But seems like protobuf have no documentation about it. Maybe we need to add?

We have only an old issue explaining this https://github.com/golang/protobuf/issues/139

created time in 2 days

issue closedgolang/protobuf

protoreflect: setting a map / repeated field

I need to set an arbitrary field of a proto message. Unfortunately, for repeated fields and maps this is not straightforward. The code below:

message.Set(field, protoreflect.ValueOf(value))

... panics here with the message: invalid type: []string.

It seems that Converter allows conversion between reflect.Value and protoreflect.Value for all values including maps and lists, but it's in an internal package... Would this be a good candidate for exposing as public?

Or perhaps there's an easy way to accomplish this that I've missed?

@dsnet

closed time in 2 days

dave

issue commentgolang/protobuf

protoreflect: setting a map / repeated field

Closing as working as intended.

dave

comment created time in 2 days

issue commentgolang/protobuf

reflect/protoregistry: conflicts with same filename

I receive these warnings now on and older project I just came back to after a year. This project had been having no issues but, since I've come back I've made the following updates:

  • using go.mod instead of gopath
  • using a new protoc
  • using a new grpc protoc lib
  • using the old proto package that is now using the new proto package underneath
  • added go_package to my protos that I did not use before

This is happening in a layout model I was using that had components setup such as:

componentA/ io/ io.proto componentB/ io/ io.proto

So now I'm getting the: WARNING: proto: file "io.proto" is already registered, A future release will panic on registration conflicts

I also moved to using go_package as well with dsymonds overloading setup, for example:

package marmot.example.scripts.juniper_password_change.ssh;

option go_package = "github.com/bearlytools/bearmetal/framework/examples/scripts/juniper_password_change/cogs/ssh/io;io";

I'm sure I haven't thought of a million different ways this could break or is undesirable, but could we avoid this conflict by registering using the go_package full path with a flag passed, like --register_using_go_package? I'm sure this has some undesirable behavior, but I'm 100% sure neild is right, that there is probably just no great solution.

guyguy333

comment created time in 4 days

created taggoogle/go-cmp

tagv0.5.4

Package for comparing Go values in tests

created time in 9 days

release google/go-cmp

v0.5.4

released time in 9 days

delete branch google/go-cmp

delete branch : map-limit

delete time in 9 days

push eventgoogle/go-cmp

Joe Tsai

commit sha ec71d6d790538ad88c95a192fd059e11afb45b6f

Impose verbosity limit when formatting map keys (#248) Map keys should have a sensible verbosity limit imposed, otherwise the reporter can end up printing a massive data structure that cannot reasonably fit in memory.

view details

push time in 9 days

PR merged google/go-cmp

Impose verbosity limit when formatting map keys

Map keys should have a sensible verbosity limit imposed, otherwise the reporter can end up printing a massive data structure that cannot reasonably fit in memory.

Fixes #245

+19 -0

0 comment

3 changed files

dsnet

pr closed time in 9 days

issue closedgoogle/go-cmp

Reporter should be more aggressive about pruning output

The following snippet hangs:

mx := &descriptorpb.FileDescriptorProto{Name: proto.String("descriptor.proto")}
my := &descriptorpb.FileDescriptorProto{Name: proto.String("descriptor.proto")}

x := map[*descriptorpb.FileDescriptorProto]int{mx: 1}
y := map[*descriptorpb.FileDescriptorProto]int{my: 1}

cmp.Diff(x, y)

These two objects are inequal since map keys use == and not a recursive application of cmp.Equal. It hangs because cmp.Diff is trying to format the raw data structure for a descriptorpb.FileDescriptorProto. Since descriptorpb.FileDescriptorProto has a pointer to the protobuf type information, which itself closes over the transitive set of reachable protobuf types, this is a massive data structure. The reporter logic should be more aggressive about pruning the formatted value.

closed time in 9 days

dsnet

push eventgoogle/go-cmp

Joe Tsai

commit sha 449e17c6c9daf9b0c84a35fef7d79321b9535763

Fix non-determinism in diffing algorithm (#247) A previous attempt to add non-determinism to the diffing algorithm unfortunately broke the algorithm for half the cases. This change modifies the algorithm to truly switch between starting with a forward search versus a reverse search. The main for-loop of Difference would switch repeatedly between performing a forward search, then a reverse search, and vice-versa. Since we can't jump into the middle of a for-loop to start with the reverse search first, we use a series of labels and goto statements to accomplish the same effect. Fixes #238

view details

Joe Tsai

commit sha 316b1564a0a918e6fe66e7d185c0370988e3f6d3

Merge branch 'master' into map-limit

view details

push time in 9 days

delete branch google/go-cmp

delete branch : randdiff

delete time in 9 days

more