Re: [go-nuts] Re: golang program use a lot memory

[Pawel Zadrozny]

Please take a look at this article 
https://blog.learngoprogramming.com/a-visual-guide-to-golang-memory-allocator-from-ground-up-e132258453ed
TOP will show you all virtual memory which kernel reserved for 
application, not a memory used by application.


On 27.02.2019 10:20, Lee Rick wrote:



在 2019年2月27日星期三 UTC+8下午5:18:34，Lee Rick写道：

go1.12

i have 89936 records in mongodb, when i write a go program to load
data and profile it, i find it wrong
the size of 89936 records is about 85MB,  go profile it use 100MB,
and use linux command top, the res is about 300MB
go program shoud use 100MB memory, but it use 300MB

my go code in attachment

anyone can tell me how reduce memory to 100MB

1.jpg

2.jpg

3.jpg









--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--


---
The information in this email is 
confidential and may be legally privileged, it may contain information that 
is confidential in CodiLime Sp. z o. o. It is intended solely for the 
addressee. Any access to this email by third parties is unauthorized. If 
you are not the intended recipient of this message, any disclosure, 
copying, distribution or any action undertaken or neglected in reliance 
thereon is prohibited and may result in your liability for damages.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.12 with Modules enabled leading to compilation error during tests - wehre as all is OK without modules enabled

[Stephane Moreau]

Indeed, this is what I just checked this morning and saw whil generating 
coverage info on a "per package" basis
I'll check the issue status over the next weeks

Thanks for your help
Best regards

Le jeudi 28 février 2019 01:07:55 UTC+1, Krzysztof Kowalczyk a écrit :
>
> https://github.com/golang/go/issues/30374 seems to be the issue and 
> apparently, there's a workaround:
>
> > The workaround for now is to include at most one `main` package in the 
> `-coverpkg` arguments, or to run coverage in `GOPATH` mode.
>
>
>
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.12 with Modules enabled leading to compilation error during tests - wehre as all is OK without modules enabled

[Krzysztof Kowalczyk]

https://github.com/golang/go/issues/30374 seems to be the issue and 
apparently, there's a workaround:

> The workaround for now is to include at most one `main` package in the 
`-coverpkg` arguments, or to run coverage in `GOPATH` mode.




On Wednesday, February 27, 2019 at 6:01:33 AM UTC-8, Stephane Moreau wrote:
>
> Hello,
>
> Just after the new release of go 1.12, I migrated my project to use the 
> new version.
> Every thing went fine so far, all tests and code coverage reports were 
> generated accruately just like before.
>
> Once done I activated GO111MODULE option to get rid of the dep dependency 
> manager we were using before, but now CI fails
>
> At this point I get an error during my CI process (CI is run within a 
> docer image golang1.12:alpine3.9)
> 2019/02/27 14:15:40 duplicate symbol runtime/debug.modinfo (types 30 and 
> 30) in /cmd/apiserver and $WORK\b593\_pkg_.a(_go_.o)
>
> I managed to reproduce the very same issue on my windows desktop:
>
> If I run
> go test -count=1 -cover --coverpkg=all ./cache/...
> Everything goes fine and I do get the expected results
>
> If I run 
> go test -count=1 ./...
> I get it working fine too:
> ?   /cache   [no test files]
> ok  /cache/memory0.660s
>
>
> If I run 
> go test -count=1 -cover --coverpkg=all ./...
> I get :
> ?   /cache   [no test files]
> # /cache/memory.test
> 2019/02/27 14:31:55 duplicate symbol runtime/debug.modinfo (types 30 and 
> 30) in /cmd/apiserver and 
> C:\Users\steph\AppData\Local\go-build\5e\5e2f041c975bf4971f8b073ef3a2ceadb95d3c87d8b02241aa6a393d3c5a7632-d(_go_.o)
> FAIL/cache/memory [build failed]
>
> Any advice on what I'm doing wrong here ?
>
> Some more insight on the environment
>
> go version
> go version go1.12 windows/amd64
>
> go env
> set GOARCH=amd64
> set GOBIN=
> set GOCACHE=C:\Users\steph\AppData\Local\go-build
> set GOEXE=.exe
> set GOFLAGS=
> set GOHOSTARCH=amd64
> set GOHOSTOS=windows
> set GOOS=windows
> set GOPATH=C:\dev\source\catapult/go
> set GOPROXY=
> set GORACE=
> set GOROOT=C:\dev\tools\go1.12
> set GOTMPDIR=
> set GOTOOLDIR=C:\dev\tools\go1.12\pkg\tool\windows_amd64
> set GCCGO=gccgo
> set CC=gcc
> set CXX=g++
> set CGO_ENABLED=1
> set GOMOD=C:\dev\source\catapult\go\src\\go.mod
> set CGO_CFLAGS=-g -O2
> set CGO_CPPFLAGS=
> set CGO_CXXFLAGS=-g -O2
> set CGO_FFLAGS=-g -O2
> set CGO_LDFLAGS=-g -O2
> set PKG_CONFIG=pkg-config
> set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 
> -fdebug-prefix-map=C:\Users\steph\AppData\Local\Temp\go-build245172374=/tmp/go-build
>  
> -gno-record-gcc-switches
>
>
> modules used :
>
> module 
>
> go 1.12
>
> require (
> cloud.google.com/go v0.26.0
> contrib.go.opencensus.io/exporter/stackdriver v0.6.0 // indirect
> github.com/BurntSushi/toml v0.3.1 // indirect
> github.com/GoogleCloudPlatform/google-cloud-go v0.28.0
> github.com/bcicen/jstream v0.0.0-20190206022353-f306cd3e1fa6
> github.com/bxcodec/faker v2.0.1+incompatible
> github.com/elazarl/go-bindata-assetfs v0.0.0-20180223160309-38087fe4dafb
> github.com/ghodss/yaml v1.0.0 // indirect
> github.com/go-ini/ini v1.41.0 // indirect
> github.com/gogo/protobuf v1.1.1 // indirect
> github.com/golang/groupcache v0.0.0-20190129154638-5b532d6fd5ef // 
> indirect
> github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db // indirect
> github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c // indirect
> github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // indirect
> github.com/google/martian v2.1.0+incompatible // indirect
> github.com/googleapis/gax-go v2.0.0+incompatible // indirect
> github.com/googleapis/gnostic v0.2.0 // indirect
> github.com/gorilla/websocket v1.4.0
> github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7 // 
> indirect
> github.com/hashicorp/golang-lru v0.5.0 // indirect
> github.com/imdario/mergo v0.3.6 // indirect
> github.com/inconshreveable/mousetrap v1.0.0 // indirect
> github.com/json-iterator/go v1.1.5 // indirect
> github.com/kr/fs v0.1.0 // indirect
> github.com/lib/pq v1.0.0
> github.com/minio/minio-go v6.0.13+incompatible
> github.com/mitchellh/go-homedir v1.0.0 // indirect
> github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // 
> indirect
> github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742 // 
> indirect
> github.com/mongodb/mongo-go-driver v0.0.17
> github.com/nats-io/gnatsd v1.4.1 // indirect
> github.com/nats-io/go-nats v1.6.0
> github.com/nats-io/nuid v1.0.0 // indirect
> github.com/nimajalali/go-force v0.0.0-20180615191228-2b94c45dfae2
> github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
> github.com/pkg/errors v0.8.0
> github.com/pkg/sftp v1.8.3
> github.com/pmezard/go-difflib v1.0.0 // indirect
> github.com/rs/xid v1.2.1 // indirect
> github.com/rs/zerolog v1.9.1
> github.com/santhosh-tekuri/jsonschema v1.2.2
> github.com/smartystreets/goconvey v0.0.0-2019023459-a17d461953aa // 
> indirect
> github.com/spf13/cast v1.2.0
> github.com/spf13/cobra v0.0.3
> github.com/spf13/pflag v1.0.2
> 

Re: [go-nuts] Is Go a single pass compiler?

[Rob Pike]

The Go compiler was single pass until we allowed use before declaration.

-rob


On Thu, Feb 28, 2019 at 10:46 AM  wrote:

> Thanks, Ian.
>
> I remember reading in some compiler book that languages should be designed
> for a single pass to reduce compilation speed.
>
> Go proves that wrong :) It's amazingly fast, looks like computers are
> pretty good at traversing AST trees.
>
> On Wednesday, February 27, 2019 at 11:50:05 PM UTC+1, Ian Lance Taylor
> wrote:
>>
>> On Wed, Feb 27, 2019 at 2:42 PM  wrote:
>> >
>> > In Go functions can be used before they are defined, but as I
>> understand, it's still possible to have a single pass compiler.
>>
>> I don't think it's possible to compile Go in a single pass compiler,
>> unless you consider a separate parsing and code generation step to be
>> a single pass compiler.  In the general case, you can't generate code
>> for any Go function until you've seen all the functions in the
>> package.
>>
>> There are multiple Go compilers.  All the ones I am aware of are have
>> many passes.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is Go a single pass compiler?

[ivan . medoedov]

Thanks, Ian.

I remember reading in some compiler book that languages should be designed 
for a single pass to reduce compilation speed.

Go proves that wrong :) It's amazingly fast, looks like computers are 
pretty good at traversing AST trees.

On Wednesday, February 27, 2019 at 11:50:05 PM UTC+1, Ian Lance Taylor 
wrote:
>
> On Wed, Feb 27, 2019 at 2:42 PM > 
> wrote: 
> > 
> > In Go functions can be used before they are defined, but as I 
> understand, it's still possible to have a single pass compiler. 
>
> I don't think it's possible to compile Go in a single pass compiler, 
> unless you consider a separate parsing and code generation step to be 
> a single pass compiler.  In the general case, you can't generate code 
> for any Go function until you've seen all the functions in the 
> package. 
>
> There are multiple Go compilers.  All the ones I am aware of are have 
> many passes. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is Go a single pass compiler?

[Ian Lance Taylor]

On Wed, Feb 27, 2019 at 2:42 PM  wrote:
>
> In Go functions can be used before they are defined, but as I understand, 
> it's still possible to have a single pass compiler.

I don't think it's possible to compile Go in a single pass compiler,
unless you consider a separate parsing and code generation step to be
a single pass compiler.  In the general case, you can't generate code
for any Go function until you've seen all the functions in the
package.

There are multiple Go compilers.  All the ones I am aware of are have
many passes.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is Go a single pass compiler?

[ivan . medoedov]

Hello,

In Go functions can be used before they are defined, but as I understand, 
it's still possible to have a single pass compiler. 

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Dan Kortschak]

Please read https://golang.org/conduct

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] sync/atomic suggestion

[Ian Lance Taylor]

On Wed, Feb 27, 2019 at 12:46 PM Serhat Şevki Dinçer  wrote:
>
> I would like to update a counter up to a certain limit atomically, without 
> using a channel or mutex. What do you think of the following (equivalent) 
> functions for sync/atomic?
>
> func CompareAndInc(*addr, Max) bool {
>
>   if *addr < Max {
> *addr++
> return true
>   }
>   return false
> }
>
> func CompareAndDec(*addr, Min) bool {
>
>   if *addr > Min {
> *addr--
> return true
>   }
>   return false
> }

I think they are too special purpose for sync/atomic.  You can write
your own versions using CompareAndSwap.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

I could, of course, however I never did. And I'd like to keep myself out of
the scope of discussion. If you re-read my messages, you'll find they were
focused on topic, not shifting to persons. Thank you for your
participation, it's always good to hear different opinions, even if they
are not correct.

ср, 27 февр. 2019 г. в 23:35, Dan Kortschak :

> You're claiming expertise in copyright law in at least two
> jurisdictions, and claiming greater understanding of Australian
> copyright legislation than a person who has had training in Australian
> copyright legislation as part of their employment.
>
> I'm done here.
>
> On Wed, 2019-02-27 at 23:19 +0300, Space A. wrote:
> > Sorry? You have poor understanding and mess things, so what's wrong?
> > Being
> > dilatant is not crime, it's okay unless you start convincing yourself
> > that
> > false is true.
> >
> > ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :
> >
> > >
> > > Pull your head in and stop being rude to people here.
> > >
> > > On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> > > >
> > > > You have very poor understanding of the subject, messing
> > > > everything
> > > > up.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] sync/atomic suggestion

[Serhat Şevki Dinçer]

Hi,

I would like to update a counter up to a certain limit atomically, without 
using a channel or mutex. What do you think of the following (equivalent) 
functions for sync/atomic?

func CompareAndInc(*addr, Max) bool {

  if *addr < Max {
*addr++
return true
  }
  return false
}

func CompareAndDec(*addr, Min) bool {

  if *addr > Min {
*addr--
return true
  }
  return false
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Dan Kortschak]

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

I'm done here.

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Sorry? You have poor understanding and mess things, so what's wrong? Being
dilatant is not crime, it's okay unless you start convincing yourself that
false is true.

ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :

> Pull your head in and stop being rude to people here.
>
> On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> > You have very poor understanding of the subject, messing everything
> > up.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

GPL is another license with different terms, I would say offtopic.

ср, 27 февр. 2019 г. в 21:55, Robert Engels :

> You are not correct. You might wish to read this
> https://en.m.wikipedia.org/wiki/GPL_linking_exception which covers many
> of the same issues, and how they think they resolved it.
>
> On Feb 27, 2019, at 12:45 PM, Space A.  wrote:
>
> It's very clear case. It will never become a case in a court. Otherwise,
> if it ever will, I mean, compiling own program and distributing a binary
> which used stdlib e.g. without kissing someone's ass - language is dead.
>
>
>
> ср, 27 февр. 2019 г. в 21:39, Robert Engels :
>
>> That is incorrect thinking. And again, it is all subject to litigation.
>> Whether you are right or wrong is up to the courts to decide.
>>
>> On Feb 27, 2019, at 8:55 AM, Space A.  wrote:
>>
>> Regarding runtime - it's interesting (and separate question maybe), and I
>> would argue that runtime IS part of language itself because language is not
>> only a syntax. It also a garbage collector, a goroutines, etc, as you
>> mentioned. You just can't write Go program without having runtime. It's not
>> possible. So, that means that being part of the language, according to
>> copyright laws, runtime can't be covered by copyright and restricted by a
>> license.
>>
>> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>>>
 There is no "derivatives" in Go's license terms *at all*. There is
 only redistribution in binary and source form and it covers only what's in
 the repo (https://github.com/golang/go/blob/master/LICENSE).

 Compilation is not redistribution.

 For a C compiler that could be true.  For Go's compiler, it also
>>> compiles the source code in the repo for the runtime -- e.g. memory
>>> allocation, garbage collection, concurrency management, etc.  If a program
>>> uses any of the core Go libraries, the same applies.  That source code is
>>> being "redistributed in binary form" by being statically compiled into the
>>> final executable.
>>>
>>> Thus, distribution of a Go executable requires including third party
>>> notices to cover the redistribution of the runtime and core libraries
>>> compiled into that executable.
>>>
>>> Regards,
>>> David
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Dan Kortschak]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Robert Engels]

You are not correct. You might wish to read this 
https://en.m.wikipedia.org/wiki/GPL_linking_exception which covers many of the 
same issues, and how they think they resolved it. 

> On Feb 27, 2019, at 12:45 PM, Space A.  wrote:
> 
> It's very clear case. It will never become a case in a court. Otherwise, if 
> it ever will, I mean, compiling own program and distributing a binary which 
> used stdlib e.g. without kissing someone's ass - language is dead.
> 
> 
> 
> ср, 27 февр. 2019 г. в 21:39, Robert Engels :
>> That is incorrect thinking. And again, it is all subject to litigation. 
>> Whether you are right or wrong is up to the courts to decide. 
>> 
>>> On Feb 27, 2019, at 8:55 AM, Space A.  wrote:
>>> 
>>> Regarding runtime - it's interesting (and separate question maybe), and I 
>>> would argue that runtime IS part of language itself because language is not 
>>> only a syntax. It also a garbage collector, a goroutines, etc, as you 
>>> mentioned. You just can't write Go program without having runtime. It's not 
>>> possible. So, that means that being part of the language, according to 
>>> copyright laws, runtime can't be covered by copyright and restricted by a 
>>> license.
>>> 
>>> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts 
>>> :
 On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
> There is no "derivatives" in Go's license terms at all. There is only 
> redistribution in binary and source form and it covers only what's in the 
> repo (https://github.com/golang/go/blob/master/LICENSE). 
> 
> Compilation is not redistribution. 
 For a C compiler that could be true.  For Go's compiler, it also compiles 
 the source code in the repo for the runtime -- e.g. memory allocation, 
 garbage collection, concurrency management, etc.  If a program uses any of 
 the core Go libraries, the same applies.  That source code is being 
 "redistributed in binary form" by being statically compiled into the final 
 executable.
 
 Thus, distribution of a Go executable requires including third party 
 notices to cover the redistribution of the runtime and core libraries 
 compiled into that executable.
 
 Regards,
 David
 
 
 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 golang-nuts+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

It's very clear case. It will never become a case in a court. Otherwise, if
it ever will, I mean, compiling own program and distributing a binary which
used stdlib e.g. without kissing someone's ass - language is dead.



ср, 27 февр. 2019 г. в 21:39, Robert Engels :

> That is incorrect thinking. And again, it is all subject to litigation.
> Whether you are right or wrong is up to the courts to decide.
>
> On Feb 27, 2019, at 8:55 AM, Space A.  wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I
> would argue that runtime IS part of language itself because language is not
> only a syntax. It also a garbage collector, a goroutines, etc, as you
> mentioned. You just can't write Go program without having runtime. It's not
> possible. So, that means that being part of the language, according to
> copyright laws, runtime can't be covered by copyright and restricted by a
> license.
>
> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
> golang-nuts@googlegroups.com>:
>
>> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>>
>>> There is no "derivatives" in Go's license terms *at all*. There is only
>>> redistribution in binary and source form and it covers only what's in the
>>> repo (https://github.com/golang/go/blob/master/LICENSE).
>>>
>>> Compilation is not redistribution.
>>>
>>> For a C compiler that could be true.  For Go's compiler, it also
>> compiles the source code in the repo for the runtime -- e.g. memory
>> allocation, garbage collection, concurrency management, etc.  If a program
>> uses any of the core Go libraries, the same applies.  That source code is
>> being "redistributed in binary form" by being statically compiled into the
>> final executable.
>>
>> Thus, distribution of a Go executable requires including third party
>> notices to cover the redistribution of the runtime and core libraries
>> compiled into that executable.
>>
>> Regards,
>> David
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Same again, messing everything. It's not API, we are talking about
distributing compiled executables.


ср, 27 февр. 2019 г. в 21:36, Robert Engels :

> You are not correct. There are current cases where apis are being claimed
> to be copyrighted. It is under active litigation.
>
> On Feb 27, 2019, at 8:19 AM, Space A.  wrote:
>
> You have very poor understanding of the subject, messing everything up.
> There is no "derivatives" in Go's license terms *at all*. There is only
> redistribution in binary and source form and it covers only what's in the
> repo (https://github.com/golang/go/blob/master/LICENSE).
>
> Compilation is not redistribution.
>
> PS: Don't want to spend to much time on this, but just to point out -
> derivative is NOT a kind of sophistic mess when something is just based on
> something. You can fork stdlib, add some extra changes and distribute it as
> "stdlib v.2 improved" - in this case this would become derivative. If you
> just use stdlib for your work, your work is not derivative from stdlib. And
> if you want to talk in copyright laws terms, lets start from the point that
> programming languages can't be protected by copyright at all (like "idea",
> "concept", etc - same).
>
> The short answer to this question is that a
>> lawyer should be consulted.
>>
>
> This is 100% clear case and you can distribute your compiled binaries
> free, without any additional requirements, restrictions, giving or not
> credits, or binding yourself to some specific license, what so ever.
> C'mon guys.
>
>
>
>
> ср, 27 февр. 2019 г. в 07:24, Dan Kortschak :
>
>> In-line
>>
>> On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
>> > Executable is not derivative work to stdlib or anything.
>>
>> I think you'll find this is not the case in most jurisdictions. It is
>> certainly not true here, and probably also not in the US.
>>
>> From https://www.copyright.gov/circs/circ14.pdf
>>
>> "A derivative work is a work based on or derived from one or more
>> already existing works."
>>
>> > Go's repo license covers only repo.
>>
>> No.
>>
>> Point 2:
>>
>> "Redistributions in binary form must reproduce the above
>> copyright notice, this list of conditions and the following disclaimer
>> in the documentation and/or other materials provided with the
>> distribution."
>>
>> Note that redistribution is based on the notion of derivative works
>> above. The binary is a derivative of the source code, which is, in this
>> case the standard library.
>>
>> > Stdlib is not redistributed when you compile binary.
>>
>> Yes it is, in a derivative form.
>>
>> > It has nothing to do with GPL.
>>
>> The licenses are different. In this sense you are absolutely correct,
>> this has nothing to do with the GPL. However, in another, far more
>> correct sense, it is indeed related. Both the GPL and the BSD3 are
>> based on the notions that make copyright work. The licensing of the
>> work is based on that fact that the copyright owner has a sole right to
>> distribute the work. This is licensed to the recipient under a set of
>> conditions based on well established definitions of "derivative" and
>> "redistribute". Those two terms are shared by the GPL and BSD3.
>>
>> Note that the LGPL goes to lengths to distinguish between the binary of
>> the licensed work and items that are derivative, but dynamically
>> linked, purely because of the connection between the original source
>> and the binary that is the resulting executable (i.e. not the binary
>> representation of the library).
>>
>> > Go's license is simple and clear.
>>
>> And yet, here we are. The short answer to this question is that a
>> lawyer should be consulted.
>>
>>
>> >
>> > ср, 27 февр. 2019 г., 6:00 Dan Kortschak :
>> >
>> > >
>> > > Probably not. The executable is a derivative work under most
>> > > understandings (this is the basis for the GPL to require that
>> > > source
>> > > code be provided if the executable is distributed to an end user).
>> > >
>> > > Any work writen in Go, using the stdlib (which includes runtime, so
>> > > all
>> > > Go programs) is derivative of the stdlib. This means that the Go
>> > > license pertains.
>> > >
>> > > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
>> > > >
>> > > > You are wrong.
>> > > >
>> > > >
>> > > > среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian
>> > > > Denhardt
>> > > > написал:
>> > > > >
>> > > > >
>> > > > >
>> > > > > Quoting Space A. (2019-02-26 20:58:40)
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > and stdlib only when redistributed separately as a whole in
>> > > > > > binary
>> > > > > > form. When stdlib is used to compile regular binary, it's not
>> > > > > > "redistributed"
>> > > > > This is not my understanding; in general static linking
>> > > > > constitutes
>> > > > > distribution (though you are correct re: compiler output of
>> > > > > your
>> > > > > own
>> > > > > code).
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > Correct answer
>> > > > > The "correct answer," really, 

Re: [go-nuts] distribution of go executables

[Robert Engels]

That is incorrect thinking. And again, it is all subject to litigation. Whether 
you are right or wrong is up to the courts to decide. 

> On Feb 27, 2019, at 8:55 AM, Space A.  wrote:
> 
> Regarding runtime - it's interesting (and separate question maybe), and I 
> would argue that runtime IS part of language itself because language is not 
> only a syntax. It also a garbage collector, a goroutines, etc, as you 
> mentioned. You just can't write Go program without having runtime. It's not 
> possible. So, that means that being part of the language, according to 
> copyright laws, runtime can't be covered by copyright and restricted by a 
> license.
> 
> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts 
> :
>> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>>> There is no "derivatives" in Go's license terms at all. There is only 
>>> redistribution in binary and source form and it covers only what's in the 
>>> repo (https://github.com/golang/go/blob/master/LICENSE). 
>>> 
>>> Compilation is not redistribution. 
>> For a C compiler that could be true.  For Go's compiler, it also compiles 
>> the source code in the repo for the runtime -- e.g. memory allocation, 
>> garbage collection, concurrency management, etc.  If a program uses any of 
>> the core Go libraries, the same applies.  That source code is being 
>> "redistributed in binary form" by being statically compiled into the final 
>> executable.
>> 
>> Thus, distribution of a Go executable requires including third party notices 
>> to cover the redistribution of the runtime and core libraries compiled into 
>> that executable.
>> 
>> Regards,
>> David
>> 
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Robert Engels]

You are not correct. There are current cases where apis are being claimed to be 
copyrighted. It is under active litigation. 

> On Feb 27, 2019, at 8:19 AM, Space A.  wrote:
> 
> You have very poor understanding of the subject, messing everything up.
> There is no "derivatives" in Go's license terms at all. There is only 
> redistribution in binary and source form and it covers only what's in the 
> repo (https://github.com/golang/go/blob/master/LICENSE). 
> 
> Compilation is not redistribution. 
> 
> PS: Don't want to spend to much time on this, but just to point out -  
> derivative is NOT a kind of sophistic mess when something is just based on 
> something. You can fork stdlib, add some extra changes and distribute it as 
> "stdlib v.2 improved" - in this case this would become derivative. If you 
> just use stdlib for your work, your work is not derivative from stdlib. And 
> if you want to talk in copyright laws terms, lets start from the point that 
> programming languages can't be protected by copyright at all (like "idea", 
> "concept", etc - same).
> 
>> The short answer to this question is that a
>> lawyer should be consulted.  
> 
> This is 100% clear case and you can distribute your compiled binaries free, 
> without any additional requirements, restrictions, giving or not credits, or 
> binding yourself to some specific license, what so ever. 
> C'mon guys.
> 
> 
> 
> 
> ср, 27 февр. 2019 г. в 07:24, Dan Kortschak :
>> In-line
>> 
>> On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
>> > Executable is not derivative work to stdlib or anything.
>> 
>> I think you'll find this is not the case in most jurisdictions. It is
>> certainly not true here, and probably also not in the US.
>> 
>> From https://www.copyright.gov/circs/circ14.pdf
>> 
>> "A derivative work is a work based on or derived from one or more
>> already existing works."
>> 
>> > Go's repo license covers only repo.
>> 
>> No.
>> 
>> Point 2:
>> 
>> "Redistributions in binary form must reproduce the above
>> copyright notice, this list of conditions and the following disclaimer
>> in the documentation and/or other materials provided with the
>> distribution."
>> 
>> Note that redistribution is based on the notion of derivative works
>> above. The binary is a derivative of the source code, which is, in this
>> case the standard library.
>> 
>> > Stdlib is not redistributed when you compile binary.
>> 
>> Yes it is, in a derivative form.
>> 
>> > It has nothing to do with GPL.
>> 
>> The licenses are different. In this sense you are absolutely correct,
>> this has nothing to do with the GPL. However, in another, far more
>> correct sense, it is indeed related. Both the GPL and the BSD3 are
>> based on the notions that make copyright work. The licensing of the
>> work is based on that fact that the copyright owner has a sole right to
>> distribute the work. This is licensed to the recipient under a set of 
>> conditions based on well established definitions of "derivative" and 
>> "redistribute". Those two terms are shared by the GPL and BSD3.
>> 
>> Note that the LGPL goes to lengths to distinguish between the binary of
>> the licensed work and items that are derivative, but dynamically
>> linked, purely because of the connection between the original source
>> and the binary that is the resulting executable (i.e. not the binary
>> representation of the library).
>> 
>> > Go's license is simple and clear.
>> 
>> And yet, here we are. The short answer to this question is that a
>> lawyer should be consulted.
>> 
>> 
>> > 
>> > ср, 27 февр. 2019 г., 6:00 Dan Kortschak :
>> > 
>> > > 
>> > > Probably not. The executable is a derivative work under most
>> > > understandings (this is the basis for the GPL to require that
>> > > source
>> > > code be provided if the executable is distributed to an end user).
>> > > 
>> > > Any work writen in Go, using the stdlib (which includes runtime, so
>> > > all
>> > > Go programs) is derivative of the stdlib. This means that the Go
>> > > license pertains.
>> > > 
>> > > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
>> > > > 
>> > > > You are wrong.
>> > > > 
>> > > > 
>> > > > среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian
>> > > > Denhardt
>> > > > написал:
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > Quoting Space A. (2019-02-26 20:58:40)
>> > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > and stdlib only when redistributed separately as a whole in
>> > > > > > binary
>> > > > > > form. When stdlib is used to compile regular binary, it's not
>> > > > > > "redistributed"
>> > > > > This is not my understanding; in general static linking
>> > > > > constitutes
>> > > > > distribution (though you are correct re: compiler output of
>> > > > > your
>> > > > > own
>> > > > > code).
>> > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > Correct answer
>> > > > > The "correct answer," really, is to ask someone actually
>> > > > > qualified
>> > > > > to
>> > > > > give you legal advice.

[go-nuts] Re: Helping to fixing Windows virus scanner false positives

[ajstarks]

FYI, the Go 1.12 toolchain is now blessed by Symantec.


> I reported these false positives for the go command, compiler, assembler 
> and linker at
> https://submit.symantec.com/false_positive/ and the good news is that the
> go command (1.12 version) is now whitelisted. I'm waiting for the others
> tools to be so blessed.  My guess is I'll have to report again when Go is 
> updated.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Section(".gosymtab") vs SectionByType(elf.SHT_SYMTAB)

[Ian Lance Taylor]

On Wed, Feb 27, 2019 at 9:41 AM Gargi Sharma  wrote:
>
> On Tue, Feb 26, 2019 at 11:34 PM Ian Lance Taylor  wrote:
> >
> > On Tue, Feb 26, 2019 at 6:08 PM Gargi Sharma  wrote:
> > >
> > > I meant the Section and SectionByType calls.
> >
> > Those calls do different things.  They do more than just get the
> > symbol table.  They aren't equivalent.
> >
> >
> > > [ 6] .gosymtab PROGBITS 004d7758  000d7758
> > >     A   0 0 1
> > > [22] .symtab   SYMTAB     002aa000
> > >00012c30  0018  23   116 8
> > >
> > > From readelf, I see that the binary has both symtab and gosymtab. Is
> > > gosymtab a superset of information of the .symtab? If yes, why do we
> > > need the .symtab?
> >
> > I explained .gosymtab in my last message.  It is not a superset of
> > .symtab.  It is different.
> >
> > In any case we need .symtab because that is what ELF tools expect.
> Got it, I was really confused why we needed two different symbol tables.
>
> I am trying to get the program counter if I know the line number. For
> go binaries, I did this:
>
> func getPCFromLine(line int, binary string) {
> symbolTableSection := executable.Section(".gosymtab")
> symbolTableData, _ := symbolTableSection.Data()
>
> lineTableForText := gosym.NewLineTable(pcToLineData,
> executable.Section(".text").Addr)
>
> newSymbolTable, _ := gosym.NewTable(symbolTableData, lineTableForText)
>
> pc, fn, _ := newSymbolTable.LineToPC(binary, line)
> }
>
> The above function was where I was trying to use
> executable.Section(".symtab") and got this error:
> panic: bad symbol type '0' at byte 0x4

There is code that does this in cmd/internal/objfile/goobj.go, in the
method PCToLine.  You can probably do something similar.


> I am assuming if I want to do something similar for non-go binaries, I
> will have to look inside .symtab to get this information.

No, the ELF .symtab only contains the information displayed by
"readelf -s".  To get file/line information you have to parse the
debug information, normally DWARF.  The libbacktrace library can do
that for you; it has a backtrace_pcinfo function.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Section(".gosymtab") vs SectionByType(elf.SHT_SYMTAB)

[Gargi Sharma]

On Tue, Feb 26, 2019 at 11:34 PM Ian Lance Taylor  wrote:
>
> On Tue, Feb 26, 2019 at 6:08 PM Gargi Sharma  wrote:
> >
> > I meant the Section and SectionByType calls.
>
> Those calls do different things.  They do more than just get the
> symbol table.  They aren't equivalent.
>
>
> > [ 6] .gosymtab PROGBITS 004d7758  000d7758
> >     A   0 0 1
> > [22] .symtab   SYMTAB     002aa000
> >00012c30  0018  23   116 8
> >
> > From readelf, I see that the binary has both symtab and gosymtab. Is
> > gosymtab a superset of information of the .symtab? If yes, why do we
> > need the .symtab?
>
> I explained .gosymtab in my last message.  It is not a superset of
> .symtab.  It is different.
>
> In any case we need .symtab because that is what ELF tools expect.
Got it, I was really confused why we needed two different symbol tables.

I am trying to get the program counter if I know the line number. For
go binaries, I did this:

func getPCFromLine(line int, binary string) {
symbolTableSection := executable.Section(".gosymtab")
symbolTableData, _ := symbolTableSection.Data()

lineTableForText := gosym.NewLineTable(pcToLineData,
executable.Section(".text").Addr)

newSymbolTable, _ := gosym.NewTable(symbolTableData, lineTableForText)

pc, fn, _ := newSymbolTable.LineToPC(binary, line)
}

The above function was where I was trying to use
executable.Section(".symtab") and got this error:
panic: bad symbol type '0' at byte 0x4

I am assuming if I want to do something similar for non-go binaries, I
will have to look inside .symtab to get this information.

Thanks!

gargi

>
> > My code panics when I try to read the actual .symtab (doing a
> > section.data() for Section(.symtab)), which I don't understand as
> > well.
>
> Why not use the Symbols method?

>
> Perhaps we can help you if you show us a small self-contained example.
>
> Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Louki Sumirniy]

This would only be true if *derivatives* were specified. Go links 
everything static by default, so in *very* broad terms, the binaries are 
derivative of the stdlib in the distributed go compiler package. I think 
really the proper way to look at this is this exact subject is simply not 
mentioned, only distantly implied in a specific way of interpreting it, and 
it would not be open-and-shut in a law court. 

Since the compiler produces static binaries by default, I think it should 
be explicated in the licence that embedding the unmodified binary objects 
does not qualify as 'derivation' and licence terms do not apply. It's no 
problem right now, but it seems to me the licence does give wiggle room to 
Google to play silly buggers on the margins of this.

And on the other side, what about when I build the binaries of stdlib using 
gcc or some other mostly complete not-google implementation? Seems to me 
the licence would cover this, and thus require the distribution of that 
licence.

So I'm just going to quietly suggest that the licence needs to be revised.

On Wednesday, 27 February 2019 15:46:23 UTC+1, Manlio Perillo wrote:
>
>
> On Wednesday, February 27, 2019 at 2:58:40 AM UTC+1, Space A. wrote:
>>
>> Mentioned license doesn't cover binaries produced by compiler, "binary 
>> form" there means go tools themselves, and stdlib only when redistributed 
>> separately as a whole in binary form. When stdlib is used to compile 
>> regular binary, it's not "redistributed", and there are no restrictions or 
>> special requirements at all.
>>
>> Correct answer: if you are using only stdlib and Go compiler to compile a 
>> binary - there are no requirements. If you are using 3rd parties libs / 
>> binaries / sources - read their licenses.
>>
>>
> No, **there is**  a requirement:
>
> Redistributions in binary form must reproduce the above copyright notice, 
> this list of conditions and the following disclaimer in the documentation 
> and/or other materials provided with the distribution. 
>
> This requirement does not only apply when you redistribute a (possibly) 
> modified version of the Go compiler, but also to the standard library.
> So you have to link the Go License in your documentation, when you 
> redistribuite a Go program, since **every** Go program implicitly imports 
> the runtime package.
>
> But I'm not really sure.
>
>
> Manlio Perillo
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Louki Sumirniy]

There is one place where derivative is irrelevant, that would be where a 
patent sticks to the algorithm, and this patently idiotic situation is not 
universally applicable, some jurisdictions never added this kind of lunacy 
to copyright law (unfortunately, not all).

As I understand it, the licence on the Google official Go compiler makes 
absolutely no restrictions on *your* source code, nor the binaries the 
compiler creates from them, regardless of the fact it imports the standard 
library. Specifically, and in practise, the library links your code to the 
*compiled* binary objects created from the source of the stdlib. Besides, 
that would be quite inefficient anyway.

I think it should be obvious that a programmer's studio should not feel 
like a courtroom, or one has quite misplaced priorities on the whole 
business of facilitating development of new software.

I could say more about my opinions on copyright but I'll let the licences I 
put on my stuff speak for me.

On Wednesday, 27 February 2019 15:20:36 UTC+1, Space A. wrote:
>
> You have very poor understanding of the subject, messing everything up.
> There is no "derivatives" in Go's license terms *at all*. There is only 
> redistribution in binary and source form and it covers only what's in the 
> repo (https://github.com/golang/go/blob/master/LICENSE). 
>
> Compilation is not redistribution. 
>
> PS: Don't want to spend to much time on this, but just to point out -  
> derivative is NOT a kind of sophistic mess when something is just based on 
> something. You can fork stdlib, add some extra changes and distribute it as 
> "stdlib v.2 improved" - in this case this would become derivative. If you 
> just use stdlib for your work, your work is not derivative from stdlib. And 
> if you want to talk in copyright laws terms, lets start from the point that 
> programming languages can't be protected by copyright at all (like "idea", 
> "concept", etc - same).
>
> The short answer to this question is that a
>> lawyer should be consulted. 
>>
>
> This is 100% clear case and you can distribute your compiled binaries 
> free, without any additional requirements, restrictions, giving or not 
> credits, or binding yourself to some specific license, what so ever. 
> C'mon guys.
>
>
>
>
> ср, 27 февр. 2019 г. в 07:24, Dan Kortschak  >:
>
>> In-line
>>
>> On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
>> > Executable is not derivative work to stdlib or anything.
>>
>> I think you'll find this is not the case in most jurisdictions. It is
>> certainly not true here, and probably also not in the US.
>>
>> From https://www.copyright.gov/circs/circ14.pdf
>>
>> "A derivative work is a work based on or derived from one or more
>> already existing works."
>>
>> > Go's repo license covers only repo.
>>
>> No.
>>
>> Point 2:
>>
>> "Redistributions in binary form must reproduce the above
>> copyright notice, this list of conditions and the following disclaimer
>> in the documentation and/or other materials provided with the
>> distribution."
>>
>> Note that redistribution is based on the notion of derivative works
>> above. The binary is a derivative of the source code, which is, in this
>> case the standard library.
>>
>> > Stdlib is not redistributed when you compile binary.
>>
>> Yes it is, in a derivative form.
>>
>> > It has nothing to do with GPL.
>>
>> The licenses are different. In this sense you are absolutely correct,
>> this has nothing to do with the GPL. However, in another, far more
>> correct sense, it is indeed related. Both the GPL and the BSD3 are
>> based on the notions that make copyright work. The licensing of the
>> work is based on that fact that the copyright owner has a sole right to
>> distribute the work. This is licensed to the recipient under a set of 
>> conditions based on well established definitions of "derivative" and 
>> "redistribute". Those two terms are shared by the GPL and BSD3.
>>
>> Note that the LGPL goes to lengths to distinguish between the binary of
>> the licensed work and items that are derivative, but dynamically
>> linked, purely because of the connection between the original source
>> and the binary that is the resulting executable (i.e. not the binary
>> representation of the library).
>>
>> > Go's license is simple and clear.
>>
>> And yet, here we are. The short answer to this question is that a
>> lawyer should be consulted.
>>
>>
>> > 
>> > ср, 27 февр. 2019 г., 6:00 Dan Kortschak > >:
>> > 
>> > > 
>> > > Probably not. The executable is a derivative work under most
>> > > understandings (this is the basis for the GPL to require that
>> > > source
>> > > code be provided if the executable is distributed to an end user).
>> > > 
>> > > Any work writen in Go, using the stdlib (which includes runtime, so
>> > > all
>> > > Go programs) is derivative of the stdlib. This means that the Go
>> > > license pertains.
>> > > 
>> > > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
>> > > > 
>> > > > You are wrong.

Re: [go-nuts] distribution of go executables

[Manlio Perillo]

You may look at https://www.gnu.org/licenses/gcc-exception-3.1-faq.html for 
a reference.


Manlio Perillo

On Wednesday, February 27, 2019 at 3:56:10 PM UTC+1, Space A. wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I 
> would argue that runtime IS part of language itself because language is not 
> only a syntax. It also a garbage collector, a goroutines, etc, as you 
> mentioned. You just can't write Go program without having runtime. It's not 
> possible. So, that means that being part of the language, according to 
> copyright laws, runtime can't be covered by copyright and restricted by a 
> license.
>
> ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
> golan...@googlegroups.com >:
>
>> On Wed, Feb 27, 2019 at 9:20 AM Space A. > > wrote:
>>
>>> There is no "derivatives" in Go's license terms *at all*. There is only 
>>> redistribution in binary and source form and it covers only what's in the 
>>> repo (https://github.com/golang/go/blob/master/LICENSE). 
>>>
>>> Compilation is not redistribution. 
>>>
>>> For a C compiler that could be true.  For Go's compiler, it also 
>> compiles the source code in the repo for the runtime -- e.g. memory 
>> allocation, garbage collection, concurrency management, etc.  If a program 
>> uses any of the core Go libraries, the same applies.  That source code is 
>> being "redistributed in binary form" by being statically compiled into the 
>> final executable.
>>
>> Thus, distribution of a Go executable requires including third party 
>> notices to cover the redistribution of the runtime and core libraries 
>> compiled into that executable.
>>
>> Regards,
>> David
>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Ian Lance Taylor]

On Wed, Feb 27, 2019 at 6:56 AM Space A.  wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I 
> would argue that runtime IS part of language itself because language is not 
> only a syntax. It also a garbage collector, a goroutines, etc, as you 
> mentioned. You just can't write Go program without having runtime. It's not 
> possible. So, that means that being part of the language, according to 
> copyright laws, runtime can't be covered by copyright and restricted by a 
> license.

As others have said, if this really matters to you, you should consult
a lawyer who deals with copyright issues, and you should look into the
relevant laws and cases in the jurisdiction that applies to you.
Personally I do not think the statement above is correct in the U.S.,
but I am not a lawyer.

In any case you cannot go wrong by following the requirements in the
Go license, which are simple enough, and are an instance of the widely
used BSD license.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

 No that means that it will depend on what's written in this particular
license given by creator of this source codes. It's case by case. For
example they can say that compilation is not allowed at all. Go's repo
license is clear without any "derivatives" "commercial" or "personal"
complex use cases, etc.

ср, 27 февр. 2019 г. в 17:55, Jan Mercl <0xj...@gmail.com>:

> On Wed, Feb 27, 2019 at 3:47 PM Space A.  wrote:
>
> > Mentioned license doesn't cover binaries produced by compiler, "binary
> form" there means go tools themselves ...
>
> That would mean that once a copyrighted source code is compiled to binary
> form, the source code copyright holders LICENSE terms no more apply.
>
> That's not the case in most jurisdictions. Proof by contradiction is left
> as an exercise...
>
> --
>
> -j
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

Regarding runtime - it's interesting (and separate question maybe), and I
would argue that runtime IS part of language itself because language is not
only a syntax. It also a garbage collector, a goroutines, etc, as you
mentioned. You just can't write Go program without having runtime. It's not
possible. So, that means that being part of the language, according to
copyright laws, runtime can't be covered by copyright and restricted by a
license.

ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:
>
>> There is no "derivatives" in Go's license terms *at all*. There is only
>> redistribution in binary and source form and it covers only what's in the
>> repo (https://github.com/golang/go/blob/master/LICENSE).
>>
>> Compilation is not redistribution.
>>
>> For a C compiler that could be true.  For Go's compiler, it also compiles
> the source code in the repo for the runtime -- e.g. memory allocation,
> garbage collection, concurrency management, etc.  If a program uses any of
> the core Go libraries, the same applies.  That source code is being
> "redistributed in binary form" by being statically compiled into the final
> executable.
>
> Thus, distribution of a Go executable requires including third party
> notices to cover the redistribution of the runtime and core libraries
> compiled into that executable.
>
> Regards,
> David
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fwd: [go-nuts] distribution of go executables

[Jan Mercl]

On Wed, Feb 27, 2019 at 3:47 PM Space A.  wrote:

> Mentioned license doesn't cover binaries produced by compiler, "binary
form" there means go tools themselves ...

That would mean that once a copyrighted source code is compiled to binary
form, the source code copyright holders LICENSE terms no more apply.

That's not the case in most jurisdictions. Proof by contradiction is left
as an exercise...

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

 Jan, good that you read my link, however I already answered on this
(quoting myself):

Mentioned license doesn't cover binaries produced by compiler, "binary
> form" there means go tools themselves, and stdlib only when redistributed
> separately as a whole in binary form. When stdlib is used to compile
> regular binary, it's not "redistributed", and there are no restrictions or
> special requirements at all.
>

What you're saying

> By distributing a program compiled by the Go compiler, one is distributing
> the binary form of some parts of the run time library and also possibly the
> binary form of some parts of the standard library, all of which are covered
> by the said LICENSE.
>

No, No, and yet one time No. You are wrong. By distributing your compiled
binary you are not "distributing" anything from the repo and it's not the
LICENSE's covered case. You are not restricted in any way.


ср, 27 февр. 2019 г. в 17:41, Jan Mercl <0xj...@gmail.com>:

> On Wed, Feb 27, 2019 at 3:20 PM Space A.  wrote:
>
> > This is 100% clear case and you can distribute your compiled binaries
> free, without any additional requirements, restrictions, giving or not
> credits, or binding yourself to some specific license, what so ever.
>
> That's not correct. Quoting from
> https://go.googlesource.com/go/+/refs/heads/master/LICENSE
>
> =
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> ...
>
> * Redistributions in binary form
>
>
> *must reproduce the above copyright notice, this list of conditions and
> the following disclaimer in the documentation and/or other materials
> provided with the distribution.*
>
> ...
> =
>
> By distributing a program compiled by the Go compiler, one is distributing
> the binary form of some parts of the run time library and also possibly the
> binary form of some parts of the standard library, all of which are covered
> by the said LICENSE.
>
> The LICENSE mandates that this can be legally done only while satisfying
> the conditions highlighted above.
>
> --
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Manlio Perillo]

On Wednesday, February 27, 2019 at 2:58:40 AM UTC+1, Space A. wrote:
>
> Mentioned license doesn't cover binaries produced by compiler, "binary 
> form" there means go tools themselves, and stdlib only when redistributed 
> separately as a whole in binary form. When stdlib is used to compile 
> regular binary, it's not "redistributed", and there are no restrictions or 
> special requirements at all.
>
> Correct answer: if you are using only stdlib and Go compiler to compile a 
> binary - there are no requirements. If you are using 3rd parties libs / 
> binaries / sources - read their licenses.
>
>
No, **there is**  a requirement:

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

This requirement does not only apply when you redistribute a (possibly) 
modified version of the Go compiler, but also to the standard library.
So you have to link the Go License in your documentation, when you 
redistribuite a Go program, since **every** Go program implicitly imports 
the runtime package.

But I'm not really sure.


Manlio Perillo

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Jan Mercl]

On Wed, Feb 27, 2019 at 3:20 PM Space A.  wrote:

> This is 100% clear case and you can distribute your compiled binaries
free, without any additional requirements, restrictions, giving or not
credits, or binding yourself to some specific license, what so ever.

That's not correct. Quoting from
https://go.googlesource.com/go/+/refs/heads/master/LICENSE

=
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

...

* Redistributions in binary form


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

...
=

By distributing a program compiled by the Go compiler, one is distributing
the binary form of some parts of the run time library and also possibly the
binary form of some parts of the standard library, all of which are covered
by the said LICENSE.

The LICENSE mandates that this can be legally done only while satisfying
the conditions highlighted above.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

['David Golden' via golang-nuts]

On Wed, Feb 27, 2019 at 9:20 AM Space A.  wrote:

> There is no "derivatives" in Go's license terms *at all*. There is only
> redistribution in binary and source form and it covers only what's in the
> repo (https://github.com/golang/go/blob/master/LICENSE).
>
> Compilation is not redistribution.
>
> For a C compiler that could be true.  For Go's compiler, it also compiles
the source code in the repo for the runtime -- e.g. memory allocation,
garbage collection, concurrency management, etc.  If a program uses any of
the core Go libraries, the same applies.  That source code is being
"redistributed in binary form" by being statically compiled into the final
executable.

Thus, distribution of a Go executable requires including third party
notices to cover the redistribution of the runtime and core libraries
compiled into that executable.

Regards,
David

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.12 is Released

[bucarr]

Thank you, Go Team!

Installed.

My complex web app seems to work just fine under 1.12.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] distribution of go executables

[Space A.]

 You have very poor understanding of the subject, messing everything up.
There is no "derivatives" in Go's license terms *at all*. There is only
redistribution in binary and source form and it covers only what's in the
repo (https://github.com/golang/go/blob/master/LICENSE).

Compilation is not redistribution.

PS: Don't want to spend to much time on this, but just to point out -
derivative is NOT a kind of sophistic mess when something is just based on
something. You can fork stdlib, add some extra changes and distribute it as
"stdlib v.2 improved" - in this case this would become derivative. If you
just use stdlib for your work, your work is not derivative from stdlib. And
if you want to talk in copyright laws terms, lets start from the point that
programming languages can't be protected by copyright at all (like "idea",
"concept", etc - same).

The short answer to this question is that a
> lawyer should be consulted.
>

This is 100% clear case and you can distribute your compiled binaries free,
without any additional requirements, restrictions, giving or not credits,
or binding yourself to some specific license, what so ever.
C'mon guys.




ср, 27 февр. 2019 г. в 07:24, Dan Kortschak :

> In-line
>
> On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
> > Executable is not derivative work to stdlib or anything.
>
> I think you'll find this is not the case in most jurisdictions. It is
> certainly not true here, and probably also not in the US.
>
> From https://www.copyright.gov/circs/circ14.pdf
>
> "A derivative work is a work based on or derived from one or more
> already existing works."
>
> > Go's repo license covers only repo.
>
> No.
>
> Point 2:
>
> "Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions and the following disclaimer
> in the documentation and/or other materials provided with the
> distribution."
>
> Note that redistribution is based on the notion of derivative works
> above. The binary is a derivative of the source code, which is, in this
> case the standard library.
>
> > Stdlib is not redistributed when you compile binary.
>
> Yes it is, in a derivative form.
>
> > It has nothing to do with GPL.
>
> The licenses are different. In this sense you are absolutely correct,
> this has nothing to do with the GPL. However, in another, far more
> correct sense, it is indeed related. Both the GPL and the BSD3 are
> based on the notions that make copyright work. The licensing of the
> work is based on that fact that the copyright owner has a sole right to
> distribute the work. This is licensed to the recipient under a set of
> conditions based on well established definitions of "derivative" and
> "redistribute". Those two terms are shared by the GPL and BSD3.
>
> Note that the LGPL goes to lengths to distinguish between the binary of
> the licensed work and items that are derivative, but dynamically
> linked, purely because of the connection between the original source
> and the binary that is the resulting executable (i.e. not the binary
> representation of the library).
>
> > Go's license is simple and clear.
>
> And yet, here we are. The short answer to this question is that a
> lawyer should be consulted.
>
>
> >
> > ср, 27 февр. 2019 г., 6:00 Dan Kortschak :
> >
> > >
> > > Probably not. The executable is a derivative work under most
> > > understandings (this is the basis for the GPL to require that
> > > source
> > > code be provided if the executable is distributed to an end user).
> > >
> > > Any work writen in Go, using the stdlib (which includes runtime, so
> > > all
> > > Go programs) is derivative of the stdlib. This means that the Go
> > > license pertains.
> > >
> > > On Tue, 2019-02-26 at 18:35 -0800, Space A. wrote:
> > > >
> > > > You are wrong.
> > > >
> > > >
> > > > среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian
> > > > Denhardt
> > > > написал:
> > > > >
> > > > >
> > > > >
> > > > > Quoting Space A. (2019-02-26 20:58:40)
> > > > >
> > > > > >
> > > > > >
> > > > > > and stdlib only when redistributed separately as a whole in
> > > > > > binary
> > > > > > form. When stdlib is used to compile regular binary, it's not
> > > > > > "redistributed"
> > > > > This is not my understanding; in general static linking
> > > > > constitutes
> > > > > distribution (though you are correct re: compiler output of
> > > > > your
> > > > > own
> > > > > code).
> > > > >
> > > > > >
> > > > > >
> > > > > > Correct answer
> > > > > The "correct answer," really, is to ask someone actually
> > > > > qualified
> > > > > to
> > > > > give you legal advice.
> > > > >
> > > > > -Ian
> > > > >
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go 1.12 with Modules enabled leading to compilation error during tests - wehre as all is OK without modules enabled

[Stephane Moreau]

Hello,

Just after the new release of go 1.12, I migrated my project to use the new 
version.
Every thing went fine so far, all tests and code coverage reports were 
generated accruately just like before.

Once done I activated GO111MODULE option to get rid of the dep dependency 
manager we were using before, but now CI fails

At this point I get an error during my CI process (CI is run within a docer 
image golang1.12:alpine3.9)
2019/02/27 14:15:40 duplicate symbol runtime/debug.modinfo (types 30 and 
30) in /cmd/apiserver and $WORK\b593\_pkg_.a(_go_.o)

I managed to reproduce the very same issue on my windows desktop:

If I run
go test -count=1 -cover --coverpkg=all ./cache/...
Everything goes fine and I do get the expected results

If I run 
go test -count=1 ./...
I get it working fine too:
?   /cache   [no test files]
ok  /cache/memory0.660s


If I run 
go test -count=1 -cover --coverpkg=all ./...
I get :
?   /cache   [no test files]
# /cache/memory.test
2019/02/27 14:31:55 duplicate symbol runtime/debug.modinfo (types 30 and 
30) in /cmd/apiserver and 
C:\Users\steph\AppData\Local\go-build\5e\5e2f041c975bf4971f8b073ef3a2ceadb95d3c87d8b02241aa6a393d3c5a7632-d(_go_.o)
FAIL/cache/memory [build failed]

Any advice on what I'm doing wrong here ?

Some more insight on the environment

go version
go version go1.12 windows/amd64

go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\steph\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\dev\source\catapult/go
set GOPROXY=
set GORACE=
set GOROOT=C:\dev\tools\go1.12
set GOTMPDIR=
set GOTOOLDIR=C:\dev\tools\go1.12\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\dev\source\catapult\go\src\\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 
-fdebug-prefix-map=C:\Users\steph\AppData\Local\Temp\go-build245172374=/tmp/go-build
 
-gno-record-gcc-switches


modules used :

module 

go 1.12

require (
cloud.google.com/go v0.26.0
contrib.go.opencensus.io/exporter/stackdriver v0.6.0 // indirect
github.com/BurntSushi/toml v0.3.1 // indirect
github.com/GoogleCloudPlatform/google-cloud-go v0.28.0
github.com/bcicen/jstream v0.0.0-20190206022353-f306cd3e1fa6
github.com/bxcodec/faker v2.0.1+incompatible
github.com/elazarl/go-bindata-assetfs v0.0.0-20180223160309-38087fe4dafb
github.com/ghodss/yaml v1.0.0 // indirect
github.com/go-ini/ini v1.41.0 // indirect
github.com/gogo/protobuf v1.1.1 // indirect
github.com/golang/groupcache v0.0.0-20190129154638-5b532d6fd5ef // indirect
github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db // indirect
github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c // indirect
github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // indirect
github.com/google/martian v2.1.0+incompatible // indirect
github.com/googleapis/gax-go v2.0.0+incompatible // indirect
github.com/googleapis/gnostic v0.2.0 // indirect
github.com/gorilla/websocket v1.4.0
github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7 // 
indirect
github.com/hashicorp/golang-lru v0.5.0 // indirect
github.com/imdario/mergo v0.3.6 // indirect
github.com/inconshreveable/mousetrap v1.0.0 // indirect
github.com/json-iterator/go v1.1.5 // indirect
github.com/kr/fs v0.1.0 // indirect
github.com/lib/pq v1.0.0
github.com/minio/minio-go v6.0.13+incompatible
github.com/mitchellh/go-homedir v1.0.0 // indirect
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // 
indirect
github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742 // indirect
github.com/mongodb/mongo-go-driver v0.0.17
github.com/nats-io/gnatsd v1.4.1 // indirect
github.com/nats-io/go-nats v1.6.0
github.com/nats-io/nuid v1.0.0 // indirect
github.com/nimajalali/go-force v0.0.0-20180615191228-2b94c45dfae2
github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
github.com/pkg/errors v0.8.0
github.com/pkg/sftp v1.8.3
github.com/pmezard/go-difflib v1.0.0 // indirect
github.com/rs/xid v1.2.1 // indirect
github.com/rs/zerolog v1.9.1
github.com/santhosh-tekuri/jsonschema v1.2.2
github.com/smartystreets/goconvey v0.0.0-2019023459-a17d461953aa // 
indirect
github.com/spf13/cast v1.2.0
github.com/spf13/cobra v0.0.3
github.com/spf13/pflag v1.0.2
github.com/spf13/viper v1.2.0
github.com/stretchr/testify v1.2.2
github.com/tidwall/pretty v0.0.0-20180105212114-65a9db5fad51 // indirect
github.com/xdg/scram v0.0.0-20180814205039-7eeb5667e42c // indirect
github.com/xdg/stringprep v1.0.0 // indirect
github.com/zenazn/goji v0.0.0-20160507202103-64eb34159fe5 // indirect
go.opencensus.io v0.17.0 // indirect
golang.org/x/crypto v0.0.0-20180910181607-0e37d006457b
golang.org/x/net v0.0.0-20180911220305-26e67e76b6c3 // indirect
golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be
golang.org/x/sys 

[go-nuts] Go 1.12 with Modules enabled leading to compilation error during tests - wehre as all is OK without modules enabled

[Stephane Moreau]

Hello,

Just after the new release of go 1.12, I migrated my project to use the new 
version.
Every thing went fine so far, all tests and code coverage reports were 
generated accruately just like before.

Once done I activated GO111MODULE option to get rid of the dep dependency 
manager we were using before, but now CI fails

At this point I get an error during my CI process (CI is run within a docer 
image golang1.12:alpine3.9)
2019/02/27 14:15:40 duplicate symbol runtime/debug.modinfo (types 30 and 
30) in imagino/cmd/apiserver and $WORK\b593\_pkg_.a(_go_.o)

I managed to reproduce the very same issue on my windows desktop:

If I run
go test -count=1 -cover --coverpkg=all ./cache/...
Everything goes fine and I do get the expected results

If I run 
go test -count=1 ./...
I get it working fine too:
?   imagino/cache   [no test files]
ok  imagino/cache/memory0.660s


If I run 
go test -count=1 -cover --coverpkg=all ./...
I get :
?   imagino/cache   [no test files]
# imagino/cache/memory.test
2019/02/27 14:31:55 duplicate symbol runtime/debug.modinfo (types 30 and 
30) in imagino/cmd/apiserver and 
C:\Users\steph\AppData\Local\go-build\5e\5e2f041c975bf4971f8b073ef3a2ceadb95d3c87d8b02241aa6a393d3c5a7632-d(_go_.o)
FAILimagino/cache/memory [build failed]

Any advice on what I'm doing wrong here ?

Some more insight on the environment

go version
go version go1.12 windows/amd64

go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\steph\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\dev\source\catapult/go
set GOPROXY=
set GORACE=
set GOROOT=C:\dev\tools\go1.12
set GOTMPDIR=
set GOTOOLDIR=C:\dev\tools\go1.12\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\dev\source\catapult\go\src\imagino\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 
-fdebug-prefix-map=C:\Users\steph\AppData\Local\Temp\go-build245172374=/tmp/go-build
 
-gno-record-gcc-switches
PS C:\dev\source\catapult\go\src\imagino>


modules used :

go 1.12

require (
cloud.google.com/go v0.26.0
contrib.go.opencensus.io/exporter/stackdriver v0.6.0 // indirect
github.com/BurntSushi/toml v0.3.1 // indirect
github.com/GoogleCloudPlatform/google-cloud-go v0.28.0
github.com/bcicen/jstream v0.0.0-20190206022353-f306cd3e1fa6
github.com/bxcodec/faker v2.0.1+incompatible
github.com/elazarl/go-bindata-assetfs v0.0.0-20180223160309-38087fe4dafb
github.com/ghodss/yaml v1.0.0 // indirect
github.com/go-ini/ini v1.41.0 // indirect
github.com/gogo/protobuf v1.1.1 // indirect
github.com/golang/groupcache v0.0.0-20190129154638-5b532d6fd5ef // indirect
github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db // indirect
github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c // indirect
github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // indirect
github.com/google/martian v2.1.0+incompatible // indirect
github.com/googleapis/gax-go v2.0.0+incompatible // indirect
github.com/googleapis/gnostic v0.2.0 // indirect
github.com/gorilla/websocket v1.4.0
github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7 // 
indirect
github.com/hashicorp/golang-lru v0.5.0 // indirect
github.com/imdario/mergo v0.3.6 // indirect
github.com/inconshreveable/mousetrap v1.0.0 // indirect
github.com/json-iterator/go v1.1.5 // indirect
github.com/kr/fs v0.1.0 // indirect
github.com/lib/pq v1.0.0
github.com/minio/minio-go v6.0.13+incompatible
github.com/mitchellh/go-homedir v1.0.0 // indirect
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // 
indirect
github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742 // indirect
github.com/mongodb/mongo-go-driver v0.0.17
github.com/nats-io/gnatsd v1.4.1 // indirect
github.com/nats-io/go-nats v1.6.0
github.com/nats-io/nuid v1.0.0 // indirect
github.com/nimajalali/go-force v0.0.0-20180615191228-2b94c45dfae2
github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
github.com/pkg/errors v0.8.0
github.com/pkg/sftp v1.8.3
github.com/pmezard/go-difflib v1.0.0 // indirect
github.com/rs/xid v1.2.1 // indirect
github.com/rs/zerolog v1.9.1
github.com/santhosh-tekuri/jsonschema v1.2.2
github.com/smartystreets/goconvey v0.0.0-2019023459-a17d461953aa // 
indirect
github.com/spf13/cast v1.2.0
github.com/spf13/cobra v0.0.3
github.com/spf13/pflag v1.0.2
github.com/spf13/viper v1.2.0
github.com/stretchr/testify v1.2.2
github.com/tidwall/pretty v0.0.0-20180105212114-65a9db5fad51 // indirect
github.com/xdg/scram v0.0.0-20180814205039-7eeb5667e42c // indirect
github.com/xdg/stringprep v1.0.0 // indirect
github.com/zenazn/goji v0.0.0-20160507202103-64eb34159fe5 // indirect
go.opencensus.io v0.17.0 // indirect
golang.org/x/crypto v0.0.0-20180910181607-0e37d006457b
golang.org/x/net v0.0.0-20180911220305-26e67e76b6c3 // indirect

[go-nuts] Re: `gcloud app deploy` command choosing the wrong GOPATH

[fizzi36]

I have the same problem. Were you ever able to find the solution?

On Tuesday, January 8, 2019 at 5:42:37 AM UTC-8, aniruddh...@nytimes.com 
wrote:
>
> I am Using go1.11.4 for postgres connection and strictly using GAE 
> standard. My app.yaml is as below-
>
>
> runtime: go111
>
> service: alerting-postgre-service-ad
>
>
> In my main.go my imports are as below-
>
> package main
>  import (
> "database/sql"
> "encoding/json"
> "fmt"
> "log"
> "net/http"//"google.golang.org/appengine"
> _ "github.com/GoogleCloudPlatform/cloudsqlproxy/proxy/dialers/postgres")
>
>
> when I execute command - gcloud app deploy app.yaml on console I get 
> follwoing error-
>
>
> *ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build 
> a3389d5a-7969-4211-9c96-2377f487b604 status: FAILURE. *
>
> *Build error details: srv/main.go:10:2: cannot find package 
> "github.com/GoogleCloudPlatform/cloudsql-proxy/proxy/dialers/postgres 
> "
>  
> in any of: *
>
>
> */usr/local/go/src/github.com/GoogleCloudPlatform/cloudsql-proxy/proxy/dialers/postgres
>  
>  
> (from $GOROOT) *
>
> */tmp/staging321436436/srv/gopath/src/github.com/GoogleCloudPlatform/cloudsql-proxy/proxy/dialers/postgres
>  
>  
> (from $GOPATH)*
>
>
>
> As I am using windows 10, I don't know where to fix my gopath as my gopath 
> is already set to C:\Users\aniruddh.dwivedi\go while goroot is C:\Go
>
>
> I have uninstalled golang and tried after installing it again but nothing 
> works for me. Please help me in this case.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Why Go? What is the most important feature that led to you becoming a Go programmer?

[Dan Kortschak]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why Go? What is the most important feature that led to you becoming a Go programmer?

[Louki Sumirniy]

These two points really nail it:

On Wednesday, 27 February 2019 11:02:23 UTC+1, Chris Hopkins wrote:
>
>
> What made me stay is the clarity and simplicity. So many languages seem to 
> be an exercise in showing off how clever you are, by using x clever 
> pattern. Go doesn't seem to suffer this.
>

 C++ code you find in cryptocurrency server particularly demonstrate this 
problem. Ok, so partly, I just don't understand the generic syntax, the 
template, and I find its syntax absolutely repulsive (and completely 
unintuitive). But it's not just that, the code is cryptic and incredibly 
disorganised, and I guess this is where the novel build system of Go really 
shows its superiority - CPP syntax is also very cryptic. More than one 
include root... We have modules now, and right off the bat it eliminates so 
much of the manual handling that makes code like this so irritating to 
adopt and work with.
 

> If I could just use it for the embedded stuff i do...
>

Go would require a separate runtime system for embedded, due to the usually 
tiny resources. The MIT-PDOS Biscuit research OS is an example of a 
modified runtime designed for launching off bare metal, this might be a 
direction that could do with being further developed. Embedded software 
tends to need very fussy, hand-written and careful handling of resources. 
Mainly I think for these cases one simply has to expose more of GC's 
controls and possibly write different resource managers (gc modes, perhasp) 
better suited to such environments.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why Go? What is the most important feature that led to you becoming a Go programmer?

[Chris Hopkins]

What brought me to it was the concurrency. I spent my entire career 
frustrated by not only how concurrency wasn't more of a thing in popular 
languages, but also how so many people didn't seem to think it was a 
problem. I pounced on Go when I heard about it. (Although I am currently 
fluttering my eyelashes at Halide...)

What made me stay is the clarity and simplicity. So many languages seem to 
be an exercise in showing off how clever you are, by using x clever 
pattern. Go doesn't seem to suffer this.

If I could just use it for the embedded stuff i do...

Chris

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why Go? What is the most important feature that led to you becoming a Go programmer?

[minforth]

Am Dienstag, 26. Februar 2019 13:07:58 UTC+1 schrieb Louki Sumirniy:
>
>
> Many other languages force you to really separate coding and architecting, 
> Go lets you do it all on-the-fly.
>

This is fine as long as you work your design around the capabilites of 
Golang. If not...

Sounds trivial but it is not. Different data models, the famous lacking 
generics, etc. can really make Golang not to be the right tool for the job.

Otherwise I think you are right. Golang hits a sweet spot concerning the 
limited average human brain capacity - and programmers are only humans 
after all.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] New ABI in 1.12 broke Go-QML

[Ignazio Di Napoli]

I was able to solve, I will comment into the issue how I did it.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] New ABI in 1.12 broke Go-QML

[Ignazio Di Napoli]

The new ABI broke Go-QML compilation 
(https://github.com/go-qml/qml/issues/190). The error is:

cdata.Ref: relocation target runtime.acquirem not defined for ABI0 (but is 
defined for ABIInternal)

cdata.Ref: relocation target runtime.releasem not defined for ABI0 (but is 
defined for ABIInternal)

Unfortunately using other Qt bindings would require to rewrite the UI part of 
my application from the ground up. Moreover, there are licensing issues with 
therecipe/qt and qamel misses some functionality I need.

So it would be great to be able to keep go-qml on life support.

I don't understand what the assembly code does and what the cdata package 
(which compilation fails) is for (I suppose it exposes some go runtime 
internals to C code).

The code is available at https://github.com/go-qml/qml/tree/v1/cdata.

Unfortunately, as stated in 
https://github.com/golang/go/issues/27539#issuecomment-467496599 about the code 
for cdata package, "reaching into the runtime implementation like this is 
really, really not supported".

This seems to contradict what in the proposal 
(https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md#compatibility),
 that is "the situations that cause these link failures [...] all have 
reasonable workarounds."

I tried to use //go:linkname, the suggested way, with no success.

Can please 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.
For more options, visit https://groups.google.com/d/optout.