Re: [go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[Sebastien Binet]

Hi Clement,

it's a nice investigation of the benefits and limits of using reflect.

I guess it would also be as interesting to investigate what this library
would look like if the current draft for generics were to be accepted :)

-s


On Sun, Aug 4, 2019 at 4:13 PM clement auger 
wrote:

> You tell me.
>
>
> https://github.com/clementauger/sta
>
>
> sta - stream async
>
> Implements responsive data stream pipeline.
>
> It is a reasearch and concept project not to be used in production.
> Install go get -u
> github.com/clementauger/sta Doc
> godoc.org/github.com/clementauger/sta
> Example
>
> most simple.
>
> sta.Map([]string{"a", "b", "c"}).
>   Map(strings.ToUpper).
>   Sink(fmt.Println)
>
> This example demonstrate the implementation of a pipeline that bulks by
> slices of strings of length 4. It declares two parallel workers to change
> the strings cases. It outputs resulting values to stdout.
>
> sta.Map([]string{"a","b"}).
>   Map(sta.Accumulate(make([]string, 4), time.Second)).
>   Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
>   Sink(fmt.Println)
>
> Rationale
> Introduction
>
> sta takes full advantage of the CSP channel based go capabilities to
> provide a simple implementation to compose, implement and refactor
> responsive data stream pipeline.
>
> A data stream pipeline is said to be responsive when it is able to react
> with its downstream at any point in time in response to a variation of its
> input.
>
> An implementation is said to be simple to compose, implement and refactor
> a data stream pipeline if its overall result expresses the solution with
> less lines of code, easier understanding, improved rewriting capabilities
> and testing experience.
>
> Does this attempt reaches its goal ? yes and no...
> Concepts
>
> https://blog.golang.org/pipelines
> Usage
>
> sta exposes a Map function, to create stream instances.
>
>   s := sta.Map(src)
>
> src is a value that can take a plurality of data kind.
>
>   s := sta.Map([]string{"a","b"})
>   s = sta.Map([]int{1,2})
>   s = sta.Map(make(chan string))
>   s = sta.Map(func(output chan string){ output<-"hello world!" })
>
> sta.Map reads the given input in a separate routine and manages for it
> the required output communication channels.
>
> The generated output channels are given to downstream transforms of the
> stream.
>
>   s := sta.Map([]string{"a","b"}).
> Map(func(v string) int { return len(v)})
>
> stream.Map transforms a given input to an output, in a separate routine.
> It generates the required communication channels and connects them with the
> upstream and downstream automatically.
>
> To handle fine control of the data flow, stream.Map can handle functions
> that receives the upstream channel. Those functions must return a processor
> function that implements the loop over the upstream channel, and an output
> channel they are writing. The output channel is closed after that the
> processor function has terminated.
>
>   s := sta.Map([]string{"a","b"}).
> Map(func(input chan string) (func()error, chan int) {
>   output := make(chan int)
>   processor := func()error {
> for v := range input {
>   output<-len(v)
> }
>   }
>   return processor, output
> })
>
> To execute the pipeline, the developer must call for the stream.Sink
> function. stream.Sink is realy just like stream.Map except that it closes
> the stream by executing it.
>
>   err := sta.Map([]string{"a","b"}).
> Map(strings.ToUpper).
> Sink(sta.DevNull)
>
> stream.Sink writes the destination in a separate routine.
>
> The given destination value can be of kinds such as slice pointers,
> channels or functions.
>
>   outSlice := []string{}
>   sta.Map([]string{"a","b"}).Sink(&outSlice)
>
>   outChan := make(chan string)
>   sta.Map([]string{"a","b"}).Sink(outChan)
>
>   outFn := func(v string){}
>   sta.Map([]string{"a","b"}).Sink(outFn)
>
>   outChanFn := func(v chan string) (func() error) { return func()error{return 
> nil}}
>   sta.Map([]string{"a","b"}).Sink(outChanFn)
>
> Merge
>
> To merge a source, simply add more sources to the stream. Each source runs
> into their own routine.
>
> It results in a simple merge operation of the output values.
>
> Sources can have different kind, but they should converge to a compatible
> output type.
>
>   sta.Map(
> []string{"a","b"},
> []string{"c","d"},
> func(output chan string) {
>   output<-"e"
>   output<-"f"
> },
> func(output chan string) {
>   output<-"e"
>   output<-"f"
> },
>   )
>
> 

[go-nuts] Re: Contracts Draft: why are method pointers allowed

[alan . fox6]

For those who haven't already noticed, I thought I'd point out that the 
draft design has now been changed (as Ian intimated it might be) so that 
contracts may now require a pointer method in some cases i.e. if the type 
parameter is T one can now specify that *T has a certain method.

In particular, this will be needed if an implementing function is declaring 
a variable of type T but you then need to invoke a method on it where the 
receiver type is *T. To understand why this is so, one needs to re-read the 
design paper which has some examples of why the previous situation didn't 
work.

Looked at overall I think this is a better idea than what I was proposing 
earlier, though it might be difficult for folks to get their heads around 
the circumstances when and why a pointer method is needed. However, as it's 
probably a situation which will arise infrequently in practice, it should 
not be a major concern.

Alan

-- 
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/64567134-2fec-423c-8828-fed14f392fc7%40googlegroups.com.

[go-nuts] Re: package-level structs vs package-level vars

[B Carr]

Is it safe to say that environment variables (accessible to all goroutines) 
also live in the data segment?

-- 
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/01cea3eb-8f87-4ee3-a306-6641697c8a48%40googlegroups.com.

Re: [go-nuts] Re: package-level structs vs package-level vars

[burak serdar]

On Mon, Aug 5, 2019 at 8:47 AM B Carr  wrote:
>
> Is it safe to say that environment variables (accessible to all goroutines) 
> also live in the data segment?

No.

When you say "environment variables", do you mean OS env variables, or
the variables visible to a goroutine?

If you're talking about the variables visible to a goroutine, where
the variable lives depends on how it is declared and allocated.

If the variable is allocated at compile time (like a global var/struct
initialized with a literal) it lives in data segment.

If the variable is allocated dynamically using new(), or it is
declared in a function and it escapes, it lives on the heap.


>
> --
> 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/01cea3eb-8f87-4ee3-a306-6641697c8a48%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqoc0GSo8GnOtU-LnB%2B71rdk7Aiz-PVSdia%2B7DYH5T-Z4g%40mail.gmail.com.

Re: [go-nuts] Re: package-level structs vs package-level vars

[B Carr]

On Monday, August 5, 2019 at 8:52:41 AM UTC-6, burak serdar wrote:
>
> On Mon, Aug 5, 2019 at 8:47 AM B Carr > 
> wrote: 
> > 
> > Is it safe to say that environment variables (accessible to all 
> goroutines) also live in the data segment? 
>
> No. 
>
> When you say "environment variables", do you mean OS env variables, or 
> the variables visible to a goroutine? 
>
> If you're talking about the variables visible to a goroutine, where 
> the variable lives depends on how it is declared and allocated. 
>
> If the variable is allocated at compile time (like a global var/struct 
> initialized with a literal) it lives in data segment. 
>
> If the variable is allocated dynamically using new(), or it is 
> declared in a function and it escapes, it lives on the heap. 
>

Oh. I'm talking about env variables which a goroutine sets by using 
os.Setenv() which to me implies OS env variables. Are those env variables 
accessible by all goroutines regardless of which goroutine set the env 
variable? Would such env variables be available to newer goroutines that 
spin up? I think the answer to this is "Yes", based on a response I got to 
another thread.

I'm apparently being too black/white in my thinking about where things get 
put into memory and your explanations are helping to get my mind right.

-- 
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/e064b3a9-19f1-48ca-8fab-e438a737b889%40googlegroups.com.

Re: [go-nuts] Re: package-level structs vs package-level vars

[burak serdar]

On Mon, Aug 5, 2019 at 9:20 AM B Carr  wrote:
>
>
>
> On Monday, August 5, 2019 at 8:52:41 AM UTC-6, burak serdar wrote:
>>
>> On Mon, Aug 5, 2019 at 8:47 AM B Carr  wrote:
>> >
>> > Is it safe to say that environment variables (accessible to all 
>> > goroutines) also live in the data segment?
>>
>> No.
>>
>> When you say "environment variables", do you mean OS env variables, or
>> the variables visible to a goroutine?
>>
>> If you're talking about the variables visible to a goroutine, where
>> the variable lives depends on how it is declared and allocated.
>>
>> If the variable is allocated at compile time (like a global var/struct
>> initialized with a literal) it lives in data segment.
>>
>> If the variable is allocated dynamically using new(), or it is
>> declared in a function and it escapes, it lives on the heap.
>
>
> Oh. I'm talking about env variables which a goroutine sets by using 
> os.Setenv() which to me implies OS env variables. Are those env variables 
> accessible by all goroutines regardless of which goroutine set the env 
> variable? Would such env variables be available to newer goroutines that spin 
> up? I think the answer to this is "Yes", based on a response I got to another 
> thread.

Those env variables belong to the process. All gorountines share them.
If you're setting env variables from goroutines, you might want to
think about thread safety of setenv.


>
> I'm apparently being too black/white in my thinking about where things get 
> put into memory and your explanations are helping to get my mind right.
>
> --
> 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/e064b3a9-19f1-48ca-8fab-e438a737b889%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpoMgOxGtVEHUmpKva%3D7nJHvANOUSW5uWHUDAg%2BvZC-ow%40mail.gmail.com.

Re: [go-nuts] Re: package-level structs vs package-level vars

[B Carr]

On Monday, August 5, 2019 at 9:33:08 AM UTC-6, burak serdar wrote:
>
> On Mon, Aug 5, 2019 at 9:20 AM B Carr > 
> wrote: 
> > 
> > Oh. I'm talking about env variables which a goroutine sets by using 
> os.Setenv() which to me implies OS env variables. Are those env variables 
> accessible by all goroutines regardless of which goroutine set the env 
> variable? Would such env variables be available to newer goroutines that 
> spin up? I think the answer to this is "Yes", based on a response I got to 
> another thread. 
>
> Those env variables belong to the process. All gorountines share them. 
> If you're setting env variables from goroutines, you might want to 
> think about thread safety of setenv.


Oh yes. I'm using a mutex.

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7fd673ac-cc05-401d-ba6f-e07151fd6ab3%40googlegroups.com.

[go-nuts] Replace modules from command line

[Peter Feichtinger]

Hi Go Nuts,

I have a rather unusual use case and I'm hoping for some input.

For testing purposes, I want to build a Go binary with different versions 
of one of its dependencies. The only way I could think of was to modify the 
go.mod file to add a replace directive with the version I want to test.
Instead I'd like to avoid having to modify the go.mod file during the build 
and specify the replacement on the command line instead, but I don't think 
that's possible.

Do you guys have any ideas on how else I might accomplish overriding a 
module version during build?

-- Peter

-- 
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/efc91729-47a6-4dcb-a08d-6c907b24bd56%40googlegroups.com.

Re: [go-nuts] Replace modules from command line

[Paul Jolly]

Take a look at go mod edit

https://golang.org/cmd/go/#hdr-Module_maintenance



On Mon, 5 Aug 2019, 18:45 Peter Feichtinger,  wrote:

> Hi Go Nuts,
>
> I have a rather unusual use case and I'm hoping for some input.
>
> For testing purposes, I want to build a Go binary with different versions
> of one of its dependencies. The only way I could think of was to modify the
> go.mod file to add a replace directive with the version I want to test.
> Instead I'd like to avoid having to modify the go.mod file during the
> build and specify the replacement on the command line instead, but I don't
> think that's possible.
>
> Do you guys have any ideas on how else I might accomplish overriding a
> module version during build?
>
> -- Peter
>
> --
> 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/efc91729-47a6-4dcb-a08d-6c907b24bd56%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn5Hk9rG7%3DvzmH6voFuGxBH0W_BCDT9uwwZ2OHkpeVC%3D%2Bg%40mail.gmail.com.

[go-nuts] Does module name has to start with a valid domain name?

[isulsz1]

Hi, 
We are using bazel to manage dependency and would like to migrate to 
modules and use JFrog's module proxy. We have many private modules, starts 
with a name like "foo", and we specify the internal git repo in bazel. 
Based on the understanding of module proxy protocol, as long as the proxy 
response to GET requests like GET $GOPROXY/foo/@v/, it should work. The 
first part of the module name does not have to a domain name. However, when 
we try it, we do see error message complaining the missing dot in the first 
section. We looked into the source code module.go and there is a CheckPath 
function to make sure the first section looks like a domain name. Is it 
really required? I hope to hear opinions from Go team. Is the check going 
to be there forever? Or it may be removed in the future? 

Thanks,
Shizheng

-- 
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/dc9104c6-7735-4c42-8e05-ffdfb80e3f93%40googlegroups.com.

Re: [go-nuts] Does module name has to start with a valid domain name?

[Ian Lance Taylor]

On Mon, Aug 5, 2019 at 12:33 PM  wrote:
>
> We are using bazel to manage dependency and would like to migrate to modules 
> and use JFrog's module proxy. We have many private modules, starts with a 
> name like "foo", and we specify the internal git repo in bazel. Based on the 
> understanding of module proxy protocol, as long as the proxy response to GET 
> requests like GET $GOPROXY/foo/@v/, it should work. The first part of the 
> module name does not have to a domain name. However, when we try it, we do 
> see error message complaining the missing dot in the first section. We looked 
> into the source code module.go and there is a CheckPath function to make sure 
> the first section looks like a domain name. Is it really required? I hope to 
> hear opinions from Go team. Is the check going to be there forever? Or it may 
> be removed in the future?

It doesn't have to be a valid domain name but I believe that it does
have to contain a dot.  Names without a dot are in effect reserved for
the Go standard library.

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/CAOyqgcXHFZanu6afqwYicQmrhQQ4C0Z%3Daguga32sB2sj-eTeCA%40mail.gmail.com.

[go-nuts] Upgrade to Go1.12.7 problem

[Shane H]

Hi all,

I've done a bit of searching, and asked around, but not found an answer to 
my (most likely self-inflicted) problem.

I have been coding with Go 1.10 and 1.11 for a whiles, but I decided that 
it was time to join the future and upgraded to 1.12. It worked fine for the 
project I was creating at the time, but after some time (long enough for me 
to forget the steps I took to upgrade!) I discovered issues with my install.

I've tried to reinstall (Ubuntu, apt purge golang-1.* ) and reinstall, to 
no avail.

I need to know what I can check to stop this behaviour, sans reinstalling 
the OS

This is probably best demonstrated as:
shane@desktop ~/GoLang/src/github.com/ipfs/go-ipfs (master) $ make build
go version go1.12.7 linux/amd64
bin/check_go_version 1.12
go build  "-asmflags=all='-trimpath=/home/shane/GoLang'" 
"-gcflags=all='-trimpath=/home/shane/GoLang'" -ldflags="-X 
"github.com/ipfs/go-ipfs".CurrentCommit=641d9f6b0-dirty" -o "cmd/ipfs/ipfs" 
"github.com/ipfs/go-ipfs/cmd/ipfs"
/usr/local/go/src/crypto/tls/cipher_suites.go:18:2: unknown import path 
"golang_org/x/crypto/chacha20poly1305": cannot find module providing 
package golang_org/x/crypto/chacha20poly1305
/usr/local/go/src/crypto/x509/x509.go:36:2: unknown import path 
"golang_org/x/crypto/cryptobyte": cannot find module providing package 
golang_org/x/crypto/cryptobyte
/usr/local/go/src/crypto/x509/x509.go:37:2: unknown import path 
"golang_org/x/crypto/cryptobyte/asn1": cannot find module providing package 
golang_org/x/crypto/cryptobyte/asn1
/usr/local/go/src/crypto/tls/key_agreement.go:18:2: unknown import path 
"golang_org/x/crypto/curve25519": cannot find module providing package 
golang_org/x/crypto/curve25519
/usr/local/go/src/net/dnsclient.go:11:2: unknown import path 
"golang_org/x/net/dns/dnsmessage": cannot find module providing package 
golang_org/x/net/dns/dnsmessage
/usr/local/go/src/net/http/h2_bundle.go:47:2: unknown import path 
"golang_org/x/net/http/httpguts": cannot find module providing package 
golang_org/x/net/http/httpguts
/usr/local/go/src/net/http/transport.go:34:2: unknown import path 
"golang_org/x/net/http/httpproxy": cannot find module providing package 
golang_org/x/net/http/httpproxy
/usr/local/go/src/net/http/h2_bundle.go:48:2: unknown import path 
"golang_org/x/net/http2/hpack": cannot find module providing package 
golang_org/x/net/http2/hpack
/usr/local/go/src/net/http/h2_bundle.go:49:2: unknown import path 
"golang_org/x/net/idna": cannot find module providing package 
golang_org/x/net/idna
cmd/ipfs/Rules.mk:22: recipe for target 'cmd/ipfs/ipfs' failed
make: *** [cmd/ipfs/ipfs] Error 1


$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/shane/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/shane/GoLang"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build529069743=/tmp/go-build 
-gno-record-gcc-switches"


The issue is now showing up in my vim, golangci-lint is complaining of 
errors
/usr/local/go/src/net/dnsclient.go|11 col 2| could not import 
golang_org/x/net/dns/dnsmessage (invalid package name: "")

-- 
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/1578e939-7aa9-4bb6-ba09-f0405f98b5ce%40googlegroups.com.

Re: [go-nuts] Does module name has to start with a valid domain name?

[SZ Li]

I see. Makes sense.

Thanks,
Shizheng

On Mon, Aug 5, 2019 at 7:04 PM Ian Lance Taylor  wrote:

> On Mon, Aug 5, 2019 at 12:33 PM  wrote:
> >
> > We are using bazel to manage dependency and would like to migrate to
> modules and use JFrog's module proxy. We have many private modules, starts
> with a name like "foo", and we specify the internal git repo in bazel.
> Based on the understanding of module proxy protocol, as long as the proxy
> response to GET requests like GET $GOPROXY/foo/@v/, it should work. The
> first part of the module name does not have to a domain name. However, when
> we try it, we do see error message complaining the missing dot in the first
> section. We looked into the source code module.go and there is a CheckPath
> function to make sure the first section looks like a domain name. Is it
> really required? I hope to hear opinions from Go team. Is the check going
> to be there forever? Or it may be removed in the future?
>
> It doesn't have to be a valid domain name but I believe that it does
> have to contain a dot.  Names without a dot are in effect reserved for
> the Go standard library.
>
> 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/CABkpyAWL9Y20Kj0kaxyB%3D2zJeC_u5u_gSD68W0dhg7q4D%3DpAZQ%40mail.gmail.com.

[go-nuts] Re: Upgrade to Go1.12.7 problem

[Shane H]

On Tuesday, August 6, 2019 at 10:56:42 AM UTC+10, Shane H wrote:
>
> Hi all,
>
> I've done a bit of searching, and asked around, but not found an answer to 
> my (most likely self-inflicted) problem.
>
> I have been coding with Go 1.10 and 1.11 for a whiles, but I decided that 
> it was time to join the future and upgraded to 1.12. It worked fine for the 
> project I was creating at the time, but after some time (long enough for me 
> to forget the steps I took to upgrade!) I discovered issues with my install.
>
> I've tried to reinstall (Ubuntu, apt purge golang-1.* ) and reinstall, to 
> no avail.
>
> I need to know what I can check to stop this behaviour, sans reinstalling 
> the OS
>
> This is probably best demonstrated as:
> shane@desktop ~/GoLang/src/github.com/ipfs/go-ipfs (master) $ make build
> go version go1.12.7 linux/amd64
> bin/check_go_version 1.12
> go build  "-asmflags=all='-trimpath=/home/shane/GoLang'" 
> "-gcflags=all='-trimpath=/home/shane/GoLang'" -ldflags="-X "
> github.com/ipfs/go-ipfs".CurrentCommit=641d9f6b0-dirty" -o 
> "cmd/ipfs/ipfs" "github.com/ipfs/go-ipfs/cmd/ipfs"
> /usr/local/go/src/crypto/tls/cipher_suites.go:18:2: unknown import path 
> "golang_org/x/crypto/chacha20poly1305": cannot find module providing 
> package golang_org/x/crypto/chacha20poly1305
> /usr/local/go/src/crypto/x509/x509.go:36:2: unknown import path 
> "golang_org/x/crypto/cryptobyte": cannot find module providing package 
> golang_org/x/crypto/cryptobyte
> /usr/local/go/src/crypto/x509/x509.go:37:2: unknown import path 
> "golang_org/x/crypto/cryptobyte/asn1": cannot find module providing package 
> golang_org/x/crypto/cryptobyte/asn1
> /usr/local/go/src/crypto/tls/key_agreement.go:18:2: unknown import path 
> "golang_org/x/crypto/curve25519": cannot find module providing package 
> golang_org/x/crypto/curve25519
> /usr/local/go/src/net/dnsclient.go:11:2: unknown import path 
> "golang_org/x/net/dns/dnsmessage": cannot find module providing package 
> golang_org/x/net/dns/dnsmessage
> /usr/local/go/src/net/http/h2_bundle.go:47:2: unknown import path 
> "golang_org/x/net/http/httpguts": cannot find module providing package 
> golang_org/x/net/http/httpguts
> /usr/local/go/src/net/http/transport.go:34:2: unknown import path 
> "golang_org/x/net/http/httpproxy": cannot find module providing package 
> golang_org/x/net/http/httpproxy
> /usr/local/go/src/net/http/h2_bundle.go:48:2: unknown import path 
> "golang_org/x/net/http2/hpack": cannot find module providing package 
> golang_org/x/net/http2/hpack
> /usr/local/go/src/net/http/h2_bundle.go:49:2: unknown import path 
> "golang_org/x/net/idna": cannot find module providing package 
> golang_org/x/net/idna
> cmd/ipfs/Rules.mk:22: recipe for target 'cmd/ipfs/ipfs' failed
> make: *** [cmd/ipfs/ipfs] Error 1
>
>
> $ go env
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/shane/.cache/go-build"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/shane/GoLang"
> GOPROXY=""
> GORACE=""
> GOROOT="/usr/local/go"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD=""
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build529069743=/tmp/go-build 
> -gno-record-gcc-switches"
>  
>

> The issue is now showing up in my vim, golangci-lint is complaining of 
> errors
> /usr/local/go/src/net/dnsclient.go|11 col 2| could not import 
> golang_org/x/net/dns/dnsmessage (invalid package name: "")
>

When I try to upgrade my gopls server I get
$ env GO111MODULE=on go get golang.org/x/tools/gopls@latest
go: finding golang.org/x/tools/gopls v0.1.3
go: finding golang.org/x/tools v0.0.0-20190710153321-831012c29e42
go: finding golang.org/x/net v0.0.0-20190620200207-3b0461eec859
go: finding golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
go: finding golang.org/x/text v0.3.0
go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
go: downloading golang.org/x/tools v0.0.0-20190710153321-831012c29e42
go: extracting golang.org/x/tools v0.0.0-20190710153321-831012c29e42
go: downloading golang.org/x/tools/gopls v0.1.3
go: extracting golang.org/x/tools/gopls v0.1.3
go: downloading golang.org/x/sync v0.0.0-20190423024810-112230192c58
go: extracting golang.org/x/sync v0.0.0-20190423024810-112230192c58
# errors
compile: version "go1.11" does not match go tool version "go1.12.7"
# runtime/internal/sys
compile: version "go1.11" does not match go tool version "go1.12.7"
# internal/race
compile: version "go1.11" does not match go tool version "go1.12.7"
# runtime/internal/atomic
flag provided but not defined: -gensymabis
usage: asm [options] file.s ... 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-

[go-nuts] Re: Upgrade to Go1.12.7 problem [SOLVED]

[Shane H]

On Tuesday, August 6, 2019 at 11:31:40 AM UTC+10, Shane H wrote:
>
>
>
> On Tuesday, August 6, 2019 at 10:56:42 AM UTC+10, Shane H wrote:
>>
>> Hi all,
>>
>> I've done a bit of searching, and asked around, but not found an answer 
>> to my (most likely self-inflicted) problem.
>>
>> I have been coding with Go 1.10 and 1.11 for a whiles, but I decided that 
>> it was time to join the future and upgraded to 1.12. It worked fine for the 
>> project I was creating at the time, but after some time (long enough for me 
>> to forget the steps I took to upgrade!) I discovered issues with my install.
>>
>> I've tried to reinstall (Ubuntu, apt purge golang-1.* ) and reinstall, to 
>> no avail.
>>
>> I need to know what I can check to stop this behaviour, sans reinstalling 
>> the OS
>>
>> This is probably best demonstrated as:
>> shane@desktop ~/GoLang/src/github.com/ipfs/go-ipfs (master) $ make build
>> go version go1.12.7 linux/amd64
>> bin/check_go_version 1.12
>> go build  "-asmflags=all='-trimpath=/home/shane/GoLang'" 
>> "-gcflags=all='-trimpath=/home/shane/GoLang'" -ldflags="-X "
>> github.com/ipfs/go-ipfs".CurrentCommit=641d9f6b0-dirty" -o 
>> "cmd/ipfs/ipfs" "github.com/ipfs/go-ipfs/cmd/ipfs"
>> /usr/local/go/src/crypto/tls/cipher_suites.go:18:2: unknown import path 
>> "golang_org/x/crypto/chacha20poly1305": cannot find module providing 
>> package golang_org/x/crypto/chacha20poly1305
>> /usr/local/go/src/crypto/x509/x509.go:36:2: unknown import path 
>> "golang_org/x/crypto/cryptobyte": cannot find module providing package 
>> golang_org/x/crypto/cryptobyte
>> /usr/local/go/src/crypto/x509/x509.go:37:2: unknown import path 
>> "golang_org/x/crypto/cryptobyte/asn1": cannot find module providing package 
>> golang_org/x/crypto/cryptobyte/asn1
>> /usr/local/go/src/crypto/tls/key_agreement.go:18:2: unknown import path 
>> "golang_org/x/crypto/curve25519": cannot find module providing package 
>> golang_org/x/crypto/curve25519
>> /usr/local/go/src/net/dnsclient.go:11:2: unknown import path 
>> "golang_org/x/net/dns/dnsmessage": cannot find module providing package 
>> golang_org/x/net/dns/dnsmessage
>> /usr/local/go/src/net/http/h2_bundle.go:47:2: unknown import path 
>> "golang_org/x/net/http/httpguts": cannot find module providing package 
>> golang_org/x/net/http/httpguts
>> /usr/local/go/src/net/http/transport.go:34:2: unknown import path 
>> "golang_org/x/net/http/httpproxy": cannot find module providing package 
>> golang_org/x/net/http/httpproxy
>> /usr/local/go/src/net/http/h2_bundle.go:48:2: unknown import path 
>> "golang_org/x/net/http2/hpack": cannot find module providing package 
>> golang_org/x/net/http2/hpack
>> /usr/local/go/src/net/http/h2_bundle.go:49:2: unknown import path 
>> "golang_org/x/net/idna": cannot find module providing package 
>> golang_org/x/net/idna
>> cmd/ipfs/Rules.mk:22: recipe for target 'cmd/ipfs/ipfs' failed
>> make: *** [cmd/ipfs/ipfs] Error 1
>>
>>
>> $ go env
>> GOARCH="amd64"
>> GOBIN=""
>> GOCACHE="/home/shane/.cache/go-build"
>> GOEXE=""
>> GOFLAGS=""
>> GOHOSTARCH="amd64"
>> GOHOSTOS="linux"
>> GOOS="linux"
>> GOPATH="/home/shane/GoLang"
>> GOPROXY=""
>> GORACE=""
>> GOROOT="/usr/local/go"
>> GOTMPDIR=""
>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>> GCCGO="gccgo"
>> CC="gcc"
>> CXX="g++"
>> CGO_ENABLED="1"
>> GOMOD=""
>> CGO_CFLAGS="-g -O2"
>> CGO_CPPFLAGS=""
>> CGO_CXXFLAGS="-g -O2"
>> CGO_FFLAGS="-g -O2"
>> CGO_LDFLAGS="-g -O2"
>> PKG_CONFIG="pkg-config"
>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=/tmp/go-build529069743=/tmp/go-build 
>> -gno-record-gcc-switches"
>>  
>>
>
>> The issue is now showing up in my vim, golangci-lint is complaining of 
>> errors
>> /usr/local/go/src/net/dnsclient.go|11 col 2| could not import 
>> golang_org/x/net/dns/dnsmessage (invalid package name: "")
>>
>
> When I try to upgrade my gopls server I get
> $ env GO111MODULE=on go get golang.org/x/tools/gopls@latest
> go: finding golang.org/x/tools/gopls v0.1.3
> go: finding golang.org/x/tools v0.0.0-20190710153321-831012c29e42
> go: finding golang.org/x/net v0.0.0-20190620200207-3b0461eec859
> go: finding golang.org/x/sync v0.0.0-20190423024810-112230192c58
> go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
> go: finding golang.org/x/text v0.3.0
> go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
> go: downloading golang.org/x/tools v0.0.0-20190710153321-831012c29e42
> go: extracting golang.org/x/tools v0.0.0-20190710153321-831012c29e42
> go: downloading golang.org/x/tools/gopls v0.1.3
> go: extracting golang.org/x/tools/gopls v0.1.3
> go: downloading golang.org/x/sync v0.0.0-20190423024810-112230192c58
> go: extracting golang.org/x/sync v0.0.0-20190423024810-112230192c58
> # errors
> compile: version "go1.11" does not match go tool version "go1.12.7"
> # runtime/internal/sys
> compile: version "go1.11" does not match go tool version "go1.12.7"
> # internal/race
> compile: version "go1.11" does not match go tool 

Re: [go-nuts] Does module name has to start with a valid domain name?

[isulsz1]

Actually, one more thought. If we require to contain a dot, should we apply 
this check to the module name appears on the first line of the go.mod file? 
Currently I think the check is applied to the modules listed in "require" 
list, that means, I can define a module "foo", but not able to refer to it. 
So perhaps I shouldn't be allowed to define module foo at the first place. 

Thanks,
Shizheng

On Monday, August 5, 2019 at 7:05:07 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Aug 5, 2019 at 12:33 PM > wrote: 
> > 
> > We are using bazel to manage dependency and would like to migrate to 
> modules and use JFrog's module proxy. We have many private modules, starts 
> with a name like "foo", and we specify the internal git repo in bazel. 
> Based on the understanding of module proxy protocol, as long as the proxy 
> response to GET requests like GET $GOPROXY/foo/@v/, it should work. The 
> first part of the module name does not have to a domain name. However, when 
> we try it, we do see error message complaining the missing dot in the first 
> section. We looked into the source code module.go and there is a CheckPath 
> function to make sure the first section looks like a domain name. Is it 
> really required? I hope to hear opinions from Go team. Is the check going 
> to be there forever? Or it may be removed in the future? 
>
> It doesn't have to be a valid domain name but I believe that it does 
> have to contain a dot.  Names without a dot are in effect reserved for 
> the Go standard library. 
>
> 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/d21b9145-77fd-4a6b-bbcf-c37f5d0d%40googlegroups.com.

[go-nuts] Question re fcns that return multiple values

[lgodio2]

For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..} 
and f2 defined as func f2(x,y int)   (xR int)   {..} 

Why does the compiler complain about the call stmt 
f2 ( f1 (1,2,3)  )   ??

-- 
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/a2400f69-29f6-4f9c-92ab-c9dd763cb311%40googlegroups.com.

Re: [go-nuts] Question re fcns that return multiple values

[Adrian Ho]

On 6/8/19 11:38 AM, lgod...@gmail.com wrote:
> For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..} 
> and f2 defined as func f2(x,y int)           (xR int)       {..} 
>
> Why does the compiler complain about the call stmt 
> f2 ( f1 (1,2,3)  )   ??
>
It shouldn't. What little you posted is perfectly legal in Go:
https://play.golang.org/p/CHx9_LQCCEx

Something else is wrong with your code, methinks.

-- 
Best Regards,
Adrian

-- 
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/52e36d01-3558-e9aa-a71b-808ceb59b2d1%4003s.net.

Re: [go-nuts] Question re fcns that return multiple values

[Jesse McNelis]

On Tue, Aug 6, 2019 at 1:38 PM  wrote:

> For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..}
> and f2 defined as func f2(x,y int)   (xR int)   {..}
>
> Why does the compiler complain about the call stmt
> f2 ( f1 (1,2,3)  )   ??
>

I'm not sure what you're asking.
The compiler doesn't complain about this.
eg https://play.golang.org/p/0OKIsPLTipz

-- 
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/CAAuPoqfoqdNGAxR6CRXOfru7sczR1a5hjBxP2qM2XeMFe3c-TQ%40mail.gmail.com.

Re: [go-nuts] Upgrade to Go1.12.7 problem

[Ian Lance Taylor]

On Mon, Aug 5, 2019 at 5:56 PM Shane H  wrote:
>
> I've done a bit of searching, and asked around, but not found an answer to my 
> (most likely self-inflicted) problem.
>
> I have been coding with Go 1.10 and 1.11 for a whiles, but I decided that it 
> was time to join the future and upgraded to 1.12. It worked fine for the 
> project I was creating at the time, but after some time (long enough for me 
> to forget the steps I took to upgrade!) I discovered issues with my install.
>
> I've tried to reinstall (Ubuntu, apt purge golang-1.* ) and reinstall, to no 
> avail.
>
> I need to know what I can check to stop this behaviour, sans reinstalling the 
> OS
>
> This is probably best demonstrated as:
> shane@desktop ~/GoLang/src/github.com/ipfs/go-ipfs (master) $ make build
> go version go1.12.7 linux/amd64
> bin/check_go_version 1.12
> go build  "-asmflags=all='-trimpath=/home/shane/GoLang'" 
> "-gcflags=all='-trimpath=/home/shane/GoLang'" -ldflags="-X 
> "github.com/ipfs/go-ipfs".CurrentCommit=641d9f6b0-dirty" -o "cmd/ipfs/ipfs" 
> "github.com/ipfs/go-ipfs/cmd/ipfs"
> /usr/local/go/src/crypto/tls/cipher_suites.go:18:2: unknown import path 
> "golang_org/x/crypto/chacha20poly1305": cannot find module providing package 
> golang_org/x/crypto/chacha20poly1305
> /usr/local/go/src/crypto/x509/x509.go:36:2: unknown import path 
> "golang_org/x/crypto/cryptobyte": cannot find module providing package 
> golang_org/x/crypto/cryptobyte
> /usr/local/go/src/crypto/x509/x509.go:37:2: unknown import path 
> "golang_org/x/crypto/cryptobyte/asn1": cannot find module providing package 
> golang_org/x/crypto/cryptobyte/asn1
> /usr/local/go/src/crypto/tls/key_agreement.go:18:2: unknown import path 
> "golang_org/x/crypto/curve25519": cannot find module providing package 
> golang_org/x/crypto/curve25519
> /usr/local/go/src/net/dnsclient.go:11:2: unknown import path 
> "golang_org/x/net/dns/dnsmessage": cannot find module providing package 
> golang_org/x/net/dns/dnsmessage
> /usr/local/go/src/net/http/h2_bundle.go:47:2: unknown import path 
> "golang_org/x/net/http/httpguts": cannot find module providing package 
> golang_org/x/net/http/httpguts
> /usr/local/go/src/net/http/transport.go:34:2: unknown import path 
> "golang_org/x/net/http/httpproxy": cannot find module providing package 
> golang_org/x/net/http/httpproxy
> /usr/local/go/src/net/http/h2_bundle.go:48:2: unknown import path 
> "golang_org/x/net/http2/hpack": cannot find module providing package 
> golang_org/x/net/http2/hpack
> /usr/local/go/src/net/http/h2_bundle.go:49:2: unknown import path 
> "golang_org/x/net/idna": cannot find module providing package 
> golang_org/x/net/idna
> cmd/ipfs/Rules.mk:22: recipe for target 'cmd/ipfs/ipfs' failed
> make: *** [cmd/ipfs/ipfs] Error 1

This looks like you unpacked a Go distribution into a directory that
already held another Go distribution.  Always unpack a Go distribution
into an empty directory.

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/CAOyqgcVLy8VQ%3DXM7mbfj4GdKo_oS%3D6CX6Ru%2BJDYRm_RPrv_F5g%40mail.gmail.com.

Re: [go-nuts] Replace modules from command line

[Peter Feichtinger]

Thanks for that, this will come in handy for editing the go.mod file.
But I'd like to avoid editing the file at all.


On Monday, August 5, 2019 at 7:16:08 PM UTC+2, Paul Jolly wrote:
>
> Take a look at go mod edit
>
> https://golang.org/cmd/go/#hdr-Module_maintenance
>
>
>
> On Mon, 5 Aug 2019, 18:45 Peter Feichtinger, > 
> wrote:
>
>> Hi Go Nuts,
>>
>> I have a rather unusual use case and I'm hoping for some input.
>>
>> For testing purposes, I want to build a Go binary with different versions 
>> of one of its dependencies. The only way I could think of was to modify the 
>> go.mod file to add a replace directive with the version I want to test.
>> Instead I'd like to avoid having to modify the go.mod file during the 
>> build and specify the replacement on the command line instead, but I don't 
>> think that's possible.
>>
>> Do you guys have any ideas on how else I might accomplish overriding a 
>> module version during build?
>>
>> -- Peter
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/efc91729-47a6-4dcb-a08d-6c907b24bd56%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6ced2780-eca5-4692-a7f6-c0c73ad5b966%40googlegroups.com.