[go-nuts] http.Get not retrieving properly encoded page compared to browser

[Dan Kortschak]

I am putting together a tiny tool to archive the go.science G+ group
for future archeology. However, I have run into an issue that I don't
understand and so don't know how to fix.

The code is here: https://play.golang.org/p/1vVm5dvVueS

This takes in a the Takeout JSON for the community's posts and then
just gets the page. The intention is to extract the post text and
comments into JSON since Takeout does not give you all the post
content, just the metadata.

What I am seeing that I don't understand is the following. Using my
browser at this page (https://plus.google.com/+DanKortschak/posts/Gqcss
cVQuoW) I see properly encoded text...

```
Raúl Mera expressed concerns about inter-convertibility between
matrices in go.matrix and biogo/matrix. This, in conjunction with some
restrictions I found on writing matrix code with biogo/matrix that
prevented me from using blas effectively, prompted me to create an
unsafe matrix type for Dense matrices that greatly facilitates
interconversion between the two packages.

type UnsafeDense struct {
Rows, Cols int
Data   []float64
Stride int
}


```

but in the page that is retrieved, some spaces and diacritic-containing 
runes are rendered incorrectly.

```
Raúl Mera expressed concerns about inter-convertibility between
matrices in go.matrix and biogo/matrix. This, in conjunction with some
restrictions I found on writing matrix code with biogo/matrix that
prevented me from using blas effectively, prompted me to create an
unsafe matrix type for Dense matrices that greatly facilitates
interconversion between the two packages.

        type UnsafeDense struct {
                Rows, Cols int
                Data       []float64
                Stride     int
        }


```


What I think is happening is that I am being sent non-UTF-8 encoded
data when performing the GET in my code above. Is this likely to be the
case and if so, how do I communicate to the server that I want UTF-8?

thanks
Dan

-- 
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: go for robotic control, walking balance, quad flight control

[Dan Kortschak]

Yeah, Gonum is 5 years old, and yet because of the design of the
language handles some aspects of numerical and scientific coding far
better than Matlab/NumPy - the rest is a work in progress.

On Wed, 2019-01-02 at 04:26 -0800, minfo...@arcor.de wrote:
> Thanks for mentioning Gonum. While IMO it does not play in the Matlab
> or 
> NumPy league,
> the math basics are there.
> 
> After all golang is just a ..lang.. and no control development
> toolbox.
> 
> Am Mittwoch, 2. Januar 2019 00:52:01 UTC+1 schrieb kortschak:
> 
> > 
> > Who uses [][]T for this? 
> > 
> > Gonum has implementations for many of the things that you would
> > need 
> > here and other projects provide other aspects. 
> > 
> > On Tue, 2019-01-01 at 14:52 -0800, minf...@arcor.de 
> > wrote: 
> > > 
> > > 
> > > Am Montag, 31. Dezember 2018 23:06:23 UTC+1 schrieb kortschak: 
> > > > 
> > > > 
> > > > 
> > > > Where do we fall down?  
> > > > 
> > > > On Mon, 2018-12-31 at 01:38 -0800, minf...@arcor.de
> > > >  
> > > > wrote:  
> > > > > 
> > > > > 
> > > > > And then Golang doesn't treat complex   
> > > > > matrix algebra well...  
> > > You really want to do controller design with go's 2-dimensional 
> > > slices?? 
> > > Good luck. Alone the syntax is horrible. 
> > > 
> > > I don't expect Matlab-like notation, but at least not too far
> > > away 
> > > from it. 
> > > 

-- 
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] scanner.Scan is holding my goroutine ;(

[Dan Kortschak]

Can you wrap the call to scanner.Scan in a func that has access to the
ccn context and returns false when it's closed?

On Thu, 2018-12-13 at 14:04 -0800, Ivan Korjavin wrote:
> I have a goroutenie with  scanner.Scan
> It looks like:
> 
> ```
> cnn.SetReadDeadline(time.Now().Add(c.rTimeout)) // 10s
> scanner := bufio.NewScanner(cnn)
> for scanner.Scan() {
> ...
> }
> ```
> cnn is a net.Conn there
> 
> My problem is when I call cnn.Close() (and I tried 
> cnn.SetReadDeadline(time.Now()) in addition as well)
> this scanner.Scan is still running and running and running.
> 
> I would like to close it immediately, but can't find a way how.
> 
> 
> Please, help me!
> 

-- 
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] tool to automatically refresh godoc ?

[Dan Kortschak]

And yes. The curl option is -d, not -F, so 

curl -X POST -d "path=${IMPORTPATH}" https://godoc.org/-/refresh

works and could easily be made into a post-push hook to be run in the
root of the package like so:

for pkg in $(go list ./...); do
curl -X POST -d "path=${pkg}" https://godoc.org/-/refresh
done

On Sat, 2018-12-22 at 07:44 +1030, Dan Kortschak wrote:
> A quick read of the gddo source suggests that this should work (but
> presumably because I have missed something, it doesn't)
> 
> curl -X POST -F "path=${IMPORTPATH}" https://godoc.org/-/refresh
> 
> On Thu, 2018-12-20 at 09:55 +0100, Sebastien Binet wrote:
> > 
> > hi there,
> > 
> > in all my Go-based projects I have a bunch of CI/CD tools that keep
> > me
> > honest about APIs, tests, coverage and what not.
> > 
> > but it happens from time to time that I either break an API and/or
> > add a
> > new field, a new function a new type, etc...
> > 
> > and it has happened also a few times that one of my user comes back
> > to me
> > and says the godoc page is stale, missing the new documentation for
> > some
> > type, etc...
> > 
> > has somebody written a tool that crawls all the packages and
> > "subpackages"
> > of a repository and updates the godoc page?
> > this could be useful as a post-hook when merging into "master" for
> > example.
> > 
> > cheers,
> > -s
> > 

-- 
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] tool to automatically refresh godoc ?

[Dan Kortschak]

A quick read of the gddo source suggests that this should work (but
presumably because I have missed something, it doesn't)

curl -X POST -F "path=${IMPORTPATH}" https://godoc.org/-/refresh

On Thu, 2018-12-20 at 09:55 +0100, Sebastien Binet wrote:
> hi there,
> 
> in all my Go-based projects I have a bunch of CI/CD tools that keep
> me
> honest about APIs, tests, coverage and what not.
> 
> but it happens from time to time that I either break an API and/or
> add a
> new field, a new function a new type, etc...
> 
> and it has happened also a few times that one of my user comes back
> to me
> and says the godoc page is stale, missing the new documentation for
> some
> type, etc...
> 
> has somebody written a tool that crawls all the packages and
> "subpackages"
> of a repository and updates the godoc page?
> this could be useful as a post-hook when merging into "master" for
> example.
> 
> cheers,
> -s
> 

-- 
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: pass interface

[Dan Kortschak]

Oh! Yeah, that's never going to work. How could it?

On Mon, 2018-12-10 at 13:43 -0800, Tyler Compton wrote:
> If my interpretation of the question is correct, I think it boils
> down to
> whether or not it's possible to get the reflect.Type of a type in
> order to
> pass it to a function without first creating an instance of that
> type. I
> don't think it's possible but I would be interested to hear from
> someone
> who knows more.
> 
> On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak 
> wrote:
> 
> > 
> > No, it is possible, but you need to pass the pointer to the
> > interface.
> > You can then use reflect to interrogate the interface value.
> > 
> > The bigger question, and one that would help here would be what is
> > it
> > that you are actually trying to achieve.
> > 
> > On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > > 
> > > Yes, this is what I'm trying to do!
> > > Perhaps this is not possible.
> > > 
> > > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels  > > com>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > I think what the OP wants is:
> > > > 
> > > > type A interface{}
> > > > type B interface{}
> > > > 
> > > > ...
> > > > PrintInterface(A)
> > > > 
> > > > Meaning they want to pass the interface definition to some
> > > > method.
> > > > 
> > > > At least that’s what I am guessing.
> > > > 
> > > > On Dec 9, 2018, at 9:22 PM, Space A. 
> > > > wrote:
> > > > 
> > > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > > > 
> > > > package main
> > > > 
> > > > import (
> > > > "fmt"
> > > > "reflect"
> > > > )
> > > > 
> > > > func main() {
> > > > test := interface{}("test")
> > > > printInterfaceValue(test)
> > > > }
> > > > 
> > > > func printInterfaceValue(i interface{}) {
> > > > switch testing := i.(type) {
> > > > case interface{}:
> > > > fmt.Println("is interface, with value:", testing)
> > > > case string:
> > > > fmt.Println("is not interface")
> > > > }
> > > > 
> > > > fmt.Println("reflect.Type is", reflect.TypeOf().Elem())
> > > > }
> > > > 
> > > > Output:
> > > > 
> > > > is interface, with value: test
> > > > reflect.Type is interface {}
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь
> > > > Robert
> > > > Engels
> > > > написал:
> > > > > 
> > > > > 
> > > > > 
> > > > > I mean reflect.Type not a type that is an interface.
> > > > > 
> > > > > On Dec 9, 2018, at 6:53 PM, Space A. 
> > > > > wrote:
> > > > > 
> > > > > Of course. When you "pass a value whose type implements the
> > > > > interface" as
> > > > > an interface argument to a function, you in fact pass an
> > > > > *interface*.
> > > > > 
> > > > > 
> > > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь
> > > > > Mark
> > > > > Volkmann
> > > > > написал:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Is it possible to pass an interface to a function in Go? I
> > > > > > don’t want to
> > > > > > pass a value whose type implements the interface, I want to
> > > > > > pass the
> > > > > > interface.
> > > > > > 
> > > > > > --
> > > > > > R. Mark Volkmann
> > > > > > Object Computing, Inc.
> > > > > > 
> > > > > --
> > > > > 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,
> > > 

Re: [go-nuts] Re: pass interface

[Dan Kortschak]

No, it is possible, but you need to pass the pointer to the interface.
You can then use reflect to interrogate the interface value.

The bigger question, and one that would help here would be what is it
that you are actually trying to achieve.

On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> Yes, this is what I'm trying to do!
> Perhaps this is not possible.
> 
> On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
> wrote:
> 
> > 
> > I think what the OP wants is:
> > 
> > type A interface{}
> > type B interface{}
> > 
> > ...
> > PrintInterface(A)
> > 
> > Meaning they want to pass the interface definition to some method.
> > 
> > At least that’s what I am guessing.
> > 
> > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
> > 
> > reflect/* is a bit tricky. Use pointer to get interface itself.
> > 
> > package main
> > 
> > import (
> > "fmt"
> > "reflect"
> > )
> > 
> > func main() {
> > test := interface{}("test")
> > printInterfaceValue(test)
> > }
> > 
> > func printInterfaceValue(i interface{}) {
> > switch testing := i.(type) {
> > case interface{}:
> > fmt.Println("is interface, with value:", testing)
> > case string:
> > fmt.Println("is not interface")
> > }
> > 
> > fmt.Println("reflect.Type is", reflect.TypeOf().Elem())
> > }
> > 
> > Output:
> > 
> > is interface, with value: test
> > reflect.Type is interface {}
> > 
> > 
> > 
> > 
> > 
> > 
> > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
> > Engels
> > написал:
> > > 
> > > 
> > > I mean reflect.Type not a type that is an interface.
> > > 
> > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
> > > 
> > > Of course. When you "pass a value whose type implements the
> > > interface" as
> > > an interface argument to a function, you in fact pass an
> > > *interface*.
> > > 
> > > 
> > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
> > > Volkmann
> > > написал:
> > > > 
> > > > 
> > > > Is it possible to pass an interface to a function in Go? I
> > > > don’t want to
> > > > pass a value whose type implements the interface, I want to
> > > > pass the
> > > > interface.
> > > > 
> > > > --
> > > > R. Mark Volkmann
> > > > Object Computing, Inc.
> > > > 
> > > --
> > > 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.
> > 
> 
> -- 
> R. Mark Volkmann
> Object Computing, Inc.
> 

-- 
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] tools for testing transport over flakey networks

[Dan Kortschak]

Is anyone aware of testing infrastructure for simulating flakey
networks without recourse to iptables on linux, i.e. a Go package/type
that can be used to to this?

thanks
Dan

-- 
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] tools for testing transport over flakey networks

[Dan Kortschak]

Yeah, that's the kind of thing.

On Tue, 2018-12-11 at 19:45 -0500, Ian Denhardt wrote:
> Quoting robert engels (2018-12-11 19:39:46)
> 
> > 
> > I am not sure you can do this at the application layer - you need
> > kernel support to drop packets.
> One could write a mock implementation of e.g. net.Conn that does this
> kind of simulation; have a goroutine that calls time.Sleep at random
> intervals in the most basic case. If you want to test UDP, randomly
> drop
> packets, reorder, etc. Could get fancier.  No external support
> required.
> 
> That was the kind of thing I interpreted Dan's question to be asking
> about.
> 
> I don't know off-hand of a good library that already does this
> though.
> 
> -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.

Re: [go-nuts] Re: pass interface

[Dan Kortschak]

Nice is a very strong word.

This is the alternative approach that doesn't require a value:

https://play.golang.org/p/FoA-GHcr56s

(now to the whole list)

On Tue, 2018-12-11 at 10:39 +0800, Huiqiang Li wrote:
> Nice! i think this is the right answer.
> 
> Dan Kortschak  于2018年12月11日周二 上午10:34写道：
> 
> > 
> > https://play.golang.org/p/VWPb_AcgUrl

-- 
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: pass interface

[Dan Kortschak]

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

On Mon, 2018-12-10 at 20:14 -0600, Mark Volkmann wrote:
> Here is some code that shows a part of what I'm trying to do.
> https://goplay.space/#8piYtjsqveZ
> 
> package main
> 
> import (
> "fmt"
> "reflect"
> )
> 
> type Shape interface {
> Area() float64
> Rotate(angle float64)
> Translate(x, y float64)
> }
> 
> func ReportInterface(intfPtr interface{}) {
> fmt.Println("type is", reflect.TypeOf(intfPtr)) // *main.Shape
> value := reflect.ValueOf(intfPtr)
> fmt.Println("value is", value)// 
> fmt.Println("method count is", value.NumMethod()) // 0, Why not 3?
> }
> 
> func main() {
> var ptr *Shape
> ReportInterface(ptr)
> }
> 
> On Mon, Dec 10, 2018 at 3:28 PM Dan Kortschak 
> wrote:
> 
> > 
> > No, it is possible, but you need to pass the pointer to the
> > interface.
> > You can then use reflect to interrogate the interface value.
> > 
> > The bigger question, and one that would help here would be what is
> > it
> > that you are actually trying to achieve.
> > 
> > On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > > 
> > > Yes, this is what I'm trying to do!
> > > Perhaps this is not possible.
> > > 
> > > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels  > > com>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > I think what the OP wants is:
> > > > 
> > > > type A interface{}
> > > > type B interface{}
> > > > 
> > > > ...
> > > > PrintInterface(A)
> > > > 
> > > > Meaning they want to pass the interface definition to some
> > > > method.
> > > > 
> > > > At least that’s what I am guessing.
> > > > 
> > > > On Dec 9, 2018, at 9:22 PM, Space A. 
> > > > wrote:
> > > > 
> > > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > > > 
> > > > package main
> > > > 
> > > > import (
> > > > "fmt"
> > > > "reflect"
> > > > )
> > > > 
> > > > func main() {
> > > > test := interface{}("test")
> > > > printInterfaceValue(test)
> > > > }
> > > > 
> > > > func printInterfaceValue(i interface{}) {
> > > > switch testing := i.(type) {
> > > > case interface{}:
> > > > fmt.Println("is interface, with value:", testing)
> > > > case string:
> > > > fmt.Println("is not interface")
> > > > }
> > > > 
> > > > fmt.Println("reflect.Type is", reflect.TypeOf().Elem())
> > > > }
> > > > 
> > > > Output:
> > > > 
> > > > is interface, with value: test
> > > > reflect.Type is interface {}
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь
> > > > Robert
> > > > Engels
> > > > написал:
> > > > > 
> > > > > 
> > > > > 
> > > > > I mean reflect.Type not a type that is an interface.
> > > > > 
> > > > > On Dec 9, 2018, at 6:53 PM, Space A. 
> > > > > wrote:
> > > > > 
> > > > > Of course. When you "pass a value whose type implements the
> > > > > interface" as
> > > > > an interface argument to a function, you in fact pass an
> > > > > *interface*.
> > > > > 
> > > > > 
> > > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь
> > > > > Mark
> > > > > Volkmann
> > > > > написал:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Is it possible to pass an interface to a function in Go? I
> > > > > > don’t want to
> > > > > > pass a value whose type implements the interface, I want to
> > > > > > pass the
> > > > > > interface.
> > > > > > 
> > > > > > --
> > > > > > R. Mark Volkmann
> > > > > > Object Computing, Inc.
> > > > > > 
> > > > > --
> > > > > 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.
> > > > 
> > > --
> > > R. Mark Volkmann
> > > Object Computing, Inc.
> > > 

> 

-- 
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] fixed point math library

[Dan Kortschak]

On Thu, 2018-11-29 at 17:07 -0600, robert engels wrote:
> The dot imports are useful, and others feel the same https://github.c
> om/golang/lint/issues/179
> . When you make statements
> like, 
> 
> > 
> > Now given that dot imports are generally considered a bad idea in
> > Go
> It feels a lot like the “cut off the sides of the roast to fit it in
> the oven”.
> 
> As I cited, there were static imports added to Java a long time ago,
> and it is not a problem. Clearly it can’t be that challenging to Go
> developers.

Just because something existed somewhere else with different context
(where is may or may not have been a good idea) means that it will be a
good idea here.

> In Java you don’t write java.lang.Object… you write Object. Similarly
> in Go, I don’t write github.com/golang/go/runtime/X
>  I write runtime.X and I don’t
> write go.int64 I write int64 - why? because int64 is a language
> specified type.

There's a significant difference here. In go we don't continually
reiterate the import path is is unfortunately the case in java. That
additional verbosity is possibly a reason why it might have been a good
idea in java, though eliding the redundant path information at the call
site probably would have been better.

> By using dot imports you can promote user types to standard types.

And in my experience this leads to additional cognitive load on the
maintainer. A similar argument exists for why operator overloading
doesn't exist in Go.

> When writing application code - not systems code - you are often
> working in a constrained environment that the architect has chosen.
> The dot imports allow the coding to be close to a DSL. Maybe I create
> a package ‘common’ that has “wrappers/facades’ for a lot of
> APIs/packages I want my developers to use, but I don’t want to expose
> all of the functionality. By using a dot import on the common
> package, the developer works with a concept “Fixed” - she doesn’t
> need to know it is maybe a decimal.Decimal behind the scenes, and it
> has a API limited to the solving the problem domain.

The labels make close to zero difference here. If the user wants to
make a dsl, they can do that, but don't expect me to consume their
code.

> It allows the designer and extra layer of abstraction and
> simplification. The developers don’t need to import/learn a gazillion
> packages with hundreds of methods, they import ‘common’ as a facade
> providing a simplified interface to the system. Having to prefix
> every type with ‘common' is senseless. In reality there would
> probably be multiple packages, like ‘common’, ‘printing’, ‘security’,
> ‘database' etc. but even then the name collision would be limited by
> the designer. This is enterprise/framework design 101.
> 
> 
> 
> 
> 
> > 
> > On Nov 29, 2018, at 4:34 PM, Daniel Kortschak 
> > wrote:
> > 
> > fixed.Number reduces stutter and is more informative. This was
> > Jan's
> > point.
> > 
> > In general dot imports are a bad idea when maintaining large code
> > bases
> > since it requires more work to figure out what is actually
> > providing
> > the X that has been added to the . imports pool. It also a prevents
> > the
> > protection you get from importing colliding labels under different
> > name
> > spaces. foo.X and bar.X; import ( . "foo"; . "bar" ) and you have
> > problems.
> > 
> > When you change the rules of the game, of course you can win. My
> > point
> > below says that information is not reduced by lossless compression
> > (your claim being the opposite). Given that as you show fixed.Fixed
> > is
> > almost completely compressible without any tricks to 50% its
> > original
> > size (almost because of the capitalisation, but given the
> > requirement
> > for exported labels to be capitalised we can invoke context,
> > though...
> > if you rename your package to Fixed, then you get perfect 50%
> > compression without context). Now given that dot imports are
> > generally
> > considered a bad idea in Go and that as you show your label can be
> > compressed, the conclusion is not that you should compress, but
> > rather
> > there is room to add additional information; fixed.Number.
> > 
> > Thanks for playing!
> > 
> > On Thu, 2018-11-29 at 16:24 -0600, robert engels wrote:
> > > 
> > > Right and since fixed.Fixed can be reduced to Fixed with no loss
> > > of
> > > information, it is a great lossless compression - more than 50 %.
> > > 
> > > Thanks for playing !
> > > 
> > > 
> > > > 
> > > > 
> > > > On Nov 29, 2018, at 4:11 PM, Daniel Kortschak  > > > .io>
> > > > wrote:
> > > > 
> > > > That is correct. The number of physical bits used to represent
> > > > the
> > > > information is reduced. The number of bits of information
> > > > remains
> > > > the
> > > > same except in the case of lossy compression.
> > > > 
> > > > If this were not true, I could propose the following
> > > > compression
> > > > protocol: count the 

Re: [go-nuts] [ANN] fixed point math library

[Dan Kortschak]

Very nice.

On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote:
> Nigel Tao  once said:
> > 
> > Well, there's already context.Context, hash.Hash, image.Image and
> > time.Time in the standard library.
> All of which are not great. Better names are context.Frame,
> hash.Function, raster.Image, and time.Instant.
> 
>   Anthony
> 

-- 
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] Package Stutter

[Dan Kortschak]

That's pretty different to a dot import in Go. If the imports below
gave you 

List list = singletonList(someobject)

Then they would be comparable - the static imports are more comparable
to Go's dot imports, but then in your next post you say that they're
mainly used for constants, "although for some types of routines it is
used to make the code read like a DSL."



On Sun, 2018-12-02 at 00:04 -0600, robert engels wrote:
> When you use
> 
> import java.util.Collections;
> import java.util.List;
> 
> You are actually doing a dot import, so you can in the code just
> refer to it as so
> 
> List list = Collections.singletonList(someobject)
> 
> otherwise you need to write the code as:
> 
> java.util.List list =
> java.util.Collections.singletonList(someobject);

-- 
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: [SUSPECTED SPAM][go-nuts] pass interface

[Dan Kortschak]

If you want the interface to be interpreted as an interface value and
your parameter type is interface{}, you can pass a pointer to the
interface value and then work with that.

On Sun, 2018-12-09 at 14:23 -0600, Mark Volkmann wrote:
> Is it possible to pass an interface to a function in Go? I don’t want
> to
> pass a value whose type implements the interface, I want to pass the
> interface.
> 
> -- 
> R. Mark Volkmann
> Object Computing, Inc.
> 

-- 
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] Syntax highlighting (again) [WAS go language sensitive editor?]

[Dan Kortschak]

As Ian has said, this is true in some circumstances.

When I want to know what something does I will read it. When I am
dipping in to refresh my memory or to start investigating a bug, then I
read with random access. The latter two are more common.

Dan

On Sat, 2018-11-24 at 16:06 -0600, robert engels wrote:
> I would argue that good code reads in a linear manner - if it doesn’t
> it is a problem with the programmer or the language syntax/grammer.

-- 
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] Syntax highlighting (again) [WAS go language sensitive editor?]

[Dan Kortschak]

Thanks for bumping this. I had intended to respond.

There is a fundamental difference between reading English prose (or
whatever your native language is) and code; prose is read as a
continuous stream while code is often read in a random access manner.
An interesting point here is that natural language writing like
reference manuals actually do often include things similar to syntax
highlighting where key points are bolded, underlined or italicised in a
manner broader than is common in prose.

The other point here is that syntax highlighting is not restricted to
altering the colours of parts of speech. For example, I use semantic
highlighting (what I jokingly call Hawaiian style) that colours labels
based on their hash (my theme also renders keywords in an intensity
diminished form since they are largely punctuation in my reading). This
helps me recognise patterns in code much more quickly.

Is it a crutch, sure, but until you're editing with butterfly wing
flaps, we're all using crutches.

Dan

On Sat, 2018-11-24 at 07:09 -0600, Sam Whited wrote:
> On Fri, Nov 23, 2018, at 17:06, Jay Ts wrote:
> >
> > Nowadays I use vim
> > because there are a few nice things about it that aren't in vi. At
> > least,
> > vim is ok after you turn off syntax highlighting and all the other
> > newbie
> > crutches. :-P Seriously, how many people can't read or write in
> > English (or
> > their native language) if the verbs, nouns, and prepositions are
> > the same
> > color? I don't get it.
> Okay, I'll bite: Anyone can still read code without syntax
> highlighting, it doesn't provide any information that's not already
> there. It just provides another dimension of visibility to that
> information so that you can make certain judgements quicker. If the
> compiler gives you a worthless error message and you don't know why
> something isn't working, you might be able to see at a glance that a
> multi-line string isn't terminated when everything is in string color
> instead of scrolling up several hundred lines wondering why it said
> the file ended early. It's not a crutch, as it probably doesn't help
> you if you can't walk already.
>
> —Sam
>

-- 
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] Is conversion between int and uint a no-op i.e. is it free

[Dan Kortschak]

int and uint are the same size per the spec, so there is nothing to do
(no sign extension and no subsequent truncation).

What happens in other languages is largely irrelevant here (golang-
nuts).

On Sat, 2018-11-24 at 18:16 -0600, robert engels wrote:
> This maybe true for Go, but not necessarily all languages. It might
> be implemented as
>
> result = original & 0x7FFF (for 32 bit int to uint)
>
> it depends on how the language specifies the conversion will occur.
>
> That being said, in Go the spec says:
> For the conversion of non-constant numeric values, the following
> rules apply:
>
> When converting between integer types, if the value is a signed
> integer, it is sign extended to implicit infinite precision;
> otherwise it is zero extended. It is then truncated to fit in the
> result type's size. For example, if v := uint16(0x10F0), then
> uint32(int8(v)) == 0xFFF0. The conversion always yields a valid
> value; there is no indication of overflow.
> the compiler and platform might actually need to add the AND as
> specified above, or other sign extension operations… on most
> platforms, probably not since int and uint would be the same size.
> The ambiguity with the above spec, is that a negative number will
> become positive, or visa-verse - even though this is not technically
> ‘overflow’, at least IMO.
>
> >
> > On Nov 24, 2018, at 5:49 PM, 'Keith Randall' via golang-nuts  > g-n...@googlegroups.com> wrote:
> >
> > int<->uint conversions should never generate any machine code. They
> > are free.
> >
> > On Saturday, November 24, 2018 at 10:55:50 AM UTC-8, Andy Balholm
> > wrote:
> > There is nothing in the language spec that guarantees anything
> > about performance. But if logic tells you that it should be a no-
> > op, and examination of the generated code shows you that it is a
> > no-op in the cases you tested, you can safely assume that it is not
> > going to be an issue for your program’s performance.
> >
> > Andy
> >
> > >
> > > On Nov 24, 2018, at 8:45 AM, Ugorji Nwoke >
> > > wrote:
> > >
> > > Thanks so much Silviu. I love this tool - I had seen it before,
> > > but didn't realize it also supported go language. Thanks so much
> > > for bringing it up - it should help me do more investigation on
> > > my own faster.
> > >
> > > I used it to compare the asm output, and I got the same thing as
> > > when I did
> > > go build -gcflags "-S" num_conversion.go
> > >
> > > i.e. it leads me to conclude, as I suspected, that conversion
> > > from int to uint is free (no-op at runtime).
> > >
> > > However, I get concerned that my proof may be insufficient, or
> > > there may be other reason why the asm looks same, and that is why
> > > I wanted a definitive answer from someone familiar with the
> > > internals.
> > >
> > >
> > > On Saturday, November 24, 2018 at 11:28:43 AM UTC-5, Silviu
> > > Capota Mera wrote:
> > > A very nice tool from Matt Godbolt (and team of volunteers): http
> > > s://godbolt.org/z/4nt5cJ 
> > >
> > > You can switch compiler version (e.g. Go 1.4, 1.7, 1.9, 1.11,
> > > tip, etc) and/or gccgo, take a look at variations, etc
> > >
> > > On Saturday, 24 November 2018 11:07:51 UTC-5, Jan Mercl wrote:
> > > On Sat, Nov 24, 2018 at 4:31 PM Ugorji Nwoke  > > <>> wrote:
> > >
> > > >
> > > > Jan, you and I have the same understanding i.e. float <-> int
> > > > is obviously non-free, but I can't think of why int <-> uint
> > > > will not be free. However, I want someone with knowledge of
> > > > the
> > >  > compiler/runtime/codegeneration/SSA internals that can give me
> > > a definitive answer.
> > >
> > > Any correct compiler is an implementation of the language
> > > specification. From the language specification it follows that
> > > the compiler _may_ check that - for example - 42 != 314 or 278 ==
> > > 278 while performing the 'uint' <-> 'int" conversion. It may also
> > > try to factor M4170639287. The question is why to do so when
> > > nothing of that is mandated by the language specification for a
> > > correct implementation?
> > >
> > > The next reasonable step is to assume Occam's razor is a thing.
> > >
> > > --
> > > -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...@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  > olang-nuts+unsubscr...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> > .
--
CRICOS provider code 00123M

-- 
You received this 

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Dan Kortschak]

I don't agree that it was a bad idea. It eases reading and writing in
many cases. The mutability of a value is based on the method signature,
which is readily available through the godoc.

On Mon, 2018-11-19 at 17:57 -0600, Robert Engels wrote:
> I understand that. I was stating that the syntactic sugar of
> automatic pointer creation to call a method should be removed. Having
> an A become a *A in one instance but not in others just causes
> confusion, let alone makes things not obviously mutable, mutable,
> causing a developer to determine that the method actually have a
> pointer receiver. I know it won’t because of backwards compatibility,
> but it was a very bad choice IMO.

-- 
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: Force pointer at compile time to interface{} parameter

[Dan Kortschak]

As Axel points out this is not the case. This can be demonstrated by
trying to assign the struct to an interface that has the method you are
wanting to call. The following would compile under the rules you're
suggesting. It doesn't.

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


On Mon, 2018-11-19 at 15:37 -0600, Robert Engels wrote:
> That is not really true though, as I can declare a method that take a
> pointer receiver and mutate through it, but the caller can pass a
> struct which it thinks can not be mutated.
>
> https://play.golang.org/p/Abf4VX9kUTR
>
> Go isn’t type safe by stating that methods cannot mutate structs. Any
> reader of the above code would think that couldn’t work, unless they
> inspected the source to find a pointer receiver.
>
> >
> > On Nov 19, 2018, at 3:28 PM, Axel Wagner  > .com> wrote:
> >
> > The restriction has nothing to do with heaps (in fact, the Go
> > language
> > (i.e. the spec) doesn't even have a concept of a "heap"). It's a
> > type-safety requirement. If you pass in a value, it can't be
> > mutated,
> > full-stop. Reflect shouldn't allow you to bypass type-safety - only
> > "unsafe" can do that, hence the name.
> > >
> > > On Mon, Nov 19, 2018 at 9:51 PM Robert Engels  > > com> wrote:
> > >
> > > Interesting. I guess that makes sense. But you would think that
> > > if using a reflection call should force the compiler to heap
> > > allocate , then no reason for the restriction.
> > >
> > > >
> > > > On Nov 19, 2018, at 2:33 PM, Ian Denhardt 
> > > > wrote:
> > > >
> > > > Quoting Robert Engels (2018-11-19 15:13:53)
> > > > >
> > > > > But isn’t that just for safety. Meaning the unmarshall could
> > > > > use it as a pointer via reflection and mutate it (but that is
> > > > > probably not what the caller expects in Go) ?
> > > > No, see:
> > > >
> > > >   https://play.golang.org/p/MyF0Dx87-1j
> > > >
> > > > If you pass in  instead and insert the appropriate call to
> > > > value.Elem(), it works.
> > > >
> > > > --
> > > > 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.

-- 
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] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Dan Kortschak]

A way around that might be to use the name of the variable that holds
the anonymous function, defaulting to func#n when it's a func literal.
This should be able to be gleaned from the analysis.

On Sun, 2018-11-25 at 16:04 -0800, Russtopia wrote:
> That still doesn't address what I'm getting at -- it doesn't give a
> semantically meaningful name to the goroutines, in stack traces,
> source
> code, or in code visualization tools such as graphviz diagrams.
>
> What does that goroutine actually *do*? Is it a worker for some
> specific
> purpose, does it read from stdin and forward to a pty/socket, does it
> wait
> for data on some channel, does it sleep until a particular event
> occurs and
> then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't
> very
> useful names for documentation and the current Go syntax allows no
> specification of this by naming the goroutine itself, short of moving
> it
> completely out of the scope of the enclosing named function, and
> losing the
> benefits of a closure.
>
> I guess what I'm getting at is that goroutines can't be named for
> what they
> *mean* or *do*. Comments can of course explain this within the source
> code,
> but I think there would be a concrete benefit to defining a
> convention for
> comment-tagging goroutines, in provide this foothold for external
> documentation tools; or, perhaps even better, a way to actually name
> goroutines like how GCC allows named, nested functions. This could
> even
> improve the readability of stack traces could it not?
>
> I've already devised a 'comment above each goroutine' hack, plus a
> post-processing tool (basically a sed script) to massage the output
> of the
> graphviz 'dot' data, where I place info above each goroutine so it
> can be
> renamed in the output diagram. That addresses the naming issue within
> graphviz diagrams for me, for now.
>
>
> On Sun, 25 Nov 2018 at 15:28, Dan Kortschak  du.au>
> wrote:
>
> >
> > That package doesn't introspect on running code, so a goroutine
> > name is
> > not necessary. go-callvis could label the anonymous functions by
> > their
> > filepath:line number or something else.
> >
> > On Sun, 2018-11-25 at 15:12 -0800, Russtopia wrote:
> > >
> > > I recently tried out a go tool for outputting code structure
> > > visualization
> > > using graphviz -- https://github.com/TrueFurby/go-callvis
> > >
> > > I found that goroutines are just labelled $1
> > > or
> > > similar
> > > by go-callvis. I could of course be wrong, but my thinking is
> > > that
> > > this is
> > > not really a shortcoming of graphviz, but rather a lack of
> > > support
> > > for
> > > naming goroutines within the language itself as goroutines are
> > > also
> > > 'unnamed' in this sense within stack traces. It would aid in
> > > understanding
> > > the purpose of goroutines within a structure diagram if
> > > goroutines
> > > could be
> > > named somehow.
> > >
> > > I was hoping there was a way within Go to give goroutines
> > > meaningful
> > > names
> > > in such a way that graphviz-like tools could pick up on it and
> > > make
> > > meaningful annotations.
> > >
> > > The runtime would, I suppose, also have to suffix a goroutine ID
> > > to a
> > > goroutine's name, since calling a function that contained
> > > goroutines
> > > repeatedly would result in multiple instances of each goroutine.
> > >
> > >
> > > On Fri, 23 Nov 2018 at 22:36,  wrote:
> > >
> > > >
> > > >
> > > > Debugging. For example, if I have a deadlocked request I might
> > > > want
> > > > to
> > > > attach with a debugger and find where exactly it's stuck.
> > > >
> > > > Right now this is complicated, you have to examine stacks of
> > > > all
> > > > goroutines to find the correct one.
> > > >
> > > > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > What's the need for this?
> > > > --
> > > > 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.
> > > >
--
CRICOS provider code 00123M

-- 
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] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Dan Kortschak]

That package doesn't introspect on running code, so a goroutine name is
not necessary. go-callvis could label the anonymous functions by their
filepath:line number or something else.

On Sun, 2018-11-25 at 15:12 -0800, Russtopia wrote:
> I recently tried out a go tool for outputting code structure
> visualization
> using graphviz -- https://github.com/TrueFurby/go-callvis
>
> I found that goroutines are just labelled $1 or
> similar
> by go-callvis. I could of course be wrong, but my thinking is that
> this is
> not really a shortcoming of graphviz, but rather a lack of support
> for
> naming goroutines within the language itself as goroutines are also
> 'unnamed' in this sense within stack traces. It would aid in
> understanding
> the purpose of goroutines within a structure diagram if goroutines
> could be
> named somehow.
>
> I was hoping there was a way within Go to give goroutines meaningful
> names
> in such a way that graphviz-like tools could pick up on it and make
> meaningful annotations.
>
> The runtime would, I suppose, also have to suffix a goroutine ID to a
> goroutine's name, since calling a function that contained goroutines
> repeatedly would result in multiple instances of each goroutine.
>
>
> On Fri, 23 Nov 2018 at 22:36,  wrote:
>
> >
> > Debugging. For example, if I have a deadlocked request I might want
> > to
> > attach with a debugger and find where exactly it's stuck.
> >
> > Right now this is complicated, you have to examine stacks of all
> > goroutines to find the correct one.
> >
> > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram
> > wrote:
> > >
> > >
> > > What's the need for this?
> > --
> > 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] The most performant deque of all time?

[Dan Kortschak]

Sometimes the code used in production is more concise or clever in
order to be more performant. The testing code then is more verbose in
order to do the work in a less efficient but clearer way. This may
result in the test code being longer than the tested code. In addition
to this there may be many lines describing test cases in tables; take
for example fmt where the fmt_test.go file is 1522 sloc while the
format.go and print.go files that it tests are together 1312 sloc,
similarly in json where decode_test.go is 1920 sloc and decode.go is
971.

Dan

On Tue, 2018-11-27 at 21:40 -0600, robert engels wrote:
> If the tests are internal, you technically needs tests for the tests
> - based on LOC there is more logic in the tests to “be correct” than
> actual lines of code.
>
> That is a snowballing problem if you ask me… If the code needs 3x LOC
> for “internal tests”, its a sign that the actual code is too complex
> / poorly designed / structured.
>
> Public API tests are a completely different thing, as their logic is
> documented by the public API.
>
> Again, JMO.
>
> >
> > On Nov 27, 2018, at 7:55 PM, Freddy Martinez  > m> wrote:
> >
> > Sorry Chris, I haven’t seen the code + tests, I don’t think that
> > having x lines of code and 2x lines for test code is a problem, in
> > fact, if you use TDD this is very common because you’ll have a
> > looot of line code in your tests because this is how TDD works…
> >
> > Why is this an issue ?
> >
> > Again, I haven’t seen the code, but IMHO, I don’t think that there
> > is a limit in the number line of code in your tests.
> >
> > Regards
> >
> >
> > =
> > Freddy Martínez García
> > Software Engineer
> > B.S. Computer Science
> > LinkedIn: https://ar.linkedin.com/in/freddy-martinez-garcia-4715725
> > 9 <https://ar.linkedin.com/in/freddy-martinez-garcia-47157259>
> >
> > “If you give someone a program, you will frustrate them for a day;
> > if you teach them how to program, yo will frustrate them for a
> > lifetime.”
> >
> > David Leinweber
> >
> > On 27 November 2018 at 22:20:25, Christian Petrin (christianpetrin@
> > gmail.com <mailto:christianpet...@gmail.com>) wrote:
> >
> > >
> > > FYI, I have released deque version 1.0.1 <https://github.com/ef-d
> > > s/deque/blob/master/CHANGELOG.md>. Turns out there was a bug
> > > related to spared links. I really appreciate the help, Roger
> > > (@rogpeppe), for pointing out and helping fix the bug.
> > >
> > > On Mon, Nov 26, 2018 at 8:07 PM robert engels  > > com <mailto:reng...@ix.netcom.com>> wrote:
> > > No problem, but just one last word on this…
> > >
> > > You have 748 lines of internal unit tests and only 295 lines of
> > > actual code.. This IMO does not lend itself to maintainable &
> > > flexible code. If your 295 lines needs 748 to verify its
> > > correctness something is wrong. You have an additional 400 lines
> > > of integration tests - if those are full coverage they should be
> > > more than enough IMO, but again, just something to think about
> > > and to each his own.
> > >
> > >
> > >
> > > >
> > > > On Nov 26, 2018, at 9:56 PM, Christian Petrin  > > > gmail.com <mailto:christianpet...@gmail.com>> wrote:
> > > >
> > > > Moved the non-unit tests to the "deque_test" package. The tests
> > > > <https://github.com/ef-ds/deque>, package-wise, look as they
> > > > should now. Thanks Robert for the suggestion. :-)
> > > >
> > > > On Mon, Nov 26, 2018 at 2:01 PM robert engels  > > > m.com <mailto:reng...@ix.netcom.com>> wrote:
> > > > It’s funny though, if you look at the container/ring tests,
> > > > they test the internal structure, but there are no tests of the
> > > > behavior, so if the data structure design is not correct, the
> > > > tests will pass but the operations may not work as expected
> > > > (especially after a refactor). A case of I know what should
> > > > happen…
> > > >
> > > > And then some public methods like Do()/Move() are not tested at
> > > > all.
> > > >
> > > >
> > > > >
> > > > > On Nov 26, 2018, at 3:43 PM, robert engels  > > > > .com <mailto:reng...@ix.netcom.com>> wrote:
> > > > >
> > > > > My “none” looks to have been a little s

[go-nuts] contracts thought experiment: dimension checks

[Dan Kortschak]

Background:

As part of the Gonum dev team, I have an interest in using Go for
scientific computing. This stems from long experience with unsafe
computing environments often used in, particularly, bioinformatics
(perl, python and R being standouts in the field, with packages that
often use dubious design and implementation practices that allow silent
failures giving plausible but incorrect results rather than following
than following the rule of repair. In Gonum packages we (perhaps non-
idiomatically in the context of the broader Go ecosystem) insist on
failing noisily when we can rather than allowing silent progression to
an incorrect result; we use panics instead of errors a fair bit because
they cannot be implicitly ignored.

Question:

One of the areas where we do this is in the mat package for matrix
arithmetic and linear algebra. We use panics in lieue of a compile-time
type check for appropriate input matrix shape (e.g. the check needed to
ensure [mxw] <- [mxn] x [nxw] is a valid operation). I don't see any
way to encode this kind of information into a contract as it stands in
the current contracts draft. I'm not entirely sure that any kind of
reasonably simple contract system *would* allow this. If we assume that
there is some type parameterised function that operates on say [n][m]T
to perform a matrix mult, can anyone see a way of encoding the required
constraint?

thanks
Dan

-- 
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: contracts thought experiment: dimension checks

[Dan Kortschak]

Thanks, Ian.

On Mon, 2018-11-26 at 20:46 -0800, Ian Lance Taylor wrote:
> On Mon, Nov 26, 2018 at 5:14 PM Dan Kortschak
>  wrote:
> >
> >
> > Background:
> >
> > As part of the Gonum dev team, I have an interest in using Go for
> > scientific computing. This stems from long experience with unsafe
> > computing environments often used in, particularly, bioinformatics
> > (perl, python and R being standouts in the field, with packages
> > that
> > often use dubious design and implementation practices that allow
> > silent
> > failures giving plausible but incorrect results rather than
> > following
> > than following the rule of repair. In Gonum packages we (perhaps
> > non-
> > idiomatically in the context of the broader Go ecosystem) insist on
> > failing noisily when we can rather than allowing silent progression
> > to
> > an incorrect result; we use panics instead of errors a fair bit
> > because
> > they cannot be implicitly ignored.
> >
> > Question:
> >
> > One of the areas where we do this is in the mat package for matrix
> > arithmetic and linear algebra. We use panics in lieue of a compile-
> > time
> > type check for appropriate input matrix shape (e.g. the check
> > needed to
> > ensure [mxw] <- [mxn] x [nxw] is a valid operation). I don't see
> > any
> > way to encode this kind of information into a contract as it stands
> > in
> > the current contracts draft. I'm not entirely sure that any kind of
> > reasonably simple contract system *would* allow this. If we assume
> > that
> > there is some type parameterised function that operates on say
> > [n][m]T
> > to perform a matrix mult, can anyone see a way of encoding the
> > required
> > constraint?
> There is no way to express that constraint.  In general contracts are
> only intended to express things that can be described in the type
> system.  What you are asking for--a relationship between the lengths
> of different slice types--can not be described in the type system.
>
> This of it this way: the purpose of a contract is to decide when it
> is
> OK to instantiate a generic function with a given type.  When making
> that decision at compile time, we don't know the length of a slice.
> So we can't use the length of a slice when deciding whether to
> instantiate a generic function.
>
> (That said, one could imagine extending contracts to permit them to
> describe non-type arguments, and then one could use an integer
> argument to set the size of an array, and then one could write a
> contract describing the relationship between arrays.  Of course the
> caller would have to pass arrays rather than slices, which would not
> work well with sub-matrixes.)
>
> Ian
--
CRICOS provider code 00123M

-- 
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] contracts thought experiment: dimension checks

[Dan Kortschak]

Yes, this was raised as a possibility by Ian. But this negates a very
valuable aspect of matrices that I completely failed to consider in
writing the question: the issue of submatrices and how these are
valuable.

On Mon, 2018-11-26 at 20:49 -0800, Tamás Gulácsi wrote:
> Just a silly idea: what if you make the dimensions (m,n) part of the
> type, not just T, somehow?
>

-- 
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] The most performant deque of all time?

[Dan Kortschak]

container/ring (a arguably non-idiomatic stdlib package does indeed
contain this kind of test). It also does not have in code asserts,
which are something that I've found to be very rare in Go code.

On Mon, 2018-11-26 at 12:09 -0600, robert engels wrote:
> I am just offering, and many would disagree, that unit tests that
> like are brittle and not worthwhile. I don’t see them in the Go
> stdlib for major packages, but I could be wrong.
>
> My thought on this is that if you are testing the nitty details of
> the implementation, you need to get that “correct” twice - and if it
> is failing, you don’t really know which one is wrong… This is
> especially problematic as things are refactored - all of those types
> of tests break.
>
> I’m of the opinion - test the behavior comprehensively, and expose
> the expected usage (and corresponding design) there.
>
> >
> > On Nov 26, 2018, at 11:58 AM, Christian Petrin  > il.com> wrote:
> >
> > Hi Robert,
> >
> > the deque has unit, integration and API tests. The unit tests, I
> > agree, are hard to follow as they have to check all internal
> > properties to make sure the code is doing what it is supposed to do
> > (keep a well formed ring linked list during all steps). Given their
> > nature (unit tests), the only way to access the internal deque
> > variables is to have them in the same package.
> >
> > Regarding the other, API and integration tests, I agree 100%. They
> > should be in the dequeue_test package as they are not supposed to
> > access (or know of) any of the deque internal variables. I'll move
> > these tests to a different file in the dequeue_test package.
> >
> > Really appreciate the suggestion (correction, really).
> >
> > Thanks,
> > Christian
> >
> >
> >
> >
> > On Mon, Nov 26, 2018 at 9:42 AM robert engels  > m > wrote:
> > Just an FYI, IMO your testing is incorrect.
> >
> > Your tests should be in a package dequeue_test so that they cannot
> > access the internal details. This makes them brittle and hard to
> > follow.
> >
> > For reference, look at the Go stdlib sync/map.go and
> > sync/map_test.go. All of the tests are in sync_test for all of the
> > structs/methods.
> >
> >
> > >
> > > On Nov 26, 2018, at 10:59 AM, Christian Petrin  > > mail.com > wrote:
> > >
> > > Hello,
> > >
> > > I'm working on a logging system called CloudLogger  > > b.com/cloud-logger/docs> and to cut to the chase, CloudLogger
> > > needs an unbounded in-memory queue. The idea is to use the queue
> > > as a sequential data store. As there's no telling beforehand how
> > > much data will need to be stored, the queue has to be able to
> > > scale to support large amounts of data, so CloudLogger needs an
> > > unbounded queue, a very fast and efficient one.
> > >
> > > Noticing Go doesn't offer an unbounded queue implementation, I
> > > came up with an idea to build a queue based on linked slices.
> > >
> > > I was so impressed with the results that I decided to spend some
> > > time researching about other queue designs and ways to improve
> > > it. I'm finally done with the research and I feel like the new
> > > queue is worth being considered to be part of the standard
> > > library.
> > >
> > > So please take a look at the issue. All suggestions, questions,
> > > comments, etc are most welcome!
> > >
> > > Due to many suggestions, I have deployed the deque as a proper
> > > external package. In order to help validate the deque and get it
> > > into the standard library, I need to somehow get people to start
> > > using it. If you are using a queue/stack/deque, please consider
> > > switching to the new deque. Also if you know someone who is using
> > > a queue/stack/deque, please let them know about the deque.
> > >
> > > I'm extremely interested in improving the queue and I love
> > > challenges. If you suspect there's a possibly better design or a
> > > better, more performant and balanced deque implementation out
> > > there, please let me know and I'm very glad to benchmark it
> > > against deque.
> > >
> > > Proposal: https://github.com/golang/go/issues/27935
> > > 
> > > Deque package: https://github.com/ef-ds/deque
> > > 
> > >
> > > Thanks,
> > > Christian
> > >
> > > --
> > > 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
> > > .
> >
> >
> > --
> > Thanks,
> > Christian
--
CRICOS provider code 00123M

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

Re: [go-nuts] Github independent issue tracker

[Dan Kortschak]

My suspicion is that using the email reply would require that the
correspondent be a GitHub user (possibly even a GitHub user subscribed
to the issue). This would not be the case for Jan with a bot having
filed the issue by proxy. In that case he probably would not even have
received any email notification of posts to an issue.

On Tue, 2019-01-08 at 12:14 +0100, Sebastien Binet wrote:
> On Tue, Jan 8, 2019 at 12:04 PM Jakob Borg  wrote:
> 
> > 
> > On 8 Jan 2019, at 11:11, Jan Mercl <0xj...@gmail.com> wrote:
> > 
> > 
> > But the most important thing is that no one is suggesting
> > "eschewing
> > GitHub". The topic of this thread was listed in the OP: How to make
> > it
> > easy/easier for people without a MS account to contribute to the
> > project.
> > This does not affect users having/using/creating MS accounts at
> > all.
> > 
> > Full disclosure: Yes, I do not touch anything Microsoft unless my
> > employer
> > needs that. I'm even lucky enough to have a $DAYJOB that does not
> > require
> > it. But that was not discussed or mentioned and it's _not_ the
> > topic. Let's
> > please stay on topic, thank you.
> > 
> > 
> > The topic is "GitHub independent issue tracker". Moving the issue
> > tracker
> > *away* from GitHub is what I’m referring to as "eschewing GitHub"
> > and is
> > what I think would be a mistake. Perhaps that’s not what you were
> > suggesting.
> > 
> > For just filing issues I could see something like a web form with
> > Google
> > authentication, proxied by a bot into GitHub. That is, something
> > similar to
> > what was used during the migration of issues to GitHub. But that
> > will make
> > it difficult or annoying to interact beyond the initial filing, I
> > would
> > think.
> > 
> FYI, one can reply-to with one's favorite email composer just fine.
> e.g.: https://github.com/gonum/gonum/issues/745#issuecomment-16460792
> 9
> 
> so that web-form would just need a valid email address, I think.
> 
> -s
> 

-- 
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: Secure password hashing algorithm in go.

[Dan Kortschak]

The problem with this approach is that something that's good enough for
This Use™ by the owner of the code will be seen by another person and
then used by someone else with less understanding. The world of
cryptography implementations is already contaminated enough with badly
implemented Correct™ systems, let's not add more choices for weak and
intrinsically broken systems.

On Mon, 2019-01-07 at 12:11 -0800, minfo...@arcor.de wrote:
> But as I said, for non-crypto requirements weak data (or password) 
> obfuscation can be sufficient.
> For such weak purposes an FNV-1 code 3-liner may be adequate.

-- 
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: C++ 11 to Golang convertor

[Dan Kortschak]

Note there that cznic/cc has moved to gitlab, at https://modernc.org/cc

On Mon, 2019-01-07 at 09:56 -0700, K Davidson wrote:
> My original comment was in regaurd to c++11, but seeing as the
> discussion
> has drifted towards c, you may want to take a look at
> https://github.com/xlab/c-for-go, it is based off of its based off of
> https://github.com/cznic/cc, and has been used to create go bindings
> for
> portaudio, libvpx, and a few others, including android ndk (android-
> go). It
> uses 'hints' via yaml file to ease  indirect translations, and me be
> adaptable to your needs.
> 

-- 
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: go for robotic control, walking balance, quad flight control

[Dan Kortschak]

Julia is a nightmare for peer reviewability.

Gonum exists largely because Matlab, NumPy and Julia did not satisfy.

On Fri, 2019-01-04 at 00:06 -0800, minfo...@arcor.de wrote:
> Am Mittwoch, 2. Januar 2019 22:51:07 UTC+1 schrieb kortschak:
> > 
> > 
> > Yeah, Gonum is 5 years old, and yet because of the design of the 
> > language handles some aspects of numerical and scientific coding
> > far 
> > better than Matlab/NumPy
> > 
> > 
> This is more than debatable. Don't underestimate scientific
> computation 
> needs,
> libraries and tools. Big data handling is another aspect there.
> 
> To get a feeling, you could also take a spin with Julia.
> 

-- 
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] [ANN] delivery for extending Google Takeout for Google+ Communities posts

[Dan Kortschak]

I wanted to be able to archive the posts from the go.science Google+
community. So I have made a pico tool that will do this, packaging up
the posts and JSON manifest into a zip when given the metadata from
Takeout.

The tools is available here: https://github.com/kortschak/delivery

It requires that you either have ownership of the community or can
obtain the posts metadata from an owner.

Given that The Go+ community has been used as a channel for Go
communication, it would be good if one of the owners (presumably in the
Go team) would make the Posts.json metadata available, archive and
publish the posts before sunset, or both.

Dan

-- 
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 can I find the Golang spec source code?

[Dan Kortschak]

That is the correct file, just at the wrong commit, here it is for
go1.12

https://github.com/golang/go/blob/release-branch.go1.12/doc/go_spec.html

On Wed, 2019-04-03 at 11:11 +0800, 李健 wrote:
> The web page is at: https://golang.org/ref/spec
> 
> I've searched Google/GitHub but can't find its source code, something
> like `golang_spec.md`.
> 
> In golang/go GitHub repo, I found a file named
> `go_spec.html`(https://github.com/golang/go/blob/master/doc/go_spec.h
> tml),
> but its contents don't match the spec web page.
> 
> 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.

Re: [go-nuts] a way to query the module sum of a dependency with the go tool?

[Dan Kortschak]

*bump*

On Fri, 2019-03-22 at 08:33 +1030, Dan Kortschak wrote:
> Is there a command that does something like `go list -m ` but
> also outputs the sum for the module and module's go.mod? Other than
> `grep  go.sum`.
> 
> thanks
> Dan
> 

-- 
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] a way to query the module sum of a dependency with the go tool?

[Dan Kortschak]

It just seemed like something that could probably exist. Partly
convenience though; go mod -p verify (print) or some such would work
anywhere in the module, while the approach I am using must be done at
the root. Not a big deal though.

thanks

On Sat, 2019-03-23 at 09:54 +, Paul Jolly wrote:
> FWIW, none that I'm aware of. If there were to be such a command I
> would probably expect it be an option to go mod verify.
> 
> Is there a problem with using go.sum in the way you're proposing?
> 
> Or is this more a convenience thing?
> 
> On Thu, 21 Mar 2019 at 22:03, Dan Kortschak  wrote:
> > 
> > 
> > Is there a command that does something like `go list -m `
> > but
> > also outputs the sum for the module and module's go.mod? Other than
> > `grep  go.sum`.
> > 
> > thanks
> > Dan
> > 
> > --
> > 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] Re: Why Go? What is the most important feature that led to you becoming a Go programmer?

[Dan Kortschak]

For the embedded, https://tinygo.org/, but limited back ends.

On Wed, 2019-02-27 at 02:02 -0800, Chris Hopkins wrote:
> What brought me to it was the concurrency. I spent my entire career 
> frustrated by not only how concurrency wasn't more of a thing in
> popular 
> languages, but also how so many people didn't seem to think it was a 
> problem. I pounced on Go when I heard about it. (Although I am
> currently 
> fluttering my eyelashes at Halide...)
> 
> What made me stay is the clarity and simplicity. So many languages
> seem to 
> be an exercise in showing off how clever you are, by using x clever 
> pattern. Go doesn't seem to suffer this.
> 
> If I could just use it for the embedded stuff i do...
> 
> Chris
> 
> On Tuesday, 26 February 2019 12:07:58 UTC, Louki Sumirniy wrote:
> > 
> > 
> > I just wanted to jot down and share my personal most important
> > reason, and 
> > make this thread a short sample of the most important aspect of Go
> > that 
> > drove you to learn and use it.
> > 
> > For me, it was this: I have been tinkering with programming on and
> > off 
> > over the years since I was 8 years old, when a TRS-80 CoCo arrived
> > in my 
> > house, and in all the time, and with many languages, from BASIC,
> > Assembler, 
> > Amiga E (this was the first that really came close to this reason
> > for me to 
> > learn go), C, Python and Vala, but in all of these instances, until
> > Go, I 
> > was unable to do the most important thing, as I have very good
> > visual 
> > thinking skills, but poor attention - to be able to complete even
> > a 
> > relatively simple application. 
> > 
> > My usual problem always was that I would get bogged down in some
> > detail, 
> > forget the bigger picture, and hit some big blocker in this detail
> > and then 
> > basically turn off the computer and go ride my skateboard. I have
> > now 
> > written several useful libraries, and massively extended and
> > rewritten (now 
> > around 80% done) a bitcoin-based cryptocurrency wallet/node server
> > suite.
> > 
> > Without Go's immediacy and simple, logical syntax and build system,
> > I am 
> > lost. Go may be unforgiving in its syntax and semantics, but this
> > is good 
> > because it's less decisions to make, and its really very possible
> > with Go 
> > to start writing code immediately, and figuring out how to slice up
> > the 
> > pieces and add new parts is far easier than in many other
> > languages, start 
> > from a very simple, vague base and sketch out the details bit by
> > bit. No 
> > other language has had this property that I have encountered
> > before. I 
> > often remark that the language's name and the short-attention-span
> > and high 
> > intelligence of many of its adopters have in common to some degree.
> > 
> > I think part of it has to do with how one must be explicit with
> > many 
> > things, but at the same time, other places you can skip
> > explications 
> > because of the implicit, also lets you focus on what's important
> > and not so 
> > much distract you with superficial details.
> > 
> > Many other languages force you to really separate coding and
> > architecting, 
> > Go lets you do it all on-the-fly.
> > 

-- 
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] distribution of go executables

[Dan Kortschak]

You're claiming expertise in copyright law in at least two
jurisdictions, and claiming greater understanding of Australian
copyright legislation than a person who has had training in Australian
copyright legislation as part of their employment.

I'm done here.

On Wed, 2019-02-27 at 23:19 +0300, Space A. wrote:
> Sorry? You have poor understanding and mess things, so what's wrong?
> Being
> dilatant is not crime, it's okay unless you start convincing yourself
> that
> false is true.
> 
> ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :
> 
> > 
> > Pull your head in and stop being rude to people here.
> > 
> > On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> > > 
> > > You have very poor understanding of the subject, messing
> > > everything
> > > up.

-- 
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] distribution of go executables

[Dan Kortschak]

Please read https://golang.org/conduct

Your comments here have been in my view contrary to this document.

On Wed, 2019-02-27 at 23:48 +0300, Space A. wrote:
> I could, of course, however I never did. And I'd like to keep myself
> out of
> the scope of discussion. If you re-read my messages, you'll find they
> were
> focused on topic, not shifting to persons. Thank you for your
> participation, it's always good to hear different opinions, even if
> they
> are not correct.
> 
> ср, 27 февр. 2019 г. в 23:35, Dan Kortschak :
> 
> > 
> > You're claiming expertise in copyright law in at least two
> > jurisdictions, and claiming greater understanding of Australian
> > copyright legislation than a person who has had training in
> > Australian
> > copyright legislation as part of their employment.
> > 
> > I'm done here.
> > 
> > On Wed, 2019-02-27 at 23:19 +0300, Space A. wrote:
> > > 
> > > Sorry? You have poor understanding and mess things, so what's
> > > wrong?
> > > Being
> > > dilatant is not crime, it's okay unless you start convincing
> > > yourself
> > > that
> > > false is true.
> > > 
> > > ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :
> > > 
> > > > 
> > > > 
> > > > Pull your head in and stop being rude to people here.
> > > > 
> > > > On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> > > > > 
> > > > > 
> > > > > You have very poor understanding of the subject, messing
> > > > > everything
> > > > > up.

-- 
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] distribution of go executables

[Dan Kortschak]

Pull your head in and stop being rude to people here.

On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> You have very poor understanding of the subject, messing everything
> up.

-- 
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] does assembly pay the cgo transition cost / does runtime.LockOSThread() make CGO calls faster?

[Dan Kortschak]

Assembly incurs a function call cost (non-inlineable AFAIU), but Cgo
incurs a function call cost with additional work for C stack and call
conventions translation as said by Tamás.




On Fri, 2019-03-01 at 08:13 -0800, Jason E. Aten wrote:
> If I include a chunk of assembly .s code in my Go code, does my
> program pay 
> the CGO transition cost of locking and changing to a C stack?
> 
> I'm pretty sure the answer is no. But my knowledge of the Go
> internals is 
> low enough that I thought I would like confirm that before I go
> pulling in 
> .s code.
> 
> Then for numerical work, if I need to call some Fortran 90 compiled
> library 
> routines, does it not just look like assembly? I suppose not... in
> the 
> sense that it makes certain assumptions about being able to grow the
> stack 
> it is running on without running out of space. Are there assumptions
> beyond 
> the stack that are used? Probably some "standard library" runtime 
> dependencies? 
> 
> So on to my central question: Can the CGO transition stack switching
> cost 
> be minimized by telling Go to run my main (single threaded) Go
> routine on a 
> C thread to start with?  In other words, can I minimize the CGO
> switching 
> cost by doing runtime.LockOSThread() or similar?
> 
> It seems like if we are already on a C thread, then perhaps *some
> large 
> part* of the cost of Go -> f90 can be avoided. Of course the Go
> compiler 
> doesn't know we are on a C thread in the general case, right(?), so
> it 
> probably can't optimize those transitions by omitting change-the-
> stack code.
> 
> Returning to the original throught about .s code, what would happen
> if that 
> code tried to grow the stack too far?  Just crash? Is there guidance
> about 
> how far assembly can grow the stack before it needs to check back
> with the 
> runtime?
> 
> Thanks!
> 
> 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] does assembly pay the cgo transition cost / does runtime.LockOSThread() make CGO calls faster?

[Dan Kortschak]

Yes, that's not unreasonable. With f2c, you could potentially get your
fortran into C, then Go asm and then call that.

Dan

On Fri, 2019-03-01 at 20:17 -0800, Jason E. Aten wrote:
> On Friday, March 1, 2019 at 6:46:11 PM UTC-6, kortschak wrote:
> > 
> > 
> > Assembly incurs a function call cost (non-inlineable AFAIU), but
> > Cgo 
> > incurs a function call cost with additional work for C stack and
> > call 
> > conventions translation as said by Tamás. 
> > 
> Thanks @kortschak.  The c2goasm project (https://github.com/minio/c2g
> oasm) 
> that Andrei mentioned shows benchmarks on
> its front README that suggest that even with the function call cost 
> included, the speed ratio is about 20:1 favoring assembly
> over CGO.
> 

-- 
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] distribution of go executables

[Dan Kortschak]

Probably not. The executable is a derivative work under most
understandings (this is the basis for the GPL to require that source
code be provided if the executable is distributed to an end user).

Any work writen in Go, using the stdlib (which includes runtime, so all
Go programs) is derivative of the stdlib. This means that the Go
license pertains.

On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
> You are wrong. 
> 
> 
> среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian Denhardt
> написал:
> > 
> > 
> > Quoting Space A. (2019-02-26 20:58:40) 
> > 
> > > 
> > > and stdlib only when redistributed separately as a whole in
> > > binary 
> > > form. When stdlib is used to compile regular binary, it's not 
> > > "redistributed" 
> > This is not my understanding; in general static linking
> > constitutes 
> > distribution (though you are correct re: compiler output of your
> > own 
> > code). 
> > 
> > > 
> > > Correct answer 
> > The "correct answer," really, is to ask someone actually qualified
> > to 
> > give you legal advice. 
> > 
> > -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.

Re: [go-nuts] distribution of go executables

[Dan Kortschak]

In-line

On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
> Executable is not derivative work to stdlib or anything.

I think you'll find this is not the case in most jurisdictions. It is
certainly not true here, and probably also not in the US.

From https://www.copyright.gov/circs/circ14.pdf

"A derivative work is a work based on or derived from one or more
already existing works."

> Go's repo license covers only repo.

No.

Point 2:

"Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution."

Note that redistribution is based on the notion of derivative works
above. The binary is a derivative of the source code, which is, in this
case the standard library.

> Stdlib is not redistributed when you compile binary.

Yes it is, in a derivative form.

> It has nothing to do with GPL.

The licenses are different. In this sense you are absolutely correct,
this has nothing to do with the GPL. However, in another, far more
correct sense, it is indeed related. Both the GPL and the BSD3 are
based on the notions that make copyright work. The licensing of the
work is based on that fact that the copyright owner has a sole right to
distribute the work. This is licensed to the recipient under a set of 
conditions based on well established definitions of "derivative" and 
"redistribute". Those two terms are shared by the GPL and BSD3.

Note that the LGPL goes to lengths to distinguish between the binary of
the licensed work and items that are derivative, but dynamically
linked, purely because of the connection between the original source
and the binary that is the resulting executable (i.e. not the binary
representation of the library).

> Go's license is simple and clear.

And yet, here we are. The short answer to this question is that a
lawyer should be consulted.


> 
> ср, 27 февр. 2019 г., 6:00 Dan Kortschak :
> 
> > 
> > Probably not. The executable is a derivative work under most
> > understandings (this is the basis for the GPL to require that
> > source
> > code be provided if the executable is distributed to an end user).
> > 
> > Any work writen in Go, using the stdlib (which includes runtime, so
> > all
> > Go programs) is derivative of the stdlib. This means that the Go
> > license pertains.
> > 
> > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
> > > 
> > > You are wrong.
> > > 
> > > 
> > > среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian
> > > Denhardt
> > > написал:
> > > > 
> > > > 
> > > > 
> > > > Quoting Space A. (2019-02-26 20:58:40)
> > > > 
> > > > > 
> > > > > 
> > > > > and stdlib only when redistributed separately as a whole in
> > > > > binary
> > > > > form. When stdlib is used to compile regular binary, it's not
> > > > > "redistributed"
> > > > This is not my understanding; in general static linking
> > > > constitutes
> > > > distribution (though you are correct re: compiler output of
> > > > your
> > > > own
> > > > code).
> > > > 
> > > > > 
> > > > > 
> > > > > Correct answer
> > > > The "correct answer," really, is to ask someone actually
> > > > qualified
> > > > to
> > > > give you legal advice.
> > > > 
> > > > -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.

Re: [go-nuts] Performance comparison of Go, C++, and Java for biological sequencing tool

[Dan Kortschak]

It should be pointed out that these three implementations have close to
zero testing. In the absence of that, there is little that should be
drawn from the integration benchmarks that this suggests.

If we relax correct correctness requirements we can get answers in O(1)
with small constants.

On Thu, 2019-02-28 at 09:05 -0800, 'Isaac Gouy' via golang-nuts wrote:
> "We reimplemented elPrep in all three languages and benchmarked
> their 
> runtime performance and memory use. Results: *The Go implementation 
> performs best*, yielding the best balance between runtime performance
> and 
> memory use. While the Java benchmarks report a somewhat faster
> runtime than 
> the Go benchmarks, the memory use of the Java runs is significantly
> higher."
> 
> proggit discussion 
>  parison_of_go_c_and_java_for/>
> 
> article 
> 
> 

-- 
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] go.mod & go.sum mutability during CI builds

[Dan Kortschak]

Can you just check that the vcs diffs them as no diff?

e.g.
```
if [ -n "$(git diff -- go.mod go.sum)" ]; then   
git diff -- go.mod go.sum
exit 1
fi
```

On Wed, 2019-03-06 at 11:07 -0800, eborgst...@nerdwallet.com wrote:
> Hi fellow Gophers,
> 
> My company has a requirement in our CI builds that no files which are
> part 
> of the repository are modified as part of the build.
> 
> For our Go builds this bites us sometimes because there are
> circumstances 
> where someone can push a commit where when `go build`/`go test` are
> called 
> the go.mod/go.sum files end up being modified.
> 
> It's generally always an easy fix, but what I'm looking for is a way
> to 
> provide early & explicit feedback to our Gophers.
> 
> I've been through all the CLI docs but I can't find anything which
> asserts 
> that go.mod & go.sum are in sync without actually changing them.
> 
> Does anyone have any suggestions here?
> 
> Thanks!
> EB
> 

-- 
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] go.mod & go.sum mutability during CI builds

[Dan Kortschak]

Wrap the go tool with shell code that does the same check after
invoking the real go tool?

On Wed, 2019-03-06 at 12:45 -0800, Evan Borgstrom wrote:
> Our CI pipeline already does `git status -s -uno` and if there is any
> output prints the diff & exits.
> 
> However, this happens at the END of a build (after running lint,
> build,
> test, doc generation, etc), which means you could wait ~minutes
> before you
> get the feedback.  We have specialized checks for other languages
> during
> the lint stage that ensures this very early in the build so we don't
> waste
> time, and I'm looking for something similar with go.
> 
> EB
> 
> On Wed, Mar 6, 2019 at 12:35 PM Dan Kortschak 
> wrote:
> 
> > 
> > Can you just check that the vcs diffs them as no diff?
> > 
> > e.g.
> > ```
> > if [ -n "$(git diff -- go.mod go.sum)" ]; then
> > git diff -- go.mod go.sum
> > exit 1
> > fi
> > ```
> > 
> > On Wed, 2019-03-06 at 11:07 -0800, eborgst...@nerdwallet.com wrote:
> > > 
> > > Hi fellow Gophers,
> > > 
> > > My company has a requirement in our CI builds that no files which
> > > are
> > > part
> > > of the repository are modified as part of the build.
> > > 
> > > For our Go builds this bites us sometimes because there are
> > > circumstances
> > > where someone can push a commit where when `go build`/`go test`
> > > are
> > > called
> > > the go.mod/go.sum files end up being modified.
> > > 
> > > It's generally always an easy fix, but what I'm looking for is a
> > > way
> > > to
> > > provide early & explicit feedback to our Gophers.
> > > 
> > > I've been through all the CLI docs but I can't find anything
> > > which
> > > asserts
> > > that go.mod & go.sum are in sync without actually changing them.
> > > 
> > > Does anyone have any suggestions here?
> > > 
> > > Thanks!
> > > EB
> > > 

-- 
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] go.mod & go.sum mutability during CI builds

[Dan Kortschak]

Alternatively, setting GOFLAGS=-mod=readonly may help depending on what
go tool subcommands you are running.

On Wed, 2019-03-06 at 12:45 -0800, Evan Borgstrom wrote:
> Our CI pipeline already does `git status -s -uno` and if there is any
> output prints the diff & exits.
> 
> However, this happens at the END of a build (after running lint,
> build,
> test, doc generation, etc), which means you could wait ~minutes
> before you
> get the feedback.  We have specialized checks for other languages
> during
> the lint stage that ensures this very early in the build so we don't
> waste
> time, and I'm looking for something similar with go.
> 
> EB
> 
> On Wed, Mar 6, 2019 at 12:35 PM Dan Kortschak 
> wrote:
> 
> > 
> > Can you just check that the vcs diffs them as no diff?
> > 
> > e.g.
> > ```
> > if [ -n "$(git diff -- go.mod go.sum)" ]; then
> > git diff -- go.mod go.sum
> > exit 1
> > fi
> > ```
> > 
> > On Wed, 2019-03-06 at 11:07 -0800, eborgst...@nerdwallet.com wrote:
> > > 
> > > Hi fellow Gophers,
> > > 
> > > My company has a requirement in our CI builds that no files which
> > > are
> > > part
> > > of the repository are modified as part of the build.
> > > 
> > > For our Go builds this bites us sometimes because there are
> > > circumstances
> > > where someone can push a commit where when `go build`/`go test`
> > > are
> > > called
> > > the go.mod/go.sum files end up being modified.
> > > 
> > > It's generally always an easy fix, but what I'm looking for is a
> > > way
> > > to
> > > provide early & explicit feedback to our Gophers.
> > > 
> > > I've been through all the CLI docs but I can't find anything
> > > which
> > > asserts
> > > that go.mod & go.sum are in sync without actually changing them.
> > > 
> > > Does anyone have any suggestions here?
> > > 
> > > Thanks!
> > > EB
> > > 

-- 
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] how to deal with absent go.mod file in tool package when GO111MODULE=on

[Dan Kortschak]

Thanks, though I don't think that will help us for our specific
problem. gobin does not compile for https://github.com/golang/go/commit/65c2069a9f30cb6fa2c512d17dc0ad65
4d621da9





On Mon, 2019-03-04 at 14:13 +, roger peppe wrote:
> It's not a standard tool, but you could use github.com/myitcv/gobin.
> 
> 
> On Sun, 3 Mar 2019 at 20:56, Dan Kortschak  wrote:
> 
> > 
> > As part of our testing we need to install a tool that currently
> > does
> > not have go.mod/go.sum files. Since we test on Go versions both
> > with
> > and without module support and want to test using modules on the
> > versions that have module support we need to use an approach that
> > works
> > in both of those situations. We use git clone and checkout to get
> > the
> > version we want.
> > 
> > However, this fails when GO111MODULE=on because go install wants to
> > find a go.mod and does not. Note that the tool has no external
> > dependencies.
> > 
> > ```
> > $ mkdir -p /home/travis/gopath/src/github.com/goccmack
> > $ git clone https://github.com/goccmack/gocc.git
> > /home/travis/gopath/src/
> > github.com/goccmack/gocc
> > Cloning into '/home/travis/gopath/src/github.com/goccmack/gocc'...
> > $ cd /home/travis/gopath/src/github.com/goccmack/gocc
> > $ git checkout 0e2cfc030005b281b2e5a2de04fa7fe1d5063722
> > Note: checking out '0e2cfc030005b281b2e5a2de04fa7fe1d5063722'.
> > 
> > You are in 'detached HEAD' state. You can look around, make
> > experimental
> > changes and commit them, and you can discard any commits you make
> > in this
> > state without impacting any branches by performing another
> > checkout.
> > 
> > If you want to create a new branch to retain commits you create,
> > you may
> > do so (now or later) by using -b with the checkout command again.
> > Example:
> > 
> >   git checkout -b 
> > 
> > HEAD is now at 0e2cfc0... Merge pull request #78 from
> > shivansh/fix/Makefile
> > $ go install
> > go: cannot find main module, but found .git/config in
> > /home/travis/gopath/src/github.com/goccmack/gocc
> > to create a module there, run:
> > go mod init
> > ```
> > 
> > My approach to dealing with this is to set GO111MODULE=auto for the
> > go
> > install operation, but this is very kludgy and not guaranteed to
> > work
> > if GO111MODULE=auto/off is not respected in the future by one Go
> > version (we support 3 minor versions of Go, so this could
> > potentially
> > happen).
> > 
> > What is the recommended approach for this situation, assuming the
> > tool
> > authors do not want to add a go.mod file?
> > 
> > --
> > 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] Re: Visual Studio Code oddity with Go

[Dan Kortschak]

Please remember to try to make golang-nuts a welcoming venue to discuss
Go.

The OP has tried to find out a solution and has been unable to. Asking
here seems like a reasonable place.

On Thu, 2019-02-21 at 17:28 -0800, Space A. wrote:
> Nothing comes for free. For example, now you are wasting your (and
> others) 
> time. 
> 
> 
> среда, 20 февраля 2019 г., 17:14:21 UTC+3 пользователь Rich написал:
> > 
> > 
> > I tried googling this but I not been able to find a solution,
> > hopefully I 
> > can ask this here and someone else knows how to fix this.  I use
> > Visual 
> > Studio Code -- because it's free. The issue I am having is that
> > every time 
> > I use Visual Studio Code I get the popup that says: 
> > 
> > The Go extension is better with the latest version of
> > "gocode".  Use "go 
> > > 
> > > get -u -v github.com/mdempsky/gocode" to update
> > 
> > Anyone else have this or know how to fix this? It shouldn't ask
> > EVERY time 
> > I use Visual Studio Code? 
> > 

-- 
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] Visual Studio Code oddity with Go

[Dan Kortschak]

Have you run `go get -u github.com/mdempsky/gocode` in a terminal? Is
the binary put in your $PATH? If you try vim with vim-go or emac with
go-mode does gocode work for you there?

Dan

On Thu, 2019-02-21 at 18:51 -0800, Rich wrote:
> Just about every video on Go, I see people using VSC, and so was
> hoping to 
> find another Go user that has this problem, that's why I posted it
> here 
> rather than the VSC Github site. I'm on a mac, reinstalled, deleted
> my 
> settings -- all the usual stuff but it keeps popping up a message to 
> install gocode tools.
> 
> I tried the solution posted by Andrey (Thank you!) and it still does
> the 
> popup thing.  Oh well, it's a minor distraction, click update and it
> goes 
> away.
> 
> 
> On Thursday, February 21, 2019 at 9:14:12 PM UTC-5, andrey
> mirtchovski 
> wrote:
> > 
> > 
> > reposting my private comment from a day ago for those searching
> > for 
> > answers: 
> > 
> > try "command-shift-p" or ctrl-shift-p depending on your operating 
> > system, to bring the "all commands" pop-up. there you should be
> > able 
> > to find "Go: Install/Update tools". click on the checkboxes. hit 
> > enter. 
> > 
> > On Wed, Feb 20, 2019 at 7:14 AM Rich  > > 
> > wrote: 
> > > 
> > > 
> > > I tried googling this but I not been able to find a solution,
> > > hopefully 
> > I can ask this here and someone else knows how to fix this.  I use
> > Visual 
> > Studio Code -- because it's free. The issue I am having is that
> > every time 
> > I use Visual Studio Code I get the popup that says: 
> > > 
> > > 
> > > > 
> > > > The Go extension is better with the latest version of
> > > > "gocode".  Use 
> > "go get -u -v github.com/mdempsky/gocode" to update 
> > > 
> > > 
> > > 
> > > Anyone else have this or know how to fix this? It shouldn't ask
> > > EVERY 
> > time I use Visual Studio Code? 
> > > 
> > > 
> > > -- 
> > > 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] [CoC] screenshot images. Lazines or incompetence?

[Dan Kortschak]

There is an increasing culture of this in many places. Many students
often post screen shots in place of reproducers and textual error. I
invariably reply that they need to post code and text. I am not sure I
am winning here.

Dan

On Mon, 2019-03-11 at 11:17 +0100, Wojciech S. Czarnecki wrote:
> There is an emerging issue with screenshots of logs or code
> being posted to the programming mail lists just because posters
> either are too incompetent to learn how to copy/paste text,
> or are too lazy to mark relevant parts and then press a few
> keys more than PrtSc. Meanwhile asking others to give to
> them a ten minutes or a half an hour.
> 
> Our list has a CoC. And I urge whomever is responsible
> for enforcing it to act promptly not only in cases of trolls being
> called by name but also in a cases of such blatant and grave
> discrimination as recent [1].
> 
> I also urge anyone who gives their time to look at the posted
> picture,
> just because they can see, and who want to help a screenshot's OP
> to demand from her or him that she or he will take her time to repost
> her answer this time with errs/code in textual form.
> 
> Thank you for your attention,
> 
> TC
> 
> [1] > From: Nada Saif  at Fri, 8 Mar 2019
> 17:00:30 +0200
> > 
> > The go command works, but when I try to build any golang code,
> > it gives me : [image: go-err.png]
> P.S. Only on a few lists I know of moderators or admins reacted
> fast. On others lists, where such discriminating behavior was not
> stopped outright at its advent, screenshots plague catches
> like a wildfire. To the point that now someone posting megabytes
> of screencast think he's right because "ah, I gave mp4 as it went
> over the terminal window so I scrolled it all for someone to see".
> 
> -- 
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
> 

-- 
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] Removing Go's nacl port

[Dan Kortschak]

I use it for present to allow students to run code as part of lecture
material.

Dan

On Tue, 2019-03-19 at 11:22 -0700, Brad Fitzpatrick wrote:
> We plan to remove Go's Native Client (nacl) port, probably in Go
> 1.14.
> (It's probably too soon to remove it in Go 1.13)
> 
> Is anybody using it? If so, how?
> 
> We currently use it for the playground (at play.golang.org) but the
> plan is
> to move that to run linux/amd64 binaries under gvisor.
> 
> We suspect we're the only user.
> 

-- 
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: why compiler do not accept elided type in this case ?

[Dan Kortschak]

It can infer the type, but from memory, it was decided that for
improved safety explicit types should be used. There have been
discussion about relaxing this in the past and it is an open proposal.

See https://github.com/golang/go/issues/21496

On Mon, 2019-03-18 at 20:01 -0700, zhou yu wrote:
> gc can not infer the type of {1, 2} of {1,2,3,4}, so you need to
> indicate 
> it's type

-- 
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] -buildmode=shared -linkshared and main: panic?

[Dan Kortschak]

I am trying to build an lgo docker image for Go1.10 (working up to
Go1.12 with this), but I am finding that the process fails with the
following panic.

lgo invokes go install with -buildmode=shared -linkshared and I suspect
this is the cause of the problem.

Is this a known issue?

thanks
Dan

panic: runtime error: index out of range

goroutine 1 [running]:
cmd/go/internal/work.(*Builder).linkSharedAction.func2(0x831da0)
/usr/local/go/src/cmd/go/internal/work/action.go:708 +0x995
cmd/go/internal/work.(*Builder).cacheAction(0xc42011f2c0, 0xc420532f40,
0x14, 0x0, 0xc42037a150, 0xc420532f40)
/usr/local/go/src/cmd/go/internal/work/action.go:300 +0x9f
cmd/go/internal/work.(*Builder).linkSharedAction(0xc42011f2c0, 0x1,
0x1, 0xc4200254e8, 0x6, 0xc420139680, 0xc4200254e8)
/usr/local/go/src/cmd/go/internal/work/action.go:701 +0x29f
cmd/go/internal/work.(*Builder).buildmodeShared(0xc42011f2c0, 0x1, 0x1,
0xc42001e0d0, 0x1, 0x1, 0x0, 0x0, 0x0, 0xc420139680, ...)
/usr/local/go/src/cmd/go/internal/work/action.go:612 +0x12f
cmd/go/internal/work.InstallPackages(0xc42001e0d0, 0x1, 0x1, 0x0)
/usr/local/go/src/cmd/go/internal/work/build.go:478 +0xdac
cmd/go/internal/work.runInstall(0xb01a40, 0xc42001e0d0, 0x1, 0x1)
/usr/local/go/src/cmd/go/internal/work/build.go:412 +0x49
main.main()
/usr/local/go/src/cmd/go/main.go:140 +0x7e1
(16/121) failed to install
"gonum.org/v1/gonum/blas/testblas/benchautogen": exit status 2

-- 
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] goreadme - automate Github Go projects readme files.

[Dan Kortschak]

There is also Dave's https://github.com/davecheney/godoc2md, though
this is no longer maintained and intended for command line use.

On Fri, 2019-03-08 at 05:34 -0800, Eyal wrote:
> Hi
> 
> I've created this Github App that automates the creation of readme
> files.
> It generates for Go project a readme up on the Go doc.
> 
> I think it will be useful because it removes the burden of
> maintaining two 
> documentation resources, and as a side effect, will result in
> improving the 
> go doc of projects who use it.
> 
> Please check it out:
> 
> Website: https://goreadme.herokuapp.com.
> Github App page: https://github.com/apps/goreadme
> Github pages:
> 
>    - Server: https://github.com/posener/goreadme-server
>    - Library: https://github.com/posener/goreadme
> 
> Enjoy,
> Eyal
> 

-- 
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] [CoC] screenshot images. Lazines or incompetence?

[Dan Kortschak]

My approach to dealing with these it that I set my mail client to text
only display. This means that I see plain text where IDE coloured text
is pasted, and I don't see images unless I go out of my way to do so.

Dan

On Mon, 2019-03-11 at 08:36 -0500, Robert Engels wrote:
> I think you are confusing screenshots and copy and paste as html. The
> latter works with screen readers and still gives colored text because
> most likely the person is using an IDE. 
> 
> > 
> > On Mar 11, 2019, at 7:21 AM, Wojciech S. Czarnecki  > > wrote:
> > 
> > On Mon, 11 Mar 2019 07:39:40 -0400
> > Sameer Ajmani  wrote:
> > 
> > > 
> > > I believe calling fellow community members lazy or incompetent
> > > violates our Code of Conduct. 
> > Q.E.D.
> > 
> > > 
> > > Please endeavor to restate your concern in a way that doesn't
> > > insult others.
> > > I expect they simply do not know why sending screenshots is
> > > problematic.
> > I used "Either". If the OP "simply do not know why sending
> > screenshots is problematic"
> > she or he **is incompetent**. If he or she does know but still uses
> > PrtSc/Enter, she or
> > he is at least **lazy**.
> > 
> > I need not, making a voice for sight impaired persons being
> > discriminated here
> > (in fact right against the law of both EU and US) I need not to be
> > a hypocrite.
> > 
> > Where in CoC is written that I am obliged to be a liar?
> > 
> > Where in CoC is written that I must do care about an incompetent or
> > a lazy person
> > feelings more than I care about sight impaired person's ability to
> > get to the
> > information others can simply see?
> > 
> > > 
> > > Please endeavor to restate your concern in a way that doesn't
> > > insult others.
> > Just please react in prompt to the postings containing screenshots
> > of logs or code.
> > 
> > 
> > TC,
> > 
> > -- 
> > Wojciech S. Czarnecki
> > << ^oo^ >> OHIR-RIPE
> > 
> > -- 
> > 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] a way to query the module sum of a dependency with the go tool?

[Dan Kortschak]

Is there a command that does something like `go list -m ` but
also outputs the sum for the module and module's go.mod? Other than
`grep  go.sum`.

thanks
Dan

-- 
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] Request Content Length zero when copy from another Request

[Dan Kortschak]

I didn't mention the word internal, nor did I imply it; with
documentation stating that it would be used, it is clearly *not*
internal.

If you look at the code in question, you can see a probable reason why
a Lener interface is not used; for each of the blessed types, a
concrete copy of the pointed-to-value is made to allow GetBody to
return it. This cannot be done with an interface value without the use
of reflect.

Please show me a Len method in the standard library that does not
return the number of available-to-access elements in a collection.


On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote:
> I am not following. You stated that the usage of Len was internal and
> a type switch on known concrete types, so how is related to how the
> OP was attempting to have things work?
> 
> There is no “generally accepted use of Len()”, otherwise it would not
> need to perform a type switch on known concrete types - it would cast
> to an interface declaring Len(), and use the interface, and then it
> would work with any type.
> 
> > 
> > On Feb 7, 2019, at 1:07 PM, Dan Kortschak  wrote:
> > 
> > Yeah, I'm not agreeing with you.
> > 
> > On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
> > > 
> > > You are agreeing with me. A type switch on concrete types (that
> > > you
> > > control) is far different than using an available Len() method
> > > and
> > > assuming the same semantics. 
> > > 
> > > > 
> > > > 
> > > > On Feb 7, 2019, at 1:05 AM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > Addressing the first sentence, it was a direct answer to a
> > > > comment
> > > > you
> > > > made:
> > > > 
> > > > > 
> > > > > 
> > > > > But is it really? If you read the description for Len() on
> > > > > bytes.Buffer it is the length of unread portion. But that
> > > > > doesn’t
> > > > > mean the buffer isn’t just a portion of the entire body - it
> > > > > can
> > > > > be a
> > > > > chunk which is continually reloaded.
> > > > As far as the claim that there is a need to have a Len method
> > > > in
> > > > io.Reader, have a look at the code in question. It type asserts
> > > > on
> > > > three concrete types that are known to the function, all three
> > > > have
> > > > a
> > > > Len method and this is used to obtain the known length. All
> > > > other
> > > > io.Readers are considered to have an unknown length.
> > > > 
> > > > Whether it's wrong to use Len depends on whether there is a
> > > > generally
> > > > accepted and consistent set of semantics to Len() int. There
> > > > is.
> > > > This
> > > > is strengthened if the use of an existing Len method is noted
> > > > in
> > > > the
> > > > docs.
> > > > 
> > > > > 
> > > > > 
> > > > > On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote:
> > > > > I am not sure what that has to do with the discussion. My
> > > > > point
> > > > > was
> > > > > that for it to be applicable here, it needs to be defined as
> > > > > part
> > > > > of
> > > > > io.Reader, since that is what Body is declared as. It is not,
> > > > > so
> > > > > using in the manner outlined is not correct IMO.
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Feb 6, 2019, at 3:37 PM, Dan Kortschak  > > > > > >
> > > > > > wrote:
> > > > > > 
> > > > > > The generalised semantics of Len are that it returns the
> > > > > > number
> > > > > > of
> > > > > > available elements in the collection, being a cognate of
> > > > > > the
> > > > > > len
> > > > > > built-
> > > > > > in. This means that as you consume elements from a buffer,
> > > > > > the
> > > > > > Len
> > > > > > value reduces. This is directly equivalent to
> > > > > > 
> > > > > > for len(buf) != 0 {
> > > > > &g

Re: [go-nuts] Request Content Length zero when copy from another Request

[Dan Kortschak]

Yeah, I'm not agreeing with you.

On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
> You are agreeing with me. A type switch on concrete types (that you
> control) is far different than using an available Len() method and
> assuming the same semantics. 
> 
> > 
> > On Feb 7, 2019, at 1:05 AM, Dan Kortschak  wrote:
> > 
> > Addressing the first sentence, it was a direct answer to a comment
> > you
> > made:
> > 
> > > 
> > > But is it really? If you read the description for Len() on
> > > bytes.Buffer it is the length of unread portion. But that doesn’t
> > > mean the buffer isn’t just a portion of the entire body - it can
> > > be a
> > > chunk which is continually reloaded.
> > As far as the claim that there is a need to have a Len method in
> > io.Reader, have a look at the code in question. It type asserts on
> > three concrete types that are known to the function, all three have
> > a
> > Len method and this is used to obtain the known length. All other
> > io.Readers are considered to have an unknown length.
> > 
> > Whether it's wrong to use Len depends on whether there is a
> > generally
> > accepted and consistent set of semantics to Len() int. There is.
> > This
> > is strengthened if the use of an existing Len method is noted in
> > the
> > docs.
> > 
> > > 
> > > On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote:
> > > I am not sure what that has to do with the discussion. My point
> > > was
> > > that for it to be applicable here, it needs to be defined as part
> > > of
> > > io.Reader, since that is what Body is declared as. It is not, so
> > > using in the manner outlined is not correct IMO.
> > > 
> > > > 
> > > > 
> > > > On Feb 6, 2019, at 3:37 PM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > The generalised semantics of Len are that it returns the number
> > > > of
> > > > available elements in the collection, being a cognate of the
> > > > len
> > > > built-
> > > > in. This means that as you consume elements from a buffer, the
> > > > Len
> > > > value reduces. This is directly equivalent to
> > > > 
> > > > for len(buf) != 0 {
> > > >    println(buf[0])
> > > >    buf = buf[1:]
> > > > }
> > > > 
> > > > > 
> > > > > On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
> > > > > 
> > > > > But is it really? If you read the description for Len() on
> > > > > bytes.Buffer it is the length of unread portion. But that
> > > > > doesn’t
> > > > > mean the buffer isn’t just a portion of the entire body - it
> > > > > can
> > > > > be a
> > > > > chunk which is continually reloaded. 
> > > > > 
> > > > > This is the danger in using private APIs publically based
> > > > > upon
> > > > > the
> > > > > existence of a method - it leads to very brittle code - and
> > > > > there
> > > > > are
> > > > > almost certainly better ways to design it to avoid these
> > > > > issues.
> > > > > If
> > > > > the core api is not expressive enough then it will be more
> > > > > difficult. 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Feb 6, 2019, at 8:30 AM, Burak Serdar 
> > > > > > wrote:
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, Feb 6, 2019 at 5:15 AM Robert Engels  > > > > > > netc
> > > > > > > om.c
> > > > > > > om> wrote:
> > > > > > > 
> > > > > > > I see now, but if that can be the case, shouldn’t the
> > > > > > > Body be
> > > > > > > documented that the Reader may be a ReaderWithLen, and
> > > > > > > the
> > > > > > > consumer is free to type check/cast? If not, you are
> > > > > > > using
> > > > > > > internal details that you should not be.
> > > > > > Yes, the documentation should say if the reader has a Len()
> > > > > > 

Re: [go-nuts] Request Content Length zero when copy from another Request

[Dan Kortschak]

Their is an assumption in the code that users don't mutate values under
the feet of routines that have been called. The copy does not protect
against that and is not designed for that purpose; it is there to make
the GetBody function return a zeroed copy of the body (for some
definition of zeroed - zero is the state that was handed in to the
NewRequest call). If the behaviour of the copy here is broken, any Go
code that causes a slice, map or pointer to be retained is broken since
the user can mutate the backing data after the call has done work on
it. This becomes a philosophical point.

There is a simple work around (not as simple as having NewRequest Just
Do The Right Thing™, but reasonable) that does not require reflect and
puts the control in the users' hands. Since the ContentLength and
GetBody fields are exported, they can be set after the return of
NewRequest in the same way that NewRequest does for the blessed types,
but with the users' knowledge of internal behaviours of their types.

An example of this is here https://bitbucket.org/ausocean/iot/pull-requ
ests/42

On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote:
> I see the documented use of the types in NewRequest - you are correct
> - I was wrong.
> 
> But, it could of easily also declared that if the provided Reader is
> also a Lener, it uses it to determine the content length. Why have
> this behavior for Closer and not for Lener? Then you don’t need the
> type switch. You say, well the copy...
> 
> The current code with the copy is broken - the caller could continue
> to modify the contents of the bytes.Buffer and things would not work
> as expected since the backing array of the slice is shared - so how
> is the copy helping ? The length will remain the same, but the data
> represented could be corrupted.
> 
> The correct solution is to declare that NewRequest takes an interface
> Content, that has both Reader and ContentLength methods, where
> ContentLength() can return -1 if the content length is indeterminate.
> Then declare simple facades for Content from bytes.Buffer, a string,
> etc. And also declare that continued use of the Content after
> NewRequest is undefined. And if you wanted to retain the simplicity,
> just declare it uses ContentLength like it uses Closer.
> 
> I am all for the simplicity of Go, but “solutions" like NewRequest
> are not the way modern software should be developed. Casting an
> interface to a concrete type is a sign of code that needs design
> work. Having to read the doc in addition to the method signature is
> also a sign the interface needs work (primarily since changes to the
> doc can/will/might change behavior but it avoids compile time type
> checking = brittle code with obscure bugs).
> 
> 
> > 
> > On Feb 7, 2019, at 1:56 PM, Dan Kortschak  wrote:
> > 
> > I didn't mention the word internal, nor did I imply it; with
> > documentation stating that it would be used, it is clearly *not*
> > internal.
> > 
> > If you look at the code in question, you can see a probable reason
> > why
> > a Lener interface is not used; for each of the blessed types, a
> > concrete copy of the pointed-to-value is made to allow GetBody to
> > return it. This cannot be done with an interface value without the
> > use
> > of reflect.
> > 
> > Please show me a Len method in the standard library that does not
> > return the number of available-to-access elements in a collection.
> > 
> > 
> > On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote:
> > > 
> > > I am not following. You stated that the usage of Len was internal
> > > and
> > > a type switch on known concrete types, so how is related to how
> > > the
> > > OP was attempting to have things work?
> > > 
> > > There is no “generally accepted use of Len()”, otherwise it would
> > > not
> > > need to perform a type switch on known concrete types - it would
> > > cast
> > > to an interface declaring Len(), and use the interface, and then
> > > it
> > > would work with any type.
> > > 
> > > > 
> > > > 
> > > > On Feb 7, 2019, at 1:07 PM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > Yeah, I'm not agreeing with you.
> > > > 
> > > > On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote:
> > > > > 
> > > > > 
> > > > > You are agreeing with me. A type switch on concrete types
> > > > > (that
> > > > > you
> > > > > control) is far different than using an available Len()
> > > > > method
> > > > > and
&g

Re: [go-nuts] Request Content Length zero when copy from another Request

[Dan Kortschak]

Keeping a zeroed state is important for the GetBody func because the
io.ReadCloser returned by GetBody can be read and closed. If there is
no zero state for the next time GetBody is called, it is not
idempotent. This would break the whole point of it existing.

See https://go-review.googlesource.com/c/go/+/31733/

On Thu, 2019-02-07 at 15:33 -0600, robert engels wrote:
> I agree with you on the correct solution - vs. the OP’s request of
> the GetWrapped method.
> 
> I guess I still don’t understand the “zeroed” concern though. If you
> adhere to the “don’t mutate values…” then why do the zero copy at all
> ? The state of the body should still be the state it was passed in as
> (unless the caller was breaking the aforementioned rule anyway…).
> 
> Having “blessed types” is not a good design IMO - better to just
> declare the required interfaces and use those - especially when the
> object being provided as a parameter is already an interface… just
> seems lazy… (and long-term error prone).
> 
> 
> 
> > 
> > On Feb 7, 2019, at 3:05 PM, Dan Kortschak  wrote:
> > 
> > Their is an assumption in the code that users don't mutate values
> > under
> > the feet of routines that have been called. The copy does not
> > protect
> > against that and is not designed for that purpose; it is there to
> > make
> > the GetBody function return a zeroed copy of the body (for some
> > definition of zeroed - zero is the state that was handed in to the
> > NewRequest call). If the behaviour of the copy here is broken, any
> > Go
> > code that causes a slice, map or pointer to be retained is broken
> > since
> > the user can mutate the backing data after the call has done work
> > on
> > it. This becomes a philosophical point.
> > 
> > There is a simple work around (not as simple as having NewRequest
> > Just
> > Do The Right Thing™, but reasonable) that does not require reflect
> > and
> > puts the control in the users' hands. Since the ContentLength and
> > GetBody fields are exported, they can be set after the return of
> > NewRequest in the same way that NewRequest does for the blessed
> > types,
> > but with the users' knowledge of internal behaviours of their
> > types.
> > 
> > An example of this is here https://bitbucket.org/ausocean/iot/pull-
> > requ
> > ests/42
> > 
> > On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote:
> > > 
> > > I see the documented use of the types in NewRequest - you are
> > > correct
> > > - I was wrong.
> > > 
> > > But, it could of easily also declared that if the provided Reader
> > > is
> > > also a Lener, it uses it to determine the content length. Why
> > > have
> > > this behavior for Closer and not for Lener? Then you don’t need
> > > the
> > > type switch. You say, well the copy...
> > > 
> > > The current code with the copy is broken - the caller could
> > > continue
> > > to modify the contents of the bytes.Buffer and things would not
> > > work
> > > as expected since the backing array of the slice is shared - so
> > > how
> > > is the copy helping ? The length will remain the same, but the
> > > data
> > > represented could be corrupted.
> > > 
> > > The correct solution is to declare that NewRequest takes an
> > > interface
> > > Content, that has both Reader and ContentLength methods, where
> > > ContentLength() can return -1 if the content length is
> > > indeterminate.
> > > Then declare simple facades for Content from bytes.Buffer, a
> > > string,
> > > etc. And also declare that continued use of the Content after
> > > NewRequest is undefined. And if you wanted to retain the
> > > simplicity,
> > > just declare it uses ContentLength like it uses Closer.
> > > 
> > > I am all for the simplicity of Go, but “solutions" like
> > > NewRequest
> > > are not the way modern software should be developed. Casting an
> > > interface to a concrete type is a sign of code that needs design
> > > work. Having to read the doc in addition to the method signature
> > > is
> > > also a sign the interface needs work (primarily since changes to
> > > the
> > > doc can/will/might change behavior but it avoids compile time
> > > type
> > > checking = brittle code with obscure bugs).
> > > 
> > > 
> > > > 
> > > > 
> > > > On Feb 7, 2019, at 1:56 PM, Dan Kortschak 
> >

Re: [go-nuts] Request Content Length zero when copy from another Request

[Dan Kortschak]

I agree that this is a brittle API and it's one that has bitten us
twice (partly because - I beleive - the dev_appserver.py development
server is broken in how it deals with the cases here. This is why I
filed an issue - though not with great hope of a fix other than maybe
improving the documentation.

On Thu, 2019-02-07 at 16:10 -0600, robert engels wrote:
> So GetBody just fails… It returns NoBody in this case.. which means
> calling code will just break (when the original request is not one of
> the known types).
> 
> So, according to the referenced issue, 307/308 redirects won’t work
> when the underlying request is not a known type.
> 
> This is a very brittle API IMO. If you need to do stuff like this,
> the readers should be using mark/reset etc with buffered streams, not
> relying on special cased functions like GetBody that don’t work in
> all cases.
> 
> > 
> > On Feb 7, 2019, at 3:42 PM, Dan Kortschak  wrote:
> > 
> > Keeping a zeroed state is important for the GetBody func because
> > the
> > io.ReadCloser returned by GetBody can be read and closed. If there
> > is
> > no zero state for the next time GetBody is called, it is not
> > idempotent. This would break the whole point of it existing.
> > 
> > See https://go-review.googlesource.com/c/go/+/31733/
> > 
> > On Thu, 2019-02-07 at 15:33 -0600, robert engels wrote:
> > > 
> > > I agree with you on the correct solution - vs. the OP’s request
> > > of
> > > the GetWrapped method.
> > > 
> > > I guess I still don’t understand the “zeroed” concern though. If
> > > you
> > > adhere to the “don’t mutate values…” then why do the zero copy at
> > > all
> > > ? The state of the body should still be the state it was passed
> > > in as
> > > (unless the caller was breaking the aforementioned rule anyway…).
> > > 
> > > Having “blessed types” is not a good design IMO - better to just
> > > declare the required interfaces and use those - especially when
> > > the
> > > object being provided as a parameter is already an interface…
> > > just
> > > seems lazy… (and long-term error prone).
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > On Feb 7, 2019, at 3:05 PM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > Their is an assumption in the code that users don't mutate
> > > > values
> > > > under
> > > > the feet of routines that have been called. The copy does not
> > > > protect
> > > > against that and is not designed for that purpose; it is there
> > > > to
> > > > make
> > > > the GetBody function return a zeroed copy of the body (for some
> > > > definition of zeroed - zero is the state that was handed in to
> > > > the
> > > > NewRequest call). If the behaviour of the copy here is broken,
> > > > any
> > > > Go
> > > > code that causes a slice, map or pointer to be retained is
> > > > broken
> > > > since
> > > > the user can mutate the backing data after the call has done
> > > > work
> > > > on
> > > > it. This becomes a philosophical point.
> > > > 
> > > > There is a simple work around (not as simple as having
> > > > NewRequest
> > > > Just
> > > > Do The Right Thing™, but reasonable) that does not require
> > > > reflect
> > > > and
> > > > puts the control in the users' hands. Since the ContentLength
> > > > and
> > > > GetBody fields are exported, they can be set after the return
> > > > of
> > > > NewRequest in the same way that NewRequest does for the blessed
> > > > types,
> > > > but with the users' knowledge of internal behaviours of their
> > > > types.
> > > > 
> > > > An example of this is here https://bitbucket.org/ausocean/iot/p
> > > > ull-
> > > > requ
> > > > ests/42
> > > > 
> > > > On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote:
> > > > > 
> > > > > 
> > > > > I see the documented use of the types in NewRequest - you are
> > > > > correct
> > > > > - I was wrong.
> > > > > 
> > > > > But, it could of easily also declared that if the provided
> > > > > Reader
> > > > > is
> > > > > also a Lener, it 

Re: [go-nuts] Request Content Length zero when copy from another Request

[Dan Kortschak]

The generalised semantics of Len are that it returns the number of
available elements in the collection, being a cognate of the len built-
in. This means that as you consume elements from a buffer, the Len
value reduces. This is directly equivalent to

for len(buf) != 0 {
println(buf[0])
buf = buf[1:]
}

On Wed, 2019-02-06 at 08:56 -0600, Robert Engels wrote:
> But is it really? If you read the description for Len() on
> bytes.Buffer it is the length of unread portion. But that doesn’t
> mean the buffer isn’t just a portion of the entire body - it can be a
> chunk which is continually reloaded. 
> 
> This is the danger in using private APIs publically based upon the
> existence of a method - it leads to very brittle code - and there are
> almost certainly better ways to design it to avoid these issues. If
> the core api is not expressive enough then it will be more
> difficult. 
> 
> > 
> > On Feb 6, 2019, at 8:30 AM, Burak Serdar  wrote:
> > 
> > > 
> > > On Wed, Feb 6, 2019 at 5:15 AM Robert Engels  > > om> wrote:
> > > 
> > > I see now, but if that can be the case, shouldn’t the Body be
> > > documented that the Reader may be a ReaderWithLen, and the
> > > consumer is free to type check/cast? If not, you are using
> > > internal details that you should not be.
> > Yes, the documentation should say if the reader has a Len() method
> > it
> > would be used to set the ContentLength. Len is no longer an
> > internal
> > detail then.
> > 
> > > 
> > > 
> > > This is a problem with Go in general. Because the returned object
> > > “implements” some interface because it happens to have the
> > > required method, doesn’t mean it was designed to be used that
> > > way, or that it has the required semantics - unless documented to
> > > have them.
> > I agree with you there. Len() is straight forward, but in general
> > just
> > because a function is named something doesn't mean it'll do the
> > same
> > thing for all implementations. On the other end of the spectrum is
> > Java-like interfaces where you want explicit inheritance of a
> > specific
> > interface. I don't know if there's anything in between, but I like
> > Go's approach much better.
> > 
> > > 
> > > 
> > > On Feb 6, 2019, at 2:22 AM, Matteo Biagetti  > > l.com> wrote:
> > > 
> > > Make sense, thanks for explanation
> > > 
> > > 
> > > 
> > > Il giorno mercoledì 6 febbraio 2019 07:28:54 UTC+1, Burak Serdar
> > > ha scritto:
> > > > 
> > > > 
> > > > On Tue, Feb 5, 2019 at 8:13 PM robert engels  > > > com> wrote:
> > > > > 
> > > > > 
> > > > > That’s what I was trying to point out. Your design is not
> > > > > correct. The Body is a Reader, not a Buffer - the length of
> > > > > the request/body may be indeterminate - that is, a stream.
> > > > > Attempting to get the length of an underlying buffer is not
> > > > > only probably not possible, but not correct in many
> > > > > situations.
> > > > The length of the body *may* be indeterminate, and if that's
> > > > the case,
> > > > the underlying Reader will not have a Len method. The design is
> > > > to
> > > > handle the case where the underlying Reader is a Buffer with a
> > > > Len
> > > > method. If the Reader has Len, then the NopCloser derived from
> > > > that
> > > > will also have a Len, and NewRequest can set the content
> > > > length. If
> > > > the Reader does not have Len, then the content length is
> > > > unknown.
> > > > 
> > > > > 
> > > > > 
> > > > > There is a reason the Body is a ReaderCloser and not a
> > > > > buffer. It is part of the http specification.
> > > > > 
> > > > > On Feb 5, 2019, at 9:00 PM, Burak Serdar 
> > > > > wrote:
> > > > > 
> > > > > On Tue, Feb 5, 2019 at 7:00 PM Robert Engels  > > > > m.com> wrote:
> > > > > 
> > > > > 
> > > > > Shouldn’t you just be taking the content length from the
> > > > > header if forwarding the same body. There is no need for the
> > > > > length of the body.
> > > > > 
> > > > > 
> > > > > True. What I was suggesting is a fix for the general case.
>

Re: [go-nuts] ZXBasic string slicing

[Dan Kortschak]

https://play.golang.org/p/6GqrX15gXZ7

On Mon, 2019-02-11 at 13:04 -0800, Everton Marques wrote:
> Funny feature from ZXBasic:
> 
> There is a notation called slicing for describing substrings, and
> this can 
> be applied to arbitrary string expressions.
> 
> `"abcdef"(2 TO 5)="bcde"`
> 
> http://www.worldofspectrum.org/ZXBasicManual/zxmanchap8.html
> 
> 

-- 
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] GAE import of cloud and appengine data stores fails when in same file

[Dan Kortschak]

One of our developers has found that when they import both
"google.golang.org/appengine/datastore" and
"cloud.google.com/go/datastore", renaming the second import
to remoteds, the build on AE fails, though it does not fail locally
with dev_appserver.py.

This only happens when the imports are in the same file; if they are in
separate files of the same package, everything is OK.

Does anyone else have experience of this or understand why two packages
imported under separate names would be rejected by GAE?

thanks
Dan

-- 
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] Request Content Length zero when copy from another Request

[Dan Kortschak]

Personally, I think this is a bug in the behaviour of NewRequest. See h
ttps://github.com/golang/go/issues/18117 for some additional context.

On Tue, 2019-02-05 at 05:18 -0800, matteo.biage...@gmail.com wrote:
> I've the following situation: 
> I proxy a request to another server and when I made a POST and create
> a new 
> request, the contentLength is zero:
> 
> req2, _ := http.NewRequest(req.Method, newApiUrl , req.Body)
> fmt.Println("New request from body:", req2.ContentLength) //
> print 0
> 
> Checking in the source code of the NewRequest func Body don't respect
> some 
> interface and populate the ContentLength field.
> 
> Could be a bug? Which could be a valid approach in order to create a
> new 
> request from an existing one and correct set the Body length?
> 
> A working example here:
> 
> https://play.golang.org/p/SvCDLj0NrXb
> 
> 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] why does go test with GO111MODULE=on add self requirement

[Dan Kortschak]

Ignore this - pebcak.

On Wed, 2019-02-20 at 15:56 +1030, Dan Kortschak wrote:
> I am starting to introduce modules to some packages and when I ran
> tests a require statement was added to go.mod that is the module
> itself. Why would this be a good idea?
> 

-- 
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 does go test with GO111MODULE=on add self requirement

[Dan Kortschak]

I am starting to introduce modules to some packages and when I ran
tests a require statement was added to go.mod that is the module
itself. Why would this be a good idea?

-- 
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] undefined and implementation defined behavior in Go

[Dan Kortschak]

Saying something other than "something else" requires that the all of
the other possible things that are not currently listed there must be
listed. The possible outcomes listed are reasonably likely, but other
non-"make demons fly out of your nose" type outcomes are also possible,
like "program hangs" — enumerating all these would be onerous and add
unreasonably to the weight of the document.

The intention of the warning is: "Don't do this."

On Tue, 2019-02-19 at 11:24 -0800, Manlio Perillo wrote:
> That's "something else" is quite dangerous.

-- 
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] lock for assigning to different elements of an array

[Dan Kortschak]

When machines (compilers or processors) are allowed to optimise things,
reality gets weird.

The compiler may elide the check because it is not conformant with the
spec via the memory model, or value A.a may be in a local CPU cache and
so never be altered as far as the core is concerned.

On Fri, 2019-02-01 at 13:58 -0800, Michael Ellis wrote:
> I'm confused. I can see how that would fail if the test were A.a ==
> 100 
> since Go routine #1 might increment past 100 before #2 ,  but as
> written it 
> seems wrong only if the application logic depends on Go routine #2
> exiting 
> the loop as soon as A.a reaches 100 (as opposed to any time
> afterward.) 
> 
> What am I missing?

-- 
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] Why is "v" prefix for VCS tag required for ?

[Dan Kortschak]

The text of for that answer is not saying that a person cannot use
"vM.m.p", but that "vM.m.p" means semver M.m.p. They even use `git tag
v1.2.3 -m "Release version 1.2.3"` as an example.

In the case of Go, the v is a marker that the following is a semver
version.

On Sun, 2019-02-03 at 02:20 -0800, gudv...@gmail.com wrote:
> Many teams use prefix-less tags for versions (both for Go before
> modules 
> and non-Go projects). Not to mention that it's not a valid semver 
>  antic-version> (but 
> very common though) and thus requirement even less understandable.

-- 
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] Modules. A "new" system.

[Dan Kortschak]

Robert Griesamer *is* Niklaus Wirth?

On Tue, 2019-02-05 at 09:19 -0800, Michael Jones wrote:
> Go learns from Oberon via Go and Oberon insider Robert Griesemer,
> whose
> Wirth-number is zero.
> 
> On Tue, Feb 5, 2019 at 3:47 AM Gerard  wrote:
> 
> > 
> > Hello everyone. There has been one issue in Go that has never
> > gotten out
> > of my head, so it went on and on. The problem is modules.
> > 
> > In the beginning there was Oberon. Let's just face it. Oberon was a
> > brilliant designed piece of engineering. Oberon did have some
> > marvelous
> > features that just don't exist today, such as GC for everything,
> > including
> > closing files (anyone ever seen that), and their memory system was
> > also GC,
> > including modules entirely. So they made a counter for each module
> > that was
> > being used. You add one, the counter increase. You lose one, the
> > counter
> > went down and when that counter went zero that module got erased
> > from
> > memory. Pretty clever.
> > 
> > Oberon also got very small compiled modules. They were compiled and
> > the
> > API was being check-summed. And they didn't got generics ;-) There
> > was no
> > need for that since the basic types were so simple, a lot simpler
> > than in
> > Go.
> > 
> > Why were they using this compiled  API file? That was only used for
> > identification. Everything that has public code goes into the
> > compiled
> > header file. There is AFAIK no no linking. The only thing that is
> > being
> > used are the compiled modules and compiled header files.
> > 
> > Now I have explained everything that I know that I know about
> > modules.
> > What are the areas of interest? The only answer that I can find out
> > is OS
> > design. But for that the benefits are huge, but only if you have
> > the guts
> > to really gutter the whole thing down.
> > 
> > What compiles:
> > That is pretty easy. Everything that is public will be part of a
> > header
> > file, the rest stays inside the module itself.
> > 
> > The benefits:
> > 
> >    1. This maps a lot better for OS development.
> >    2. No linking involved.
> >    3. updates could have been "on the fly", with just a couple of
> > LOC you
> >    can download and compile an entire module, as long as the API
> > hasn't
> >    changed.
> >    4. Fit well with systems such as apt-get, GNU GUIX, but also go
> > get.
> > 
> > 
> > The downsides:
> > 
> >    1. This could confuse people who tend to use it. How can you use
> > it?
> >    That is why I think that this could probably only work for OS
> > design. You
> >    just don't want to download a half baked module.
> >    2. It could have been used proprietary. Personally I have a lot
> >    against proprietary code.
> > 
> > 
> > Questions:
> > 
> > 
> > 
> > Links:
> > 
> >    1. http://members.home.nl/jmr272/Oberon/ModToOberon.pdf
> >    2. https://en.wikipedia.org/wiki/Oberon_(programming_language)
> >    3. http://www.ethoberon.ethz.ch/WirthPubl/ProgInOberon.pdf
> > 
> > 
> > --
> > 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.
> > 
> 
> -- 
> 
> *Michael T. jonesmichael.jo...@gmail.com *
> 

-- 
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] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Thank you. I have reviewed the code. I was hoping for some friendly and
helpful input.

On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
> As I said, I reviewed the code - which you can do as well. It is
> below. At least for “unix-ish” systems - it goes to syscall.Read()
> which is why I linked you to the unix documentation on the difference
> between read() and recv().
> 
> Instead of waiting for someone else to confirm, you can think about
> it logically - sending packet based messages as a stream would not
> work as you have no boundaries, and no ordering guarantees - so
> streaming them would be useless - it would require every protocol on
> top of UDP to have embedded length and framing information in order
> to detect packet starts. Not to mention it would be impossible to
> read the OOB data (like sender address - since a UDP socket can
> receive from multiple senders - so you would have no ability to know
> where the packet came from (unless bound to a single sender).
> 
> udpsock.go -> net.go -> poll/fd_unix.go 
> 
> // Read implements io.Reader.
> func (fd *FD) Read(p []byte) (int, error) {
>   if err := fd.readLock(); err != nil {
>   return 0, err
>   }
>   defer fd.readUnlock()
>   if len(p) == 0 {
>   // If the caller wanted a zero byte read, return
> immediately
>   // without trying (but after acquiring the readLock).
>   // Otherwise syscall.Read returns 0, nil which looks
> like
>   // io.EOF.
>   // TODO(bradfitz): make it wait for readability? (Issue
> 15735)
>   return 0, nil
>   }
>   if err := fd.pd.prepareRead(fd.isFile); err != nil {
>   return 0, err
>   }
>   if fd.IsStream && len(p) > maxRW {
>   p = p[:maxRW]
>   }
>   for {
>   n, err := syscall.Read(fd.Sysfd, p)
>   if err != nil {
>   n = 0
>   if err == syscall.EAGAIN && fd.pd.pollable() {
>   if err = fd.pd.waitRead(fd.isFile); err
> == nil {
>   continue
>   }
>   }
> 
>   // On MacOS we can see EINTR here if the user
>   // pressed ^Z.  See issue #22838.
>   if runtime.GOOS == "darwin" && err ==
> syscall.EINTR {
>           continue
>   }
>   }
>   err = fd.eofError(n, err)
>   return n, err
>   }
> }
> 
> 
> > 
> > On May 12, 2019, at 9:37 PM, Dan Kortschak 
> > wrote:
> > 
> > Yes, I'm aware of all this. However, the net.UDPConn Read method
> > states
> > that it "Read implements the Conn Read method", and does not the
> > io.Reader interface; net.Conn has the explicit method, not an
> > embedding
> > of io.Reader.
> > 
> > I'd like to hear from someone who contributed to net.
> > 
> > On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
> > > 
> > > Which is a big problem with the Go “interface” specification… 
> > > 
> > > But the de-facto standard is as I stated - if it implements the
> > > method it implements the interface. There is no requirement that
> > > the
> > > method/struct “be documented” to be an implementor - buyer
> > > beware!
> > > 
> > > We is also why you should never use method names that collide
> > > with
> > > “stdlib interfaces” unless you intend them to have the same
> > > semantics.
> > > 
> > > > 
> > > > 
> > > > On May 12, 2019, at 8:58 PM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > This is not quite true. The language itself doesn't make claims
> > > > other
> > > > than types and method names. However, there are conventions
> > > > around
> > > > the
> > > > semantics of methods in an interface. For example, a Read
> > > > method
> > > > that
> > > > returns 0, nil is allowed for io.Reader, but frowned upon
> > > > unless
> > > > the
> > > > buffer is zero length, and a Read method that fills the buffer
> > > > with
> > > > n
> > > > bytes and returns n-1 (or n+1), nil is not a correct
> > > > implementation
> > > > of
> > > > io.Reader. Nor is an implementation correct if it retains the
> > 

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Yes, I'm aware of all this. However, the net.UDPConn Read method states
that it "Read implements the Conn Read method", and does not the
io.Reader interface; net.Conn has the explicit method, not an embedding
of io.Reader.

I'd like to hear from someone who contributed to net.

On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
> Which is a big problem with the Go “interface” specification… 
> 
> But the de-facto standard is as I stated - if it implements the
> method it implements the interface. There is no requirement that the
> method/struct “be documented” to be an implementor - buyer beware!
> 
> We is also why you should never use method names that collide with
> “stdlib interfaces” unless you intend them to have the same
> semantics.
> 
> > 
> > On May 12, 2019, at 8:58 PM, Dan Kortschak 
> > wrote:
> > 
> > This is not quite true. The language itself doesn't make claims
> > other
> > than types and method names. However, there are conventions around
> > the
> > semantics of methods in an interface. For example, a Read method
> > that
> > returns 0, nil is allowed for io.Reader, but frowned upon unless
> > the
> > buffer is zero length, and a Read method that fills the buffer with
> > n
> > bytes and returns n-1 (or n+1), nil is not a correct implementation
> > of
> > io.Reader. Nor is an implementation correct if it retains the
> > buffer.
> > 
> > Just as the BDNF is not a complete definition of the grammar of the
> > language, interface type decls are not complete definitions of
> > interfaces.
> > 
> > This is why I am asking.
> > 
> > On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote:
> > > 
> > > There is no claim because that is not how Go interfaces work

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557715058.21310.72.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Further to this, you can see that having two diametrically opposite
claims (1. UDPConn.Read implements Conn.Read and Conn is a generic
stream-oriented network connection cf 2. UDP is not stream oriented)
might be somewhat confusing.

On Sun, 2019-05-12 at 20:00 -0700, Kurtis Rader wrote:
> And the Conn documentation says: "Conn is a generic stream-oriented
> network
> connection."  UDP sockets are not stream-oriented. As Robert has
> already
> pointed out the Read() method on such an object is a wrapper around
> the
> read() syscall. Which for a UDP socket is equivalent to recv() with
> flags
> set to zero. You can't use it to read multiple packets with a single
> call.
> Nor can you use it to read a packet incrementally. At least on UNIX
> like
> platforms the excess bytes will be discarded.
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557723269.21310.88.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

This is not quite true. The language itself doesn't make claims other
than types and method names. However, there are conventions around the
semantics of methods in an interface. For example, a Read method that
returns 0, nil is allowed for io.Reader, but frowned upon unless the
buffer is zero length, and a Read method that fills the buffer with n
bytes and returns n-1 (or n+1), nil is not a correct implementation of
io.Reader. Nor is an implementation correct if it retains the buffer.

Just as the BDNF is not a complete definition of the grammar of the
language, interface type decls are not complete definitions of
interfaces.

This is why I am asking.

On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote:
> There is no claim because that is not how Go interfaces work

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557712717.21310.68.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

No worries. Thanks for trying.

Dan

On Sun, 2019-05-12 at 22:10 -0500, robert engels wrote:
> I am sorry if you think I was not helpful, nor friendly - I was
> trying to be both.
> 
> That is why I took the time to pass on the relevant documentation,
> and code.
> 
> > 
> > On May 12, 2019, at 10:04 PM, Dan Kortschak 
> > wrote:
> > 
> > Thank you. I have reviewed the code. I was hoping for some friendly
> > and
> > helpful input.
> > 
> > On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
> > > 
> > > As I said, I reviewed the code - which you can do as well. It is
> > > below. At least for “unix-ish” systems - it goes to
> > > syscall.Read()
> > > which is why I linked you to the unix documentation on the
> > > difference
> > > between read() and recv().
> > > 
> > > Instead of waiting for someone else to confirm, you can think
> > > about
> > > it logically - sending packet based messages as a stream would
> > > not
> > > work as you have no boundaries, and no ordering guarantees - so
> > > streaming them would be useless - it would require every protocol
> > > on
> > > top of UDP to have embedded length and framing information in
> > > order
> > > to detect packet starts. Not to mention it would be impossible to
> > > read the OOB data (like sender address - since a UDP socket can
> > > receive from multiple senders - so you would have no ability to
> > > know
> > > where the packet came from (unless bound to a single sender).
> > > 
> > > udpsock.go -> net.go -> poll/fd_unix.go 
> > > 
> > > // Read implements io.Reader.
> > > func (fd *FD) Read(p []byte) (int, error) {
> > >   if err := fd.readLock(); err != nil {
> > >   return 0, err
> > >   }
> > >   defer fd.readUnlock()
> > >   if len(p) == 0 {
> > >   // If the caller wanted a zero byte read, return
> > > immediately
> > >   // without trying (but after acquiring the readLock).
> > >   // Otherwise syscall.Read returns 0, nil which looks
> > > like
> > >   // io.EOF.
> > >   // TODO(bradfitz): make it wait for readability? (Issue
> > > 15735)
> > >   return 0, nil
> > >   }
> > >   if err := fd.pd.prepareRead(fd.isFile); err != nil {
> > >   return 0, err
> > >   }
> > >   if fd.IsStream && len(p) > maxRW {
> > >   p = p[:maxRW]
> > >   }
> > >   for {
> > >   n, err := syscall.Read(fd.Sysfd, p)
> > >   if err != nil {
> > >   n = 0
> > >   if err == syscall.EAGAIN && fd.pd.pollable() {
> > >   if err = fd.pd.waitRead(fd.isFile); err
> > > == nil {
> > >   continue
> > >   }
> > >   }
> > > 
> > >   // On MacOS we can see EINTR here if the user
> > >   // pressed ^Z.  See issue #22838.
> > >   if runtime.GOOS == "darwin" && err ==
> > > syscall.EINTR {
> > >   continue
> > >   }
> > >   }
> > >   err = fd.eofError(n, err)
> > >   return n, err
> > >   }
> > > }
> > > 
> > > 
> > > > 
> > > > 
> > > > On May 12, 2019, at 9:37 PM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > Yes, I'm aware of all this. However, the net.UDPConn Read
> > > > method
> > > > states
> > > > that it "Read implements the Conn Read method", and does not
> > > > the
> > > > io.Reader interface; net.Conn has the explicit method, not an
> > > > embedding
> > > > of io.Reader.
> > > > 
> > > > I'd like to hear from someone who contributed to net.
> > > > 
> > > > On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
> > > > > 
> > > > > 
> > > > > Which is a big problem with the Go “interface”
> > > > > specification… 
> > > > > 
> > > > > But the de-facto standard is as I stated - if it implements
> > > > > the
> > > > > method it implements the 

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

bump?

On Thu, 2019-05-09 at 16:23 +0930, Dan Kortschak wrote:
> The Conn and UDPConn Read methods look like io.Reader Read methods,
> but
> there is no explicit claim that Conn is an io.Reader. Are the Read
> methods of these two types identical in behaviour to io.Reader?
> Specifically, are the reads allowed to fill the buffer with arbitrary
> numbers of bytes in 0 <= len(p) <= n?
> 
> Also, can UPDConn.Read fill the buffer with more than one packet if
> the
> buffer would accommodate that? (I am guessing yes, and that if this
> is
> important then the ReadFrom method should be used).
> 
> thanks
> Dan
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557706800.21310.59.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Thank you, that has clarified what I was wanting to confirm.

Dan

On Sun, 2019-05-12 at 20:00 -0700, Kurtis Rader wrote:
> On Sun, May 12, 2019 at 7:38 PM Dan Kortschak 
> wrote:
> 
> > 
> > Yes, I'm aware of all this. However, the net.UDPConn Read method
> > states
> > that it "Read implements the Conn Read method", and does not the
> > io.Reader interface; net.Conn has the explicit method, not an
> > embedding
> > of io.Reader.
> > 
> And the Conn documentation says: "Conn is a generic stream-oriented
> network
> connection."  UDP sockets are not stream-oriented. As Robert has
> already
> pointed out the Read() method on such an object is a wrapper around
> the
> read() syscall. Which for a UDP socket is equivalent to recv() with
> flags
> set to zero. You can't use it to read multiple packets with a single
> call.
> Nor can you use it to read a packet incrementally. At least on UNIX
> like
> platforms the excess bytes will be discarded.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557716944.29848.8.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Dan Kortschak]

Please don't say I've said things I didn't. I did not dissuade someone
from understanding or using something. I quoted the memory model, and I
pointed out that the advice given by previous posters was not incorrect
as you claim. What you are reading them as saying may be wrong, but not
what they are actually saying.

On Mon, 2019-05-27 at 07:10 -0500, robert engels wrote:
> They are not clever. They are foundational in high performance lock-
> free structures and other techniques commonly found in HPC and HFT  -
> and even the linux kernel (RCU). This is a decent overview 
> https://www.cs.cmu.edu/~410-s05/lectures/L31_LockFree.pdf but a bit
> hard to follow since it is slides.
> 
> You can review github.com/robaho/go-concurrency-test to see the
> performance difference lock-free techniques can offer in certain
> applications.
> 
> For certain, most programs do not need these techniques but
> dissuading someone from understanding and/or using them because they
> are “being clever” is not appropriate.
> 
> 
> > On May 26, 2019, at 6:59 PM, Dan Kortschak 
> > wrote:
> > 
> > Please don't. Java is not relevant here and the advice given by
> > other
> > prior to this post in the thread is not incorrect. Using atomic
> > operations (in this case it would be atomic.Value's Load and Store
> > methods) invokes a write barrier, which is fundamentally just a
> > memory
> > synchronisation. In pkg sync there is good advice in the Overview
> > of
> > the package, though the best advice is in the MM 
> > https://golang.org/ref
> > /mem#tmp_1:
> > 
> > > Programs that modify data being simultaneously accessed by
> > > multiple
> > > goroutines must serialize such access.
> > > 
> > > To serialize access, protect the data with channel operations or
> > > other synchronization primitives such as those in the sync and
> > > sync/atomic packages.
> > > 
> > > If you must read the rest of this document to understand the
> > > behavior
> > > of your program, you are being too clever.
> > > 
> > > Don't be clever.
> > 
> > 
> > On Sun, 2019-05-26 at 12:51 -0500, Robert Engels wrote:
> > > Ignore the incorrect comments from the others. There are many
> > > valid
> > > cases where relaxed concurrency rules apply and you don’t need
> > > synchronization just atomic ops (and with certain platform this
> > > is
> > > not needed - eg java volatile)That is why GC systems can
> > > outperform
> > > non GC systems in concurrent scenarios. But you need to allocate
> > > new
> > > objects not modify existing ones (a big reason GC platform
> > > strings
> > > are usually immutable). You can do the same in Go. 
> > > 
> > > > 
> > > > On May 26, 2019, at 11:17 AM, Sotirios Mantziaris <
> > > > smantziaris@gmai
> > > > l.com> wrote:
> > > > 
> > > > I understand, i have to synchronize access...
> > > > Coming from another language i had some guarantees on some
> > > > assignments mostly int. A string might be a issue here of
> > > > course...
> > > > I have to refactor my code in order to make is safe.
> > > > 
> > > > thanks.
> > > > 
> > > > > 
> > > > > On Sunday, May 26, 2019 at 6:13:56 PM UTC+3, Jan Mercl wrote:
> > > > > On Sun, May 26, 2019 at 4:03 PM Sotirios Mantziaris 
> > > > >  wrote: 
> > > > > 
> > > > > > 
> > > > > > Let's assume that the string field Name has the value `Mr.
> > > > > > Smith` and we change this to  `Mr. Anderson` in the
> > > > > > goroutine,
> > > > > > what are the possible values that i could bet on a read? 
> > > > > > 
> > > > > > If these are either `Mr. Smith` or `Mr. Anderson` i am very
> > > > > > ok
> > > > > > with that because i want the value to be eventually
> > > > > > consistent. 
> > > > > 
> > > > > That would be the only possible outcomes iff a multi word
> > > > > value
> > > > > is 
> > > > > updated atomically. 
> > > > > 
> > > > > > 
> > > > > > If there is another possible outcome then i need to
> > > > > > synchronize
> > > > > > the access and refactor a lot. 
> > > > > 
> > > > > Any outcome is poss

Re: [go-nuts] Is this a bug?

[Dan Kortschak]

The interfaces that define the contracts should come from a third
package/source. The issue that I suspect you are hitting is that type
identity for interface types is based on the name, not the method set.
This means that, for example with your code below a function
PrintB(StringerB) and another function PrintA(StringerA) are not
assignable to the same variable unless it is type interface{}.

https://play.golang.org/p/a8aWwA6CAB_K // remove comment to see failure

On Fri, 2019-05-24 at 20:38 -0700, Henry wrote:
> Thanks for the reply. 
> 
> Is there any specific use case that this intended behavior is
> supposed to 
> solve? It appears to me that it is just a case of simplistic
> implementation 
> where Go does not look deep enough to see if any dependent interfaces
> are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable,
> rather 
> than semantic equality. So when I refer to TypeA and TypeB as
> identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
> 
> Back to the actual situation, Package A and Package B are developed
> in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture.
> They 
> use interface to define contracts that are required in order for
> their 
> components to work. Since Go interface is implicit, this is supposed
> to 
> work fine. As an example, if I were to reduce the prior example as
> follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
> 
> import (
> "fmt"
> )
> 
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
> 
> type StringerA interface {
> String() string
> }
> 
> type StringerB interface {
> String() string
> }
> 
> type MyString string
> 
> func (s MyString) String() string {
> return string(s)
> }
> 
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
> 
> However, when I add a more complex interface, as in the first
> example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA
> and 
> FormatterB are interchangeable despite the facts that their
> dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the
> components 
> should look like this:
> 
> [image: go.png]
> Let me know what you think.
> 
> Thanks.
> 
> Henry
> 
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
> > 
> > It's not a bug, FormatterA and FormatterB method has different 
> > signatures, they are not identical, one wants Format(StringerA)
> > other 
> > Format(StringerB), thus your Format type only implements
> > FormatterA 
> > but Print wants a FormatterB. 
> > 
> 
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/71965bccd27ed0288b09f9b5b1b3dfc75b3a4ef2.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Dan Kortschak]

In the post that I was replying to you told the OP to ignore incorrect
comments and then brought in the java world and stated that
synchronisation was not needed, only atomic operations. The comments by
previous posters were not incorrect and how things work in java is only
barely relevant here given the way that that language handles objects
and how that that differs from how Go handles values. The claim that
synchronisation is not required is arguably correct; the use of atomics
in Go imposes a write barrier, which is a form of synchronisation.

On the being clever issue, the benefits that are gained from using
lower level synchronisation constructs and building from there rather
than using the language-idiomatic constructs depend on context. In
cases they are definitely warranted, in others not so much. Given that
the OP was asking about issues that indicated that there was some
misunderstanding about how race conditions affect Go, using lower level
constructs seems like something that should not be happening now (maybe
later if warranted by performance needs). Given that the aspect of the
project that is being asked about is in re-configuration, it is likely
not to be on a hot path and so probably (I have not looked at the code
in depth) will never need to have that level of performance
optimisation. From the OP, the sensible approach looks like a
sync.RWLock-protected struct with getters and setters.

On Mon, 2019-05-27 at 14:58 -0500, robert engels wrote:
> I’m sorry if you think I put words in your mouth, I did not mean to.
> 
> Can you please explain what "Please don’t” means then? I took it at
> face value, and that it was a affirmative response to “Don’t be
> clever."
> 
> > 
> > On May 27, 2019, at 7:33 AM, Dan Kortschak 
> > wrote:
> > 
> > Please don't say I've said things I didn't. I did not dissuade
> > someone
> > from understanding or using something. I quoted the memory model,
> > and I
> > pointed out that the advice given by previous posters was not
> > incorrect
> > as you claim. What you are reading them as saying may be wrong, but
> > not
> > what they are actually saying.
> > 
> > On Mon, 2019-05-27 at 07:10 -0500, robert engels wrote:
> > > 
> > > They are not clever. They are foundational in high performance
> > > lock-
> > > free structures and other techniques commonly found in HPC and
> > > HFT  -
> > > and even the linux kernel (RCU). This is a decent overview 
> > > https://www.cs.cmu.edu/~410-s05/lectures/L31_LockFree.pdf but a
> > > bit
> > > hard to follow since it is slides.
> > > 
> > > You can review github.com/robaho/go-concurrency-test to see the
> > > performance difference lock-free techniques can offer in certain
> > > applications.
> > > 
> > > For certain, most programs do not need these techniques but
> > > dissuading someone from understanding and/or using them because
> > > they
> > > are “being clever” is not appropriate.
> > > 
> > > 
> > > > 
> > > > On May 26, 2019, at 6:59 PM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > Please don't. Java is not relevant here and the advice given by
> > > > other
> > > > prior to this post in the thread is not incorrect. Using atomic
> > > > operations (in this case it would be atomic.Value's Load and
> > > > Store
> > > > methods) invokes a write barrier, which is fundamentally just a
> > > > memory
> > > > synchronisation. In pkg sync there is good advice in the
> > > > Overview
> > > > of
> > > > the package, though the best advice is in the MM 
> > > > https://golang.org/ref
> > > > /mem#tmp_1:
> > > > 
> > > > > 
> > > > > Programs that modify data being simultaneously accessed by
> > > > > multiple
> > > > > goroutines must serialize such access.
> > > > > 
> > > > > To serialize access, protect the data with channel operations
> > > > > or
> > > > > other synchronization primitives such as those in the sync
> > > > > and
> > > > > sync/atomic packages.
> > > > > 
> > > > > If you must read the rest of this document to understand the
> > > > > behavior
> > > > > of your program, you are being too clever.
> > > > > 
> > > > > Don't be clever.
> > > > 
> > > > On Sun, 2019-05-26 at 12:51 -0500, Robert Engels wrote:
> > > > > 
> &g

Re: [go-nuts] Data race question in config package of harvester

[Dan Kortschak]

Jan's comments about possible outcomes other than those outlined in
Sotirios' second post are correct. Using atomic.Value would synchronise
the values due to the introduction of a write barrier. I'm not omitting
much of the argument, you're just missing it.

Sorry, I'm done.

On Mon, 2019-05-27 at 19:22 -0500, Robert Engels wrote:
> You have conveniently omitted much of the argument, for example, like
> reading Ander from a string containing Anderson due to improper
> synchronization - which is clearly incorrect and what I was pointing
> out. The java refs are important to this discussion since when
> everything is ref and under GC, the ABA problem does not
> occur.  Since Go has value structures and arrays of them the issue is
> dependent upon the detailed data structures as to what concurrency
> techniques are suitable. 
> 
> The op specifically asked about valid values that could be seen. It
> had nothing to do with being clever or over optimizing. As in the
> slides I included, just saying use a lock or mutex is not correct, as
> locks have other issues (deadlocks, priority inversion, others ). 
> 
> Lastly, if you are going to argue against the points, feel free to do
> so, but incorrectly changing the argument or my position is not very
> welcome. 
> 
> > 
> > On May 27, 2019, at 6:51 PM, Dan Kortschak 
> > wrote:
> > 
> > In the post that I was replying to you told the OP to ignore
> > incorrect
> > comments and then brought in the java world and stated that
> > synchronisation was not needed, only atomic operations. The
> > comments by
> > previous posters were not incorrect and how things work in java is
> > only
> > barely relevant here given the way that that language handles
> > objects
> > and how that that differs from how Go handles values. The claim
> > that
> > synchronisation is not required is arguably correct; the use of
> > atomics
> > in Go imposes a write barrier, which is a form of synchronisation.
> > 
> > On the being clever issue, the benefits that are gained from using
> > lower level synchronisation constructs and building from there
> > rather
> > than using the language-idiomatic constructs depend on context. In
> > cases they are definitely warranted, in others not so much. Given
> > that
> > the OP was asking about issues that indicated that there was some
> > misunderstanding about how race conditions affect Go, using lower
> > level
> > constructs seems like something that should not be happening now
> > (maybe
> > later if warranted by performance needs). Given that the aspect of
> > the
> > project that is being asked about is in re-configuration, it is
> > likely
> > not to be on a hot path and so probably (I have not looked at the
> > code
> > in depth) will never need to have that level of performance
> > optimisation. From the OP, the sensible approach looks like a
> > sync.RWLock-protected struct with getters and setters.
> > 
> > > 
> > > On Mon, 2019-05-27 at 14:58 -0500, robert engels wrote:
> > > I’m sorry if you think I put words in your mouth, I did not mean
> > > to.
> > > 
> > > Can you please explain what "Please don’t” means then? I took it
> > > at
> > > face value, and that it was a affirmative response to “Don’t be
> > > clever."
> > > 
> > > > 
> > > > 
> > > > On May 27, 2019, at 7:33 AM, Dan Kortschak 
> > > > wrote:
> > > > 
> > > > Please don't say I've said things I didn't. I did not dissuade
> > > > someone
> > > > from understanding or using something. I quoted the memory
> > > > model,
> > > > and I
> > > > pointed out that the advice given by previous posters was not
> > > > incorrect
> > > > as you claim. What you are reading them as saying may be wrong,
> > > > but
> > > > not
> > > > what they are actually saying.
> > > > 
> > > > > 
> > > > > On Mon, 2019-05-27 at 07:10 -0500, robert engels wrote:
> > > > > 
> > > > > They are not clever. They are foundational in high
> > > > > performance
> > > > > lock-
> > > > > free structures and other techniques commonly found in HPC
> > > > > and
> > > > > HFT  -
> > > > > and even the linux kernel (RCU). This is a decent overview 
> > > > > https://www.cs.cmu.edu/~410-s05/lectures/L31_LockFree.pdf but
> > > > > a
> > >

Re: [go-nuts] How can I read private field in go struct instance

[Dan Kortschak]

Sorry, missed the go- prefix in Dave's package.

github.com/davecgh/go-spew

On Tue, 2019-06-04 at 09:48 +0930, Dan Kortschak wrote:
> There are packages already available for this.
>
> github.com/kortschak/utter (for Go syntax-like printing)
> github.com/davecgh/spew (for less Go syntax-like printing)
>
>
>
> On Mon, 2019-06-03 at 08:54 -0700, 杜沁园 wrote:
> >
> > I recently write a program to recursively print all fields and
> > value
> > in a
> > struct. Interface() is the most convinence way to get underlying
> > value in
> > go.
> > But it will panic when field is private.How can I access private
> > field?
> >
> > For simple type, I can stil use Int(),Bool(),etc to read private
> > field.
> >  But if the field is a interface, I do not know how to access is
> > concrete
> > value without use Interface() method.
> >
> >
> > For example:
> >
> > type Expr interface {
> >eval(v string) bool
> > }
> >
> > type MyExpr struct {
> >Haha string
> > }
> >
> >
> > type Web struct {
> >Hoststring
> >epr Expr
> > }
> >
> >
> >
> >
> > How can I get Web.Epr Value by reflection without use Interface()
> > method

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1559607573.21310.215.camel%40adelaide.edu.au.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How can I read private field in go struct instance

[Dan Kortschak]

There are packages already available for this.

github.com/kortschak/utter (for Go syntax-like printing)
github.com/davecgh/spew (for less Go syntax-like printing)



On Mon, 2019-06-03 at 08:54 -0700, 杜沁园 wrote:
> I recently write a program to recursively print all fields and value
> in a 
> struct. Interface() is the most convinence way to get underlying
> value in 
> go.
> But it will panic when field is private.How can I access private
> field? 
> 
> For simple type, I can stil use Int(),Bool(),etc to read private
> field.  
>  But if the field is a interface, I do not know how to access is
> concrete 
> value without use Interface() method.
> 
> 
> For example:
> 
> type Expr interface {
>    eval(v string) bool
> }
> 
> type MyExpr struct {
>    Haha string
> }
> 
> 
> type Web struct {
>    Hoststring
>    epr Expr
> }
> 
> 
> 
> 
> How can I get Web.Epr Value by reflection without use Interface()
> method
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1559607505.21310.214.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How can I read private field in go struct instance

[Dan Kortschak]

The code in utter is essentially the same (I forked it from go-spew),
but the output can be used in Go code. Depending on what you want, both
are useful.

On Mon, 2019-06-03 at 19:44 -0700, 杜沁园 wrote:
> go-spew is a really good library, I don not need to write it myself,
> Thanks
> 
> 在 2019年6月4日星期二 UTC+8上午8:19:55，kortschak写道：
> > 
> > 
> > Sorry, missed the go- prefix in Dave's package. 
> > 
> > github.com/davecgh/go-spew 
> > 
> > On Tue, 2019-06-04 at 09:48 +0930, Dan Kortschak wrote: 
> > > 
> > > There are packages already available for this. 
> > > 
> > > github.com/kortschak/utter (for Go syntax-like printing) 
> > > github.com/davecgh/spew (for less Go syntax-like printing) 
> > > 
> > > 
> > > 
> > > On Mon, 2019-06-03 at 08:54 -0700, 杜沁园 wrote: 
> > > > 
> > > > 
> > > > I recently write a program to recursively print all fields and 
> > > > value 
> > > > in a 
> > > > struct. Interface() is the most convinence way to get
> > > > underlying 
> > > > value in 
> > > > go. 
> > > > But it will panic when field is private.How can I access
> > > > private 
> > > > field? 
> > > > 
> > > > For simple type, I can stil use Int(),Bool(),etc to read
> > > > private 
> > > > field. 
> > > >  But if the field is a interface, I do not know how to access
> > > > is 
> > > > concrete 
> > > > value without use Interface() method. 
> > > > 
> > > > 
> > > > For example: 
> > > > 
> > > > type Expr interface { 
> > > >    eval(v string) bool 
> > > > } 
> > > > 
> > > > type MyExpr struct { 
> > > >    Haha string 
> > > > } 
> > > > 
> > > > 
> > > > type Web struct { 
> > > >    Hoststring 
> > > >    epr Expr 
> > > > } 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > How can I get Web.Epr Value by reflection without use
> > > > Interface() 
> > > > method 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1559616362.21310.227.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

The semantics of the directive are not defined, and there are comments
like this[1] that would introduce breakage for people who target more
than one version of Go.

Which version do we choose to write? Gonum support latest and two
previous versions. We have had to write go 1.10 into that line so that
the tests against master don't fail, but this is another line that we
have to edit we we adjust versions for testing. When it becomes
important, I'd be happy to write it down, but the absence of any
semantic definition, it's just another line of text that has an
expected syntax, but no other apparent value.

[1]https://github.com/golang/go/issues/30791#issuecomment-472431458


On Mon, 2019-06-10 at 22:27 -0700, Ian Lance Taylor wrote:
> On Mon, Jun 10, 2019 at 9:56 PM Dan Kortschak 
> wrote:
> > 
> > 
> > The semantics of this line of go.mod is not described anywhere, but
> > the
> > tool chain blithely writes it to a go.mod file when there is no go
> > directive present.
> > 
> > Is there a way to mark the go.mod as go version-agnostic?
> No.  But there is no particular reason to do so.
> 
> The semantics, such as they are, are documented at
> https://golang.org/cmd/go/#hdr-The_go_mod_file: it's "the expected
> language version."  It sets the -lang option passed to cmd/compile,
> documented at https://golang.org/cmd/compile/.
> 
> You can write your own Go directive if you like, and it won't be
> modified.  You can also set it programatically using `go mod edit
> -go=version`.
> 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1560232311.21310.232.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

The semantics of this line of go.mod is not described anywhere, but the
tool chain blithely writes it to a go.mod file when there is no go
directive present.

Is there a way to mark the go.mod as go version-agnostic?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/669b835c8d42ec9adb9b5d4b0a4e44362973c19e.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

Thanks, Ian.

I'll look later today.

Dan

On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> wrote:
> > 
> > Having that and exactly what it means in the go help modules output
> > would probably be the best outcome.
> > 
> > Currently it's not mentioned in that output for the current release
> > (1.12.6) and the meaning/implication of "expected [Go] language
> > version" is not defined in tip's version (f2a4c13).
> 
> I sent https://golang.org/cl/18184 to add some text to "go help
> go.mod".
> 
> Ian
> 
> > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > 
> > > > It would be very nice if the documentation and clarity of
> > > > communication
> > > > around this were improved.
> > > 
> > > I struggle with what to say beyond "it sets the language
> > > version."
> > > Language features available as of that version will be available
> > > for
> > > use.  Language features removed in earlier versions, or added in
> > > later
> > > versions, will not be available.  For almost all users the
> > > default
> > > value will be correct.  At least, I hope that is the case.
> > > 
> > > 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8e6f134c5b7abc9fd1ad124c86a0ecf115fb903.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

For others, the cl is https://golang.org/cl/181840 (note the extra 0).

On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> wrote:
> > 
> > Having that and exactly what it means in the go help modules output
> > would probably be the best outcome.
> > 
> > Currently it's not mentioned in that output for the current release
> > (1.12.6) and the meaning/implication of "expected [Go] language
> > version" is not defined in tip's version (f2a4c13).
> 
> I sent https://golang.org/cl/18184 to add some text to "go help
> go.mod".
> 
> Ian
> 
> > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > 
> > > > It would be very nice if the documentation and clarity of
> > > > communication
> > > > around this were improved.
> > > 
> > > I struggle with what to say beyond "it sets the language
> > > version."
> > > Language features available as of that version will be available
> > > for
> > > use.  Language features removed in earlier versions, or added in
> > > later
> > > versions, will not be available.  For almost all users the
> > > default
> > > value will be correct.  At least, I hope that is the case.
> > > 
> > > 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e22dce014816ce427109b3c2ed6867cd46364614.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

I feel your pain. For me it's at the other end of the keyboard.

Dan

On Wed, 2019-06-12 at 17:01 -0700, Ian Lance Taylor wrote:
> On Wed, Jun 12, 2019 at 2:55 PM Dan Kortschak 
> wrote:
> > 
> > For others, the cl is https://golang.org/cl/181840 (note the extra
> > 0).
> 
> Thanks.
> 
> (My laptop keyboard is barely a year old and already becoming
> unreliable.)
> 
> Ian
> 
> 
> > On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> > > On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > Having that and exactly what it means in the go help modules
> > > > output
> > > > would probably be the best outcome.
> > > > 
> > > > Currently it's not mentioned in that output for the current
> > > > release
> > > > (1.12.6) and the meaning/implication of "expected [Go] language
> > > > version" is not defined in tip's version (f2a4c13).
> > > 
> > > I sent https://golang.org/cl/18184 to add some text to "go help
> > > go.mod".
> > > 
> > > Ian
> > > 
> > > > On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> > > > > On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak <
> > > > > d...@kortschak.io>
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > It would be very nice if the documentation and clarity of
> > > > > > communication
> > > > > > around this were improved.
> > > > > 
> > > > > I struggle with what to say beyond "it sets the language
> > > > > version."
> > > > > Language features available as of that version will be
> > > > > available
> > > > > for
> > > > > use.  Language features removed in earlier versions, or added
> > > > > in
> > > > > later
> > > > > versions, will not be available.  For almost all users the
> > > > > default
> > > > > value will be correct.  At least, I hope that is the case.
> > > > > 
> > > > > 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3a3a1981ebe3eb1ecd816f027e284cd5ce2df6a2.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[Dan Kortschak]

This is interesting. I have exactly the opposite situation; up-down is
much easier than significant left-right because of faulty saccades.

On Wed, 2019-06-12 at 11:41 -0700, Michael Jones wrote:
> Bakul, more good arguments. I have another motivation in the "?"
> world that
> I've not argued because it is personal/not general, but a decade ago
> I had
> two detached retinas, surgeries, and imperfect recovery. Part of my
> vision
> that I lost is just below the center...maybe -15 degrees to -40
> degrees.
> The brain knows when I want to see things things there and moves the
> eyes
> around to gather that part of the visual field. This "hunting" is
> tiring of
> the muscles and causes issues. left-to-right density is easy for me,
> vertical is very bad. Your:
> 
> x := b? 2 : 1
> 
> is instantaneous, a sight read; while the:
> 
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
> 
> and
> 
> x := 1
> if b {
>   x = 2
> }
> 
> ...feel like climbing Everest. It is hard to explain the difficulty.
> Fortunately it is not a widespread problem. Certainly not Go's
> problem, but
> I'd pay double for a "wide" mode where gofmt tolerated "var x int; if
> b { x
> = 2 } else { x = 1 }". In fact, now that i've just seen this, I am
> going to
> make a local version and hook it to vs code. Why did I not think of
> this
> before! Wow.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e256bf8c6f380acf4999385f4d1e557f1f201d6b.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

Thanks, Ian.

Comments in-line.

On Tue, 2019-06-11 at 06:42 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:40 AM Ian Lance Taylor 
> wrote:
> > 
> > On Mon, Jun 10, 2019 at 10:51 PM Dan Kortschak 
> > wrote:
> > > 
> > > The semantics of the directive are not defined, and there are
> > > comments
> > > like this[1] that would introduce breakage for people who target
> > > more
> > > than one version of Go.
> > 
> > Yes.  A good reason to not do that.  We don't do it today, and
> > there
> > are no plans to do it.

However it was suggested by a googler who is apparently reasonably
involved in the implementation of modules judging by the issues they
are respond to and CLs they send. In the absence of any comments to the
commentary (now here, thanks), this would lend some credence to the
idea that it would happen.


> > 
> > > Which version do we choose to write? Gonum support latest and two
> > > previous versions. We have had to write go 1.10 into that line so
> > > that
> > > the tests against master don't fail, but this is another line
> > > that we
> > > have to edit we we adjust versions for testing. When it becomes
> > > important, I'd be happy to write it down, but the absence of any
> > > semantic definition, it's just another line of text that has an
> > > expected syntax, but no other apparent value.
> > 
> > Why do you think you would ever have to change the value go1.10?
> 
> That was perhaps a bit terse.  Let me add: the clearest description
> of
> the use of the go directive is at
> 
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md
> .
> 

I've just had a look through that again, and I come away little better
informed about what it means in this situation. There are two sections
that talk about it: "Language removals" and "Language additions". The
first describes it as a maximum version (which suggests that we should
not have it at 1.10, but rather 1.12 at the moment - noting well that
the maximum version does not state what will build but what language
features are available), and the latter talks about minimum versions
although this is described as optional.

It would be very nice if the documentation and clarity of communication
around this were improved.

thanks
Dan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ceee67bdd20e4d5b749e8b2580bc2bab1f7911d8.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

Having that and exactly what it means in the go help modules output
would probably be the best outcome.

Currently it's not mentioned in that output for the current release
(1.12.6) and the meaning/implication of "expected [Go] language
version" is not defined in tip's version (f2a4c13).

Dan

On Tue, 2019-06-11 at 17:35 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak 
> wrote:
> > 
> > 
> > It would be very nice if the documentation and clarity of
> > communication
> > around this were improved.
> I struggle with what to say beyond "it sets the language version."
> Language features available as of that version will be available for
> use.  Language features removed in earlier versions, or added in
> later
> versions, will not be available.  For almost all users the default
> value will be correct.  At least, I hope that is the case.
> 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1560303035.21310.240.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Thanks, Jake. This was very helpful.

On Mon, 2019-05-13 at 09:19 -0700, jake6...@gmail.com wrote:
> On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote:
> > 
> > 
> > The Conn and UDPConn Read methods look like io.Reader Read methods,
> > but 
> > there is no explicit claim that Conn is an io.Reader. Are the Read 
> > methods of these two types identical in behaviour to io.Reader? 
> > 
>  
> I can not say definitively, but on unix, UDPConn.Read() is actually 
> net.conn.Read() ,
> whch 
> calls net.netFD.Read(), which in turn calls poll.FD.Read() 
> . You can see
> there 
> in the code:
> 
> // Read implements io.Reader.
> 
> The windows and plan9 versions also land in Read() functions that
> have the same comment. So it seems to me that UDPConn.Read() is an
> io.Reader. Of course, that only means that it conforms to the
> requirements of io.Reader .
> 
> Specifically, are the reads allowed to fill the buffer with
> arbitrary 
> > 
> > numbers of bytes in 0 <= len(p) <= n? 
> > 
>  
> Yes, according to io.Reader  docs,
> an 
> implementation may do that. Looking at the actual implementations of
> the 
> poll.FD.Read functions, I would say that it seems like they will
> always 
> return the full UDP packts, if it is <= len(p). A full search of the 
> relevant platform docs would be required to say definitively. 
> 
> 
> > 
> > Also, can UPDConn.Read fill the buffer with more than one packet if
> > the 
> > buffer would accommodate that? (I am guessing yes, and that if this
> > is 
> > important then the ReadFrom method should be used). 
> > 
> > 
> It looks to me like this will in fact read one packet at a time on
> amd64 
> unix. The function will return after a single successful
> syscall(SYS_READ) 
> which, IIUC will just be one packet for UDP. Since there is no
> actual 
> documentation guaranteeing this, you would have to look at the source
> code, 
> and platform docs, for every platform you care about to be 100%
> sure. 
> However, if it did not work this way, it would make UDP programming
> very 
> hard, or even impossible. So I think it very likely. 
>  
> 
> > 
> > thanks 
> > Dan 
> > 
> 
>  
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557783886.17937.0.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Yes. There's also the unfortunate collision with io.ReaderFrom's method
name which is directionally opposite to net.PacketConn's ReadFrom. This
is unfixable because of Go1.

Dan

On Mon, 2019-05-13 at 15:14 -0700, Ian Lance Taylor wrote:
> On Mon, May 13, 2019 at 2:45 PM Dan Kortschak 
> wrote:
> > 
> > 
> > Thanks, Jake. This was very helpful.
> It does seem that the docs in this area should be improved.  Alas.
> 
> Ian
> 
> 
> > 
> > On Mon, 2019-05-13 at 09:19 -0700, jake6...@gmail.com wrote:
> > > 
> > > On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote:
> > > > 
> > > > 
> > > > 
> > > > The Conn and UDPConn Read methods look like io.Reader Read
> > > > methods,
> > > > but
> > > > there is no explicit claim that Conn is an io.Reader. Are the
> > > > Read
> > > > methods of these two types identical in behaviour to io.Reader?
> > > > 
> > > I can not say definitively, but on unix, UDPConn.Read() is
> > > actually
> > > net.conn.Read() <https://golang.org/src/net/net.go?s=6157:6199#L1
> > > 63>,
> > > whch
> > > calls net.netFD.Read(), which in turn calls poll.FD.Read()
> > > <https://golang.org/src/internal/poll/fd_unix.go#L144>. You can
> > > see
> > > there
> > > in the code:
> > > 
> > > // Read implements io.Reader.
> > > 
> > > The windows and plan9 versions also land in Read() functions that
> > > have the same comment. So it seems to me that UDPConn.Read() is
> > > an
> > > io.Reader. Of course, that only means that it conforms to the
> > > requirements of io.Reader <https://golang.org/pkg/io/#Reader>.
> > > 
> > > Specifically, are the reads allowed to fill the buffer with
> > > arbitrary
> > > > 
> > > > 
> > > > numbers of bytes in 0 <= len(p) <= n?
> > > > 
> > > Yes, according to io.Reader <https://golang.org/pkg/io/#Reader>
> > > docs,
> > > an
> > > implementation may do that. Looking at the actual implementations
> > > of
> > > the
> > > poll.FD.Read functions, I would say that it seems like they will
> > > always
> > > return the full UDP packts, if it is <= len(p). A full search of
> > > the
> > > relevant platform docs would be required to say definitively.
> > > 
> > > 
> > > > 
> > > > 
> > > > Also, can UPDConn.Read fill the buffer with more than one
> > > > packet if
> > > > the
> > > > buffer would accommodate that? (I am guessing yes, and that if
> > > > this
> > > > is
> > > > important then the ReadFrom method should be used).
> > > > 
> > > > 
> > > It looks to me like this will in fact read one packet at a time
> > > on
> > > amd64
> > > unix. The function will return after a single successful
> > > syscall(SYS_READ)
> > > which, IIUC will just be one packet for UDP. Since there is no
> > > actual
> > > documentation guaranteeing this, you would have to look at the
> > > source
> > > code,
> > > and platform docs, for every platform you care about to be 100%
> > > sure.
> > > However, if it did not work this way, it would make UDP
> > > programming
> > > very
> > > hard, or even impossible. So I think it very likely.
> > > 
> > > 
> > > > 
> > > > 
> > > > thanks
> > > > Dan
> > > > 
> > > 
> > > 
> > --
> > 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.
> > To view this discussion on the web visit https://groups.google.com/
> > d/msgid/golang-nuts/1557783886.17937.0.camel%40kortschak.io.
> > 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557791271.21310.94.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] gob Decode cannot override "true" value with "false"

[Dan Kortschak]

This is because zero values are not sent by encoding/gob. So the false
value never goes over the wire to overwrite the true. If you want
things to be zeroable, you need to do that yourself before decoding.

From https://golang.org/pkg/encoding/gob/#hdr-Encoding_Details

"If a field has the zero value for its type (except for arrays; see
above), it is omitted from the transmission."

On Mon, 2019-05-20 at 22:24 -0700, nvcnvn wrote:
> It seem if a field with boolean value setted to "true", some how gob
> Decode 
> cannot change it to false.
> Example:
> https://play.golang.org/p/5eCp_0d1UC4
> 
> (original question are here 
> https://stackoverflow.com/questions/56230143/why-decode-two-different
> -objects-into-a-same-object-but-the-bool-member-has-not
>  )
> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1558416527.21310.122.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[Dan Kortschak]

:)

In Gonum source/text, we have a policy of ASE in user-facing
documentation, but all my internal comments and commit messages are
written in BE (though read by me in AuE). We also avoid usages that are
ambigiguous when read in BE/AuE or grammatically incorrect when read in
those dialects (the best example of this is alternate/alternate for
alternate/alternative where this is a reduction in the semantic space
in ASE).

On Fri, 2019-05-17 at 09:20 -0700, ma...@madra.net wrote:
> Spare a thought for those of us who actually speak and write
> 'proper' 
> English and not that American version used in all programming
> languages.
> 
> We get to write in our own language but have to remember to spell
> half the 
> words wrong!
> 
> > 
> > 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1558137839.4874.25.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[Dan Kortschak]

On Sat, 2019-05-18 at 09:43 +1000, Rob Pike wrote:
> Australia is closer to Britain but sticks with jail
> and tire.

I don't think this is true Australia wide - in Melbourne and Adelaide
(my home cities), I have always seen gaol and tyre.

> I'm sure every English speaking country has its own set, and each
> is valid in place.

And also at a finer resolution.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1558138124.4874.26.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

The Conn and UDPConn Read methods look like io.Reader Read methods, but
there is no explicit claim that Conn is an io.Reader. Are the Read
methods of these two types identical in behaviour to io.Reader?
Specifically, are the reads allowed to fill the buffer with arbitrary
numbers of bytes in 0 <= len(p) <= n?

Also, can UPDConn.Read fill the buffer with more than one packet if the
buffer would accommodate that? (I am guessing yes, and that if this is
important then the ReadFrom method should be used).

thanks
Dan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1557384824.4298.19.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.