[go-nuts] Type-checking from Memory?

Hi All, Right now, I can run the type-checker by writing the GitHub tarball contents to disk and using the packages.Load function to parse and type-check the contents. Unfortunately, all I've been able to make work at the moment with packages.Load would entail writing the entire repository conten

Re: [go-nuts] Building a totally static go binary.

On Thursday, January 21, 2021 at 12:38:30 AM UTC+8 axel.wa...@googlemail.com wrote: > I just tried building using > > mero@hix ~/go/src$ CGO_ENABLED=0 ./make.bash > mero@hix ~/go/src$ file ../bin/go > ../bin/go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically > linked, Go > Bu

Re: [go-nuts] Building a totally static go binary.

On Thursday, January 21, 2021 at 8:27:02 AM UTC+8 Ian Lance Taylor wrote: > On Wed, Jan 20, 2021 at 8:28 AM Hongyi Zhao wrote: > > > > On Ubuntu 20.10, I use the following steps to build the go binary: > > > > $ sudo apt-get build-dep -y golang > > $ git clone https://github.com/golang/go.

[go-nuts] Re: program times out on go playground and runs but with race on mac running go1.16beta

Thanks a million Totally missed that first err was not limited to the scope of the case or the go routine. On Wednesday, January 20, 2021 at 6:02:29 PM UTC-6 Carla Pfaff wrote: > result <- Event{event, err} > > reads the `err` variable in one goroutine, and > > err = watcher.Add(dir) > >

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

I know but in the case of map, it's a built-in. We have easily higher order functions for that that can be defined. Where there is a problem is defining higher order functions for generic user-defined containers... I think that it is going a bit too far in the parametrization. It may happen and

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

FTR, the same argument that applies to `List(List(int))` also applies to `Set(Set(int))` and `Map(Key1, Map(Key2, Val))`, neither of which suffers from algorithmic complexity issues and both of which I have used in the past in real code. On Thu, Jan 21, 2021 at 1:35 AM atd...@gmail.com wrote: >

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

On Wed, Jan 20, 2021 at 2:27 PM Axel Wagner wrote: > I think the general rule of thumb I find agreeable is "the length of an > identifier should be inversely correlated to the distance between its > declaration and its use". > I just realized that this is wrong. It should be correlated, not inve

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

Oh, I know it does, as mentioned above. Typically to emulate matrices. My point was that it is still different from a linked list of linked lists.If not time complexity, data locality etc. May be useful for some type of very large graph datastructures, I wouldn,'t know since I haven't encounter

Re: [go-nuts] Building a totally static go binary.

On Wed, Jan 20, 2021 at 8:28 AM Hongyi Zhao wrote: > > On Ubuntu 20.10, I use the following steps to build the go binary: > > $ sudo apt-get build-dep -y golang > $ git clone https://github.com/golang/go.git go.git > $ cd go.git/src > $ ./make.bash > $ cd ../ > $ ldd bin/go > linux-vdso.so.1 (0x00

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

On Wed, Jan 20, 2021 at 1:19 PM atd...@gmail.com wrote: > > I have been asking because the List of List example seemed a bit contrieved > to me. I have seen maps of linked lists or slice of slices for math stuff but > rarely lists of lists.(probably because of the time complexity) We will have

[go-nuts] Re: program times out on go playground and runs but with race on mac running go1.16beta

result <- Event{event, err} reads the `err` variable in one goroutine, and err = watcher.Add(dir) writes the same `err` variable in another goroutine. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and s

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, Jan 20, 2021 at 3:24 AM Brian Candler wrote: > > Yes. Conceptually at least, interfaces defined as type lists could be used > as interfaces: > > type Foo interface { type int32, int64 } > func f(a, b Foo) { > if (a < b) ... > } > > Without specialisation, there would be dynamic disp

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, Jan 20, 2021 at 2:08 AM Brian Candler wrote: > > In the Generics proposal, type constraints (other than type lists) take the > form of interfaces. For example, a generic type T may be constrained with > interface C. > > Question: if a function takes type T, does that permit *both* value

[go-nuts] program times out on go playground and runs but with race on mac running go1.16beta

if I run this program in the playground, I get: timeout running program Program exited: status 1 https://play.golang.org/p/5cDYasXtl_n If I run it on my macos Catalina machine with go 1.16 beta I get a data race warning ``` WARNING: DATA RACE Read at 0x00c00011a2a0 by goroutine 10: main.New.f

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 10:02 PM burak serdar wrote: > > As a generic-function writer, I do not know if the argument will be an > interface or a concrete type. I don't want to check if it is > zero-value, I want to check if it is nil, because I don't want it to > panic. Other people in this threa

[go-nuts] Announcing godocs.io, a maintained fork of godoc.org

Greetings. For those who do not wish to follow Golang to pkg.go.dev, and prefer the authentic godoc.org experience, I have forked the gddo codebase and set up an instance which will be maintained indefinitely: https://godocs.io The source code is available here: https://sr.ht/~sircmpwn/godocs.io

Re: [go-nuts] package is not in goroot

* Jan Mercl <0xj...@gmail.com> [210120 15:27]: > On Wed, Jan 20, 2021 at 9:03 PM Marvin Renich wrote: > > > I still cannot find any mention of reserved import paths in any > > documentation (go help modules/importpath/gopath). It's just an issue > > on the tracker. > > When an important part of

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

It's not about bad or useless, the same way Go is not useless because of its current set of constraints. It's about implementing which you can derive the most value of(also in terms of simplicity, code-sharing etc.) Meta-programming is all-encompassing but it's problematic. Give someone a hamme

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

Personally, I feel that "let's reduce utility while keeping complexity constant" is a questionable approach, if you feel that generics don't provide enough value to justify their complexity. I feel that *if* we introduce generics, we should make sure they actually pay for their cost. I'd much rathe

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

I have been asking because the List of List example seemed a bit contrieved to me. I have seen maps of linked lists or slice of slices for math stuff but rarely lists of lists.(probably because of the time complexity) But yes, composing the parametrization is probably not something that should

Re: [go-nuts] `go list` across multiple modules?

As long as these things are bugs and not "that's not how it works or will ever work", I have some hope. This is a back-burner exploration for me, so I am not in a panic. Every now and again I will circle back and see if anything new happens :) On Wed, Jan 20, 2021 at 10:50 AM Jay Conrod wrote:

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

On Wed, Jan 20, 2021 at 11:42 AM atd...@gmail.com wrote: > > > It didn't seem to me like proposal-killers enoguh so much so that they might > not have liked some of the design choices they entailed. > > The proble with the current running proposal is that it is a generalization > fo what the com

Re: [go-nuts] package is not in goroot

On Wed, Jan 20, 2021 at 9:03 PM Marvin Renich wrote: > I still cannot find any mention of reserved import paths in any > documentation (go help modules/importpath/gopath). It's just an issue > on the tracker. When an important part of the implementation is undocumented then it's a documentation

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

FWIW, personally, I believe if you make it painful to write generics, what will happen is that people will write generic code and complain about how painful it is. I don't think the outcome will be that people will use it less. If someone thinks they need generics and wants to use them, they will.

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

Hello FWIW I had a go at imagining a way to make a variant of your idea (package-level parametrisation) work. At the time my principal worry was contracts and I was keen to use interfaces instead to express parametric constraints: https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2

Re: [go-nuts] package is not in goroot

* Jan Mercl <0xj...@gmail.com> [210120 10:46]: > On Wed, Jan 20, 2021 at 3:57 PM Marvin Renich wrote: > > > I don't understand what you are saying. What is a "reserved import > > path" and where is it defined? > > See https://github.com/golang/go/issues/32819 ??? Thanks for pointing this out!

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

On Wed, Jan 20, 2021 at 8:42 PM atd...@gmail.com wrote: > It didn't seem to me like proposal-killers enoguh so much so that they > might not have liked some of the design choices they entailed. Yes, that's in general what kills proposals. The proble with the current running proposal is that it

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

It didn't seem to me like proposal-killers enoguh so much so that they might not have liked some of the design choices they entailed. The proble with the current running proposal is that it is a generalization fo what the compiler does. It definitely permits the spread of generic functions ac

Re: [go-nuts] Re: Quick question about the generics alternatives that have been considered

The proposal-killers are mentioned - it is awkward for different instantiations of the same package to interact and there is no reason to believe generic usecases will delineate neatly into packages. It sounds like you do not agree that those are proposal-killers. And of course, you are welcome to

Re: [go-nuts] `go list` across multiple modules?

You appear to have discovered another new bug. Sorry for that. I've opened #43806 to track it. With that bug, it doesn't look like `go list` with local paths (relative or absolute) in a repository with nested replacement directories will work (at least n

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, 20 Jan 2021 at 11:04, Brian Candler wrote: > What do you make of this? > https://go2goplay.golang.org/p/gN-FK2kbYK5 > > Using interface values, it seems possible to bypass a declared constraint > that two arguments have the same type. > This code is misleading. By passing the value to `r

[go-nuts] Re: Quick question about the generics alternatives that have been considered

It does mention it but I fail to see the problem specifically. I am curious about anything that would make it a proposal-killer in terms of design for Go. Also, the distinction I see is that it would not be the same instantiation of the same package as much as the creation of new packages ( the

[go-nuts] Re: Quick question about the generics alternatives that have been considered

If I understand correctly, this question is specifically addressed by the design draft: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages On Wednesday, January 20, 2021 at 10:22:19 AM UTC-5 atd...@gmail.com wrote:

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam wrote: > The encoding scheme is described briefly in the README[0] and the code[1]. > > To answer your two specific questions, interfaces are represented as a > pair (typeNumber, value) where typeNumber maps to a registered type. (Like > gob, types

[go-nuts] Re: GODOC: how to create a reference to another definition in a comment?

For instance, // Node returns a tree node. The value for the node type are specified // in the definition of @href="NodeType" type Node struct{...} // NodeType defines the types of Node values // They can be ...etc type NodeType int clicking on the ref would allow to make a jump to the relevan

Re: [go-nuts] Building a totally static go binary.

I just tried building using mero@hix ~/go/src$ CGO_ENABLED=0 ./make.bash mero@hix ~/go/src$ file ../bin/go ../bin/go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=vuwQ_gWzFYzm9u1fSb6J/teB52WVS50es5tAa1xez/9HCuFMUtERd7wPEheIgP/i3RObo0pxXnfqkowogAH, not stripped

[go-nuts] Building a totally static go binary.

On Ubuntu 20.10, I use the following steps to build the go binary: $ sudo apt-get build-dep -y golang $ git clone https://github.com/golang/go.git go.git $ cd go.git/src $ ./make.bash $ cd ../ $ ldd bin/go linux-vdso.so.1 (0x7ffef27ee000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread

Re: [go-nuts] package is not in goroot

On Wed, Jan 20, 2021 at 3:57 PM Marvin Renich wrote: > I don't understand what you are saying. What is a "reserved import > path" and where is it defined? See https://github.com/golang/go/issues/32819 -- You received this message because you are subscribed to the Google Groups "golang-nuts"

[go-nuts] Quick question about the generics alternatives that have been considered

Hello, It' has probably been discussed somewhere but I am curious about what might have been the issues when considering an implementation of generics that would parameterized packages? The rationale being that usually, packages have a non-mutable interface for the user and are the ompilation

Re: [go-nuts] package is not in goroot

* Marvin Renich [210120 09:58]: > * Jan Mercl <0xj...@gmail.com> [210120 09:32]: > > On Wed, Jan 20, 2021 at 2:58 PM Marvin Renich wrote: > > > > > The error message is really incomplete, and therefore confusing. It > > > should be "package ... is not in GOROOT or any element of GOPATH". > > >

Re: [go-nuts] package is not in goroot

* Jan Mercl <0xj...@gmail.com> [210120 09:32]: > On Wed, Jan 20, 2021 at 2:58 PM Marvin Renich wrote: > > > The error message is really incomplete, and therefore confusing. It > > should be "package ... is not in GOROOT or any element of GOPATH". > > _That_ would be incorrect and confusing. Res

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

50ns is approximately the cost of a cross-CPU L2 cache miss. Any time you have tight cross-CPU communication, you're going to incur that cost no matter how the communication is performed — whether it's via a sync.Mutex, a channel, or an atomic write. The way to eliminate that cost is to elimina

Re: [go-nuts] package is not in goroot

On Wed, Jan 20, 2021 at 2:58 PM Marvin Renich wrote: > The error message is really incomplete, and therefore confusing. It > should be "package ... is not in GOROOT or any element of GOPATH". _That_ would be incorrect and confusing. Reserved import paths are never searched for in GOPATH. -- Y

Re: [go-nuts] package is not in goroot

* Alexander Mills [210119 16:54]: > i am getting this weird error message: > > package twitch/go-scripts/dynamo-creators-to-s3/lib is not in GOROOT > (/usr/local/Cellar/go/1.15.6/libexec/src/twitch/go-scripts/dynamo-creators-to-s3/lib) > > my GOPATH=$PWD/scripts/go > > so there is only 1 GOPA

Re: [go-nuts] Golang security and reliability

On 1/20/21 1:46 PM, Axel Wagner wrote: >  My personal projection is that security will mostly be unaffected (/I don't > know of many security issues in the past that were related to Go type safety > or > lack thereof/), if it *is* affected, the effect will be positive and that > type-safety will i

Re: [go-nuts] Golang security and reliability

On Wed, Jan 20, 2021 at 2:25 PM Kevin Chadwick wrote: > It has been stated in a thread that there have never been any type safety > related security issues. I assume you are referring to what I said and I'd just like to point out that I never made such claims. I said two things: I assume panic

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

The encoding scheme is described briefly in the README[0] and the code[1]. To answer your two specific questions, interfaces are represented as a pair (typeNumber, value) where typeNumber maps to a registered type. (Like gob, types must be registered.) Structs are represented as: startCode (fieldN

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

On Wed, Jan 20, 2021 at 10:05 AM Jérôme Champion wrote: > A bit out of subject but the naming with generics has always bothered me. > It's more of an general observation and don't have a solution for it. > I think we all agree that naming types and variables is important. Why for > generics we ac

Re: [go-nuts] Golang security and reliability

On 1/20/21 12:27 PM, Axel Wagner wrote: > > Language design is a trade-off and there is no such thing as a perfect > type-system. Go has decided that it doesn't want to occupy the "most > type-safety > possible" spot in the language design space. > > I don't think it is true that anyone is "downpl

Should Generics also be as usable as empty interfaces; Was: [go-nuts] Golang security and reliability

>> I don't understand what you are trying to say or achieve. But, to be clear: >> 1. Yes, Go does intentionally not attempt to build a type-system which >> excludes as many bugs as possible statically. >> 2. Yes, there is a possibility that Go software has security bugs that could (or would) have b

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, Jan 20, 2021 at 1:10 PM Brian Candler wrote: > On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com > wrote: > >> Can you come up with a realistic reason to have that constraint that >> doesn't end up needing reflect anyway (where you can implement any checks >> you wan

Re: [go-nuts] Golang security and reliability

On Wed, Jan 20, 2021 at 12:47 PM Kevin Chadwick wrote: > I know Go is far from plagued by these issues and I certainly wouldn't > want to > trade Gos simplicity away. However, there seems to be a playing down of > null > pointers and type safety issue potential. > I don't understand what you are

Re: [go-nuts] Re: Interface arguments to generic functions

On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com wrote: > Can you come up with a realistic reason to have that constraint that > doesn't end up needing reflect anyway (where you can implement any checks > you want)? > Mainly it's programmer comfort. If I write a contain

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

On Wednesday, 20 January 2021 at 10:39:48 UTC Carla Pfaff wrote: > Also, until now, in Go identifiers beginning with a capital letter are > exported. > Function parameters and local variables which start with a capital letter are not exported. I think it's a matter of taste whether you write

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, Jan 20, 2021 at 12:04 PM Brian Candler wrote: > What do you make of this? > https://go2goplay.golang.org/p/gN-FK2kbYK5 > > Using interface values, it seems possible to bypass a declared constraint > that two arguments have the same type. > I understand if people are confused by it. I fin

[go-nuts] Golang security and reliability

I know Go is far from plagued by these issues and I certainly wouldn't want to trade Gos simplicity away. However, there seems to be a playing down of null pointers and type safety issue potential. Is this not a type safety issue? "https://www.cvedetails.com/cve/CVE-2019-14809/"; and obviously n

Re: [go-nuts] Re: Interface arguments to generic functions

On Wednesday, 20 January 2021 at 10:53:10 UTC axel.wa...@googlemail.com wrote: > On Wed, Jan 20, 2021 at 11:08 AM Brian Candler wrote: > >> What I mean is, the difference between >> func f(a, b fmt.Stringer) c fmt.Stringer { ... } >> and >> func f[T fmt.Stringer](a, b T) c T { ... } >> would sim

Re: [go-nuts] Re: Interface arguments to generic functions

On 1/20/21 10:42 AM, 'Axel Wagner' via golang-nuts wrote: > IMO it is confusing to allow comparing generic values to nil, in general. If > we > could, I would either assume I can compare any *non*-generic value to nil. I > would assume we can always go from a generic function to an instantiated on

Re: [go-nuts] Re: Interface arguments to generic functions

What do you make of this? https://go2goplay.golang.org/p/gN-FK2kbYK5 Using interface values, it seems possible to bypass a declared constraint that two arguments have the same type. I am wondering the following. 1. If the function signature says two types should be the same (via type parameter

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, Jan 20, 2021 at 11:08 AM Brian Candler wrote: > With my wild hat on: it makes me wonder what would happen if the generics > proposal became nothing more than interfaces with linked constraints - so > that you could say "this function takes a function of type T (interface C) > and returns

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, Jan 20, 2021 at 11:08 AM Brian Candler wrote: > The end result is there's a crucial but subtle difference between: > > type Foo interface { ... } > func f(v Foo) ... > > and > > type Foo interface { ... } > func f[T Foo](v T) ... > > Given that the second case supports both concrete types

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

On Wednesday, 20 January 2021 at 10:05:24 UTC+1 cham...@gmail.com wrote: > A bit out of subject but the naming with generics has always bothered me. > It's more of an general observation and don't have a solution for it. > I think we all agree that naming types and variables is important. Why for

[go-nuts] Re: Interface arguments to generic functions

On Wednesday, 20 January 2021 at 03:06:43 UTC bbse...@gmail.com wrote: > Is it possible to write a generic function that can test if its > argument with a constraint is nil? > I think there is a deeper question in there. In the Generics proposal, type constraints (other than type lists) take t

Re: [go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.

A bit out of subject but the naming with generics has always bothered me. It's more of an general observation and don't have a solution for it. I think we all agree that naming types and variables is important. Why for generics we accept that naming them E, K P, T etc.. is good and sufficient? I