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

[Mohamed Yousif]

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, mentioned that he worked for a company that used go
> to create a commercial password manager, using go's multi-platform and
> networking abilities.
>
> But I can't remember who, when or which company.
>
> I would like to at least consider this company and their product.
>
> Anyone remember? hints? links?
>
> 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.
>

-- 
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] Windows amd64 MSI Installer

[Andrew]

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 
"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?

[gplus]

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 
questions. Quick and easy. Try this with the 1300+ pages of C++ spec!

I also appreciate the intentional lack of inheritance, the stability of the 
language, the get-things-done mentality of the community (or large parts 
thereof), as opposed to discussing "clever" code constructs as the 
umpteenth "elegant" solution to the ever same problem, the 
libraries-not-frameworks attitude, and all the other awesome aspects of the 
language and the people around it.

Oh yes, and the garbage collector that clearly increases programmer 
productivity and reduces the number of possible bugs at the same time.


On Tuesday, February 26, 2019 at 1:07:58 PM UTC+1, 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 rFor eally 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.

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

[Ian Lance Taylor]

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.

> 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

[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.

Re: [go-nuts] distribution of go executables

[Space A.]

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 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.

Re: [go-nuts] distribution of go executables

[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.

Re: [go-nuts] distribution of go executables

[Space A.]

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.

Re: [go-nuts] distribution of go executables

[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.

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

[Gargi Sharma]

I meant the Section and SectionByType calls.

[ 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?
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.

-- 
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] Helping to fixing Windows virus scanner false positives

[ajstarks]

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*
* confused by the structure of Go binaries, which they don't see as often 
as*
* those compiled from other languages.*

On my Windows 10 machine running the Symmantec scanner the situation is not 
the
structure of the binary but the "reputation".  I get separate messages
running the go command or go build (one for the compiler, assembler and
linker) like this:

Event: Security Risk Found
Security risk detected: WS.Reputation.1
File: c:\Users\xx\Desktop\go\bin\go.exe
Location: Deleted or access blocked
Computer: xx
User: x
Action taken: Leave Alone succeeded

Looking up WS.Reputation.1 means:
(https://www.symantec.com/security-center/writeup/2010-051308-1854-99)

* WS.Reputation.1 is a detection for files that have a low reputation score*
* based on analyzing data from Symantec’s community of users and therefore*
* are likely to be security risks. Detections of this type are based on*
* Symantec’s reputation-based security technology. Because this detection 
is*
* based on a reputation score, it does not represent a specific class of*
* threat like adware or spyware, but instead applies to all threat*
* categories.*

* The reputation-based system uses "the wisdom of crowds" (Symantec’s tens 
of*
* millions of end users) connected to cloud-based intelligence to compute a*
* reputation score for an application, and in the process identify 
malicious*
* software in an entirely new way beyond traditional signatures and*
* behavior-based detection techniques.*

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.

I'm wondering if others in the Go community can help by reporting as well, 
raising Go's "reputation".

-- 
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.]

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.



среда, 27 февраля 2019 г., 2:18:45 UTC+3 пользователь Ian Lance Taylor 
написал:
>
> 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? 
>
> Yes, quite a few.  You may want to look at https://golang.org/wiki/GoUsers. 
>
>
> 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] Re: How do I update all direct and indirect dependencies in go.mod

[Francis Chuang]

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 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 
> requirements of your direct dependencies.
>
> There is a proposal to make that easier here, along with some related 
> discussion:
>
> https://github.com/golang/go/issues/28424
>
> Regards,
> thepudds
>
> On Tuesday, February 26, 2019 at 7:43:18 PM UTC-5, Francis Chuang wrote:
>>
>> 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 get -u`, it pulls in the latest versions of the dependencies 
>> as well as all the dependencies for running their tests on all platforms. 
>> In effect, my go.mod file has more then tripled in size. 
>>
>> Is there any way to update my direct (and some required indirect) 
>> dependencies required just to build my project in go.mod?
>>
>

-- 
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: do you use binary-only packages?

[Robert Engels]

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 automation for 
> oil&gas 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 
> not cut it as stated by others e.g. on 
> https://github.com/golang/go/issues/28152 ).
> 
> Just shutting a feature off like this means a huge loss for us.
> 
> Again, we wouldn't care too much about sharing source (clear or obfuscated) 
> but we wrote all the legal agreements around the BOP concept. We would have 
> to refactor to C which we tested (CGo that is) and it has significant 
> performance drop. 
> 
> But more than anything it's the sheer investment I made...
> 
> 
> Thanks for any further consideration
> 
>> On Thursday, October 18, 2018 at 1:16:43 PM UTC-4, Russ Cox wrote:
>> The go command supports "binary-only packages", in which 
>> the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg
>> but the corresponding source code is only a stub with relevant
>> imports (for linking), a special comment marking it as a binary-only
>> package, and perhaps documentation for exported API.
>> 
>> While the go command will use these packages if they exist in
>> GOROOT or GOPATH, 'go get' will not download them: 'go get'
>> is intentionally only about source code distribution.
>> 
>> Furthermore, binary-only packages only work when the build is
>> using the exact versions of whatever imported packages are
>> needed by the binary-only package. If there were any important
>> differences in a dependency between compilation and linking,
>> the binary-only portion might have stale information about details
>> of the imported package, such as type sizes, struct field offsets,
>> inlined function bodies, escape analysis decisions, and so on,
>> leading to silent memory corruption at runtime.
>> 
>> Binary-only packages also only work when the build is using the
>> exact version of the Go toolchain that was used for compilation.
>> This is at least enforced at link time, with the effect that if your
>> binary-only package only imports the standard library and you don't
>> use any special compilation flags, then the toolchain version check
>> suffices to avoid the silent memory corruption problem described in
>> the previous package. But if your package imports any non-standard
>> package for which that the eventual user might try to combine with
>> a different version, you're in trouble again.
>> 
>> Compiled Go programs also contain much richer amounts of runtime
>> information than compiled C programs, so that for example all the
>> details of type declarations, including struct definitions, are in the
>> compiled code, along with file names and line numbers for the compiled
>> code, and increasingly good debug information that was impossible to
>> turn off until very recently. Overall, a binary-only package obscures very 
>> little.
>> 
>> In short, binary-only packages:
>> 
>> - have never been supported by 'go get',
>> so you've had to go out of your way to use them,
>> - aren't even guaranteed to work when you do use them,
>> possibly leading to silent memory corruption, and
>> - still expose quite a lot more than most people would expect
>> about the original source code.
>> 
>> For these reasons, we're looking at removing binary-only package
>> support entirely.
>> 
>> If you use binary-only packages and think it's important to keep that
>> support around, please let us know either on this thread or at
>> golang.org/issue/28152. 
>> 
>> Thanks.
>> Russ
> 
> -- 
> 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.

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

[Pat Farrell]

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 and 
networking abilities.

But I can't remember who, when or which company.

I would like to at least consider this company and their product.

Anyone remember? hints? links?

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.

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

[thepudds1460]

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 
requirements of your direct dependencies.

There is a proposal to make that easier here, along with some related 
discussion:

https://github.com/golang/go/issues/28424

Regards,
thepudds

On Tuesday, February 26, 2019 at 7:43:18 PM UTC-5, Francis Chuang wrote:
>
> 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 get -u`, it pulls in the latest versions of the dependencies 
> as well as all the dependencies for running their tests on all platforms. 
> In effect, my go.mod file has more then tripled in size. 
>
> Is there any way to update my direct (and some required indirect) 
> dependencies required just to build my project in go.mod?
>

-- 
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] How do I update all direct and indirect dependencies in go.mod

[Francis Chuang]

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 get -u`, it pulls in the latest versions of the dependencies 
as well as all the dependencies for running their tests on all platforms. 
In effect, my go.mod file has more then tripled in size. 

Is there any way to update my direct (and some required indirect) 
dependencies required just to build my project in go.mod?

-- 
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]

(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 of your program
belongs to you.)

The tricky bit is that your compiled Go program isn't *just* your source,
it's the Go runtime as well, plus any other core Go libraries that you
import.  Because those are open source, your are required to distribute a
list of such third party copyrights & licenses either with your
documentation or in some UI with your program.

If you've ever delved into, say, an Android phone's "Settings -> About
Phone -> Legal Information -> Third Party Licenses" menu, you can see how
that might appear.  In the case of MongoDB, for instance, along with the
binaries in a tarball we ship a THIRD-PARTY-NOTICES text file with a list
of all open source packages and licenses used.  Either approach satisfies
the requirements of open source licenses.

Regards,
David

On Tue, Feb 26, 2019 at 6:18 PM Ian Lance Taylor  wrote:

> 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?
>
> Yes, quite a few.  You may want to look at https://golang.org/wiki/GoUsers
> .
>
> 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] Re: Go 1.12 is Released

[Ian Lance Taylor]

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.  Thanks.

You can still use your Go installation despite this error.  It's going
to be something odd.

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] Re: do you use binary-only packages?

[cos . pipero]

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&gas 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 not cut it as stated by others e.g. on 
https://github.com/golang/go/issues/28152 ).

Just shutting a feature off like this means a huge loss for us.

Again, we wouldn't care too much about sharing source (clear or obfuscated) 
but we wrote all the legal agreements around the BOP concept. We would have 
to refactor to C which we tested (CGo that is) and it has significant 
performance drop. 

But more than anything it's the sheer investment I made...


Thanks for any further consideration

On Thursday, October 18, 2018 at 1:16:43 PM UTC-4, Russ Cox wrote:
>
> The go command supports "binary-only packages", in which 
> the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg
> but the corresponding source code is only a stub with relevant
> imports (for linking), a special comment marking it as a binary-only
> package, and perhaps documentation for exported API.
>
> While the go command will use these packages if they exist in
> GOROOT or GOPATH, 'go get' will not download them: 'go get'
> is intentionally only about source code distribution.
>
> Furthermore, binary-only packages only work when the build is
> using the exact versions of whatever imported packages are
> needed by the binary-only package. If there were any important
> differences in a dependency between compilation and linking,
> the binary-only portion might have stale information about details
> of the imported package, such as type sizes, struct field offsets,
> inlined function bodies, escape analysis decisions, and so on,
> leading to silent memory corruption at runtime.
>
> Binary-only packages also only work when the build is using the
> exact version of the Go toolchain that was used for compilation.
> This is at least enforced at link time, with the effect that if your
> binary-only package only imports the standard library and you don't
> use any special compilation flags, then the toolchain version check
> suffices to avoid the silent memory corruption problem described in
> the previous package. But if your package imports any non-standard
> package for which that the eventual user might try to combine with
> a different version, you're in trouble again.
>
> Compiled Go programs also contain much richer amounts of runtime
> information than compiled C programs, so that for example all the
> details of type declarations, including struct definitions, are in the
> compiled code, along with file names and line numbers for the compiled
> code, and increasingly good debug information that was impossible to
> turn off until very recently. Overall, a binary-only package obscures very 
> little.
>
> In short, binary-only packages:
>
> - have never been supported by 'go get',
> so you've had to go out of your way to use them,
> - aren't even guaranteed to work when you do use them,
> possibly leading to silent memory corruption, and
> - still expose quite a lot more than most people would expect
> about the original source code.
>
> For these reasons, we're looking at removing binary-only package
> support entirely.
>
> If you use binary-only packages and think it's important to keep that
> support around, please let us know either on this thread or at
> golang.org/issue/28152. 
>
> Thanks.
> Russ
>

-- 
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

[Camilo Aguilar]

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 
/Users/c4milo/Projects/c4milo/go-darwin-amd64-bootstrap/.
Building Go toolchain1 using 
/Users/c4milo/Projects/c4milo/go-darwin-amd64-bootstrap/.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.


Building Go toolchain2 using go_bootstrap and Go toolchain1.


Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/amd64.

# Testing packages.
ok  archive/tar 0.059s
ok  archive/zip 2.284s
ok  bufio 0.080s
ok  bytes 0.634s
ok  compress/bzip2 0.119s
ok  compress/flate 0.916s
ok  compress/gzip 0.024s
ok  compress/lzw 0.017s
ok  compress/zlib 0.028s
ok  container/heap 0.024s
ok  container/list 0.017s
ok  container/ring 0.023s
ok  context 1.027s
ok  crypto 0.011s
ok  crypto/aes 0.058s
ok  crypto/cipher 0.921s
ok  crypto/des 0.031s
ok  crypto/dsa 0.030s
ok  crypto/ecdsa 0.344s
ok  crypto/elliptic 0.554s
ok  crypto/hmac 0.013s
ok  crypto/internal/subtle 0.016s
ok  crypto/md5 0.015s
ok  crypto/rand 0.058s
ok  crypto/rc4 0.057s
ok  crypto/rsa 0.101s
ok  crypto/sha1 0.037s
ok  crypto/sha256 0.014s
ok  crypto/sha512 0.018s
ok  crypto/subtle 0.020s



ok  crypto/tls 1.595s
ok  crypto/x509 3.853s
ok  database/sql 0.602s
ok  database/sql/driver 0.015s
ok  debug/dwarf 0.028s
ok  debug/elf 0.038s
ok  debug/gosym 4.764s
ok  debug/macho 0.023s
ok  debug/pe 0.021s
ok  debug/plan9obj 0.017s
ok  encoding/ascii85 0.017s
ok  encoding/asn1 0.018s
ok  encoding/base32 0.031s
ok  encoding/base64 0.017s
ok  encoding/binary 0.014s
ok  encoding/csv 0.025s
ok  encoding/gob 0.055s
ok  encoding/hex 0.016s
ok  encoding/json 0.848s
ok  encoding/pem 0.045s
ok  encoding/xml 0.036s
ok  errors 0.013s
ok  expvar 0.033s
ok  flag 0.012s
ok  fmt 0.265s
ok  go/ast 0.016s
ok  go/build 0.623s
ok  go/constant 0.014s
ok  go/doc 0.072s
ok  go/format 0.019s
ok  go/importer 0.427s
ok  go/internal/gccgoimporter 0.023s
ok  go/internal/gcimporter 0.719s
ok  go/internal/srcimporter 2.683s
ok  go/parser 0.053s
ok  go/printer 0.439s
ok  go/scanner 0.012s
ok  go/token 0.037s
ok  go/types 1.794s
ok  hash 0.013s
ok  hash/adler32 0.016s
ok  hash/crc32 0.016s
ok  hash/crc64 0.013s
ok  hash/fnv 0.012s
ok  html 0.027s
ok  html/template 0.058s
ok  image 0.142s
ok  image/color 0.036s
ok  image/draw 0.115s
ok  image/gif 0.445s
ok  image/jpeg 0.495s
ok  image/png 0.047s
ok  index/suffixarray 0.016s
ok  internal/cpu 0.040s
ok  internal/fmtsort 0.012s
ok  internal/poll 0.034s
ok  internal/singleflight 0.023s
ok  internal/trace 4.343s
ok  internal/x/crypto/chacha20poly1305 0.177s
ok  internal/x/crypto/cryptobyte 0.015s
ok  internal/x/crypto/curve25519 0.042s
ok  internal/x/crypto/hkdf 0.012s
ok  internal/x/crypto/internal/chacha20 0.069s
ok  internal/x/crypto/poly1305 0.019s
ok  internal/x/net/dns/dnsmessage 0.063s
ok  internal/x/net/http/httpguts 0.016s
ok  internal/x/net/http/httpproxy 0.020s
ok  internal/x/net/http2/hpack 0.015s
ok  internal/x/net/idna 0.012s
ok  internal/x/net/nettest 0.810s
ok  internal/x/net/route 0.023s
ok  internal/x/text/transform 0.012s
ok  internal/x/text/unicode/norm 0.012s
ok  internal/xcoff 0.033s
ok  io 0.037s
ok  io/ioutil 0.015s
ok  log 0.016s
ok  log/syslog 4.260s
ok  math 0.015s
ok  math/big 2.743s
ok  math/bits 0.019s
ok  math/cmplx 0.015s
ok  math/rand 3.563s
ok  mime 0.018s
ok  mime/multipart 0.489s
ok  mime/quotedprintable 0.116s
ok  net 6.212s
ok  net/http 3.320s
ok  net/http/cgi 0.839s
ok  net/http/cookiejar 0.038s
ok  net/http/fcgi 0.031s
ok  net/http/httptest 0.056s
ok  net/http/httptrace 0.030s
ok  net/http/httputil 0.089s
ok  net/http/internal 0.012s
ok  net/http/pprof 2.039s
ok  net/internal/socktest 0.016s
ok  net/mail 0.019s
ok  net/rpc 0.056s
ok  net/rpc/jsonrpc 0.033s
ok  net/smtp 0.048s
ok  net/textproto 0.018s
ok  net/url 0.023s
ok  os 1.012s
ok  os/exec 2.171s
ok  os/signal 4.737s
ok  os/user 0.020s
ok  path 0.011s
ok  path/filepath 0.063s
ok  plugin 0.015s
ok  reflect 0.165s
ok  regexp 0.108s
ok  regexp/syntax 1.347s
ok  runtime 30.389s
ok  runtime/debug 0.080s
ok  runtime/internal/atomic 0.162s
ok  runtime/internal/math 0.010s
ok  runtime/internal/sys 0.011s
ok  runtime/pprof 13.246s
ok  runtime/pprof/internal/profile 0.012s
ok  runtime/trace 1.846s
ok  sort 0.162s
ok  strconv 1.872s
ok  strings 0.451s
ok  sync 0.328s
ok  sync/atomic 0.044s
ok  syscall 0.096s
ok  testing 0.910s
ok  testing/quick 0.174s
ok  text/scanner 0.014s
ok  text/tabwriter 0.013s
ok  text/template 0.964s
ok  text/template/parse 0.019s
ok  time 2.620s
ok  unicode 0.015s
ok  unicode/utf16 0.013s
ok  unicode/utf8 0.018s
ok  cmd/addr2line 5.558s
ok  cmd/api 0.053s
ok  cmd/asm/internal/asm 1.340s
ok  cmd/asm/internal/lex 0.016s
ok  cmd/compile 0.015s
ok  cmd/compile/internal/gc 26.294s
ok  cmd/compile/internal

Re: [go-nuts] distribution of go executables

[Ian Lance Taylor]

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?

Yes, quite a few.  You may want to look at https://golang.org/wiki/GoUsers.

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)

[Ian Lance Taylor]

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 answers, what is more is that the Section(".gosymtab") has 
> a "SHT_PROGBITS" in the result. Anyone know why or what am i missing?
> the ELF has only one .symtab section, so these should be the one and the same

Which two calls do you mean?  The File type has these methods:
DynamicSymbols, ImportedSymbols, Symbols.

The .gosymtab section is not an ELF symbol table.  It holds the
information used for stack backtraces, including runtime.Callers and
friends.  The format is roughly as described at
https://golang.org/s/go12symtab, although that is out of date and
there have been various changes.

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] random errors after upgrade to Go1.12 + MacOS High Sierra

[Ulderico]

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   : runtime.throw(0x5862926, 0x1e)
svc.0   : /usr/local/go/src/runtime/panic.go:617 +0x72 
fp=0xc001079fa8 sp=0xc001079f78 pc=0x402f422
svc.0   : sync.throw(0x5862926, 0x1e)
svc.0   : /usr/local/go/src/runtime/panic.go:603 +0x35 
fp=0xc001079fc8 sp=0xc001079fa8 pc=0x402f3a5
svc.0   : sync.(*Mutex).Lock(0xc00045ace0)
svc.0   : /usr/local/go/src/sync/mutex.go:143 +0x15b 
fp=0xc00107a008 sp=0xc001079fc8 pc=0x40740db
svc.0   : sync.(*Once).Do(0xc00045ace0, 0xc00107a048)
svc.0   : /usr/local/go/src/sync/once.go:40 +0x3b 
fp=0xc00107a038 sp=0xc00107a008 pc=0x407435b
(this first seems to be a encapsulated sync.Once
var releaseOnce sync.Once
lockRelease := func() { releaseOnce.Do(func() { lock.Release() }) }
defer lockRelease()
)

And

svc.0   : runtime: nelems=170 nalloc=86 previous allocCount=85 
nfreed=65535
svc.0   : fatal error: sweep increased allocation count
svc.0   : 
svc.0   : goroutine 18 [running]:
svc.0   : runtime.throw(0x58677ea, 0x20)
svc.0   : /usr/local/go/src/runtime/panic.go:617 +0x72 
fp=0xc68660 sp=0xc68630 pc=0x402f422
svc.0   : runtime.(*mspan).sweep(0xb2a5190, 0xca2000, 
0x4059200)
svc.0   : /usr/local/go/src/runtime/mgcsweep.go:329 +0x8da 
fp=0xc68740 sp=0xc68660 pc=0x402427a
svc.0   : runtime.sweepone(0x5909220)
svc.0   : /usr/local/go/src/runtime/mgcsweep.go:136 +0x26e 
fp=0xc687a8 sp=0xc68740 pc=0x402374e
svc.0   : runtime.bgsweep(0xca2000)
svc.0   : /usr/local/go/src/runtime/mgcsweep.go:73 +0xbb 
fp=0xc687d8 sp=0xc687a8 pc=0x402342b
svc.0   : runtime.goexit()
svc.0   : /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 
fp=0xc687e0 sp=0xc687d8 pc=0x405e671
svc.0   : created by runtime.gcenable
svc.0   : /usr/local/go/src/runtime/mgc.go:208 +0x58

(we couldn't trace this one to any particular part of the code)

Has anyone been affected by these problems too?


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.

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

[gs051095]

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 answers, what is more is that the Section(".gosymtab") 
has a "SHT_PROGBITS" in the result. Anyone know why or what am i missing?
the ELF has only one .symtab section, so these should be the one and the 
same

-- 
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] distribution of go executables

[R Srinivasan]

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 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] efficient random float32 number generator?

[Ian Denhardt]

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 part of it is making
> > the raw bytes into float. I'm not sure - could you take 4 random bytes,
> > grab the unsafe pointer and cast back to float32?
>
> No, you could get one of many NANs.  However, converting uint16 to
> float32 (or float64) should be very efficient, then you have one
> floating point divide by constant to get the desired range.

See my comment elsewhere in the thread from yesterday; you could just
hard code the sign bit and the exponent (an exponent of -24 will make
sure you get the right range), and then fill in the fractional part of
the float with random bits.

-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] Re: trouble passing an argument to a script

[Tamás Gulácsi]

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 in ini format).
>
> If I hard code the file name in the script, it works, but 
>
> Code:
>
> =start 
> package main
>
> import (
> "fmt"
> "gopkg.in/alecthomas/kingpin.v2"
> "gopkg.in/ini.v1"
> "os"
> )
>
> var (
> config  = kingpin.Flag("config", "configuration 
> file").Short('c').Required().ExistingFile()
> url, api, user, pwd = parse_config()
> )
>
> func init() {
> kingpin.Parse()
> }
>
> func main() {
> fmt.Println("yay")
> }
>
> func parse_config() (string, string, string, string) {
> //cfg, err := ini.Load("api.conf")
> fmt.Printf("%v, %s, %T\n", config, config, config)
> cfg, err := ini.Load(config)
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
>
> url := cfg.Section("").Key("url").String()
> api := cfg.Section("").Key("api").String()
> user := cfg.Section("").Key("user").String()
> pwd := cfg.Section("").Key("password").String()
>
> return url, api, user, pwd
> }
>
> =end
> and when running it:
>
> $ go run yetanother.go --config api.conf 
> 0xc547e0, %!s(*string=0xc547e0), *string
> error parsing data source: unknown type '%!s(*string=0xc8ceb0)'
> exit status 1
>
> This must be pretty basic, but I'm stuck :(
>
> Any tips welcome.
>
> Thanks in advance.
>
> -- 
> regards,
> Natxo
>
>
>
https://godoc.org/gopkg.in/alecthomas/kingpin.v2#FlagClause.ExistingFile 
returns a *string (a pointer to a string),  
https://godoc.org/gopkg.in/ini.v1#Load wants a string - so dereference it:

cfg, err := ini.Load(*config)


-- 
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] efficient random float32 number generator?

[DrGo]

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   5000   32.1 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=4-12   5000   35.4 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=8-12   5000   32.0 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=16-12   5000   32.0 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=32-12   5000   32.1 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=64-12   5000   36.9 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=128-12   5000   31.6 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=256-12   5000   31.0 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=512-12   5000   36.1 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=1024-12   5000   31.8 
ns/op   0 B/op  0 allocs/op

## using pcg
BenchmarkScalingFreqDistributionSampler/n-levels=2-12   1  13.5 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=4-12   1  17.1 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=8-12   1  13.3 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=16-12   1  13.3 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=32-12   1  14.2 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=64-12   1  19.1 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=128-12   1  14.0 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=256-12   1  13.3 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=512-12   1  18.1 
ns/op   0 B/op  0 allocs/op
BenchmarkScalingFreqDistributionSampler/n-levels=1024-12   1  14.0 
ns/op   0 B/op  0 allocs/op

-- 
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] efficient random float32 number generator?

[DrGo]

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" 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] Help-Callback notification

[afriyie . abraham]

Hi,

Am trying to implement a case where a client sends a POST request to 
subscribe to some service to a server including a "nfStatusNotificationUri" 
in the JSON data.
The server responds with the subscription data, however after some time if 
there is a change in the subscritpion 
information in the server, the server have to send notification to the 
client about the changes.
I currently do not have an idea how to do this. I have implemented the POST 
subscription part but ave no idea how to implent the notification part.
Need help about how to do this. Thanks in advance.

This what i have done so far:

// server
// functions

func (m *NfInstanceDataAccess) Insertsub(nfinstancesub Subscriptions) error 
{
err := db.C(COLLECTION).Insert(&nfinstancesub)
return err
}

func CreateNewSubscriptionPost(w http.ResponseWriter, r *http.Request) {
var nfinstancesub Subscriptions
id := uuid.New()
subscriptionID := id.String()

if r.Header.Get("Accept") != "application/json" {
WriteError(w, ErrNotAcceptable)
return
}
if err := json.NewDecoder(r.Body).Decode(&nfinstancesub); err != nil {
respondWithError(w, http.StatusBadRequest, "Invalid request payload")
return
}
nfinstancesub.ID = bson.NewObjectId()
nfinstancesub.SubscriptionID = subscriptionID
if err := da.Insertsub(nfinstancesub); err != nil {
respondWithError(w, http.StatusInternalServerError, err.Error())
return
}
w.Header().Set("Response-Code", "201")
w.Header().Set("Response-Desc", "Success")
w.Header().Set("Cache-Control", "max-age=2592000") // 30 days
respondWithJson(w, http.StatusCreated, nfinstancesub)
}

// Main function

func main() {

http.HandleFunc("/nnrf-nfm/v1/subscriptions, CreateNewSubscriptionPost)

log.Fatal(http.ListenAndServe(":8080", nil))
}


The JSON data to request subscription including the notification 
uri "nfStatusNotificationUri".
Am using mongodb to store this json data request is sent.


{
  "nfStatusNotificationUri": "string",
  "subscriptionID": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "validityTime": "2019-02-11T09:45:52.015Z",
  "reqNotifEvents": [
"NF_REGISTERED",
"string"
  ],
  "plmnId": {
"mcc": "string",
"mnc": "string"
  },
  "notifCondition": {
"monitoredAttributes": [
  "string"
],
"unmonitoredAttributes": [
  "string"
]
  },
  "reqNfFqdn": "string"
}

Thanks in advance.

-- 
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] trouble passing an argument to a script

[Pawel Zadrozny]

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 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 := ini.Load(*config)

Thanks!

I had indeed already tried that but alas:

$ go run kk.go --config api.conf
, , string
open : no such file or directory
exit status 1

after dereferencing config, it appears to be empty.

Scratching my head ...
--
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.

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

[Sebastien Binet]

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()
>>> 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 := ini.Load(*config)
>>>
>>> Thanks!
>>
>> I had indeed already tried that but alas:
>>
>> $ go run kk.go --config api.conf
>> , , string
>> open : no such file or directory
>> exit status 1
>>
>> after dereferencing config, it appears to be empty.
>>
>>
> it appears that defining the config variable and the other variables
> globally does not work. If I define the url/api/user/pwd in main(), then I
> can use the config variable as expected (indeed with a pointer *config).
>
I believe (but I am no kingpin expert) that declaring them globally is fine.
what is probably the issue here is to call kingpin.Parse() during init().
try moving that code inside main() and see what gives.

hth,
-s

-- 
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] trouble passing an argument to a script

[Natxo Asenjo]

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, %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 := ini.Load(*config)
>>
>> Thanks!
>
> I had indeed already tried that but alas:
>
> $ go run kk.go --config api.conf
> , , string
> open : no such file or directory
> exit status 1
>
> after dereferencing config, it appears to be empty.
>
>
it appears that defining the config variable and the other variables
globally does not work. If I define the url/api/user/pwd in main(), then I
can use the config variable as expected (indeed with a pointer *config).

Thanks for the tip.

--
regards,
natxo

-- 
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] efficient random float32 number generator?

[Marvin Renich]

* 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 not sure - could you take 4 random bytes, 
> grab the unsafe pointer and cast back to float32?

No, you could get one of many NANs.  However, converting uint16 to
float32 (or float64) should be very efficient, then you have one
floating point divide by constant to get the desired range.

...Marvin

-- 
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] Why Go? What is the most important feature that led to you becoming a Go programmer?

[Louki Sumirniy]

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: Best way to do this in golang

[Louki Sumirniy]

When you say you only have read permissions, I assume you mean on the 
database server. Surely the application could generate and run a ticker or 
triggers to update the index when (some number of) changes are made on 
these tables (in some DBMS systems you could subscribe to notifications of 
updates on a specific database and/or table. Also, yes, if this is a 
frequent need in the application the database can specifically be told to 
create indices for the data, depending on the system in question, but this 
will obviously be distant from your field of influence.

It looks to me like you have a pretty fixed set of matching criteria so an 
index could return the subset very quickly. The Badger database is a good 
choice for creating the indices as you can easily encapsulate some part of 
the search index in the keys, which can optionally held in memory for super 
fast access, or at least in the case of Badger the key and value logs are 
separated so even on disk it's still faster if you can add something 
searchable to the keys with, while not overly reducing write speed.

On Tuesday, 26 February 2019 07:08:00 UTC+1, RZ wrote:
>
> Thanks Tamas,
>
> Query itself is slow if i include all url strings. it takes about 10 mins. 
> But when i hit one at a time, i see better response overall. Yes so was 
> planning on running them in parallel.
>
> We only have read permissions and hence i am not allowed to add new index, 
> but good idea, will try reaching out to Admin and see if they can add this.
>
> i have not tried that way of similar to, will try that as well.
>
>
> On Tuesday, 26 February 2019 00:36:26 UTC+5:30, Tamás Gulácsi wrote:
>>
>> How fast is the query? You can make it parallel, but if it is sliw, the 
>> you have to target that first.
>>
>> How big is the set of one user's all urls? How fast is to get this? Maybe 
>> adding some indexes may help
>>
>>
>> How fast is the query with one pattern only? Maybe combining them into a 
>> "similar to '%(abc|def|ghi)%'" would be faster?
>>
>>

-- 
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: Best way to do this in golang

[Louki Sumirniy]

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 lines of code to implement the shortcuts. The OR operator in Go can 
indeed be parallelised, but you would be limited by the number of CPU 
cores, so again, prioritisation of more important results means you could 
find them and respond on that item even as the rest are being tested.

On Tuesday, 26 February 2019 07:08:00 UTC+1, RZ wrote:
>
> Thanks Tamas,
>
> Query itself is slow if i include all url strings. it takes about 10 mins. 
> But when i hit one at a time, i see better response overall. Yes so was 
> planning on running them in parallel.
>
> We only have read permissions and hence i am not allowed to add new index, 
> but good idea, will try reaching out to Admin and see if they can add this.
>
> i have not tried that way of similar to, will try that as well.
>
>
> On Tuesday, 26 February 2019 00:36:26 UTC+5:30, Tamás Gulácsi wrote:
>>
>> How fast is the query? You can make it parallel, but if it is sliw, the 
>> you have to target that first.
>>
>> How big is the set of one user's all urls? How fast is to get this? Maybe 
>> adding some indexes may help
>>
>>
>> How fast is the query with one pattern only? Maybe combining them into a 
>> "similar to '%(abc|def|ghi)%'" would be faster?
>>
>>

-- 
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] efficient random float32 number generator?

[Louki Sumirniy]

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, 
grab the unsafe pointer and cast back to float32?

On Tuesday, 26 February 2019 00:16:20 UTC+1, Rob 'Commander' Pike wrote:
>
> If you don't need precision, just generate ints and scale them.
>
> -rob
>
>
> On Tue, Feb 26, 2019 at 9:39 AM DrGo > 
> wrote:
>
>> Thanks Ian,
>> The std lib float32 is slow for my purpose. In my benchmarking it is 
>> actually slower than the float64. But I don’t even need float16 precision.
>> I am working on implementing othe alias method for sampling from a fixed 
>> freq dist with possibly thousands of arbitrary values. So the rng doesn’t 
>> need to be precise or high quality because of rounding eg a rn of .67895 
>> might end up selecting the same arbitrary value as .67091 or even .65!!
>> https://en.m.wikipedia.org/wiki/Alias_method
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@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.

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

[Volker Dobler]

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 fast and not statistics at all you could
use a constant like 0.234. Won't get any faster.
But perhaps that's too less "Statistical performance".

V.

-- 
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] trouble passing an argument to a script

[Natxo Asenjo]

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)
> should be replaced with:
>  fmt.Printf("%v, %s, %T\n", *config, *config, *config)
>  cfg, err := ini.Load(*config)
>
> Thanks!

I had indeed already tried that but alas:

$ go run kk.go --config api.conf 
, , string
open : no such file or directory
exit status 1

after dereferencing config, it appears to be empty.

Scratching my head ...

-- 
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] trouble passing an argument to a script

[Sebastien Binet]

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 := ini.Load(*config)

hth,
-s

On Tue, Feb 26, 2019 at 10:46 AM Natxo Asenjo 
wrote:

> 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:
>
> =start 
> package main
>
> import (
> "fmt"
> "gopkg.in/alecthomas/kingpin.v2"
> "gopkg.in/ini.v1"
> "os"
> )
>
> var (
> config  = kingpin.Flag("config", "configuration
> file").Short('c').Required().ExistingFile()
> url, api, user, pwd = parse_config()
> )
>
> func init() {
> kingpin.Parse()
> }
>
> func main() {
> fmt.Println("yay")
> }
>
> func parse_config() (string, string, string, string) {
> //cfg, err := ini.Load("api.conf")
> fmt.Printf("%v, %s, %T\n", config, config, config)
> cfg, err := ini.Load(config)
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
>
> url := cfg.Section("").Key("url").String()
> api := cfg.Section("").Key("api").String()
> user := cfg.Section("").Key("user").String()
> pwd := cfg.Section("").Key("password").String()
>
> return url, api, user, pwd
> }
>
> =end
> and when running it:
>
> $ go run yetanother.go --config api.conf
> 0xc547e0, %!s(*string=0xc547e0), *string
> error parsing data source: unknown type '%!s(*string=0xc8ceb0)'
> exit status 1
>
> This must be pretty basic, but I'm stuck :(
>
> Any tips welcome.
>
> Thanks in advance.
>
> --
> regards,
> Natxo
>
>
> --
> 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.

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

[Natxo Asenjo]

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:

=start 
package main

import (
"fmt"
"gopkg.in/alecthomas/kingpin.v2"
"gopkg.in/ini.v1"
"os"
)

var (
config  = kingpin.Flag("config", "configuration 
file").Short('c').Required().ExistingFile()
url, api, user, pwd = parse_config()
)

func init() {
kingpin.Parse()
}

func main() {
fmt.Println("yay")
}

func parse_config() (string, string, string, string) {
//cfg, err := ini.Load("api.conf")
fmt.Printf("%v, %s, %T\n", config, config, config)
cfg, err := ini.Load(config)
if err != nil {
fmt.Println(err)
os.Exit(1)
}

url := cfg.Section("").Key("url").String()
api := cfg.Section("").Key("api").String()
user := cfg.Section("").Key("user").String()
pwd := cfg.Section("").Key("password").String()

return url, api, user, pwd
}

=end
and when running it:

$ go run yetanother.go --config api.conf 
0xc547e0, %!s(*string=0xc547e0), *string
error parsing data source: unknown type '%!s(*string=0xc8ceb0)'
exit status 1

This must be pretty basic, but I'm stuck :(

Any tips welcome.

Thanks in advance.

-- 
regards,
Natxo


-- 
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] Does gc hate me?

[yangwuist]

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, 2019 at 4:36 AM > wrote:
>
> Yesterday you showed us an incorrect use of unsafe.Pointers while 
> interacting with C. It might be the same/similar problem. The lines 
> indicated in your post all allocate memory and may trigger GC, yes, but 
> they per se are improbable to crash the process. I think the crash is 
> caused by memory corruption which happened way before executing those lines.
>
> Without a complete, self-contained, minimal reproducer it's next to 
> impossible to see where is the problem rooted.
>
> -- 
>
> -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.