[go-nuts] Re: Go package manager

[Yashish Dua]

Yes, I just realized my Readme doesn't indicate this. I will update this.
Yes, other commands are a sort of wrapper over Go tool commands but it 
takes care of you few scenarios where a user might have to add flags to Go 
tool command explicitly.


On Saturday, June 1, 2019 at 5:19:51 AM UTC+5:30, Justin Israel wrote:
>
> On Saturday, June 1, 2019 at 12:43:50 AM UTC+12, yashi...@gmail.com 
> wrote: 
> > Hi everyone! 
> > 
> > I recently build an interesting Go tool - GPM (Go Project Manager). It 
> allows you to build and manage go projects. Ont op, it also allows to 
> update version of Go from cli. 
> > Check it out: https://github.com/YashishDua/gpm 
> > 
> > Feedback is appreciated! 
>
> Your README doesn't indicate that it only supports OSX. The "update" 
> command downloads the osx build and replaces a hard-coded system install 
> location. 
>
> Aside from the "create" command setting up an opinionated project 
> structure, to me is seems like the build, mod, vendor logic just thinly 
> wraps calls to the Go tool equivalent commands. What is it really doing 
> that the current go tool doesn't handle? I thought go module support works 
> in any location already. 

-- 
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/70abbebc-caed-42ce-8183-3b2baa88d8f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoid global variables in Http handlers

[Aldrin Leal]

wrapping into a typedef?

typedef MyHandler struct {
  GlobalThing string
}

func (h *MyHandler) handle(w http.ResponseWriter, r *http.Request) {
}

func main() {
  h := MyHandler{}

  http.HandleFunc("/", MyHandler.handle)
}

--
-- Aldrin Leal,  / https://ingenieux.io/about/


On Mon, Jun 3, 2019 at 10:48 PM Tong Sun  wrote:

>
> Here is a BAD example (using global variables):
>
>
> var globalThing string
>
> func specificHandler(w http.ResponseWriter, r *http.Request) {
> w.Write(globalConfigThing)}
>
> func main() {
> globalThing = "Hello world!"
> http.HandleFunc("/something", specificHandler)
> http.ListenAndServe(":8080", nil)}
>
>
> How to avoid using global variables?
>
> thx
>
>
>
> --
> 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/1bc9f505-9638-49e2-b873-6f4d7b88dfbc%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALpo8NtfwgfpvB_3OnR-fV4qTgrw7grw_-Sc3YZGJqOfuS1hYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Avoid global variables in Http handlers

[Tong Sun]

Here is a BAD example (using global variables):


var globalThing string

func specificHandler(w http.ResponseWriter, r *http.Request) {
w.Write(globalConfigThing)}

func main() {
globalThing = "Hello world!"
http.HandleFunc("/something", specificHandler)
http.ListenAndServe(":8080", nil)}


How to avoid using global variables? 

thx



-- 
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/1bc9f505-9638-49e2-b873-6f4d7b88dfbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.8 port to FreeBSD/PowerPC64

[Curtis Hamilton]

Currently. the FreeBSD port only supports "i386 amd64 armv6 armv7" and does not 
support powerpc64 (ppc64).  I'm starting with an older version because newer 
versions seem to only support power8, while I'm using power5.

-- 
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/3c198aef-9c1d-4c9d-9978-c2e176010ba7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 1.8 port to FreeBSD/PowerPC64

[Curtis Hamilton]

I modified the freebsd/amd64 Go code and linux/ppc64 specific assembly code for 
freebsd/ppc64. 

With that done, I used the following to cross-compile on freebsd/amd64 host to 
create the bootstrap:

env GOOS=freebsd GOARCH=ppc64 GOROOT_BOOTSTRAP=/usr/local/go ./bootstrap.bash

I placed the resulting bootstrap build on freebsd/powerpc64 target and from the 
go-freebsd-ppc64-bootstrap directory:

Command-line: bin/go

Results:

Go is a tool for managing Go source code.

Usage:

go  [arguments]

The commands are:

bug start a bug report
build   compile packages and dependencies
clean   remove object files and cached files
doc show documentation for package or symbol
env print Go environment information
fix update packages to use new APIs
fmt gofmt (reformat) package sources
generategenerate Go files by processing source
get download and install packages and dependencies
install compile and install packages and dependencies
listlist packages or modules
mod module maintenance
run compile and run Go program
testtest packages
toolrun specified go tool
version print Go version
vet report likely mistakes in packages

Use "go help " for more information about a command.

Additional help topics:

buildmode   build modes
c   calling between Go and C
cache   build and test caching
environment environment variables
filetypefile types
go.mod  the go.mod file
gopath  GOPATH environment variable
gopath-get  legacy GOPATH go get
goproxy module proxy protocol
importpath  import path syntax
modules modules, module versions, and more
module-get  module-aware go get
packagespackage lists and patterns
testflagtesting flags
testfunctesting functions

Use "go help " for more information about that topic.

Command-line: bin/go env

Results:

go: cannot find GOROOT directory: /usr/ports/tmp/go-freebsd-ppc64-bootstrap

Setting GOROOT to go-freebsd-ppc64-bootstrap (or any other location), does not 
resolve the problem.  I know that it is finds the "environment", setting 
because whatever I set it to is returned when I execute bin/go env.

-- 
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/175674b5-da2a-412b-9439-7e0a379cceb1%40googlegroups.com.
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 can I read private field in go struct instance

[杜沁园]

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/7e811ac0-41f1-4924-a78b-dc197cfe150b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Connecting to SQL (Postgresql) instance from Go in Google Run, get "database is closed"

[Steve West]

Hi,
I have a simple Go program in Cloud Run that uses the Postgres SQL 
driver "github.com/lib/pq" to connect to a Cloud SQL Postgresql instance in 
the same Google Project. I have enabled the security by setting "Apps in 
this project: All authorized". The database and the Cloud Run service are 
in the same project.  I have used the Instance Connection Name as the 
connection string, however at runtime in Google Run I see the following 
error:

 http: panic serving 169.254.8.129:25475: sql: database is closed

Is there any further security settings to be made in order for the service 
to connect to the database?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6e7b2945-f65e-4144-915a-67169f01b5e7%40googlegroups.com.
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]

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] [help] trying to use gccgo but missing something

[Ian Lance Taylor]

On Mon, Jun 3, 2019 at 1:59 PM anthony Place  wrote:
>
> there is a 100 or so containing gccgo; '.go','.a','.c', batch and '.html' but 
> no executable (other than the batch files)
>
> i was previously hopeful about one called 'gccgo_install.html', but it was 
> about compilation and then assumed the executable existed.
>
> it seems something was not set to make to 'executable'? there isn't any 
> reference to it in the package listing.
>
> my interest was not major.
>
> i had originally thought to use go in a container, and compile stuff, but 
> solus had good support for all i needed, so i didn't bother.
>
> many thanks for the help.

Most likely your distro has a different package that contains the
gccgo executable, and you'll need to install that one separately.

For example, if you are using Debian, you would have to install the
gccgo package as well as the gcc package.

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/CAOyqgcXhLVEHS8Y5NqZE%3DcL714zOSBoDKBeEf-j-oPONTvzZ%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[anthony Place]

there is a 100 or so containing gccgo; '.go','.a','.c', batch and '.html' 
but no executable (other than the batch files)

i was previously hopeful about one called 'gccgo_install.html', but it was 
about compilation and then assumed the executable existed.

it seems something was not set to make to 'executable'? there isn't any 
reference to it in the package listing.

my interest was not major.

i had originally thought to use go in a container, and compile stuff, but 
solus had good support for all i needed, so i didn't bother.

many thanks for the 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/16faad5a-290c-4705-818e-2ac425ead666%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[Ian Lance Taylor]

On Mon, Jun 3, 2019 at 12:54 PM anthony Place  wrote:
>
> > What does "which gccgo" print?
>
> which: no gccgo in (/sbin:/bin:/usr/sbin:/usr/bin:/snap/bin)
>
> i was wondering if i had to add something to the path, or that it wasn't 
> being packaged, but..
>
> * gcc doc says go supported.

Yes, Go is supported, but that doesn't mean that installing your
distro's gcc package installed gccgo.

> * if i search the fs for gccgo i get all sorts of hits.

Is one of those an executable named "gccgo"?

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/CAOyqgcUCbPVM5QnVJb6dkQMb427GtY0gOVQHJSGM0vL7jtQs9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[anthony Place]

> What does "which gccgo" print? 

which: no gccgo in (/sbin:/bin:/usr/sbin:/usr/bin:/snap/bin)

i was wondering if i had to add something to the path, or that it wasn't 
being packaged, but..

* gcc doc says go supported.
* if i search the fs for gccgo i get all sorts of hits.





-- 
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/b564ac63-8b0c-42e9-9b0e-85428a5641f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [help] trying to use gccgo but missing something

[Ian Lance Taylor]

On Mon, Jun 3, 2019 at 8:48 AM anthony Place  wrote:
>
> i hoped adding -compiler gccgo to go build would just work but...
>
> > gccgo: exec: "gccgo": executable file not found in $PATH
>
> i have gcc (8.3) repo. package (solus 5) installed and the docs with it say 
> it supports go, and there doesn't seem to be anything else about gccgo in the 
> repo. so not really sure where to even look next.

What does "which gccgo" print?  If it doesn't print anything then
either you don't have gccgo installed or it's not on your PATH.  Note
that many distros package gccgo separately from the main gcc package.

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/CAOyqgcUFD4fj0EEDhckr%2BCjd7OBEFBpGXf7iJjTKXDHrRaWPcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Weiming Shi]

Let us have some concrete code snippet for discussion:
https://play.golang.org/p/fdcEs3k9U8I

Is this what you would like to have?


On Mon, Jun 3, 2019 at 11:54 AM 杜沁园  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/66703aa4-de59-4ae8-8407-928e7ebf95c5%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHS-Gt0z9gCi1dbSOxeXXEXH%3DW-iDNCS4PLdXfi5g%2BivrRPWMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[杜沁园]

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/66703aa4-de59-4ae8-8407-928e7ebf95c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [help] trying to use gccgo but missing something

[anthony Place]

i hoped adding -compiler gccgo to go build would just work but...

> gccgo: exec: "gccgo": executable file not found in $PATH

i have gcc (8.3) repo. package (solus 5) installed and the docs with it say 
it supports go, and there doesn't seem to be anything else about gccgo in 
the repo. so not really sure where to even look next.


-- 
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/2d31f04a-eae5-4b1e-baf2-40f38699f468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] GoGoConf 2019 is coming! [14.06.2019, Kraków, Poland]

[aneta]

Dear Go enthusiasts!

2019 GoGoConf edition is coming! We meet in two weeks in Hevre (Kazimierz, 
Krakow) to listen to great speakers, exchange knowledge and meet other 
Golang users.

We already know the topics of all talks:

Roberto Clapis, Google

Tackling contention: the monsters inside the `sync.Locker`

Prakash Mallela, CB Insights

Patterns for effective and effortless Observability

Oleg Kovalov, Allegro

Patterns for effective and effortless Observability

Michał Świętek, Aleph Zero

ALEPH: scaling and speeding blockchain up with DAG’s and Go

Anthony Seure, Algolia

Developing a Go API client: the do’s and don’ts

Mateusz Dymiński, Nokia

Diagnose your Golang App anytime anywhere!

Sounds interesting, right? If you haven’t bought tickets yet, grab one now!

https://gogoconf.eventbrite.com

www.gogoconf.rocks

[image: gogoconf.png] 

-- 
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/0ea2e43b-f4f3-40ec-94f7-16446323d4ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Martin Schnabel]

I agree. That is a good point. I consider arrays an edge case. Although 
still important, it will probably not be all too common. So the extra 
verbosity should not be a problem.


I am happy you generally agree and think these minor tweaks can make a 
big difference for the roll-out of the proposed feature, if accepted.


I also think, that this is one of the better proposals. It at least
feels more like go, syntax-wise, than most, except for the num part, 
which seems like an afterthought.


Again thank you for your work exploring this!

Best regards
  Marin

On 03.06.19 15:49, Michal Strba wrote:
'const' could be fine too. I guess this is mostly a matter of personal 
preference.


Regarding the array length syntax. It does require qualifying for two 
reasons:


1. Unnamed arguments.
2. Using 'gen' (or 'type', 'const') makes it easy to say "gen is not 
allowed in the return types", which is an important rule. Without 
qualification, this rule would be hard to express.


On Mon, Jun 3, 2019, 15:26 Martin Schnabel > wrote:


Hi Michal,

I would argue that the 'const' keyword would by more correct. Because
the array length is and needs to be constant anyway. And it has
currently no valid meaning in a parameter list, just like with
the 'type' keyword. However i would argue that the array length, if
written as part of the array syntax, as in '[n]elem' does not need an
explicit keyword qualifier, because - again - it's unambiguous in the
parameter context. Would you agree?

Best regards
    Martin

On 03.06.19 14:20, Michal Strba wrote:
 > Hi Martin.
 >
 > The proposal adds types as "values", but not really. You can only
accept
 > a type to a function, but you cannot return a type. That makes the
 > system far from a dependent type system, even with the support for
 > generic array lengths.
 >
 > Being able to return types from functions and use those functions in
 > types is what brings all the power (and complexity) of dependent
typing,
 > but what I proposed is just a simple system for explicit type
anotation
 > directly in the function signature.
 >
 > Regarding the 'gen' keyword, I chose it because I propose not only
 > generic types, but also generic array lengths. But you are right
that
 > using 'type' would probably be better. Do you think that using the
 > 'type' keyword also in the context of generic array lengths would
be fine?
 >
 > On Mon, Jun 3, 2019, 12:53 Martin Schnabel mailto:m...@mb0.org>
 > >> wrote:
 >
 >     Hi,
 >
 >     is my impression correct, that this proposal adds types as
values to
 >     the
 >     language? It's seems like it does the section 'Unnamed generic
 >     arguments'. That by itself would go a long way and warrants some
 >     discussion, I'd say.
 >
 >     If so, then why use a new keyword 'gen'? Why not 'type' itself.
 >     It would have some symmetry with how the func and struct
keywords are
 >     used for closures and unnamed structs. The 'type' keyword has no
 >     possible meaning in the parameter list currently.
 >
 >     I use the 'gen' keyword a lot as identifier, mostly for
generators
 >     and generated code. While nobody can claim to use 'type'.
This would
 >     make converting code so much easier, if this proposal is
accepted.
 >
 >     Just a though. Please tell me whether this would be possible.
 >
 >     Thanks for your work, it's much appreciated.
 >         Martin
 >
 >
 >     On 30.05.19 14:08, Michal Strba wrote:
 >      > Hi Gophers! :)
 >      >
 >      > I've been thinking about generics in Go 2 ever since the
original
 >      > contracts proposal and few days ago, ideas finally
clicked. One
 >     of the
 >      > main things about this proposal is that it deliberately
omits the
 >      > ability to restrict the set of types a function can work with.
 >     This is a
 >      > limitation, but I hope to convince you that we can still
do a vast
 >      > majority of the things we were missing, when we were missing
 >     generics.
 >      >
 >      > I'd love to share my proposal with you and engage in a
good faith
 >      > conversation.
 >      >
 >      > Link to the proposal.
 >      >

 >      >
 >      > Here's what the proposal covers:
 >      >
 >      > 1. Syntax of a new gen keyword.
 >      > 2. Generic functions.
 >      > 3. Unnamed generic arguments (a.k.a. a way to gve a type
to the
 >     built-in
 >      > newfunction).
 >      > 4. Semantics of generic values (ability to use them as map
keys,
 >     ...).

[go-nuts] Re: tracking down broken module dependency golint

[t hepudds]

For this error:

  github.com/golang/lint@v0.0.0-20190409202823-959b441ac422: parsing 
go.mod: unexpected module path "golang.org/x/lint"

That is saying 'github.com/golang/lint' was loaded, but the 'go.mod' found 
at that location for that version had a different module name 
('golang.org/x/lint') declared in the go.mod there. The 'go' command does 
not allow that mismatch between how a module is referenced vs. how the 
module declares its identity in its go.mod.

You can probably make it work by adding a 'replace' statement for 
github.com/golang/lint using the version from just before the 'go.mod' was 
added there.

Here is an example.

First, verify we get a similar failure with 'go get -u' for this old 
version of zipkin-go:
$ cd $(mktemp -d)
$ git clone -b v0.1.5 --depth=1 https://github.com/openzipkin/zipkin-go 
.
$ go get -u 
  
...which fails with the same error you reported:
  github.com/golang/lint@v0.0.0-20190409202823-959b441ac422: parsing 
go.mod: unexpected module path "golang.org/x/lint"

We can add a replace for the version of github.com/golang/lint from just 
before the 'go.mod' was added there. This will be a temporary measure that 
allows this upgrade to succeed, and then 'go mod tidy' will drop 
github.com/golang/lint from the module graph as no longer needed in this 
case.

   $ echo 'replace github.com/golang/lint => github.com/golang/lint 
5614ed5bae' >> go.mod
   $ go get -u
   $ go mod tidy
   $ go mod graph | grep github.com/golang/lint

...which now succeeds, and the grep finds nothing for the older github.com 
name.

There is a good chance that technique will work for you. There is a longer 
explanation of why that error occurs and why that technique usually works 
in this troubleshooting FAQ on the "Modules" wiki:


https://github.com/golang/go/wiki/Modules#how-can-i-resolve-parsing-gomod-unexpected-module-path-and-error-loading-module-requirements-errors-caused-by-a-mismatch-between-import-paths-vs-declared-module-identity

An alternative solution can be to try with the tip / master version of Go, 
which has better upgrade logic that can often sidestep this problem, and 
also often has a better error message for this situation:

   $ go get golang.org/dl/gotip && gotip download
   $ gotip get -u all
   $ gotip mod tidy

Hope that helps, but reply back to the list with more details if it does 
not.

Regards,
thepudds

On Monday, June 3, 2019 at 9:52:52 AM UTC-4, Joseph Lorenzini wrote:
>
> Hi all,
>
> I've been happily using go modules for several months. A couple days ago, 
> I decided to update my dependencies with go get -u. This failed with:
>
> go: github.com/golang/lint@v0.0.0-20190409202823-959b441ac422: parsing 
> go.mod: unexpected module path "golang.org/x/lint"
>
> Which led me to: https://github.com/golang/go/issues/30831
>
> So then I added a replace directive but that failed too because of 
> https://github.com/golang/go/issues/26904
>
> Which means as long as I depend on the golint package,  then go get -u 
> will not work. And then it occurred to me: how and why is this package 
> being pulled in? If i can remove my module's transitive dependency on 
> golint, then go get -u will start working. So I first ran go mod tidy. 
> Then I used go mod why however that was no help because whenever i executed 
> go mod why on the module, this is the output returned:
>
> (main module does not need module github.com/golang/lint)
>
> I also verified that github.com/golang/lint is not in my go.mod after 
> running go mod tidy. My understanding of tidy is that it pulls in direct 
> and transitive module dependencies ergo if go get -u is trying to upgrade 
> my deps according to go.mod, then it should be in my go.mod. So I am 
> stumped why go get -u is trying to upgrade golint, when according to go mod 
> tidy, my go.mod file, and go mod why, I don't have a dependency on it.
>
> Any advice would be appreciated.
>
> Thanks,
> Joe
>
>
>
>

-- 
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/3dc32542-d423-4920-a6ff-d4171b4667ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] tracking down broken module dependency golint

[Joseph Lorenzini]

Hi all,

I've been happily using go modules for several months. A couple days ago, I 
decided to update my dependencies with go get -u. This failed with:

go: github.com/golang/lint@v0.0.0-20190409202823-959b441ac422: parsing 
go.mod: unexpected module path "golang.org/x/lint"

Which led me to: https://github.com/golang/go/issues/30831

So then I added a replace directive but that failed too because of 
https://github.com/golang/go/issues/26904

Which means as long as I depend on the golint package,  then go get -u will 
not work. And then it occurred to me: how and why is this package being 
pulled in? If i can remove my module's transitive dependency on golint, 
then go get -u will start working. So I first ran go mod tidy. Then I used 
go mod why however that was no help because whenever i executed go mod why 
on the module, this is the output returned:

(main module does not need module github.com/golang/lint)

I also verified that github.com/golang/lint is not in my go.mod after 
running go mod tidy. My understanding of tidy is that it pulls in direct 
and transitive module dependencies ergo if go get -u is trying to upgrade 
my deps according to go.mod, then it should be in my go.mod. So I am 
stumped why go get -u is trying to upgrade golint, when according to go mod 
tidy, my go.mod file, and go mod why, I don't have a dependency on it.

Any advice would be appreciated.

Thanks,
Joe



-- 
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/0cb6129b-32aa-4be5-aa33-ab266ab2317c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

'const' could be fine too. I guess this is mostly a matter of personal
preference.

Regarding the array length syntax. It does require qualifying for two
reasons:

1. Unnamed arguments.
2. Using 'gen' (or 'type', 'const') makes it easy to say "gen is not
allowed in the return types", which is an important rule. Without
qualification, this rule would be hard to express.

On Mon, Jun 3, 2019, 15:26 Martin Schnabel  wrote:

> Hi Michal,
>
> I would argue that the 'const' keyword would by more correct. Because
> the array length is and needs to be constant anyway. And it has
> currently no valid meaning in a parameter list, just like with
> the 'type' keyword. However i would argue that the array length, if
> written as part of the array syntax, as in '[n]elem' does not need an
> explicit keyword qualifier, because - again - it's unambiguous in the
> parameter context. Would you agree?
>
> Best regards
>Martin
>
> On 03.06.19 14:20, Michal Strba wrote:
> > Hi Martin.
> >
> > The proposal adds types as "values", but not really. You can only accept
> > a type to a function, but you cannot return a type. That makes the
> > system far from a dependent type system, even with the support for
> > generic array lengths.
> >
> > Being able to return types from functions and use those functions in
> > types is what brings all the power (and complexity) of dependent typing,
> > but what I proposed is just a simple system for explicit type anotation
> > directly in the function signature.
> >
> > Regarding the 'gen' keyword, I chose it because I propose not only
> > generic types, but also generic array lengths. But you are right that
> > using 'type' would probably be better. Do you think that using the
> > 'type' keyword also in the context of generic array lengths would be
> fine?
> >
> > On Mon, Jun 3, 2019, 12:53 Martin Schnabel  > > wrote:
> >
> > Hi,
> >
> > is my impression correct, that this proposal adds types as values to
> > the
> > language? It's seems like it does the section 'Unnamed generic
> > arguments'. That by itself would go a long way and warrants some
> > discussion, I'd say.
> >
> > If so, then why use a new keyword 'gen'? Why not 'type' itself.
> > It would have some symmetry with how the func and struct keywords are
> > used for closures and unnamed structs. The 'type' keyword has no
> > possible meaning in the parameter list currently.
> >
> > I use the 'gen' keyword a lot as identifier, mostly for generators
> > and generated code. While nobody can claim to use 'type'. This would
> > make converting code so much easier, if this proposal is accepted.
> >
> > Just a though. Please tell me whether this would be possible.
> >
> > Thanks for your work, it's much appreciated.
> > Martin
> >
> >
> > On 30.05.19 14:08, Michal Strba wrote:
> >  > Hi Gophers! :)
> >  >
> >  > I've been thinking about generics in Go 2 ever since the original
> >  > contracts proposal and few days ago, ideas finally clicked. One
> > of the
> >  > main things about this proposal is that it deliberately omits the
> >  > ability to restrict the set of types a function can work with.
> > This is a
> >  > limitation, but I hope to convince you that we can still do a vast
> >  > majority of the things we were missing, when we were missing
> > generics.
> >  >
> >  > I'd love to share my proposal with you and engage in a good faith
> >  > conversation.
> >  >
> >  > Link to the proposal.
> >  >  >
> >  >
> >  > Here's what the proposal covers:
> >  >
> >  > 1. Syntax of a new gen keyword.
> >  > 2. Generic functions.
> >  > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
> > built-in
> >  > newfunction).
> >  > 4. Semantics of generic values (ability to use them as map keys,
> > ...).
> >  > 5. Generic array lengths.
> >  > 6. Reflection and interface{}.
> >  > 7. Generic types (with two examples: Listand Matrix).
> >  > 8. Generic methods and their limitations due to reflection.
> >  > 9. Generic interfaces.
> >  > 10. List of things this proposal can't do.
> >  >
> >  > Thanks,
> >  > faiface
> >  >
> >  > --
> >  > 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
> >  >
> >
> 

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Martin Schnabel]

Hi Michal,

I would argue that the 'const' keyword would by more correct. Because 
the array length is and needs to be constant anyway. And it has 
currently no valid meaning in a parameter list, just like with
the 'type' keyword. However i would argue that the array length, if 
written as part of the array syntax, as in '[n]elem' does not need an 
explicit keyword qualifier, because - again - it's unambiguous in the 
parameter context. Would you agree?


Best regards
  Martin

On 03.06.19 14:20, Michal Strba wrote:

Hi Martin.

The proposal adds types as "values", but not really. You can only accept 
a type to a function, but you cannot return a type. That makes the 
system far from a dependent type system, even with the support for 
generic array lengths.


Being able to return types from functions and use those functions in 
types is what brings all the power (and complexity) of dependent typing, 
but what I proposed is just a simple system for explicit type anotation 
directly in the function signature.


Regarding the 'gen' keyword, I chose it because I propose not only 
generic types, but also generic array lengths. But you are right that 
using 'type' would probably be better. Do you think that using the 
'type' keyword also in the context of generic array lengths would be fine?


On Mon, Jun 3, 2019, 12:53 Martin Schnabel > wrote:


Hi,

is my impression correct, that this proposal adds types as values to
the
language? It's seems like it does the section 'Unnamed generic
arguments'. That by itself would go a long way and warrants some
discussion, I'd say.

If so, then why use a new keyword 'gen'? Why not 'type' itself.
It would have some symmetry with how the func and struct keywords are
used for closures and unnamed structs. The 'type' keyword has no
possible meaning in the parameter list currently.

I use the 'gen' keyword a lot as identifier, mostly for generators
and generated code. While nobody can claim to use 'type'. This would
make converting code so much easier, if this proposal is accepted.

Just a though. Please tell me whether this would be possible.

Thanks for your work, it's much appreciated.
    Martin


On 30.05.19 14:08, Michal Strba wrote:
 > Hi Gophers! :)
 >
 > I've been thinking about generics in Go 2 ever since the original
 > contracts proposal and few days ago, ideas finally clicked. One
of the
 > main things about this proposal is that it deliberately omits the
 > ability to restrict the set of types a function can work with.
This is a
 > limitation, but I hope to convince you that we can still do a vast
 > majority of the things we were missing, when we were missing
generics.
 >
 > I'd love to share my proposal with you and engage in a good faith
 > conversation.
 >
 > Link to the proposal.
 > 
 >
 > Here's what the proposal covers:
 >
 > 1. Syntax of a new gen keyword.
 > 2. Generic functions.
 > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
built-in
 > newfunction).
 > 4. Semantics of generic values (ability to use them as map keys,
...).
 > 5. Generic array lengths.
 > 6. Reflection and interface{}.
 > 7. Generic types (with two examples: Listand Matrix).
 > 8. Generic methods and their limitations due to reflection.
 > 9. Generic interfaces.
 > 10. List of things this proposal can't do.
 >
 > Thanks,
 > faiface
 >
 > --
 > 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/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.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
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/739d147e-162d-14fc-a13a-9e7962f074e2%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you 

[go-nuts] Re: Go 1.8 port to FreeBSD/PowerPC64

[B Carr]

I'm wondering what you are trying to do as well. Go (latest version) is 
already available in the ports collection for FreeBSD. Installs just fine.


On Friday, May 31, 2019 at 7:54:55 PM UTC-6, Curtis Hamilton wrote:
>
> I’m porting Go 1.8 to FreeBSD/PowerPC64.  I’ve successfully built 
> go-FreeBSD-ppc64-bootstrap using go on FreeBSD/amd64.


> Can someone 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9c24b6b2-8d99-4f5a-a91a-7b104883c958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Michal Strba]

Hi Martin.

The proposal adds types as "values", but not really. You can only accept a
type to a function, but you cannot return a type. That makes the system far
from a dependent type system, even with the support for generic array
lengths.

Being able to return types from functions and use those functions in types
is what brings all the power (and complexity) of dependent typing, but what
I proposed is just a simple system for explicit type anotation directly in
the function signature.

Regarding the 'gen' keyword, I chose it because I propose not only generic
types, but also generic array lengths. But you are right that using 'type'
would probably be better. Do you think that using the 'type' keyword also
in the context of generic array lengths would be fine?

On Mon, Jun 3, 2019, 12:53 Martin Schnabel  wrote:

> Hi,
>
> is my impression correct, that this proposal adds types as values to the
> language? It's seems like it does the section 'Unnamed generic
> arguments'. That by itself would go a long way and warrants some
> discussion, I'd say.
>
> If so, then why use a new keyword 'gen'? Why not 'type' itself.
> It would have some symmetry with how the func and struct keywords are
> used for closures and unnamed structs. The 'type' keyword has no
> possible meaning in the parameter list currently.
>
> I use the 'gen' keyword a lot as identifier, mostly for generators
> and generated code. While nobody can claim to use 'type'. This would
> make converting code so much easier, if this proposal is accepted.
>
> Just a though. Please tell me whether this would be possible.
>
> Thanks for your work, it's much appreciated.
>Martin
>
>
> On 30.05.19 14:08, Michal Strba wrote:
> > Hi Gophers! :)
> >
> > I've been thinking about generics in Go 2 ever since the original
> > contracts proposal and few days ago, ideas finally clicked. One of the
> > main things about this proposal is that it deliberately omits the
> > ability to restrict the set of types a function can work with. This is a
> > limitation, but I hope to convince you that we can still do a vast
> > majority of the things we were missing, when we were missing generics.
> >
> > I'd love to share my proposal with you and engage in a good faith
> > conversation.
> >
> > Link to the proposal.
> > 
> >
> > Here's what the proposal covers:
> >
> > 1. Syntax of a new gen keyword.
> > 2. Generic functions.
> > 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in
> > newfunction).
> > 4. Semantics of generic values (ability to use them as map keys, ...).
> > 5. Generic array lengths.
> > 6. Reflection and interface{}.
> > 7. Generic types (with two examples: Listand Matrix).
> > 8. Generic methods and their limitations due to reflection.
> > 9. Generic interfaces.
> > 10. List of things this proposal can't do.
> >
> > Thanks,
> > faiface
> >
> > --
> > 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/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/golang-nuts/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com?utm_medium=email_source=footer
> >.
> > 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/739d147e-162d-14fc-a13a-9e7962f074e2%40mb0.org
> .
> 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/CAO6k0ut8W8STeA6_AadA9FbL7HxkVimKMfMT3bTBtxDyP1N5_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Martin Schnabel]

Hi,

is my impression correct, that this proposal adds types as values to the 
language? It's seems like it does the section 'Unnamed generic 
arguments'. That by itself would go a long way and warrants some 
discussion, I'd say.


If so, then why use a new keyword 'gen'? Why not 'type' itself.
It would have some symmetry with how the func and struct keywords are
used for closures and unnamed structs. The 'type' keyword has no
possible meaning in the parameter list currently.

I use the 'gen' keyword a lot as identifier, mostly for generators
and generated code. While nobody can claim to use 'type'. This would
make converting code so much easier, if this proposal is accepted.

Just a though. Please tell me whether this would be possible.

Thanks for your work, it's much appreciated.
  Martin


On 30.05.19 14:08, Michal Strba wrote:

Hi Gophers! :)

I've been thinking about generics in Go 2 ever since the original 
contracts proposal and few days ago, ideas finally clicked. One of the 
main things about this proposal is that it deliberately omits the 
ability to restrict the set of types a function can work with. This is a 
limitation, but I hope to convince you that we can still do a vast 
majority of the things we were missing, when we were missing generics.


I'd love to share my proposal with you and engage in a good faith 
conversation.


Link to the proposal. 



Here's what the proposal covers:

1. Syntax of a new gen keyword.
2. Generic functions.
3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
newfunction).

4. Semantics of generic values (ability to use them as map keys, ...).
5. Generic array lengths.
6. Reflection and interface{}.
7. Generic types (with two examples: Listand Matrix).
8. Generic methods and their limitations due to reflection.
9. Generic interfaces.
10. List of things this proposal can't do.

Thanks,
faiface

--
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/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/739d147e-162d-14fc-a13a-9e7962f074e2%40mb0.org.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[Randall O'Reilly]

I wrote up a coherent proposal based on the core of the idea below, and added 
it to the feedback wiki:

https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d

Overall I think it seems quite promising as perhaps the most “Go” version of 
generics possible, which solves the major use-cases, while retaining 
essentially the same existing syntax and just adding a few additional keywords. 
 I can’t see any major limitations other than those intrinsic to the idea 
itself (e.g., you can’t define a Min function that works across any type 
whatsoever), and I don’t think it introduces any violations of existing static 
type safety.  Curious to hear what others think!  Cheers,

- Randy

> On May 31, 2019, at 4:28 PM, Randall O'Reilly  wrote:
> 
> This seems similar to previous proposals based on introducing kind-based type 
> categories for contracts.  Putting the kind right there in the arg instead of 
> a separate contract seems like an improvement, keeping it more local to where 
> it is used.  Why not just take this one step further and just introduce 
> entirely new types:
> 
> * number
> * slice
> * map (re-useable from existing use-case?)
> * etc
> 
> func Min(x, y number) number {
>   if x < y {
>  return x
>   }
>   return y
> }
> 
> func Delete(sl *slice, idx int) {
>   *sl = append((*sl)[:idx], (*sl)[idx+1:])
> }
> 
> The compiler would just do its normal thing based on whatever actual kind you 
> pass in — an implicit type switch basically..
> 
> You could convert any `number` into a specific type (e.g., float64) when you 
> need to, and if you passed two different underlying types of numbers as args 
> to Min, it would automatically up-convert to the one with highest precision.  
> Essentially, this is undoing all the strict type specificity of Go, and 
> making it work like C, or Python..
> 
> This minimalist approach avoids all the complexity and ugliness of 
> parameterizing types etc — it is just a more generic type of type, and is 
> more or less how the generic builtin operators and functions like len, copy, 
> etc already work on their respective kinds.
> 
> Composite types seem like they might even just work without a type parameter:
> 
> type Vec2 struct {
>   X, Y number
> }
> 
> func (u Vec2) Add(v Vec2) Vec2 {
>   return Vec2{u.X + v.X, u.Y + u.Y}
> }
> 
> In summary, this is really just introducing a very controlled dose of dynamic 
> typing into the language (adding a dash of Python into Go).  Probably this 
> has already been considered and rejected hundreds of times over the course of 
> these discussions, but I’ve lost track, and seems at least like a very simple 
> conceptual proposal: you can achieve a lot of generics functionality by just 
> introducing dynamic typing.  Syntactically and conceptually, it is far 
> cleaner and simpler than anything else I’ve seen in the generics discussion, 
> at least.
> 
> - Randy
> 
>> On May 31, 2019, at 6:52 AM, Michal Strba  wrote:
>> 
>> @Ian, I have been thinking and I’ve come up with a possible solution to 
>> yours and some other problems. I’d love to hear your thoughts on it. Note, 
>> that this is a very fresh idea.
>> 
>> I’m addressing two problems here:
>> 
>>  • Inability to do Min/Max and other generic numeric functions.
>>  • There are a few kinds of generic parameters, but the kind is always 
>> implicit. This can be a problem because changing the body of a function can 
>> result in a backward-incompatible change, even when the signature remains 
>> the same.
>> Here are the ideas (also described in the proposal now, in the section 
>> called ‘Further ideas’).
>> 
>> The kind of a generic parameters is currently completely implicit. Some 
>> annotation could be added. One possible syntax could be like this:
>> 
>>  • gen n for generic array lengths.
>>  • gen T for arbitrary types (convertible to interface{}).
>>  • gen eq T for equalable types (comparable with == and usable as map 
>> keys).
>>  • gen num T for numeric types (with operators like +, -, <, …).
>> Array lengths and arbitrary types can have the same notation because it’s 
>> always possible to distinguish them by context. Alternatively, they could be 
>> distinguished by capitalization (lower-case for array lengths, upper-case 
>> for types).
>> 
>> Syntax-wise, eq and num would not be keywords on their own. Rather, gen eq 
>> and gen num would be two-word keywords.
>> 
>> The syntax is rather ad-hoc, I admit. It’s a very fresh idea, completely 
>> open to refinement. However, since there are only four cases, an ad-hoc 
>> syntax may actually be the right choice.
>> 
>> It’s also easily extensible with new possible “contracts”, but I’d generally 
>> advise against that.
>> 
>> The addition of the num restriction would actually enable many cool things. 
>> First, the Min/Max functions:
>> 
>> func
>> Min(x, y gen num T) T {
>> 
>> if
>> x < y {
>> 
>> return
>> x
>>}
>> 
>> return
>> y
>> }
>> 
>> It would also be useful 

[go-nuts] Re: ANN: Zstandard Go compression package

[Jimmy Tang]

great stuff, not having to lug around the cgo based library that's already 
there will make deployments easier.

On Sunday, 2 June 2019 17:36:46 UTC+1, Klaus Post wrote:
>
> I am happy to announce the availability of the first Zstandard compressor 
> written in Go. This package will allow you to get very fast compression to 
> the Zstandard format.
>
> The current compressor is focused mainly on speed and outperforms 
> gzip/deflate typically by a factor of 3x for similar compression ratios. It 
> is also within a reasonable margin, typically 0.75x the throughput of the 
> reference library called with cgo. Also, it has CRC checks and better error 
> handling compared to the cgo library.
>
> Alongside the previously released decompressor, this will allow you to do 
> very fast compression and decompression with unrivaled efficiency in pure 
> Go.
>
> Both a stream and byte blob compressor is made available and both operate 
> without allocations if re-used, so it will also play nicely with the rest 
> of your application.
>
> As a bonus, there is a Snappy -> Zstandard stream converter. This was 
> mainly a development tool, but could be useful for some.
>
> Current status: The main goal for the initial release was to get something 
> that would be a feasible replacement for both deflate/gzip and the cgo 
> wrapper. The package in its current shape allows to replace both for 
> scenarios where fast compression is required. The compressor has been 
> (fuzz) tested, but may still contain subtle bugs - so if you are dealing 
> with critical data, you might want to do your own testing first.
>
> Feedback and experience reports are appreciated. This has taken most of my 
> free time the last several months and has been a great learning experience. 
> I plan to dive into the more efficient (and slower) compression modes next 
> - but feel free to write if you desperately need something else.
>
>
> Package: https://github.com/klauspost/compress/tree/master/zstd#zstd
>
>
> /Klaus
>

-- 
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/c0db67f0-39aa-49cd-a376-a244c9241924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 1.8 port to FreeBSD/PowerPC64

[Ian Lance Taylor]

On Fri, May 31, 2019 at 6:54 PM Curtis Hamilton  wrote:
>
> I’m porting Go 1.8 to FreeBSD/PowerPC64.  I’ve successfully built 
> go-FreeBSD-ppc64-bootstrap using go on FreeBSD/amd64.
>
> However, l’m getting the error go: cannot find GOROOT directory, when 
> executing ‘go env’ on the target system.
>
> I’m not sure if this is a code issue.  I’ve tried some of the tips about 
> setting GOROOT and GOPATH, with no success.
>
> Can someone help?

Why not port a newer version of Go?

What exactly are you doing?  In particular, are you using
src/bootstrap.bash?  Show us the exact commands that you are running,
and the exact unexpected output that you are getting.

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/CAOyqgcUCjT_pom40Ysx-f9PugNzAW_q-Miw6f7b6wNzU8PCEXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.