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

[Peter Waller]

On 31 January 2018 at 16:23, roger peppe  wrote:

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


Neat trick!


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


I'll bite, does it involve struct { len int; content [maxCount]int }, or
did you have something else in mind?

-- 
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: Any plans to add ASN.1 PER support?

[David Wahlstedt]

Thanks!

Den lördag 27 januari 2018 kl. 20:02:18 UTC+1 skrev Matt Harden:
>
> It isn't something that is likely to be added to the stdlib. If anything, 
> a library like https://github.com/Logicalis/asn1 might be interested in 
> supporting it / accepting a pull request to add it.
>
> On Fri, Jan 12, 2018 at 9:50 AM David Wahlstedt  > wrote:
>
>> ASN.1 is still alive and present in telecom applications. The PER 
>> encoding is missing in the go library, unfortunately...
>>
>>
>> Den torsdag 11 januari 2018 kl. 20:04:50 UTC+1 skrev Pat Farrell:
>>>
>>> On Thursday, January 11, 2018 at 10:50:24 AM UTC-5, David Wahlstedt 
>>> wrote:

 I wonder if there are any plans to add PER encoding/decoding support 
 for ASN.1?
 I have looked around, and it seems that there isn't any project 
 supporting this, currently.

>>>
>>> Wow, I haven't heard anyone ask for ASN.1 PER or DER in two decades.
>>> I know it still is listed in the specs, but  ASN.1 was  worse than XML
>>>
>> -- 
>> 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.

[go-nuts] Re: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Egon]

I recommend re-writing them using real-world examples, where they really 
are the "best solution", rather than a facilitated example.

Often beginners learn from such facilitated examples and end-up misusing 
and getting the wrong idea about them. Using realistic examples helps to 
avoid those problems (to some degree).

On Friday, 2 February 2018 19:03:54 UTC+2, matthe...@gmail.com wrote:
>
> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
> Elements of Reusable Object-Oriented Software” and writing out a few as the 
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>
> Matt
>

-- 
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 5 February 2018 at 08:36, Peter Waller  wrote:
> On 31 January 2018 at 16:23, roger peppe  wrote:
>>
>> BTW you can already do something like this:
>> https://play.golang.org/p/q4bz8-AckN3
>
>
> Neat trick!
>
>>
>> You can even do it without reflect, which I'll leave as an exercise for
>> the reader :)
>
>
> I'll bite, does it involve struct { len int; content [maxCount]int }, or did
> you have something else in mind?

Something else. No size limit. Not what one might call efficient though. :)

-- 
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?

[Peter Waller]

On 5 February 2018 at 11:04, roger peppe  wrote:

> > I'll bite, does it involve struct { len int; content [maxCount]int }, or
> did
> > you have something else in mind?
>
> Something else. No size limit. Not what one might call efficient though. :)
>

[low growling]

(ok, so I've been watching Stranger Things with subtitles too much...)

I'm... not sure I can figure out what you're thinking of, dangit.

Does it involve gratuitous numbers of calls to the fmt package?

-- 
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: GOTCHA: Just when you think you understand interfaces

[Chris Hopkins]

Well, the first allows one Less per package, the second allows one per 
type. Since I tend to have multiple types in a package I find that more 
readable.

Anyway, I finally fixed the problem with mixture of reflect and type 
assertion
  val := reflect.ValueOf(b)
  if val.Kind() == reflect.Slice {
leng = val.Len() // outer length
for i := 0; i < leng; i++ {
  v := val.Index(i)
  if v.Kind() == reflect.Slice {
sz = v.Len() // inner length
for j := 0; j < sz; j++ {
  vv := v.Index(j)
if m, ok := vv.Interface().(Useable); ok {
n, ok := 
reflect.ValueOf(a).Index(i).Index(j).Interface().(Useable)
if !ok {
  log.Fatal("a is not the same type as b")
}
good = m.Equal(n)
  } else {
log.Fatal("Candidate cannot be converted to a Usable type")
  }
}
  }
}
  }


Yeah it's a bit ugly and I'm working on something better, but the immediate 
issue is closed for now, so thanks everyone for the kick in the right 
direction.

Regards

Chris


On Thursday, 1 February 2018 18:55:27 UTC, Axel Wagner wrote:
>
> I don't really see the difference in writing
> func Less(a, b *T) bool
> and
> func (a *T) Less(b *T) bool
> convenience wise - except that the latter requires the name to be exported 
> and doesn't allow using a function literal (so, yeah, the latter actually 
> seems significantly *less* convenient).
>
> On Thu, Feb 1, 2018 at 7:51 PM, Chris Hopkins  > wrote:
>
>> No, was hoping to use the interface (It's the only reason I defined it) 
>> to test if two items are equal.
>> I guess I could enforce that you have to supply the equals function like 
>> the sort interface does. I was just hoping for more.
>>
>> I'll have a rethink next time I have time.
>>
>> Thanks
>>
>> On Thursday, 1 February 2018 18:46:09 UTC, Axel Wagner wrote:
>>>
>>> On Thu, Feb 1, 2018 at 11:52 AM, Chris Hopkins  
>>> wrote:
>>>
 Yeah, so having played with this. It seems that this is going to take 
 some judicious use of reflect if I'm to stand any chance of maintaining a 
 flexible API, which I really hoped to avoid.

>>>
>>> I'm 99% sure that you don't have to use reflect at all. You only have to 
>>> swap elements around, that's kind of what sort.Interface was made for. It 
>>> already comes with implementations for slices of common datatypes and you 
>>> can make a function that works on arbitrary slices with less than ten lines 
>>> of reflect code.
>>>
>>> Like, I *really* don't understand your problem.
>>>  
>>>
 I had assumed that the point of interfaces was to avoid this. I guess 
 from a high level I don't see why a slice of type is really that different 
 from a type. But I have never written a compiler so I'm sure that it's way 
 more complex than it seems. :-)

 Thanks for the help.
 Chris


 On Thursday, 1 February 2018 00:42:04 UTC, simon place wrote:
>
> 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...@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...@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] comparing empty interface values?

[l vic]

Working on the package that should handle multiple data types. I started 
with using empty interfaces
but got stuck when it come to comparing empty interface values, seems it's 
possible to get empty interface type, but not value
Is there a working pattern to use in this case, aside of using reflection?

-- 
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] [ANN] A gradient boosting regressor package

[Aliaksandr Valialkin]

On Tuesday, January 30, 2018 at 12:43:38 AM UTC+2, Sina Siadat wrote:
>
> Hi Sebastien,
>
> ​Thanks for your comment and question :)
>
> > I have one "drive-by-comment" and a question:
> > you could have perhaps used gonum for the stats stuff :)
>
> ​Actually, I did start with gonum :)) but I thought it was a large 
> dependency and I only needed a few funcs from it, so I decided to 
> copy/write them!
>
> > and the question: did you compare your package with XGBoost (which is 
> now kind of a standard candle nowadays) in terms of accuracy, speed and 
> memory usage?
>
> ​I haven't used XGBoost yet, it looks pretty cool, thanks for mentioning 
> it. I will install it and see if I can compare the two.
>

Take a look at CatBoost - https://github.com/catboost/catboost . See also 
this link 
- 
https://www.quora.com/What-is-the-new-CatBoost-machine-learning-algorithm-and-how-does-it-compare-to-XGBoost
 
.

-- 
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] comparing empty interface values?

[Jan Mercl]

On Mon, Feb 5, 2018 at 1:48 PM l vic  wrote:

> Working on the package that should handle multiple data types. I started
with using empty interfaces

Probably not a good idea.

> but got stuck when it come to comparing empty interface values, seems
it's possible to get empty interface type, but not value
> Is there a working pattern to use in this case, aside of using
reflection?

if you need to compare values of different types stored in `interface{}`
typed values, you can do that directly: expr1 == expr2. The result is true
if both dynamic types are equal and the values are comparable and equal.

But maybe this problem calls for using

type Equaler interface{
Equal(Equaler) bool
}

instead of `interface{}`.

-- 

-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] comparing empty interface values?

[l vic]

I have problem with "<" ">", like in example below

invalid operation: j < i (operator < not defined on interface)

var i interface{}

var j interface{}

i = 2

j = 3

if j == i {

fmt.Println("correct")

}



On Mon, Feb 5, 2018 at 7:58 AM, Jan Mercl <0xj...@gmail.com> wrote:

> On Mon, Feb 5, 2018 at 1:48 PM l vic  wrote:
>
> > Working on the package that should handle multiple data types. I started
> with using empty interfaces
>
> Probably not a good idea.
>
> > but got stuck when it come to comparing empty interface values, seems
> it's possible to get empty interface type, but not value
> > Is there a working pattern to use in this case, aside of using
> reflection?
>
> if you need to compare values of different types stored in `interface{}`
> typed values, you can do that directly: expr1 == expr2. The result is true
> if both dynamic types are equal and the values are comparable and equal.
>
> But maybe this problem calls for using
>
> type Equaler interface{
> Equal(Equaler) bool
> }
>
> instead of `interface{}`.
>
> --
>
> -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.

[go-nuts] Re: [ANN] rsrc - Tool for embedding Windows executable manifests in Go programs.

[manish . webref]

On Monday, December 9, 2013 at 8:31:32 PM UTC+5:30, salvor...@gmail.com 
wrote:
>
> On Sunday, December 8, 2013 5:55:28 PM UTC-6, Mateusz Czapliński wrote:
>>
>> rsrc - Tool for embedding Windows executable manifests in Go programs.
>>
>> INSTALL: go get github.com/akavel/rsrc
>>
>> USAGE: rsrc.exe -manifest FILE.exe.manifest [-o FILE.syso]
>> Generates a .syso file with specified resources embedded in .rsrc section,
>> aimed for consumption by Go linker when building Win32 excecutables.
>> OPTIONS:
>>   -manifest="": path to a Windows manifest file to embed
>>   -o="rsrc.syso": name of output COFF (.res or .syso) file
>>
>>
> This is nice, 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: [ANN] rsrc - Tool for embedding Windows executable manifests in Go programs.

[manish . webref]

Hi guys 

I was done this all process but side-by-side configuration error occurring.

-- 
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: Extensive Go resources for CS101

[Looserof7]

Thank you.

-- 
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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[matthewjuran]

They haven’t seemed necessary in small application development. I'll 
monitor for real-world examples.

There's a few repositories for Go design patterns: 

https://github.com/tmrts/go-patterns
https://github.com/monochromegane/go_design_pattern
https://github.com/yksz/go-design-patterns

But they don't have real-world examples.

Matt

On Monday, February 5, 2018 at 4:17:15 AM UTC-6, Egon wrote:
>
> I recommend re-writing them using real-world examples, where they really 
> are the "best solution", rather than a facilitated example.
>
> Often beginners learn from such facilitated examples and end-up misusing 
> and getting the wrong idea about them. Using realistic examples helps to 
> avoid those problems (to some degree).
>
> On Friday, 2 February 2018 19:03:54 UTC+2, matthe...@gmail.com wrote:
>>
>> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
>> Elements of Reusable Object-Oriented Software” and writing out a few as the 
>> equivalent in Go.
>>
>> Visitor: https://play.golang.org/p/A5tNzxMmetH
>>
>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>
>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>
>> Facade: https://play.golang.org/p/forPdwy9VCi
>>
>> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>>
>> I’m curious how more experienced people rank these and the other patterns.
>>
>> Matt
>>
>

-- 
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: GOTCHA: Just when you think you understand interfaces

['Axel Wagner' via golang-nuts]

On Mon, Feb 5, 2018 at 1:13 PM, Chris Hopkins  wrote:

> Well, the first allows one Less per package, the second allows one per
> type.
>

No, the first allows an arbitrary number of Less' per package or type and
the second one allows one per type.
You can call a function LessByName, LessByID, LessBy…. You can also use
method-expressions to transform methods into func()s. And you can use
closures, which really is what sets it apart.

But anyway.

Since I tend to have multiple types in a package I find that more readable.
>
> Anyway, I finally fixed the problem with mixture of reflect and type
> assertion
>   val := reflect.ValueOf(b)
>   if val.Kind() == reflect.Slice {
> leng = val.Len() // outer length
> for i := 0; i < leng; i++ {
>   v := val.Index(i)
>   if v.Kind() == reflect.Slice {
> sz = v.Len() // inner length
> for j := 0; j < sz; j++ {
>   vv := v.Index(j)
> if m, ok := vv.Interface().(Useable); ok {
> n, ok := reflect.ValueOf(a).Index(i).
> Index(j).Interface().(Useable)
> if !ok {
>   log.Fatal("a is not the same type as b")
> }
> good = m.Equal(n)
>   } else {
> log.Fatal("Candidate cannot be converted to a Usable type")
>   }
> }
>   }
> }
>   }
>
>
> Yeah it's a bit ugly and I'm working on something better, but the
> immediate issue is closed for now, so thanks everyone for the kick in the
> right direction.
>
> Regards
>
> Chris
>
>
> On Thursday, 1 February 2018 18:55:27 UTC, Axel Wagner wrote:
>>
>> I don't really see the difference in writing
>> func Less(a, b *T) bool
>> and
>> func (a *T) Less(b *T) bool
>> convenience wise - except that the latter requires the name to be
>> exported and doesn't allow using a function literal (so, yeah, the latter
>> actually seems significantly *less* convenient).
>>
>> On Thu, Feb 1, 2018 at 7:51 PM, Chris Hopkins  wrote:
>>
>>> No, was hoping to use the interface (It's the only reason I defined it)
>>> to test if two items are equal.
>>> I guess I could enforce that you have to supply the equals function like
>>> the sort interface does. I was just hoping for more.
>>>
>>> I'll have a rethink next time I have time.
>>>
>>> Thanks
>>>
>>> On Thursday, 1 February 2018 18:46:09 UTC, Axel Wagner wrote:

 On Thu, Feb 1, 2018 at 11:52 AM, Chris Hopkins 
 wrote:

> Yeah, so having played with this. It seems that this is going to take
> some judicious use of reflect if I'm to stand any chance of maintaining a
> flexible API, which I really hoped to avoid.
>

 I'm 99% sure that you don't have to use reflect at all. You only have
 to swap elements around, that's kind of what sort.Interface was made for.
 It already comes with implementations for slices of common datatypes and
 you can make a function that works on arbitrary slices with less than ten
 lines of reflect code.

 Like, I *really* don't understand your problem.


> I had assumed that the point of interfaces was to avoid this. I guess
> from a high level I don't see why a slice of type is really that different
> from a type. But I have never written a compiler so I'm sure that it's way
> more complex than it seems. :-)
>
> Thanks for the help.
> Chris
>
>
> On Thursday, 1 February 2018 00:42:04 UTC, simon place wrote:
>>
>> 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...@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...@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
>

[go-nuts] Re: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

['Eric Johnson' via golang-nuts]

An interesting idea. Some thoughts

On Friday, February 2, 2018 at 9:03:54 AM UTC-8, matthe...@gmail.com wrote:
>
> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
> Elements of Reusable Object-Oriented Software” and writing out a few as the 
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>

Your visitor pattern here seems to not be a "visitor" pattern. I would 
think that the Go equivalent would define an interface, and visit based on 
that interface.
 

>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>

This isn't really an example of a factory method, because it isn't 
instantiating things of different types.
 

>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
 

>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>

I didn't look at all your examples, but in most cases, it seems like error 
handling, which would be an important part of a Go example, is completely 
absent in the examples given here.

Eric
 

>
> Matt
>

-- 
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 5 February 2018 at 11:38, Peter Waller  wrote:
> On 5 February 2018 at 11:04, roger peppe  wrote:
>>
>> > I'll bite, does it involve struct { len int; content [maxCount]int }, or
>> > did
>> > you have something else in mind?
>>
>> Something else. No size limit. Not what one might call efficient though.
>> :)
>
>
> [low growling]
>
> (ok, so I've been watching Stranger Things with subtitles too much...)
>
> I'm... not sure I can figure out what you're thinking of, dangit.
>
> Does it involve gratuitous numbers of calls to the fmt package?

Nope. No fmt at all.

A clue: struct{x interface{}}{12} == struct{x interface{}}{12}

-- 
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] Question about the spec: Method Sets and Pointer Receivers

[theckman via golang-nuts]

Hey Gophers,

I've run in to an interesting case regarding Method Sets that makes me 
wonder whether it should be disallowed by the spec[1]. Before opening an 
issue on GitHub I thought I'd reach out here to get some clarifications as 
I may be misreading the spec.

Based on my understanding of method sets, a variable with the type *T should 
have a method set that contains methods on T and *T, while a variable of 
type T should only have methods with a receiver for T in the method set. To 
me this translates that if my variable is not a pointer type it should not 
be able to call a method that's receiving a pointer type.

However, I've observed that to not be the case. If I have a variable of 
type T, I am able to invoke methods that are receiving *T[2]. Should that 
be permitted by the spec? It adds some inconsistency because I am able to 
invoke the method on my variable, but the variable won't satisfy an 
interface that has that method included[3]. I think it's acceptable that 
the interface isn't satisfied, but what makes it so that invoking the 
method directly is permitted?

Cheers!
-Tim

[1] https://golang.org/ref/spec#Method_sets
[2] https://play.golang.org/p/-OMAnD7U0Vl
[3] https://play.golang.org/p/uP0_eMYqYEe

-- 
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] Question about the spec: Method Sets and Pointer Receivers

[Paul Jolly]

Hi Tim,

Take a look at https://golang.org/ref/spec#Calls:

"A method call x.m() is valid if the method set of (the type of) x contains
m and the argument list can be assigned to the parameter list of m. If x is
addressable and &x's method set contains m, x.m() is shorthand for (&x).m()"


Paul

On 5 February 2018 at 17:42, theckman via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hey Gophers,
>
> I've run in to an interesting case regarding Method Sets that makes me
> wonder whether it should be disallowed by the spec[1]. Before opening an
> issue on GitHub I thought I'd reach out here to get some clarifications as
> I may be misreading the spec.
>
> Based on my understanding of method sets, a variable with the type *T should
> have a method set that contains methods on T and *T, while a variable of
> type T should only have methods with a receiver for T in the method set.
> To me this translates that if my variable is not a pointer type it should
> not be able to call a method that's receiving a pointer type.
>
> However, I've observed that to not be the case. If I have a variable of
> type T, I am able to invoke methods that are receiving *T[2]. Should that
> be permitted by the spec? It adds some inconsistency because I am able to
> invoke the method on my variable, but the variable won't satisfy an
> interface that has that method included[3]. I think it's acceptable that
> the interface isn't satisfied, but what makes it so that invoking the
> method directly is permitted?
>
> Cheers!
> -Tim
>
> [1] https://golang.org/ref/spec#Method_sets
> [2] https://play.golang.org/p/-OMAnD7U0Vl
> [3] https://play.golang.org/p/uP0_eMYqYEe
>
> --
> 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] Question about the spec: Method Sets and Pointer Receivers

[Burak Serdar]

On Mon, Feb 5, 2018 at 10:42 AM, theckman via golang-nuts
 wrote:
> Hey Gophers,
>
> I've run in to an interesting case regarding Method Sets that makes me
> wonder whether it should be disallowed by the spec[1]. Before opening an
> issue on GitHub I thought I'd reach out here to get some clarifications as I
> may be misreading the spec.
>
> Based on my understanding of method sets, a variable with the type *T should
> have a method set that contains methods on T and *T, while a variable of
> type T should only have methods with a receiver for T in the method set. To
> me this translates that if my variable is not a pointer type it should not
> be able to call a method that's receiving a pointer type.


I believe this is not what the spec says. If type T has:

func (t T) A() {}
func (t *T) B() {}

Then the method set of T is [A], where the method set of *T is [A,B]

For a variable x:=T{}, x.A() is called with a copy of x, and x.B() is
called with a copy of &x. So, for instance:

func f(m map[string]T) {
   m["key"].A() // works
   m["key"].B() // doesn't work, m["key"] is not addressable

>
> However, I've observed that to not be the case. If I have a variable of type
> T, I am able to invoke methods that are receiving *T[2]. Should that be
> permitted by the spec? It adds some inconsistency because I am able to
> invoke the method on my variable, but the variable won't satisfy an
> interface that has that method included[3]. I think it's acceptable that the
> interface isn't satisfied, but what makes it so that invoking the method
> directly is permitted?
>
> Cheers!
> -Tim
>
> [1] https://golang.org/ref/spec#Method_sets
> [2] https://play.golang.org/p/-OMAnD7U0Vl
> [3] https://play.golang.org/p/uP0_eMYqYEe
>
> --
> 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] Question about the spec: Method Sets and Pointer Receivers

[theckman via golang-nuts]

Yep, this is exactly it. I missed this section when I was trying to figure 
this out.

Thank you!

-Tim

On Monday, February 5, 2018 at 11:53:32 AM UTC-8, Paul Jolly wrote:
>
> Hi Tim,
>
> Take a look at https://golang.org/ref/spec#Calls:
>
> "A method call x.m() is valid if the method set of (the type of) x 
> contains m and the argument list can be assigned to the parameter list of 
> m. If x is addressable and &x's method set contains m, x.m() is shorthand 
> for (&x).m()"
>
>
> Paul
>
> On 5 February 2018 at 17:42, theckman via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> Hey Gophers,
>>
>> I've run in to an interesting case regarding Method Sets that makes me 
>> wonder whether it should be disallowed by the spec[1]. Before opening an 
>> issue on GitHub I thought I'd reach out here to get some clarifications as 
>> I may be misreading the spec.
>>
>> Based on my understanding of method sets, a variable with the type *T should 
>> have a method set that contains methods on T and *T, while a variable of 
>> type T should only have methods with a receiver for T in the method set. 
>> To me this translates that if my variable is not a pointer type it should 
>> not be able to call a method that's receiving a pointer type.
>>
>> However, I've observed that to not be the case. If I have a variable of 
>> type T, I am able to invoke methods that are receiving *T[2]. Should 
>> that be permitted by the spec? It adds some inconsistency because I am able 
>> to invoke the method on my variable, but the variable won't satisfy an 
>> interface that has that method included[3]. I think it's acceptable that 
>> the interface isn't satisfied, but what makes it so that invoking the 
>> method directly is permitted?
>>
>> Cheers!
>> -Tim
>>
>> [1] https://golang.org/ref/spec#Method_sets
>> [2] https://play.golang.org/p/-OMAnD7U0Vl
>> [3] https://play.golang.org/p/uP0_eMYqYEe
>>
>> -- 
>> 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.

[go-nuts] Global variable initialized in init() not working in main()

[mbrizic]

I'm initializing a Logger variable in an init() function and then 
attempting to use in the main() function. However, I'm able to Printf from 
the Logger in the init() function but not inside the main() function. Any 
help would be appreciated.

package main

import (

"fmt"
"log"
"io"

"os"

}

var (

logFile *os.File 
logger *log.Logger
multiWriter io.Writer

)

func init() {

fmt.Println("init() function")

var logFileError error
logFile, logFileError = os.Create("gopoc.log")
if logFileError != nil {
panic(logFileError)
}
defer logFile.Close()

fmt.Println("Creating log file")

multiWriter = io.MultiWriter(logFile, os.Stdout)

logger = log.New(multiWriter, gopocLogPrefix, log.Ldate | log.Ltime | 
log.Lshortfile)
logger.SetOutput(multiWriter)

fmt.Println("Created logger")

logger.Printf("Using logger")  // prints to console and logFile as expected

}

func main() {

fmt.Println("main() function ") // prints to console

fmt.Println(logger) // I can see the object pointer

logger.Print("hello") // This does not print to logFile nor 
os.Stdout !!!

}

-- 
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] Question about the spec: Method Sets and Pointer Receivers

[gtownsend]

This issue once puzzled me, too.  It would help to add something to the 
spec section on method sets .  I 
suggest something like this at the very end of the second paragraph:

... Additionally, if a receiver of type T is *addressable 
*, its method set is 
effectively extended to include the method set of *T (see *calls 
*).


On Monday, February 5, 2018 at 12:53:32 PM UTC-7, Paul Jolly wrote:
>
>
> Take a look at https://golang.org/ref/spec#Calls:
>
> "A method call x.m() is valid if the method set of (the type of) x 
> contains m and the argument list can be assigned to the parameter list of 
> m. If x is addressable and &x's method set contains m, x.m() is shorthand 
> for (&x).m()"
>

-- 
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] Global variable initialized in init() not working in main()

['Thomas Bushnell, BSG' via golang-nuts]

Your init is closing the file before returning, so at that point all the
writes are failing. If you check the error you receive from logger.Print
you should see something to that effect.

Thomas


On Mon, Feb 5, 2018 at 1:39 PM  wrote:

> I'm initializing a Logger variable in an init() function and then
> attempting to use in the main() function. However, I'm able to Printf from
> the Logger in the init() function but not inside the main() function. Any
> help would be appreciated.
>
> package main
>
> import (
>
> "fmt"
> "log"
> "io"
>
> "os"
>
> }
>
> var (
>
> logFile *os.File
> logger *log.Logger
> multiWriter io.Writer
>
> )
>
> func init() {
>
> fmt.Println("init() function")
>
> var logFileError error
> logFile, logFileError = os.Create("gopoc.log")
> if logFileError != nil {
> panic(logFileError)
> }
> defer logFile.Close()
>
> fmt.Println("Creating log file")
>
> multiWriter = io.MultiWriter(logFile, os.Stdout)
>
> logger = log.New(multiWriter, gopocLogPrefix, log.Ldate | log.Ltime |
> log.Lshortfile)
> logger.SetOutput(multiWriter)
>
> fmt.Println("Created logger")
>
> logger.Printf("Using logger")  // prints to console and logFile as expected
>
> }
>
> func main() {
>
> fmt.Println("main() function ") // prints to console
>
> fmt.Println(logger) // I can see the object pointer
>
> logger.Print("hello") // This does not print to logFile nor
> os.Stdout !!!
>
> }
>
> --
> 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] Question about the spec: Method Sets and Pointer Receivers

['Axel Wagner' via golang-nuts]

That sentence wouldn't be true, though. There is a call-expression
shorthand, but the method does not actually get added to T - so, for example

var b bytes.Buffer
b.WriteString("foo") // fine
(&b).WriteString("foo") // the same, as it's just syntactic sugare
r := strings.NewReader("foo")
io.Copy(b, r) // error: bytes.Buffer does not implement io.Writer, Write
has pointer receiver
io.Copy(&b, r) // fine

Method sets are relevant for interface implementation.

On Mon, Feb 5, 2018 at 10:34 PM,  wrote:

> This issue once puzzled me, too.  It would help to add something to the
> spec section on method sets .  I
> suggest something like this at the very end of the second paragraph:
>
> ... Additionally, if a receiver of type T is *addressable
> *, its method set is
> effectively extended to include the method set of *T (see *calls
> *).
>
>
> On Monday, February 5, 2018 at 12:53:32 PM UTC-7, Paul Jolly wrote:
>>
>>
>> Take a look at https://golang.org/ref/spec#Calls:
>>
>> "A method call x.m() is valid if the method set of (the type of) x
>> contains m and the argument list can be assigned to the parameter list of
>> m. If x is addressable and &x's method set contains m, x.m() is shorthand
>> for (&x).m()"
>>
> --
> 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] Global variable initialized in init() not working in main()

[Michael Brizic]

Thank you, missed that, didn't fully understand the nature of *defer*, but 
now I do!

On Monday, February 5, 2018 at 3:42:10 PM UTC-6, Thomas Bushnell, BSG wrote:
>
> Your init is closing the file before returning, so at that point all the 
> writes are failing. If you check the error you receive from logger.Print 
> you should see something to that effect.
>
> Thomas
>
>
> On Mon, Feb 5, 2018 at 1:39 PM > wrote:
>
>> I'm initializing a Logger variable in an init() function and then 
>> attempting to use in the main() function. However, I'm able to Printf from 
>> the Logger in the init() function but not inside the main() function. Any 
>> help would be appreciated.
>>
>> package main
>>
>> import (
>>
>> "fmt"
>> "log"
>> "io"
>> 
>> "os"
>>
>> }
>>
>> var (
>>
>> logFile *os.File 
>> logger *log.Logger
>> multiWriter io.Writer
>>
>> )
>>
>> func init() {
>>
>> fmt.Println("init() function")
>>
>> var logFileError error
>> logFile, logFileError = os.Create("gopoc.log")
>> if logFileError != nil {
>> panic(logFileError)
>> }
>> defer logFile.Close()
>>
>> fmt.Println("Creating log file")
>>
>> multiWriter = io.MultiWriter(logFile, os.Stdout)
>>
>> logger = log.New(multiWriter, gopocLogPrefix, log.Ldate | log.Ltime | 
>> log.Lshortfile)
>> logger.SetOutput(multiWriter)
>>
>> fmt.Println("Created logger")
>>
>> logger.Printf("Using logger")  // prints to console and logFile as 
>> expected
>>
>> }
>>
>> func main() {
>>
>> fmt.Println("main() function ") // prints to console
>>
>> fmt.Println(logger) // I can see the object pointer
>>
>> logger.Print("hello") // This does not print to logFile nor 
>> os.Stdout !!!
>>
>> }
>>
>> -- 
>> 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.

[go-nuts] gomobile - SIGPIPE

[mihai]

I'm trying to develop a gomobile application using a http server serving 
html and a swift client serving the content from localhost through a 
WKWebView. All the work happens inside the http handlers(i.e. http requests 
to external API servers). 
  The issue is that after several requests the application crashes with 
SIGPIPE. I've searched through issues and it seems this was a known issue 
and apparently  was fixed in [0]. How can I debug this further or is there 
any known fix? 


libsystem_kernel.dylib`mach_msg_trap:

0x180c5b560 <+0>: movx16, #-0x1f

0x180c5b564 <+4>: svc#0x80

->  0x180c5b568 <+8>: ret




$ go version
go version go1.9.2 darwin/amd64


https://github.com/golang/go/issues/17393

-- 
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] gobot and raspberry pi

[JM]

anyone know where i would begin to figure out if i can use this:
https://www.robotshop.com/uk/arducam-multi-camera-adapter-module-raspberry-pi.html

on a pi with gobot? I cant find any api or reference on how to use it, let 
alone anything for golang.

on want to run multiple cameras to take different angles of photos and only 
found this that board that would support multi-camera use.

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] About golang.org/x/net/prox and cancellation

[Juliusz Chroboczek]

Hi,

I'm using golang.org/x/net/proxy, and I've run into an issue: there
appears to be no way to cancel a (*proxy.Dialer).Dial in progress --
unlike net.Dialer, there is no DialContext method for proxy.Dialer.

Any idea for a workaround?

(By the way, since net.Dial is a struct, not an interface, my code ends
up pushing around parameters of type proxy.Dial, which I find weird.
Not problematic, just weird.)

-- Juliusz

-- 
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] Question about the spec: Method Sets and Pointer Receivers

[gtownsend]

You're right.  I do think expanding the section on method sets is 
worthwhile because that section *seems* to have the complete set of rules.  
But any addition needs to be clear, concise *and* correct.  How about:

... Additionally, an addressable 
 value of type T can be used 
to call methods declared with receiver type *T (see *calls* 
).


On Monday, February 5, 2018 at 2:44:26 PM UTC-7, Axel Wagner wrote:
>
> That sentence wouldn't be true, though. There is a call-expression 
> shorthand, but the method does not actually get added to T - so, for example
>
> var b bytes.Buffer
> b.WriteString("foo") // fine
> (&b).WriteString("foo") // the same, as it's just syntactic sugare
> r := strings.NewReader("foo")
> io.Copy(b, r) // error: bytes.Buffer does not implement io.Writer, Write 
> has pointer receiver
> io.Copy(&b, r) // fine
>
> Method sets are relevant for interface implementation.
>
> On Mon, Feb 5, 2018 at 10:34 PM, > wrote:
>
>> This issue once puzzled me, too.  It would help to add something to the 
>> spec section on method sets .  
>> I suggest something like this at the very end of the second paragraph:
>>
>> ... Additionally, if a receiver of type T is *addressable 
>> *, its method set is 
>> effectively extended to include the method set of *T (see *calls 
>> *).
>>
>>
>> On Monday, February 5, 2018 at 12:53:32 PM UTC-7, Paul Jolly wrote:
>>>
>>>
>>> Take a look at https://golang.org/ref/spec#Calls:
>>>
>>> "A method call x.m() is valid if the method set of (the type of) x 
>>> contains m and the argument list can be assigned to the parameter list of 
>>> m. If x is addressable and &x's method set contains m, x.m() is shorthand 
>>> for (&x).m()"
>>>
>> -- 
>> 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.

[go-nuts] Re: gomobile - SIGPIPE

[Elias Naur]

It's hard to know what's causing the SIGPIPE without more information. 
Ideally, a standalone recipe to reproduce the problem.

Make sure you have the latest version of gomobile as well.

 - elias

On Monday, February 5, 2018 at 10:53:09 PM UTC+1, mi...@ubo.ro wrote:
>
> I'm trying to develop a gomobile application using a http server serving 
> html and a swift client serving the content from localhost through a 
> WKWebView. All the work happens inside the http handlers(i.e. http requests 
> to external API servers). 
>   The issue is that after several requests the application crashes with 
> SIGPIPE. I've searched through issues and it seems this was a known issue 
> and apparently  was fixed in [0]. How can I debug this further or is there 
> any known fix? 
>
>
> libsystem_kernel.dylib`mach_msg_trap:
>
> 0x180c5b560 <+0>: movx16, #-0x1f
>
> 0x180c5b564 <+4>: svc#0x80
>
> ->  0x180c5b568 <+8>: ret
>
>
>
>
> $ go version
> go version go1.9.2 darwin/amd64
>
>
> https://github.com/golang/go/issues/17393
>

-- 
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.