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

[Henrik Johansson]

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 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, and  XXX_sizecache.
>
> If we are moving from table-driven to codegen, then I guess there will be
> more contracts between the runtime and generated code, and potentially
> introduce contracts also between the containing message and embedded
> message fields - you probably want to extract duplicate methods into
> runtime to save code size, and the generate code needs to deal with
> submessages itself.  This is my primary concern.
>
> In a single repo development model, someone can change such contract as
> long as they change the protoc-gen and the runtime library at the same
> time. However, in open source, such change can cause dependency-hell
> issues as the different
> versions of generated protobufs are no-longer compatible with each other
> and/or with the runtime. With a more tightly coupled model, we are more
> prone to such issue.
>
> One way to solve this is to make the runtime support all the previous
> versions of the contract indefinitely and be always backward compatible.
> Then users can switch to the newest runtime to support all the old
> libraries. We are following this approach in protobuf-java 3.x, which
> causes lots of dev overhead. I'm a bit worried that we would need to do the
> same for Go, if we go with the code-gen approach.
>
>
> On Wed, Jan 31, 2018 at 10:25 PM Walter Schulze 
> wrote:
>
>> 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.
>>
>> On Wed, 31 Jan 2018, 21:44 liujisi via golang-nuts, <
>> golang-nuts@googlegroups.com> wrote:
>>
>>>
>>>
>>> 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 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 we don't perform
> full-code generation of Marshal/Unmarshal like what gogo/protobuf does? We
> are aware that full-code generation will often out-perform the 
> table-driven
> approach we took. However, full code-generation drastically bloats the
> binary size when you have many proto messages linked in. Keeping the 
> binary
> size smaller was an important design decision for us and seemed to be a
> better default.
>

 Yes, I was referring to the speed of code generation over runtime
 reflection.
 What I struggle to understand is why the optimize_for file option that
 is part of proto 2 and 3 is not considered by golang/protobuf as a way to
 specify when code generation should be used over runtime reflection.
 This seems to work for most other languages, including Java, which I
 heard is quite popular among real software developers.

>>>
>>> Note that the code-generation approach used by other languages (mostly
>>> C++/Java) has its own problem. Mostly because of the tight coupling among
>>> generated code, runtime and embedded sub messages (generated by a different
>>> party using a different version of protoc). These problem don't exist
>>> inside of google as we use a single repo build system, but it cause
>>> significant issues in opensource. For instance, Hadoop is still shipping
>>> protobuf v2.5 generated code which is incompatible with later version of
>>> protobufs. All the projects using Hadoop are then version locked to v2.5,
>>> as an upgrade in any project (including Hadoop itself) will break the
>>> build. Version upgrade can only happen when all the transitive dependency
>>> closure upgrade together atomically.
>>>
>>> We solve this problem in protobuf-java v3.0+ by introducing ABI
>>> backward/forward compatibility guarantees on generated code and runtime.
>>> However, this introduced lots of overhead on code maintenance, reduced
>>> development velocity and limited the change we could do.  We are now
>>> solving the issue by introduce table driven to Java. The recent benchmark
>>> result showed 

[go-nuts] question

[王晚成]

hello my dear friend Google man:
I have some questions.

type Point struct{
x int
   y  int
}

func (p *Point) hehe(i  int) {
  p.x = i
  p.y = i
}

func main(){
  Point{1,2}.hehe(4) // compile error: can't take address of Point literal
}

The book says that there’s no way to obtain the address of a temporary
value.

but
 ( {1,2}).hehe(4)  //sucessed

why & can obtain the address of a temporay value?

thanks

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] unused import and variables, necessary at compiler level? Experience can be improved?

[Jan Mercl]

On Thu, Feb 1, 2018 at 3:46 AM Alex Buchanan 
wrote:

Put this line into any of the package *_test.go files:

func use(...interface{}) {}

When disabling some code in non-test files leads to unused variables foo
and baz error, insert `use(foo, bar)` there to keep the compiler happy. You
cannot forget the use invocation in production code as it is defined only
when `go test` is building the program.

I have it included in my all_test
.go
template.
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Jisi Liu' via golang-nuts]

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, and  XXX_sizecache.

If we are moving from table-driven to codegen, then I guess there will be
more contracts between the runtime and generated code, and potentially
introduce contracts also between the containing message and embedded
message fields - you probably want to extract duplicate methods into
runtime to save code size, and the generate code needs to deal with
submessages itself.  This is my primary concern.

In a single repo development model, someone can change such contract as
long as they change the protoc-gen and the runtime library at the same
time. However, in open source, such change can cause dependency-hell
issues as the different
versions of generated protobufs are no-longer compatible with each other
and/or with the runtime. With a more tightly coupled model, we are more
prone to such issue.

One way to solve this is to make the runtime support all the previous
versions of the contract indefinitely and be always backward compatible.
Then users can switch to the newest runtime to support all the old
libraries. We are following this approach in protobuf-java 3.x, which
causes lots of dev overhead. I'm a bit worried that we would need to do the
same for Go, if we go with the code-gen approach.


On Wed, Jan 31, 2018 at 10:25 PM Walter Schulze 
wrote:

> 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.
>
> On Wed, 31 Jan 2018, 21:44 liujisi via golang-nuts, <
> golang-nuts@googlegroups.com> wrote:
>
>>
>>
>> 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 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 we don't perform
 full-code generation of Marshal/Unmarshal like what gogo/protobuf does? We
 are aware that full-code generation will often out-perform the table-driven
 approach we took. However, full code-generation drastically bloats the
 binary size when you have many proto messages linked in. Keeping the binary
 size smaller was an important design decision for us and seemed to be a
 better default.

>>>
>>> Yes, I was referring to the speed of code generation over runtime
>>> reflection.
>>> What I struggle to understand is why the optimize_for file option that
>>> is part of proto 2 and 3 is not considered by golang/protobuf as a way to
>>> specify when code generation should be used over runtime reflection.
>>> This seems to work for most other languages, including Java, which I
>>> heard is quite popular among real software developers.
>>>
>>
>> Note that the code-generation approach used by other languages (mostly
>> C++/Java) has its own problem. Mostly because of the tight coupling among
>> generated code, runtime and embedded sub messages (generated by a different
>> party using a different version of protoc). These problem don't exist
>> inside of google as we use a single repo build system, but it cause
>> significant issues in opensource. For instance, Hadoop is still shipping
>> protobuf v2.5 generated code which is incompatible with later version of
>> protobufs. All the projects using Hadoop are then version locked to v2.5,
>> as an upgrade in any project (including Hadoop itself) will break the
>> build. Version upgrade can only happen when all the transitive dependency
>> closure upgrade together atomically.
>>
>> We solve this problem in protobuf-java v3.0+ by introducing ABI
>> backward/forward compatibility guarantees on generated code and runtime.
>> However, this introduced lots of overhead on code maintenance, reduced
>> development velocity and limited the change we could do.  We are now
>> solving the issue by introduce table driven to Java. The recent benchmark
>> result showed performance on par for android platforms, and hopefully we
>> can release the new implementation in a few months.
>>
>> For Go, if we are going to introduce full generated code, I'd strongly
>> recommend considering those complications. Major version bump is also
>> expensive for protobufs as all the dependency libraries 

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

[Walter Schulze]

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.

On Wed, 31 Jan 2018, 21:44 liujisi via golang-nuts, <
golang-nuts@googlegroups.com> wrote:

>
>
> 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 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 we don't perform
>>> full-code generation of Marshal/Unmarshal like what gogo/protobuf does? We
>>> are aware that full-code generation will often out-perform the table-driven
>>> approach we took. However, full code-generation drastically bloats the
>>> binary size when you have many proto messages linked in. Keeping the binary
>>> size smaller was an important design decision for us and seemed to be a
>>> better default.
>>>
>>
>> Yes, I was referring to the speed of code generation over runtime
>> reflection.
>> What I struggle to understand is why the optimize_for file option that is
>> part of proto 2 and 3 is not considered by golang/protobuf as a way to
>> specify when code generation should be used over runtime reflection.
>> This seems to work for most other languages, including Java, which I
>> heard is quite popular among real software developers.
>>
>
> Note that the code-generation approach used by other languages (mostly
> C++/Java) has its own problem. Mostly because of the tight coupling among
> generated code, runtime and embedded sub messages (generated by a different
> party using a different version of protoc). These problem don't exist
> inside of google as we use a single repo build system, but it cause
> significant issues in opensource. For instance, Hadoop is still shipping
> protobuf v2.5 generated code which is incompatible with later version of
> protobufs. All the projects using Hadoop are then version locked to v2.5,
> as an upgrade in any project (including Hadoop itself) will break the
> build. Version upgrade can only happen when all the transitive dependency
> closure upgrade together atomically.
>
> We solve this problem in protobuf-java v3.0+ by introducing ABI
> backward/forward compatibility guarantees on generated code and runtime.
> However, this introduced lots of overhead on code maintenance, reduced
> development velocity and limited the change we could do.  We are now
> solving the issue by introduce table driven to Java. The recent benchmark
> result showed performance on par for android platforms, and hopefully we
> can release the new implementation in a few months.
>
> For Go, if we are going to introduce full generated code, I'd strongly
> recommend considering those complications. Major version bump is also
> expensive for protobufs as all the dependency libraries would have to bump
> their major version too.
>
>
>>
>>
>>>
>>> We are open to considering an option that allows user to specify
>>> full-code generation for select messages.
>>>
>>
>> This is exactly what gogo/protobuf allows users to do.
>> Using protobuf extensions gogo/protobuf allows the user to specify per
>> message or file whether they want to generate marshalers, unmarshalers, etc.
>> A user can also create a vanity binary to generate these methods if you
>> do not wish to use extensions and want to enforce a specific style across
>> and organization.
>>
>>
>>>
>>> > gogo/protobuf is still open to being merged back into golang/protobuf
>>> and has been since its inception 5 years ago.
>>>
>>> That is good to hear. I have not yet gone through all of gogo/protobuf
>>> to determine what it would to merge, or what should be merged. This will be
>>> future work.
>>>
>>
>> gogo/protobuf is also be open to only being partly merged.
>>
>> One other major advantage of gogo/protobuf is generating the structures
>> you want to use, by allowing you to modify the generated structure using
>> protobuf extensions like customtype.
>> This way you can avoid copying between the protobuf generated structure
>> and a user defined go structure that you actually want to use.
>> This is a huge speed and safety gain and probably the most important
>> feature of gogo/protobuf.
>> proto3 has addressed the biggest concern by allowing the generation of
>> fields without pointers, but there are other cases as well, including
>> casttype, customname for generating more lintable code and even not
>> generating the structure at all, for ultimate customization.
>> I would hope that merging some of these ideas will also be on the 

[go-nuts] auto-correct a speech-to-text output and relate to of the words based on syllables

[naveen]

Hi,

I have to make an application in which, 


   - The user asks a question, Google's API is used to convert the speech 
   to text. But the problem is due to different accent the translator 
   misunderstands the words. 
   - I want my application to guess the word to the nearest word spoken by 
   the user. 
   - When the user speaks a word, the syllables in the word should be 
   matched with the syllables of other words in my dictionary. 

Till now what I have done,

   - I used CMU pronouncing dictionary. It contains ~122300 words along 
   with its syllables.
   - Along with this, I have created my own dictionary which consists of 
   words that I need only.
   - I have implemented a python logic that makes reasonable guesses for 
   the words user speaks and matches with my dictionary.
   - But sometimes for more than a word it makes the same guess.
  - example:
 - The user speaks "Light". The system translates it as "Bright"
 - The user speaks "White" The system translates it as "Bright"
  
I don't want this to happen. This system should make a reasonable 
conversion.

Any help would be appreciated.

Regards,
Naveen BM

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] unused import and variables, necessary at compiler level? Experience can be improved?

[Alex Buchanan]

Unused variables and imports are strictly disallowed by the Go compiler. 
Most of the time, I enjoy this benefit. These days, I've started to notice 
how often things go dead and/or unused in my python code.

But, sometimes, this behavior is incredibly annoying. If I'm trying to 
debug something by commenting out lines, or if I'm hacking up an 
experimental script (meant to run with `go run`), I find this checking is 
very unwanted. For example, if I comment out one variable, it may lead to a 
new set of variables being unused, which sometimes leads back to a package 
being unused. It's not uncommon for this cycle to take 3-5 iterations, in 
my experience.

Quickly hacking up Go scripts would be improved by relaxing this 
constraint, in my opinion.

Is finding a better compromise at all interesting or even possible? Are 
parts of the compiler written to depend on the fact that variables are 
definitely used?

My idea for a potential improvement (again, having zero knowledge of the 
compiler requirements) is to move this checking to vet.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: GOTCHA: Just when you think you understand interfaces

['simon place' via golang-nuts]

also notice, if you haven’t encountered it, this makes []interfaces a bit 
awkward to handle with ellipsis functions...

https://play.golang.org/p/JWuc4jt2uSP

what i do is this; 

https://play.golang.org/p/O9Q4K_vXlul

but you will need a convert for all combinations of interfaces and ellipsis 
functions you have!

from what i understand ellipsis functions are implemented simply as 
auto-magic slices, rather than expanded out, so the function doesn’t apply 
the interface wrapping like with individual parameters.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[liujisi via golang-nuts]

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 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 we don't perform 
>> full-code generation of Marshal/Unmarshal like what gogo/protobuf does? We 
>> are aware that full-code generation will often out-perform the table-driven 
>> approach we took. However, full code-generation drastically bloats the 
>> binary size when you have many proto messages linked in. Keeping the binary 
>> size smaller was an important design decision for us and seemed to be a 
>> better default.
>>
>
> Yes, I was referring to the speed of code generation over runtime 
> reflection.
> What I struggle to understand is why the optimize_for file option that is 
> part of proto 2 and 3 is not considered by golang/protobuf as a way to 
> specify when code generation should be used over runtime reflection.
> This seems to work for most other languages, including Java, which I heard 
> is quite popular among real software developers.
>

Note that the code-generation approach used by other languages (mostly 
C++/Java) has its own problem. Mostly because of the tight coupling among 
generated code, runtime and embedded sub messages (generated by a different 
party using a different version of protoc). These problem don't exist 
inside of google as we use a single repo build system, but it cause 
significant issues in opensource. For instance, Hadoop is still shipping 
protobuf v2.5 generated code which is incompatible with later version of 
protobufs. All the projects using Hadoop are then version locked to v2.5, 
as an upgrade in any project (including Hadoop itself) will break the 
build. Version upgrade can only happen when all the transitive dependency 
closure upgrade together atomically.

We solve this problem in protobuf-java v3.0+ by introducing ABI 
backward/forward compatibility guarantees on generated code and runtime. 
However, this introduced lots of overhead on code maintenance, reduced 
development velocity and limited the change we could do.  We are now 
solving the issue by introduce table driven to Java. The recent benchmark 
result showed performance on par for android platforms, and hopefully we 
can release the new implementation in a few months.

For Go, if we are going to introduce full generated code, I'd strongly 
recommend considering those complications. Major version bump is also 
expensive for protobufs as all the dependency libraries would have to bump 
their major version too.
 

>  
>
>>
>> We are open to considering an option that allows user to specify 
>> full-code generation for select messages.
>>
>
> This is exactly what gogo/protobuf allows users to do.
> Using protobuf extensions gogo/protobuf allows the user to specify per 
> message or file whether they want to generate marshalers, unmarshalers, etc.
> A user can also create a vanity binary to generate these methods if you do 
> not wish to use extensions and want to enforce a specific style across and 
> organization.
>  
>
>>
>> > gogo/protobuf is still open to being merged back into golang/protobuf 
>> and has been since its inception 5 years ago.
>>
>> That is good to hear. I have not yet gone through all of gogo/protobuf to 
>> determine what it would to merge, or what should be merged. This will be 
>> future work.
>>
>
> gogo/protobuf is also be open to only being partly merged.
>
> One other major advantage of gogo/protobuf is generating the structures 
> you want to use, by allowing you to modify the generated structure using 
> protobuf extensions like customtype.
> This way you can avoid copying between the protobuf generated structure 
> and a user defined go structure that you actually want to use.
> This is a huge speed and safety gain and probably the most important 
> feature of gogo/protobuf.
> proto3 has addressed the biggest concern by allowing the generation of 
> fields without pointers, but there are other cases as well, including 
> casttype, customname for generating more lintable code and even not 
> generating the structure at all, for ultimate customization.
> I would hope that merging some of these ideas will also be on the table.
>
> Looking forward to working together for a change
> Please let me know how I can help
>
> Skeptically hopeful about a new era for protobufs in Go
> Walter Schulze
>  
>
>>
>> JT
>>
>> On Wednesday, January 31, 2018 at 7:13:38 AM UTC-8, Walter Schulze wrote:
>>>
>>> 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 
>>> 

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

[matthewjuran]

Converting []tmpType to []Useable: https://play.golang.org/p/u3WUOEopku9

I'm not sure I understand, but if you can make an exhaustive list of 
possible input slice types and an element can assert to Useable then the 
elements can be copied into a []Useable.

Matt

On Wednesday, January 31, 2018 at 11:52:57 AM UTC-6, Chris Hopkins wrote:
>
> Okay well the actual (working version) of the code (before I wrote the 
> test cases that are currently failing/not compiling) is here (I refuse to 
> check in broken code):
> https://github.com/cbehopkins/permutation/blob/master/helpers.go
>
> The source library (permutation) can cope with permutes on arrays of 
> arbitrary type as long as you supply a Less function. I'm trying to extend 
> the test cases so anything other than int type is tested.
> I've long preached that is you're using reflect you're probably doing it. 
> I know the source library uses reflect for these things, I'm trying to 
> avoid it.
>
> I just can't see a different way to do it.
>
> Thanks
> Chris
>
> On Wednesday, 31 January 2018 17:46:51 UTC, Axel Wagner wrote:
>>
>> FTR, you can also pass an actual []Usable, instead of a []tmpType. That 
>> is do
>> https://play.golang.org/p/N_CJh0Ekik8
>> But I do think that your code and question suggest that you are trying to 
>> use interfaces to do some sort of subtyping, which is just not how they are 
>> supposed to be used.
>>
>> On Wed, Jan 31, 2018 at 6:43 PM, Axel Wagner  
>> wrote:
>>
>>> You have to use reflection for that. Go doesn't have subtyping of that 
>>> kind. This smells a bit of an xy-problem  to 
>>> me, though. There are several things here, that suggest an antipattern 
>>> going on. With a little bit of context on the actual problem you are trying 
>>> to solve, we might be able to come up with a more idiomatic design.
>>>
>>> On Wed, Jan 31, 2018 at 6:37 PM, Chris Hopkins  
>>> wrote:
>>>
 Hi
 Sharing my ignorance:
 I didn't realise that although you can switch-case on an interface, an 
 array of interfaces doesn't work.
 https://play.golang.org/p/tD8msjCXyuZ

 Any ideas on how to cope with this? I tried:
 _, ok = tmp.([]Useable)

 But that fails for the same reason. I can't work out how to detect if 
 the type (of the empty interface) is an array of a type that satisfies the 
 (useful) interface.
 This must be a common problem and PEBKAC surely?

 Regards

 Chris

 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Walter Schulze]

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 table-driven implementation avoids reflect in the fast and common
> path. Instead, are you referring to the fact that we don't perform
> full-code generation of Marshal/Unmarshal like what gogo/protobuf does? We
> are aware that full-code generation will often out-perform the table-driven
> approach we took. However, full code-generation drastically bloats the
> binary size when you have many proto messages linked in. Keeping the binary
> size smaller was an important design decision for us and seemed to be a
> better default.
>

Yes, I was referring to the speed of code generation over runtime
reflection.
What I struggle to understand is why the optimize_for file option that is
part of proto 2 and 3 is not considered by golang/protobuf as a way to
specify when code generation should be used over runtime reflection.
This seems to work for most other languages, including Java, which I heard
is quite popular among real software developers.


>
> We are open to considering an option that allows user to specify full-code
> generation for select messages.
>

This is exactly what gogo/protobuf allows users to do.
Using protobuf extensions gogo/protobuf allows the user to specify per
message or file whether they want to generate marshalers, unmarshalers, etc.
A user can also create a vanity binary to generate these methods if you do
not wish to use extensions and want to enforce a specific style across and
organization.


>
> > gogo/protobuf is still open to being merged back into golang/protobuf
> and has been since its inception 5 years ago.
>
> That is good to hear. I have not yet gone through all of gogo/protobuf to
> determine what it would to merge, or what should be merged. This will be
> future work.
>

gogo/protobuf is also be open to only being partly merged.

One other major advantage of gogo/protobuf is generating the structures you
want to use, by allowing you to modify the generated structure using
protobuf extensions like customtype.
This way you can avoid copying between the protobuf generated structure and
a user defined go structure that you actually want to use.
This is a huge speed and safety gain and probably the most important
feature of gogo/protobuf.
proto3 has addressed the biggest concern by allowing the generation of
fields without pointers, but there are other cases as well, including
casttype, customname for generating more lintable code and even not
generating the structure at all, for ultimate customization.
I would hope that merging some of these ideas will also be on the table.

Looking forward to working together for a change
Please let me know how I can help

Skeptically hopeful about a new era for protobufs in Go
Walter Schulze


>
> JT
>
> On Wednesday, January 31, 2018 at 7:13:38 AM UTC-8, Walter Schulze wrote:
>>
>> 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 possible to golang/protobuf,
>> including also following the same version tagging.
>>
>> gogo/protobuf is disappointed that golang/protobuf still thinks that
>> runtime reflection is an efficient way of serializing structures.
>>
>> go Green go GoGoProtobuf
>>
>> PS
>>
>> gogo/protobuf is still open to being merged back into golang/protobuf and
>> has been since its inception 5 years ago.
>> gogo/protobuf feels for its users, especially those that are not
>> acknowledged by grpc-gateway and grpc-go,
>> and forced to employ work arounds, to preserve their missions of safety
>> and efficiency.
>> It knows that its existence is not something that anyone prefers, and it
>> welcomes death,
>> but only if it can preserve its legacy of fast serailization and
>> generating the structures you want to use.
>>
>>
>> On Tuesday, 30 January 2018 23:44:37 UTC+1, joe...@google.com wrote:
>>>
>>> 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 help to rollback to the latest
 working version when things break.

 –-–
 Alexey «AlekSi» Palazhchenko

 --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/F5xFHTfwRnY/unsubscribe.
> To unsubscribe from this 

[go-nuts] Re: Upcoming Go protobuf release

[thebrokentoaster]

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 we don't perform full-code 
generation of Marshal/Unmarshal like what gogo/protobuf does? We are aware 
that full-code generation will often out-perform the table-driven approach 
we took. However, full code-generation drastically bloats the binary size 
when you have many proto messages linked in. Keeping the binary size 
smaller was an important design decision for us and seemed to be a better 
default.

We are open to considering an option that allows user to specify full-code 
generation for select messages.

> gogo/protobuf is still open to being merged back into golang/protobuf and 
has been since its inception 5 years ago.

That is good to hear. I have not yet gone through all of gogo/protobuf to 
determine what it would to merge, or what should be merged. This will be 
future work.

JT

On Wednesday, January 31, 2018 at 7:13:38 AM UTC-8, Walter Schulze wrote:
>
> 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 possible to golang/protobuf, 
> including also following the same version tagging.
>
> gogo/protobuf is disappointed that golang/protobuf still thinks that 
> runtime reflection is an efficient way of serializing structures.
>
> go Green go GoGoProtobuf
>
> PS
>
> gogo/protobuf is still open to being merged back into golang/protobuf and 
> has been since its inception 5 years ago.
> gogo/protobuf feels for its users, especially those that are not 
> acknowledged by grpc-gateway and grpc-go,
> and forced to employ work arounds, to preserve their missions of safety 
> and efficiency.
> It knows that its existence is not something that anyone prefers, and it 
> welcomes death, 
> but only if it can preserve its legacy of fast serailization and 
> generating the structures you want to use.
>
>
> On Tuesday, 30 January 2018 23:44:37 UTC+1, joe...@google.com wrote:
>>
>> 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 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 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

['Axel Wagner' via golang-nuts]

It seems that https://godoc.org/sort#Interface is the way to go here. You
can combine it with reflect.Swapper to get an API like
https://godoc.org/sort#Slice

On Wed, Jan 31, 2018 at 6:52 PM, Chris Hopkins  wrote:

> Okay well the actual (working version) of the code (before I wrote the
> test cases that are currently failing/not compiling) is here (I refuse to
> check in broken code):
> https://github.com/cbehopkins/permutation/blob/master/helpers.go
>
> The source library (permutation) can cope with permutes on arrays of
> arbitrary type as long as you supply a Less function. I'm trying to extend
> the test cases so anything other than int type is tested.
> I've long preached that is you're using reflect you're probably doing it.
> I know the source library uses reflect for these things, I'm trying to
> avoid it.
>
> I just can't see a different way to do it.
>
> Thanks
> Chris
>
> On Wednesday, 31 January 2018 17:46:51 UTC, Axel Wagner wrote:
>>
>> FTR, you can also pass an actual []Usable, instead of a []tmpType. That
>> is do
>> https://play.golang.org/p/N_CJh0Ekik8
>> But I do think that your code and question suggest that you are trying to
>> use interfaces to do some sort of subtyping, which is just not how they are
>> supposed to be used.
>>
>> On Wed, Jan 31, 2018 at 6:43 PM, Axel Wagner 
>> wrote:
>>
>>> You have to use reflection for that. Go doesn't have subtyping of that
>>> kind. This smells a bit of an xy-problem  to
>>> me, though. There are several things here, that suggest an antipattern
>>> going on. With a little bit of context on the actual problem you are trying
>>> to solve, we might be able to come up with a more idiomatic design.
>>>
>>> On Wed, Jan 31, 2018 at 6:37 PM, Chris Hopkins 
>>> wrote:
>>>
 Hi
 Sharing my ignorance:
 I didn't realise that although you can switch-case on an interface, an
 array of interfaces doesn't work.
 https://play.golang.org/p/tD8msjCXyuZ

 Any ideas on how to cope with this? I tried:
 _, ok = tmp.([]Useable)

 But that fails for the same reason. I can't work out how to detect if
 the type (of the empty interface) is an array of a type that satisfies the
 (useful) interface.
 This must be a common problem and PEBKAC surely?

 Regards

 Chris

 --
 You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

[Chris Hopkins]

Okay well the actual (working version) of the code (before I wrote the test 
cases that are currently failing/not compiling) is here (I refuse to check 
in broken code):
https://github.com/cbehopkins/permutation/blob/master/helpers.go

The source library (permutation) can cope with permutes on arrays of 
arbitrary type as long as you supply a Less function. I'm trying to extend 
the test cases so anything other than int type is tested.
I've long preached that is you're using reflect you're probably doing it. I 
know the source library uses reflect for these things, I'm trying to avoid 
it.

I just can't see a different way to do it.

Thanks
Chris

On Wednesday, 31 January 2018 17:46:51 UTC, Axel Wagner wrote:
>
> FTR, you can also pass an actual []Usable, instead of a []tmpType. That is 
> do
> https://play.golang.org/p/N_CJh0Ekik8
> But I do think that your code and question suggest that you are trying to 
> use interfaces to do some sort of subtyping, which is just not how they are 
> supposed to be used.
>
> On Wed, Jan 31, 2018 at 6:43 PM, Axel Wagner  > wrote:
>
>> You have to use reflection for that. Go doesn't have subtyping of that 
>> kind. This smells a bit of an xy-problem  to me, 
>> though. There are several things here, that suggest an antipattern going 
>> on. With a little bit of context on the actual problem you are trying to 
>> solve, we might be able to come up with a more idiomatic design.
>>
>> On Wed, Jan 31, 2018 at 6:37 PM, Chris Hopkins > > wrote:
>>
>>> Hi
>>> Sharing my ignorance:
>>> I didn't realise that although you can switch-case on an interface, an 
>>> array of interfaces doesn't work.
>>> https://play.golang.org/p/tD8msjCXyuZ
>>>
>>> Any ideas on how to cope with this? I tried:
>>> _, ok = tmp.([]Useable)
>>>
>>> But that fails for the same reason. I can't work out how to detect if 
>>> the type (of the empty interface) is an array of a type that satisfies the 
>>> (useful) interface.
>>> This must be a common problem and PEBKAC surely?
>>>
>>> Regards
>>>
>>> Chris
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

['Axel Wagner' via golang-nuts]

FTR, you can also pass an actual []Usable, instead of a []tmpType. That is
do
https://play.golang.org/p/N_CJh0Ekik8
But I do think that your code and question suggest that you are trying to
use interfaces to do some sort of subtyping, which is just not how they are
supposed to be used.

On Wed, Jan 31, 2018 at 6:43 PM, Axel Wagner 
wrote:

> You have to use reflection for that. Go doesn't have subtyping of that
> kind. This smells a bit of an xy-problem  to me,
> though. There are several things here, that suggest an antipattern going
> on. With a little bit of context on the actual problem you are trying to
> solve, we might be able to come up with a more idiomatic design.
>
> On Wed, Jan 31, 2018 at 6:37 PM, Chris Hopkins 
> wrote:
>
>> Hi
>> Sharing my ignorance:
>> I didn't realise that although you can switch-case on an interface, an
>> array of interfaces doesn't work.
>> https://play.golang.org/p/tD8msjCXyuZ
>>
>> Any ideas on how to cope with this? I tried:
>> _, ok = tmp.([]Useable)
>>
>> But that fails for the same reason. I can't work out how to detect if the
>> type (of the empty interface) is an array of a type that satisfies the
>> (useful) interface.
>> This must be a common problem and PEBKAC surely?
>>
>> Regards
>>
>> Chris
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] GOTCHA: Just when you think you understand interfaces

['Axel Wagner' via golang-nuts]

You have to use reflection for that. Go doesn't have subtyping of that
kind. This smells a bit of an xy-problem  to me,
though. There are several things here, that suggest an antipattern going
on. With a little bit of context on the actual problem you are trying to
solve, we might be able to come up with a more idiomatic design.

On Wed, Jan 31, 2018 at 6:37 PM, Chris Hopkins  wrote:

> Hi
> Sharing my ignorance:
> I didn't realise that although you can switch-case on an interface, an
> array of interfaces doesn't work.
> https://play.golang.org/p/tD8msjCXyuZ
>
> Any ideas on how to cope with this? I tried:
> _, ok = tmp.([]Useable)
>
> But that fails for the same reason. I can't work out how to detect if the
> type (of the empty interface) is an array of a type that satisfies the
> (useful) interface.
> This must be a common problem and PEBKAC surely?
>
> Regards
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: any discourse-like forum in Go?

[peterGo]

Sebastien,

Go中国技术社区 - golang (https://gocn.io/) says it is Powered By WeCenter 3.1.9  
(https://github.com/wecenter).

WeCenter 问答系统的环境需求 
(https://github.com/wecenter/wecenter/blob/master/README.md)

可用的 www 服务器，如 Apache、IIS、nginx, 推荐使用性能高效的 Apache 或 nginx.
PHP 5.2.2 及以上
MySQL 5.0 及以上, 服务器需要支持 MySQLi 或 PDO_MySQL
GD 图形库支持或 ImageMagick 支持, 推荐使用 ImageMagick, 在处理大文件的时候表现良好

It looks like a PHP application, not Go.

Peter

On Wednesday, January 31, 2018 at 11:29:25 AM UTC-5, Sebastien Binet wrote:
>
> hi there,
>
> I am looking for a discourse-like forum, in Go. Does anybody know of such 
> a thing?
>
> Interestingly, reading the https://blog.golang.org/hello-china post, I 
> stumbled upon:
>
> - https://gocn.io
>
> which could be just what I am looking for, but there are no link to any 
> github repo... :}
> (and my chinese is... limited.)
>
> -s
>
> PS: cross-posted on reddit too...
>
> https://www.reddit.com/r/golang/comments/7ub10v/any_discourselike_forum_in_go/
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] GOTCHA: Just when you think you understand interfaces

[Chris Hopkins]

Hi
Sharing my ignorance:
I didn't realise that although you can switch-case on an interface, an 
array of interfaces doesn't work.
https://play.golang.org/p/tD8msjCXyuZ

Any ideas on how to cope with this? I tried:
_, ok = tmp.([]Useable)

But that fails for the same reason. I can't work out how to detect if the 
type (of the empty interface) is an array of a type that satisfies the 
(useful) interface.
This must be a common problem and PEBKAC surely?

Regards

Chris

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Vendor compilation problem

[Luis Furquim]

Hi,

Just fixing a typo.
When I said: 'from "./hudsond" to "mpf/sherlock/bot/src/hudsonbot" the 
problem was solved.'
I meant: 'from "./hudsonbot" to "mpf/sherlock/bot/src/hudsonbot" the 
problem was solved.'

Thank you for the attention!
Luis Otavio de Colla Furquim

Em quarta-feira, 31 de janeiro de 2018 15:15:25 UTC-2, Luis Furquim 
escreveu:
>
> Hi,
>
> Thanks for answering! The environment is as follows:
> vuco@azrael ~ $ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/vuco/repos/gopkg"
> GORACE=""
> GOROOT="/home/vuco/repos/go"
> GOTOOLDIR="/home/vuco/repos/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build989727804=/tmp/go-build 
> -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
>
> But I just found the solution which I will describe here just in case 
> someone else get stuck with the same problem:
>
> The vendored package is "github.com/gabrielledf/paperfishGo" (I refer to 
> is as paperfishGo) and the package who
> imports it is located at 
> /home/vuco/repos/gopkg/src/mpf/sherlock/bot/src/hudsonbot (I will call it 
> as hudsonbot).
> The package hudsonbot is being imported by hudsond, which is my main 
> package.
>
> According to the pages I found, the problem would occur if hudsonbot had 
> imported paperfishGo using a relative path.
> In my case the path was absolute. 
>
> But what I realized is that hudsonbot itself was imported by hudsond using 
> a relative path. When I changed the import path 
> from "./hudsond" to "mpf/sherlock/bot/src/hudsonbot" the problem was 
> solved.
>
> Thank you for the attention!
> Luis Otavio de Colla Furquim
>
>
> Em quarta-feira, 31 de janeiro de 2018 10:00:19 UTC-2, Dave Cheney 
> escreveu:
>>
>> Hi,
>>
>> Can you please provide the output from running,
>>
>> go env
>>
>> It looks like your GOPATH variables is either not set, or not set to the 
>> correct value, which in this case looks to be,
>>
>> /home/vuco/repos/gopkg
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Vendor compilation problem

[Luis Furquim]

Hi,

Thanks for answering! The environment is as follows:
vuco@azrael ~ $ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vuco/repos/gopkg"
GORACE=""
GOROOT="/home/vuco/repos/go"
GOTOOLDIR="/home/vuco/repos/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build989727804=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

But I just found the solution which I will describe here just in case 
someone else get stuck with the same problem:

The vendored package is "github.com/gabrielledf/paperfishGo" (I refer to is 
as paperfishGo) and the package who
imports it is located at 
/home/vuco/repos/gopkg/src/mpf/sherlock/bot/src/hudsonbot (I will call it 
as hudsonbot).
The package hudsonbot is being imported by hudsond, which is my main 
package.

According to the pages I found, the problem would occur if hudsonbot had 
imported paperfishGo using a relative path.
In my case the path was absolute. 

But what I realized is that hudsonbot itself was imported by hudsond using 
a relative path. When I changed the import path 
from "./hudsond" to "mpf/sherlock/bot/src/hudsonbot" the problem was solved.

Thank you for the attention!
Luis Otavio de Colla Furquim


Em quarta-feira, 31 de janeiro de 2018 10:00:19 UTC-2, Dave Cheney escreveu:
>
> Hi,
>
> Can you please provide the output from running,
>
> go env
>
> It looks like your GOPATH variables is either not set, or not set to the 
> correct value, which in this case looks to be,
>
> /home/vuco/repos/gopkg
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] any discourse-like forum in Go?

[Sebastien Binet]

hi there,

I am looking for a discourse-like forum, in Go. Does anybody know of such a
thing?

Interestingly, reading the https://blog.golang.org/hello-china post, I
stumbled upon:

- https://gocn.io

which could be just what I am looking for, but there are no link to any
github repo... :}
(and my chinese is... limited.)

-s

PS: cross-posted on reddit too...
https://www.reddit.com/r/golang/comments/7ub10v/any_discourselike_forum_in_go/

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

[roger peppe]

On 30 January 2018 at 23:19,   wrote:
>> - When slices can be compared, they can be used as map keys. What happens
>> if the contents of a slice are changed after it has been added to a map?
>
>
> I’m not too familiar with Go map internals, but my thought is the key hash
> would depend on the backing array values. Go maps also allow reading the
> keys back using iteration so the slice backing array (up to length) would
> have to be copied. If the slice contents are changed then that would be a
> different key and the original key would be intact.

Note that copying the slice contents to make a map key implies
that using a slice as a map key might imply copying a whole tree,
which seems rather expensive to me (especially as it might end up
using more memory than the original if some elements are duplicated,
unless an alias-aware copy algorithm is used which would be
more expensive still)

BTW you can already do something like this:
https://play.golang.org/p/q4bz8-AckN3

You can even do it without reflect, which I'll leave as an exercise
for the reader :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

['Axel Wagner' via golang-nuts]

> What about a proposal addition of “types with self-references in slices
cannot be compared”?

Are you sure that's the only edge-case? Because this thread is kinda long
and there might even be things we are not thinking about.

> I’m curious about examples where people wanted one or the other. I only
have the one example for by value.

The usecase you mentioned above seems - to me - to be served by a
map[string]*T just fine. Did I misunderstand it?

For usecases for the other, I don't know - but observationally, this thread
has a person who found the reference comparison the obviously correct
choice, underlining again, that there seems to be at least some ambiguity.
They might be able to give usecases.

> A function is just a block of data, so I’d think they’d be equal if the
compiler output is the same for each.

Are two closures capturing different values the same or not? It's the same
code, but they do very different things.
What about two functions which have the same code, but having different
sets of functions inlined into them (because of some optimization decision
taken now or in the future) so they compile to different instructions? What
about languages that don't actually compile functions to an instruction
stream (e.g. GopherJS)?

> Why wouldn’t a map comparison by value work?

Seems to have exactly the same ambiguities as slices. But also, is pretty
expensive (more so than slices, as maps are unordered, so you'd have to
roughly linearly search one and randomly access the other, trashing cashes
and the like). Personally, I don't like expensive operations being made too
simple.

On Wed, Jan 31, 2018 at 4:15 PM,  wrote:

> I agree with you Axel. One point is that allowing struct comparison but
> not slice comparison was counterintuitive to me at first.
>
> What about a proposal addition of “types with self-references in slices
> cannot be compared”?
>
> While comparison by header versus comparison by value may not be an
> obvious choice, once a choice is made then that’s easy to remember for the
> straightforward cases. Everything else can continue to be not allowed.
>
> I’m curious about examples where people wanted one or the other. I only
> have the one example for by value.
>
> What about maps and functions? A function is just a block of data, so I’d
> think they’d be equal if the compiler output is the same for each. Why
> wouldn’t a map comparison by value work?
>
> Thanks,
> Matt
>
> On Wednesday, January 31, 2018 at 1:15:45 AM UTC-6, Axel Wagner wrote:
>
>> On Wed, Jan 31, 2018 at 12:19 AM,  wrote:
>>
>>> - When slices can be compared, they can be used as map keys. What
 happens if the contents of a slice are changed after it has been added to a
 map?
>>>
>>>
>>> I’m not too familiar with Go map internals, but my thought is the key
>>> hash would depend on the backing array values. Go maps also allow reading
>>> the keys back using iteration so the slice backing array (up to length)
>>> would have to be copied. If the slice contents are changed then that would
>>> be a different key and the original key would be intact.
>>>
>>>  - It is possible to have self-referential slices [1]. How would
 comparison work in such a case?
>>>
>>>
>>> Perhaps a slice of slices would compare the contents, the slice headers,
>>> to each other like structs.
>>>
>>
>> That flies in the ideas of consistence. All other equality operators are
>> - if they are defined - defined recursively. Making slice-comparison
>> *sometimes* by contents and *sometimes* by reference is pretty bad.
>>
>> And to reiterate: The point of the people arguing against making slices
>> comparable is not that it would be impossible to define consistent
>> semantics for making that happen. Everyone agrees that it's possible. The
>> point is, that there are *too many* ways to make it happen and too many
>> edge-cases and it is not *obvious* what the correct answers to all these
>> questions are. Answering the questions in an ad-hoc manner doesn't really
>> help alleviate this concern. On the contrary, the fact that the answers
>> seem sometimes self-contradictory and even the proponents of
>> slice-comparisons can't seem to really agree on them underlines the
>> argument against it.
>>
>> Go tries, as much as possible, to have code map as obviously and clearly
>> to the resulting semantics as possible. It does sometimes fail in that and
>> that is unfortunate, but it doesn't change the fact, that we shouldn't make
>> the language more obtuse.
>>
>>
>>>
>>> type A []A
>>>
>>> // not equal
>>> a0 := A{A{}}
>>> a1 := A{}
>>>
>>> // not equal
>>> a2 := A{A{}, A{A{}}}
>>> a3 := A{A{}, A{A{}}}
>>>
>>> // not equal
>>> a4 := A{a0}
>>> a5 := A{A{A{}}}
>>>
>>> // equal
>>> a6 := A{a0}
>>> a7 := A{a0}
>>>
>>> // equal
>>> a8 := A{a0}
>>> a8[0] = a1
>>> a9 := A{a1}
>>>
>>> The self-reference:
>>>
>>> a0 := A{}
>>> // equal
>>> a1 := A{a0, A{}}
>>> a1[0] = a1
>>> a2 := A{a0, a1[1]}
>>> // not 

[go-nuts] Re: Why Goland Terminal appear Hexadecimal text, detail can see my picture

[matthewjuran]

Go files are usually encoded UTF-8, what text encoding is the terminal 
using?

Matt

On Wednesday, January 31, 2018 at 7:45:04 AM UTC-6, wangdach...@gmail.com 
wrote:
>
> This is my first posted,Thank you for helping me solve this problem
>
> my oprate-system is windows 10
>
> goland version is 2017.3
>
> how can i do to solve this situation
>
>
> 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go, VSCODE IDE, Delve debugger: am having problem debugging my console app

[evan]

hi! thanks for responding!

when i hit F5 initially to Start Debugging, the debugger stops at a preset 
breakpoint. i hit F5 to continue... the Debug Console prints out it's 
continuing ... nothing happens after ... so i hit F5 to continue again, and 
again the Debug Console prints out the debugger is continuing  but the 
app / screen doesnt show up/get displayed


Here is what I see in the Debug Console in totality:

2018/01/31 23:12:36 server.go:73: Using API v1
2018/01/31 23:12:36 debugger.go:96: launching process with args: 
[f:\gowork\src\test\debug]
API server listening at: 127.0.0.1:2345
2018/01/31 23:12:36 debugger.go:335: created breakpoint: 
{ID:1, Name:"", Addr:0x5c036b, 
File:"f:/gowork/src/test/test.go", Line:8, FunctionName:"main.main", 
Cond:"", Tracepoint:false, Goroutine:false, Stacktrace:0, 
Variables:[]string(nil), LoadArgs:(*api.LoadConfig)(nil), 
LoadLocals:(*api.LoadConfig)(nil), HitCount:map[string]uint64{}, 
TotalHitCount:0x0}
2018/01/31 23:12:36 debugger.go:492: continuing
2018/01/31 23:12:44 debugger.go:492: continuing

i'm using a terminal user interface package that i like 
(.github.com/rivo/tview)  my code is longer than the small demo code below, 
but i get the above behavior when i try to debug the code below (a tview 
demo example) inside VSCODE.  when i go run test.go (the demo go file) in a 
command prompt, a button widget appears at the top corner of the command 
prompt.

  test.go  (tview demo code example)

// Demo code for the Button primitive.
package main

import "github.com/rivo/tview"

func main() {
app := tview.NewApplication()
button := tview.NewButton("Hit Enter to close").SetSelectedFunc(func() {
app.Stop()
})
button.SetBorder(true).SetRect(0, 0, 22, 3)
if err := app.SetRoot(button, false).SetFocus(button).Run(); err != nil {
panic(err)
}
}


*** what am i not doing correctly?  what can i do to learn more what's 
going on?

On Wednesday, January 31, 2018 at 1:50:02 PM UTC+8, evan wrote:
>
> i can debug my web app server code with no problem with the Go, VSCODE, 
> and Delve setup.
>
> the client connecting to that web app is a console app, which primarily 
> does the following:
>
> gets json data from the server, stuffs the data into the table widget of 
> the terminal user interface (3rd party Go package) for display, lets users 
> edit the data, etc
>
> the console app runs fine when i go run client.go. but when i want to 
> debug the code, the client app doesn't show up :-)
>
> so i'm currently forced to log println's out to a file so i can keep 
> moving forward.
>
> any suggestion what i can do so that i can start up my console app in 
> debug mode and when it shows up, interact with it until i get to preset 
> breakpoints, etc (or other set of steps that might work)?
>
> i'm working in a windows 10 development machine, go version 1.9.2, and 
> VSCODE 1.19.3
>
> thanks for any help!
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: golang compiler warning idea

[matthewjuran]

Here's a proposal covering this: https://github.com/golang/go/issues/21114

Matt

On Wednesday, January 31, 2018 at 2:58:15 AM UTC-6, Egon wrote:
>
> Use govet and see https://golang.org/cmd/vet/#hdr-Shadowed_variables... 
> Of course, there are more tools that can help you 
> https://github.com/alecthomas/gometalinter
>
> + Egon
>
> On Wednesday, 31 January 2018 02:05:57 UTC+2, Jacob Lancaster wrote:
>>
>> So, I'm new to Go, but I wanted to make a cli app that plays go fish with 
>> another client over a network. While I was testing the main loop that takes 
>> in the commands, I noticed that the program wouldn't exit when I entered 
>> the exit command. Here is my code before I found the issue.
>>
>> var text string //Instantiating the variable that would hold the command 
>> in a scope where the loop can check it
>> for text != "exit\n" {
>> fmt.Println("Enter command")
>> text, err := reader.ReadString('\n') //This is where I realized the 
>> error was. I create another text variable that is in the scope of the loop.
>> }
>>
>> I know this was a beginner mistake, and looking back at it, I feel 
>> stupid, but it got me thinking. Go gives a compiler error if you declare a 
>> variable and don't use it. In this instance I did use the outer scope 
>> variable text, but I never gave it a value in my code. Now, I don't know if 
>> there are warnings already in place that will tell you this. If there 
>> aren't, however, I think there should be at least a compiler warning. I was 
>> told to post something here before I open an issue. So really this is just 
>> me asking if a compiler warning for this would be a good idea, or is this 
>> just a beginner mistake that no one runs into if they know what they're 
>> doing. 
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

[matthewjuran]

I agree with you Axel. One point is that allowing struct comparison but not 
slice comparison was counterintuitive to me at first.

What about a proposal addition of “types with self-references in slices 
cannot be compared”?

While comparison by header versus comparison by value may not be an obvious 
choice, once a choice is made then that’s easy to remember for the 
straightforward cases. Everything else can continue to be not allowed.

I’m curious about examples where people wanted one or the other. I only 
have the one example for by value.

What about maps and functions? A function is just a block of data, so I’d 
think they’d be equal if the compiler output is the same for each. Why 
wouldn’t a map comparison by value work?

Thanks,
Matt

On Wednesday, January 31, 2018 at 1:15:45 AM UTC-6, Axel Wagner wrote:
>
> On Wed, Jan 31, 2018 at 12:19 AM,  
> wrote:
>
>> - When slices can be compared, they can be used as map keys. What happens 
>>> if the contents of a slice are changed after it has been added to a map? 
>>
>>
>> I’m not too familiar with Go map internals, but my thought is the key 
>> hash would depend on the backing array values. Go maps also allow reading 
>> the keys back using iteration so the slice backing array (up to length) 
>> would have to be copied. If the slice contents are changed then that would 
>> be a different key and the original key would be intact.
>>
>>  - It is possible to have self-referential slices [1]. How would 
>>> comparison work in such a case?
>>
>>
>> Perhaps a slice of slices would compare the contents, the slice headers, 
>> to each other like structs.
>>
>
> That flies in the ideas of consistence. All other equality operators are - 
> if they are defined - defined recursively. Making slice-comparison 
> *sometimes* by contents and *sometimes* by reference is pretty bad.
>
> And to reiterate: The point of the people arguing against making slices 
> comparable is not that it would be impossible to define consistent 
> semantics for making that happen. Everyone agrees that it's possible. The 
> point is, that there are *too many* ways to make it happen and too many 
> edge-cases and it is not *obvious* what the correct answers to all these 
> questions are. Answering the questions in an ad-hoc manner doesn't really 
> help alleviate this concern. On the contrary, the fact that the answers 
> seem sometimes self-contradictory and even the proponents of 
> slice-comparisons can't seem to really agree on them underlines the 
> argument against it.
>
> Go tries, as much as possible, to have code map as obviously and clearly 
> to the resulting semantics as possible. It does sometimes fail in that and 
> that is unfortunate, but it doesn't change the fact, that we shouldn't make 
> the language more obtuse.
>  
>
>>
>> type A []A
>>
>> // not equal
>> a0 := A{A{}}
>> a1 := A{}
>>
>> // not equal
>> a2 := A{A{}, A{A{}}}
>> a3 := A{A{}, A{A{}}}
>>
>> // not equal
>> a4 := A{a0}
>> a5 := A{A{A{}}}
>>
>> // equal
>> a6 := A{a0}
>> a7 := A{a0}
>>
>> // equal
>> a8 := A{a0}
>> a8[0] = a1
>> a9 := A{a1}
>>
>> The self-reference:
>>
>> a0 := A{}
>> // equal
>> a1 := A{a0, A{}}
>> a1[0] = a1
>> a2 := A{a0, a1[1]}
>> // not equal
>> a3 := A{A{}, a1[1]}
>>
>> I'm not sure about this one since it seems to go against the idea of 
>> slice comparison by values.
>>
>> Matt
>>
>> On Tuesday, January 30, 2018 at 2:33:38 PM UTC-6, rog wrote:
>>>
>>> Two significant issues that need to be thought about:
>>>
>>> - When slices can be compared, they can be used as map keys. What 
>>> happens if the contents of a slice are changed after it has been added to a 
>>> map? 
>>>
>>> - It is possible to have self-referential slices [1]. How would 
>>> comparison work in such a case?
>>>
>>>
>>>  [1] https://play.golang.org/p/lTqhKjD842K
>>>
>>> On 30 Jan 2018 16:45,  wrote:
>>>
 Here’s a draft for a Go 2 proposal that I’d like to add to the issue 
 tracker since there’s no discussion there about this:

 Slices should have equality defined.

 https://golang.org/doc/faq#map_keys

 Map lookup requires an equality operator, which slices do not 
> implement. They don't implement equality because equality is not well 
> defined on such types; there are multiple considerations involving 
> shallow 
> vs. deep comparison, pointer vs. value comparison, how to deal with 
> recursive types, and so on.


 This proposal allows slices to be used as map keys and for comparison 
 with == and !=.

 https://golang.org/ref/spec#Comparison_operators

 Slice, map, and function values are not comparable.


 An initial proposal is that slices are compared by nil versus non-nil, 
 length and backing array pointer, and then by the rules for array if 
 length 
 is equal but different arrays are pointed:

 Array values are comparable if values of the array 

[go-nuts] Re: Upcoming Go protobuf release

[Walter Schulze]

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 possible to golang/protobuf, 
including also following the same version tagging.

gogo/protobuf is disappointed that golang/protobuf still thinks that 
runtime reflection is an efficient way of serializing structures.

go Green go GoGoProtobuf

PS

gogo/protobuf is still open to being merged back into golang/protobuf and 
has been since its inception 5 years ago.
gogo/protobuf feels for its users, especially those that are not 
acknowledged by grpc-gateway and grpc-go,
and forced to employ work arounds, to preserve their missions of safety and 
efficiency.
It knows that its existence is not something that anyone prefers, and it 
welcomes death, 
but only if it can preserve its legacy of fast serailization and generating 
the structures you want to use.


On Tuesday, 30 January 2018 23:44:37 UTC+1, joe...@google.com wrote:
>
> 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 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 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go, VSCODE IDE, Delve debugger: am having problem debugging my console app

[deparker]

Console app as in some sort of GUI application? Also, what actually happens 
when you run the app under Delve, like when you actually run `continue`? 

On Wednesday, January 31, 2018 at 6:50:02 AM UTC+1, evan wrote:
>
> i can debug my web app server code with no problem with the Go, VSCODE, 
> and Delve setup.
>
> the client connecting to that web app is a console app, which primarily 
> does the following:
>
> gets json data from the server, stuffs the data into the table widget of 
> the terminal user interface (3rd party Go package) for display, lets users 
> edit the data, etc
>
> the console app runs fine when i go run client.go. but when i want to 
> debug the code, the client app doesn't show up :-)
>
> so i'm currently forced to log println's out to a file so i can keep 
> moving forward.
>
> any suggestion what i can do so that i can start up my console app in 
> debug mode and when it shows up, interact with it until i get to preset 
> breakpoints, etc (or other set of steps that might work)?
>
> i'm working in a windows 10 development machine, go version 1.9.2, and 
> VSCODE 1.19.3
>
> thanks for any help!
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Unit tests - same vs separate package

[Sonia Keys]

Stevo, that's how I do it.  Most of my tests are in an _test package so I 
can be sure my exported API works.  Once in a while I want some extra tests 
on something not exported so those tests go in a separate source file.  And 
yes, I try to do something with the filename to indicate that it contains 
in-package tests.

On Tuesday, January 30, 2018 at 8:51:58 AM UTC-5, Stevo Slavić wrote:
>
> Hello Go community,
>
> Official docs recommend putting unit tests in same package as package 
> under test, see:
> - https://golang.org/doc/faq#How_do_I_write_a_unit_test
> - https://golang.org/pkg/testing/
>
> Practical experience (see 
> https://medium.com/@matryer/5-simple-tips-and-tricks-for-writing-unit-tests-in-golang-619653f90742#03db)
>  
> suggests it's better to put tests to a dedicated package so it can test 
> exported API only of the package under test, and if there's value to test 
> the package internals too then put another test suite file to the same 
> package with a special file name to make it clear it's meant to fiddle with 
> internals.
>
> Do these suggestions make sense? If so, would it make sense to make them 
> official recommended practice? Maybe in Effective Go?
>
> Kind regards,
> Stevo Slavic.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Why Goland Terminal appear Hexadecimal text, detail can see my picture

[wangdachangchang]

This is my first posted,Thank you for helping me solve this problem

my oprate-system is windows 10

goland version is 2017.3

how can i do to solve this situation



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] where in gc compiler does converting from syntax.TypeDecl to reflect.Type happen?

[Jason E. Aten]

Thanks Alex. Thanks Ian.

In case it is of interest to other gophers, since
somebody emailed me asking if my go/types -> reflect.Type
conversion code was available: yes, it is. It is called muse.

I've extracted muse from my just-in-time Go interpreter (
https://github.com/gijit/gi) and made muse stand-alone here:

https://github.com/glycerine/muse

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Vendor compilation problem

[Dave Cheney]

Hi,

Can you please provide the output from running,

go env

It looks like your GOPATH variables is either not set, or not set to the 
correct value, which in this case looks to be,

/home/vuco/repos/gopkg

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Vendor compilation problem

[Dave Cheney]

Can you please provide the output from running to eng. 

It looks like your GOPATH variables is either not set, or not set to the 
correct value, which looks to be in this case

/home/vuco/repos/gopkg

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] json struct tag

[Konstantin Khomoutov]

On Wed, Jan 31, 2018 at 09:26:35AM +1030, Dan Kortschak wrote:

> > > Does the order in which the options in the tag appear matter (e.g. 
> > > `json:"first_name,omitempty"` vs `json:"omitempty,first_name"`) ?
> > 
> > I'd say they should not as their purposes are orthogonal to each
> > other.
> It does matter, and omitempty must have a leading comma; the first
> comma separated term is the JSON field name. From the json docs:
> 
> ```
> The format string gives the name of the field, possibly followed by a
> comma-separated list of options. The name may be empty in order to
> specify options without overriding the default field name.

Thank you! I stand corrected.

I think that's what happens when you get certain knowledge deep under
your skin: sure I habitually used ",option" countless times and surely
knew that it's due to the name field having been skipped but that
knowledge was unconscious. ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] SIGSEGV with cgo

[hǎi sū]

thank you.

andrey mirtchovski於 2018年1月31日星期三 UTC+8下午1時33分04秒寫道：
>
> on the Go side you have an array of bytes, on the C side you are 
> passing a pointer to an array of shorts (16-bits) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] SIGSEGV with cgo

[hǎi sū]

thank you. now, I understand.

Ian Lance Taylor於 2018年1月31日星期三 UTC+8下午1時29分09秒寫道：
>
> On Tue, Jan 30, 2018 at 9:13 PM, hǎi sū  
> wrote: 
> > the code is below. 
> > ``` 
> > package main 
> > 
> > import "math/rand" 
> > import "fmt" 
> > 
> > /* 
> > #include  
> > #include  
> > 
> > void t(const short *buf, size_t buf_size) { 
> > printf("in t."); 
> > printf("0: %d ", buf[0]); 
> > printf("buf_size-1: %d\n", buf[buf_size-1]); 
> > } 
> > 
> > */ 
> > import "C" 
> > 
> > func main() { 
> > for { 
> > a := make([]byte, 178209) 
> > rand.Read(a) 
> > fmt.Println(a[0], a[len(a)-1]) 
> > aPointer := C.CBytes(a) 
> > C.t((*C.short)(aPointer), C.size_t(len(a))) 
> > C.free(aPointer) 
> > } 
> > } 
> > ``` 
>
> len(a) is the length in bytes, which is 178209.  But the C code is 
> using that length to index into a short*, meaning that it is looking 
> at byte 356418, which is far past the end of the array.  The C code 
> should take unsigned char * or you should divide len(a) by 2 or 
> something. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: golang compiler warning idea

[Egon]

Use govet and see https://golang.org/cmd/vet/#hdr-Shadowed_variables... Of 
course, there are more tools that can help 
you https://github.com/alecthomas/gometalinter

+ Egon

On Wednesday, 31 January 2018 02:05:57 UTC+2, Jacob Lancaster wrote:
>
> So, I'm new to Go, but I wanted to make a cli app that plays go fish with 
> another client over a network. While I was testing the main loop that takes 
> in the commands, I noticed that the program wouldn't exit when I entered 
> the exit command. Here is my code before I found the issue.
>
> var text string //Instantiating the variable that would hold the command 
> in a scope where the loop can check it
> for text != "exit\n" {
> fmt.Println("Enter command")
> text, err := reader.ReadString('\n') //This is where I realized the 
> error was. I create another text variable that is in the scope of the loop.
> }
>
> I know this was a beginner mistake, and looking back at it, I feel stupid, 
> but it got me thinking. Go gives a compiler error if you declare a variable 
> and don't use it. In this instance I did use the outer scope variable text, 
> but I never gave it a value in my code. Now, I don't know if there are 
> warnings already in place that will tell you this. If there aren't, 
> however, I think there should be at least a compiler warning. I was told to 
> post something here before I open an issue. So really this is just me 
> asking if a compiler warning for this would be a good idea, or is this just 
> a beginner mistake that no one runs into if they know what they're doing. 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.