Re: [go-nuts] commercial (?) password manager written in go (like lastpass, dashlane, etc.)

1password? They are sponsoring many of gopher conferences. On Wed, 27 Feb 2019 at 3:11 AM, Pat Farrell wrote: > I've been reading the group for a long time, and have vague memories that > someone from a company responded to a technical question posted with a nice > answer and as an aside,

[go-nuts] Windows amd64 MSI Installer

The Go 1.12 Windows amd64 MSI Installer spend 3+ minutes to "Computing space requirement". Is this normal? Or can I skip this step? 12G RAM Windows 10 Local Disk (C:) NTFS 456G free of 722G AMD A10 Thanks. -- You received this message because you are subscribed to the Google Groups

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

For me, the first thing that stood out was the readability. Clear syntax without distractions or cryptic ornamentation. This becomes especially obvious when reading other people's code. Then the small and clear language spec. For me this document is the first stop for looking up language

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

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 >

Re: [go-nuts] distribution of go executables

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

Re: [go-nuts] distribution of go executables

Executable is not derivative work to stdlib or anything. Go's repo license covers only repo. Stdlib is not redistributed when you compile binary. It has nothing to do with GPL. Go's license is simple and clear. ср, 27 февр. 2019 г., 6:00 Dan Kortschak : > Probably not. The executable is a

Re: [go-nuts] distribution of go executables

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

Re: [go-nuts] distribution of go executables

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"

Re: [go-nuts] distribution of go executables

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: [go-nuts] Section(".gosymtab") vs SectionByType(elf.SHT_SYMTAB)

I meant the Section and SectionByType calls. [ 6] .gosymtab PROGBITS 004d7758 000d7758 A 0 0 1 [22] .symtab SYMTAB 002aa000 00012c30 0018

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

One annoyance for gophers on Windows is the false positives from virus scanners when running the Go toolchain. This is mentioned in the FAQ: * This is a common occurrence, especially on Windows machines, and is almost* * always a false positive. Commercial virus scanning programs are often* *

Re: [go-nuts] distribution of go executables

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

[go-nuts] Re: How do I update all direct and indirect dependencies in go.mod

Thanks for the tip! I've subscribed to your github issue as well. Hopefully, it will be implemented in 1.13, as I feel that this is a pretty common usecase. On Wednesday, February 27, 2019 at 12:06:13 PM UTC+11, thepud...@gmail.com wrote: > > Hi Francis, > > To ask that your direct

Re: [go-nuts] Re: do you use binary-only packages?

I read the issue, and am unclear as to why a plug-in wouldn’t support your use case? > On Feb 26, 2019, at 6:19 PM, cos.pip...@gmail.com wrote: > > Has this been finally decided or is there still room to save this feature? > > We have invested all last year building an SDK (industrial

[go-nuts] commercial (?) password manager written in go (like lastpass, dashlane, etc.)

I've been reading the group for a long time, and have vague memories that someone from a company responded to a technical question posted with a nice answer and as an aside, mentioned that he worked for a company that used go to create a commercial password manager, using go's multi-platform

[go-nuts] Re: How do I update all direct and indirect dependencies in go.mod

Hi Francis, To ask that your direct dependencies be upgraded to their latest available versions, you can do the following in Go 1.11 or 1.12: go get $(go list -f '{{if not (or .Main .Indirect)}}{{.Path}}{{end}}' -m all) Your indirect dependencies will be updated as needed according to the

[go-nuts] How do I update all direct and indirect dependencies in go.mod

I have dependencies (direct and some indirect) listed in my go.mod file. This was initially populated using `go ./...` after creating the go.mod using `go mod init`. I now want to upgrade the dependencies and the indirect dependencies in the go.mod file to their latest versions. If I run `go

Re: [go-nuts] distribution of go executables

(IANAL; this is not legal advice) Generally, the historic principle has been that your source code transformed by an open source compiler to produce your binary is unrestricted. (Interesting historical note, the Perl Artistic License is one of the few licenses that was explicit that the output

Re: [go-nuts] Re: Go 1.12 is Released

On Tue, Feb 26, 2019 at 4:04 PM Camilo Aguilar wrote: > > Congrats and thank you for a new release! > > I was trying to build it from source and ran into the following error, any > hints about what I'm missing are appreciated: Odd. Please open a bug report at https://golang.org/issue/new.

[go-nuts] Re: do you use binary-only packages?

Has this been finally decided or is there still room to save this feature? We have invested all last year building an SDK (industrial automation for oil and pharma) we have two customer on a paying beta agreement. Many have spoken to this rather common scenario to protect IP (no, plugins do

[go-nuts] Re: Go 1.12 is Released

Congrats and thank you for a new release! I was trying to build it from source and ran into the following error, any hints about what I'm missing are appreciated: c4milo at camilompb in ~/Projects/c4milo/go/src on release-branch.go1.12 [$] $ ./all.bash Building Go cmd/dist using

Re: [go-nuts] distribution of go executables

On Tue, Feb 26, 2019 at 10:59 AM R Srinivasan wrote: > > what if any are the licensing requirements to distribute a "go" produced > executable? See https://go.googlesource.com/go/+/refs/heads/master/LICENSE . The requirements are minimal. > are there any "commercial" products built with go?

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

On Tue, Feb 26, 2019 at 12:51 PM wrote: > > In the debug/elf library(https://golang.org/pkg/debug/elf/), there are two > calls for getting the symbol table. To me it seems like these two calls > should be equivalent, both fetching the symbol table. But when I run these I > get two different

[go-nuts] random errors after upgrade to Go1.12 + MacOS High Sierra

Hi, A colleague of mine is getting random errors after upgrading to Go 1.12 in High Sierra, he would see among the errors these: svc.0 : fatal error: sync: inconsistent mutex state svc.0 : svc.0 : goroutine 138 [running]: svc.0 :

[go-nuts] distribution of go executables

what if any are the licensing requirements to distribute a "go" produced executable? are there any "commercial" products built with go? thanks for any info, srini -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

Re: [go-nuts] efficient random float32 number generator?

Quoting Marvin Renich (2019-02-26 07:11:47) > * Louki Sumirniy [190226 06:22]: > > Assuming there is bytes in the system's entropy pool, you can also skip the > > scrambling step, though I don't know what overhead consuming these bytes > > entails compared to a standard PRNG. Then the biggest

[go-nuts] Re: trouble passing an argument to a script

2019. február 26., kedd 10:46:44 UTC+1 időpontban Natxo Asenjo a következőt írta: > > hi, > > I am writing a script that accepts arguments and flags (using kingpin) but > am failing miserably so far. One of the arguments is a file name, which > should be then loaded by an ini library (file is

Re: [go-nuts] efficient random float32 number generator?

nice speedup using https://github.com/MichaelTJones/pcg ## using stdlb math/rand (Go 1.11.5) pkg: github.com/drgo/abm/rng BenchmarkScalingFreqDistributionSampler/n-levels=2-12

Re: [go-nuts] efficient random float32 number generator?

Thanks everyone for helpful feedback, What do people think about the approach explained here http://iquilezles.org/www/articles/sfrand/sfrand.htm? Any possible disadvantages in a Go implementation? -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] trouble passing an argument to a script

Try to use absolute path to config file. import "filepath" configPath := filepath.Abs(filepath.Clean(*config)) cfg, err := ini.Load(configPath) On 26.02.2019 10:57, Natxo Asenjo wrote: hi, On Tuesday, February 26, 2019 at 10:51:28 AM UTC+1, Sebastien Binet wrote: from the

Re: [go-nuts] trouble passing an argument to a script

On Tue, Feb 26, 2019 at 2:09 PM Natxo Asenjo wrote: > > > On Tue, Feb 26, 2019 at 10:58 AM Natxo Asenjo > wrote: > >> >> hi, >> >> On Tuesday, February 26, 2019 at 10:51:28 AM UTC+1, Sebastien Binet wrote: >>> >>> from the compilation error, it would seem kingpin.Flag...ExistingFile() >>>

Re: [go-nuts] trouble passing an argument to a script

On Tue, Feb 26, 2019 at 10:58 AM Natxo Asenjo wrote: > > hi, > > On Tuesday, February 26, 2019 at 10:51:28 AM UTC+1, Sebastien Binet wrote: >> >> from the compilation error, it would seem kingpin.Flag...ExistingFile() >> returns a *string, not a string. >> so these lines: >> fmt.Printf("%v, %s,

Re: [go-nuts] efficient random float32 number generator?

* Louki Sumirniy [190226 06:22]: > Assuming there is bytes in the system's entropy pool, you can also skip the > scrambling step, though I don't know what overhead consuming these bytes > entails compared to a standard PRNG. Then the biggest part of it is making > the raw bytes into float. I'm

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

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

[go-nuts] Re: Best way to do this in golang

I never went that far into learning SQL, but I assume that 'LIKE' is a substring match. As I see it, the two ways to improve the speed of it are to prioritise the easier to detect, and most frequent conditions, and whenever there is a shortcut, use it. This might mean double or more as many

Re: [go-nuts] efficient random float32 number generator?

Assuming there is bytes in the system's entropy pool, you can also skip the scrambling step, though I don't know what overhead consuming these bytes entails compared to a standard PRNG. Then the biggest part of it is making the raw bytes into float. I'm not sure - could you take 4 random bytes,

[go-nuts] Re: efficient random float32 number generator?

On Monday, 25 February 2019 23:01:39 UTC+1, DrGo wrote: > > what is the fastest possible algorithm to generate a float32 > pseudo-random number in [0.0,1.0)? > need to generate billions of numbers. Statistical performance and security > (and even space) are not a priority. > If all you care is

Re: [go-nuts] trouble passing an argument to a script

hi, On Tuesday, February 26, 2019 at 10:51:28 AM UTC+1, Sebastien Binet wrote: > > from the compilation error, it would seem kingpin.Flag...ExistingFile() > returns a *string, not a string. > so these lines: > fmt.Printf("%v, %s, %T\n", config, config, config) > cfg, err := ini.Load(config) >

Re: [go-nuts] trouble passing an argument to a script

from the compilation error, it would seem kingpin.Flag...ExistingFile() returns a *string, not a string. so these lines: fmt.Printf("%v, %s, %T\n", config, config, config) cfg, err := ini.Load(config) should be replaced with: fmt.Printf("%v, %s, %T\n", *config, *config, *config) cfg, err :=

[go-nuts] trouble passing an argument to a script

hi, I am writing a script that accepts arguments and flags (using kingpin) but am failing miserably so far. One of the arguments is a file name, which should be then loaded by an ini library (file is in ini format). If I hard code the file name in the script, it works, but Code:

Re: [go-nuts] Does gc hate me?

Yes, the problem is solved with the help of Tamás Gulácsi , and I'm trying to dig out the reason of my mistake there. Thank you all! On Tuesday, February 26, 2019 at 1:40:40 PM UTC+8, Jan Mercl wrote: > > > On Tue, Feb 26,