[go-nuts] beginner question about chanels

[sam]

gobyexample.com/channel-buffering explains this really nicely with a runnable 
example showing the difference!

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

[sam]

Hi all,

I'm having an issue with a messaging server I'm trying to write in Go (my 
first real Go project). I'm having an issue that I've not come across 
before in Go - the code executes as expected, then hangs after a second or 
so indefinitely, no errors, no logs showing it's exited. The code is 
available here 
<https://gitlab.com/samisagit/go-im-server/blob/changed-redis-handler-buggy/src/main.go#L110>.
 
The functions of note are RedisWriteHandler and addRedisSender. In func 
main I'm seeding a channel with the max amount of items (currently 100k) 
then starting RedisWriteHandler, this should auto scale up and down 
according to the length of the channel. However before it gets a chance to 
scale down it hangs. I've checked with redis-cli and the senders are still 
connected, but no more messages are coming though. Unfortunately I can't 
replicate this in the go playground as it's never going to return, and it 
will take too long and get kicked. I also asked this question here 
<https://stackoverflow.com/questions/50129226/golang-channels-getting-stuck> 
but it seems to have gone quiet.

Based on comments from a couple other questions in this group I've killed 
the process manually to get the stack trace which I'll attach, hopefully 
this is helpful.

Any thoughts would be greatly appreciated!

Thanks,

Sam

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


stacktrack-go-redis
Description: Binary data

[go-nuts] Re: Go routines hanging

[sam]

Please find my code here <https://play.golang.org/p/mrxbNFFOnco>, the 
playground won't run the code because of it's dependencies, but the issue 
may well be to do with these dependencies so I thought I'd better not 
remove them from the example.

On Friday, May 4, 2018 at 5:09:17 PM UTC+1, Aaron Alpar wrote:
>
>
> Can you distill the code you've provided into something that demonstrates 
> the hangs with the least code possible?
>
> Immediately I see a possible problem on lines 131 and 148 or your code: I 
> don't see specification of a timeout for the outgoing connection or sending 
> the message on the outgoing connection.  
>
> RedisWriteHandler will stall if either one of these outgoing requests 
> hangs.
>
> While timeouts will not fix your problem, they will allow you to further 
> diagnose the problem.
>
> - Aaron
>
> On Friday, May 4, 2018 at 7:24:56 AM UTC-7, s...@whites.team wrote:
>>
>> Hi all,
>>
>> I'm having an issue with a messaging server I'm trying to write in Go (my 
>> first real Go project). I'm having an issue that I've not come across 
>> before in Go - the code executes as expected, then hangs after a second or 
>> so indefinitely, no errors, no logs showing it's exited. The code is 
>> available here 
>> <https://gitlab.com/samisagit/go-im-server/blob/changed-redis-handler-buggy/src/main.go#L110>.
>>  
>> The functions of note are RedisWriteHandler and addRedisSender. In func 
>> main I'm seeding a channel with the max amount of items (currently 100k) 
>> then starting RedisWriteHandler, this should auto scale up and down 
>> according to the length of the channel. However before it gets a chance to 
>> scale down it hangs. I've checked with redis-cli and the senders are still 
>> connected, but no more messages are coming though. Unfortunately I can't 
>> replicate this in the go playground as it's never going to return, and it 
>> will take too long and get kicked. I also asked this question here 
>> <https://stackoverflow.com/questions/50129226/golang-channels-getting-stuck> 
>> but it seems to have gone quiet.
>>
>> Based on comments from a couple other questions in this group I've killed 
>> the process manually to get the stack trace which I'll attach, hopefully 
>> this is helpful.
>>
>> Any thoughts would be greatly appreciated!
>>
>> Thanks,
>>
>> Sam
>>
>

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

[sam]

Thanks for the tip! I tested this out, and all go routines are stopping, I 
ran a go routine with a non conditional for loop with a print and a sleep 
of 1 second, and this only ran twice, then nothing! How did you get around 
this?

On Saturday, May 5, 2018 at 12:31:41 AM UTC+1, Michael Andersen wrote:
>
> When you say it hangs, do you mean that every single goroutine hangs or 
> just some of them? If it is just some of them, I don't have any ideas, but 
> you could try running with -race to catch deadlocks. If it is all of them 
> then you might be running into a problem that I had where the GC suspends 
> all goroutines waiting for an unpreemptable goroutine to finish. 
>
> Try adding a goroutine that just prints "hello" and sleeps for a second in 
> a loop. If that goroutine stops printing hello then it is very likely to be 
> the problem I described.
>
> On Friday, May 4, 2018 at 7:24:56 AM UTC-7, s...@whites.team wrote:
>>
>> Hi all,
>>
>> I'm having an issue with a messaging server I'm trying to write in Go (my 
>> first real Go project). I'm having an issue that I've not come across 
>> before in Go - the code executes as expected, then hangs after a second or 
>> so indefinitely, no errors, no logs showing it's exited. The code is 
>> available here 
>> <https://gitlab.com/samisagit/go-im-server/blob/changed-redis-handler-buggy/src/main.go#L110>.
>>  
>> The functions of note are RedisWriteHandler and addRedisSender. In func 
>> main I'm seeding a channel with the max amount of items (currently 100k) 
>> then starting RedisWriteHandler, this should auto scale up and down 
>> according to the length of the channel. However before it gets a chance to 
>> scale down it hangs. I've checked with redis-cli and the senders are still 
>> connected, but no more messages are coming though. Unfortunately I can't 
>> replicate this in the go playground as it's never going to return, and it 
>> will take too long and get kicked. I also asked this question here 
>> <https://stackoverflow.com/questions/50129226/golang-channels-getting-stuck> 
>> but it seems to have gone quiet.
>>
>> Based on comments from a couple other questions in this group I've killed 
>> the process manually to get the stack trace which I'll attach, hopefully 
>> this is helpful.
>>
>> Any thoughts would be greatly appreciated!
>>
>> Thanks,
>>
>> Sam
>>
>

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

[sam]

debug.SetGCPercent(-1) 
stops the issue occurring - so I think we're onto a winner with the garbage 
collection idea! Is there something I'm doing wrong that is causing this GC 
binning off all of my go routines? Is there a way to avoid this, I'd 
obviously rather not turn off GC entirely.


On Friday, May 4, 2018 at 3:24:56 PM UTC+1, s...@whites.team wrote:
>
> Hi all,
>
> I'm having an issue with a messaging server I'm trying to write in Go (my 
> first real Go project). I'm having an issue that I've not come across 
> before in Go - the code executes as expected, then hangs after a second or 
> so indefinitely, no errors, no logs showing it's exited. The code is 
> available here 
> <https://gitlab.com/samisagit/go-im-server/blob/changed-redis-handler-buggy/src/main.go#L110>.
>  
> The functions of note are RedisWriteHandler and addRedisSender. In func 
> main I'm seeding a channel with the max amount of items (currently 100k) 
> then starting RedisWriteHandler, this should auto scale up and down 
> according to the length of the channel. However before it gets a chance to 
> scale down it hangs. I've checked with redis-cli and the senders are still 
> connected, but no more messages are coming though. Unfortunately I can't 
> replicate this in the go playground as it's never going to return, and it 
> will take too long and get kicked. I also asked this question here 
> <https://stackoverflow.com/questions/50129226/golang-channels-getting-stuck> 
> but it seems to have gone quiet.
>
> Based on comments from a couple other questions in this group I've killed 
> the process manually to get the stack trace which I'll attach, hopefully 
> this is helpful.
>
> Any thoughts would be greatly appreciated!
>
> Thanks,
>
> Sam
>

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

[sam]

Hi James,

Thanks for the tip - could you elaborate on your idea of a 'busy loop'? Is this 
a loop that is blocked, or just one that is currently operating on something? 
I'm not sure what causes GC to act on certain go routines.

I completely understand that getting the length of the channel isn't accurate, 
but that part of the program doesn't need to be particularly accurate or 
responsive, so it works okay in the instance.

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

[sam]

I see your point! Line 46 would never be in production, that was just to return 
for the specific situation I was testing, but the other loop would make more 
sense using sync. I'll take a look into sync functionality as I've not used it 
before, but that seems like the idiomatic way to do it! Thanks again!

-- 
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 you retrieve certs from the Windows Local Machine cert store with Go?

[Sam]

It seems like I should be able to use this:

store, err := syscall.CertOpenStore(syscall.CERT_STORE_PROV_MEMORY, 0, 0, 
windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, uintptr(unsafe.Pointer(my)))

but I think I am having trouble with the last argument. I only receive 
the CRYPT_E_NOT_FOUND error. I have tried to use the method from here: 
https://github.com/google/certtostore/blob/master/certtostore_windows.go 
but I don't know if it's out of date because it is the one that lead me to 
the error above. 

Has anyone done this before? How did you accomplish 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] Re: How do you retrieve certs from the Windows Local Machine cert store with Go?

[Sam]

I'd like to add that I have tried this but the store handle returned is zero
store, err := syscall.CertOpenStore(
windows.CERT_STORE_PROV_SYSTEM_W, 
0,
0,
windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, 
uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr("MY" 


On Tuesday, March 19, 2019 at 11:34:02 AM UTC-7, Sam wrote:
>
> It seems like I should be able to use this:
>
> store, err := syscall.CertOpenStore(syscall.CERT_STORE_PROV_MEMORY, 0, 0, 
> windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, uintptr(unsafe.Pointer(my)))
>
> but I think I am having trouble with the last argument. I only receive 
> the CRYPT_E_NOT_FOUND error. I have tried to use the method from here: 
> https://github.com/google/certtostore/blob/master/certtostore_windows.go 
> but I don't know if it's out of date because it is the one that lead me to 
> the error above. 
>
> Has anyone done this before? How did you accomplish 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] Re: How do you retrieve certs from the Windows Local Machine cert store with Go?

[Sam]

It turns out that the call I mentioned will indeed retrieve the Local 
Machine Personal Cert Store but you must run as Administrator on Windows to 
do so. Otherwise, the store is not found and no error is returned even 
though it is an access denied error (when run as C/C++).

On Tuesday, March 19, 2019 at 11:52:50 AM UTC-7, Sam wrote:
>
> I'd like to add that I have tried this but the store handle returned is 
> zero
> store, err := syscall.CertOpenStore(
> windows.CERT_STORE_PROV_SYSTEM_W, 
> 0,
> 0,
> windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, 
> uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr("MY" 
>
>
> On Tuesday, March 19, 2019 at 11:34:02 AM UTC-7, Sam wrote:
>>
>> It seems like I should be able to use this:
>>
>> store, err := syscall.CertOpenStore(syscall.CERT_STORE_PROV_MEMORY, 0, 0, 
>> windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, uintptr(unsafe.Pointer(my)))
>>
>> but I think I am having trouble with the last argument. I only receive 
>> the CRYPT_E_NOT_FOUND error. I have tried to use the method from here: 
>> https://github.com/google/certtostore/blob/master/certtostore_windows.go 
>> but I don't know if it's out of date because it is the one that lead me to 
>> the error above. 
>>
>> Has anyone done this before? How did you accomplish 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] Re: How do you retrieve certs from the Windows Local Machine cert store with Go?

[Sam]

Thanks, Krzysztof. I think the wrapper must be the problem. I tried 
calling syscall.GetLastError() but that came back as empty, too.

On Tuesday, March 19, 2019 at 3:22:35 PM UTC-7, Krzysztof Kowalczyk wrote:
>
> To get the real error, you probably need to call GetLastError() (
> https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-certopenstore#return-value
> ). 
>
> In principle, Go code should behave the same as C++ code, but 
> syscall.CertOpenStore is a wrapper which doesn't seem to use GetLastError() 
> as the doc requests and we can only guess what the C++ code you refer to 
> does (as CertOpenStore itself doesn't return an error code).
>
>
> On Tuesday, March 19, 2019 at 2:04:13 PM UTC-7, Sam wrote:
>>
>> It turns out that the call I mentioned will indeed retrieve the Local 
>> Machine Personal Cert Store but you must run as Administrator on Windows to 
>> do so. Otherwise, the store is not found and no error is returned even 
>> though it is an access denied error (when run as C/C++).
>>
>> On Tuesday, March 19, 2019 at 11:52:50 AM UTC-7, Sam wrote:
>>>
>>> I'd like to add that I have tried this but the store handle returned is 
>>> zero
>>> store, err := syscall.CertOpenStore(
>>> windows.CERT_STORE_PROV_SYSTEM_W, 
>>> 0,
>>> 0,
>>> windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, 
>>> uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr("MY" 
>>>
>>>
>>> On Tuesday, March 19, 2019 at 11:34:02 AM UTC-7, Sam wrote:
>>>>
>>>> It seems like I should be able to use this:
>>>>
>>>> store, err := syscall.CertOpenStore(syscall.CERT_STORE_PROV_MEMORY, 0, 
>>>> 0, windows.CERT_SYSTEM_STORE_LOCAL_MACHINE, uintptr(unsafe.Pointer(my)))
>>>>
>>>> but I think I am having trouble with the last argument. I only receive 
>>>> the CRYPT_E_NOT_FOUND error. I have tried to use the method from here: 
>>>> https://github.com/google/certtostore/blob/master/certtostore_windows.go 
>>>> but I don't know if it's out of date because it is the one that lead me to 
>>>> the error above. 
>>>>
>>>> Has anyone done this before? How did you accomplish 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] SQLite3 Support without CGo

[sam]

Hello,

I love the pure-Go compiler & tool-chain, especially how effortless it 
makes cross-compiling from our Linux development server for our estate of 
Windows PCs.

It even made me feel like it was worth the effort to create a DLL wrapper 
for SQLite3, so we can use it without CGo by bundling the pre-build DLL.
Plus I already have to bundle several other DLLs anyway, so this deployment 
method wasn't as much of an issue as the build process.

I've just put an early test version online 
here: https://github.com/iamacarpet/go-sqlite3-win64

Ideally I'd like to tweak it to worth with 32bit Windows too (should be 
fairly easy), plus Linux (which seems a bit more difficult).

>From what I've seen, dlopen is only supported via CGo 
(e.g. https://github.com/rainycape/dl).

Does anyone have advice on calling C shared libraries on Linux using 
pure-Go, like we can call DLLs on Windows?

Regards,
Samuel Melrose.

-- 
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] SQLite3 Support without CGo

[sam]

Thanks Konstantin,

That was very helpful.

I'll do some more looking into it, as taking your suggestion, the ulibc 
version (here 
) 
seems more simple than glibc.

I'm not going to kid myself though, it looks well beyond my current 
capabilities.

Is there anyone else with an interest in this kind of functionality 
(dlopen/dlsym to call C shared libs on Linux and other *nix) from pure Go, 
or at least, without CGo?
If so, maybe we could get someone from the main Go team to put it on the 
agenda?

I've heard the idea spoken of before and the support for it in Windows 
(DLLs) is fantastic!
Although I understand that's because most of the syscalls require calls to 
core DLLs, unlike Linux it seems.

Regards,
Samuel Melrose

On Monday, December 12, 2016 at 12:12:36 PM UTC, Konstantin Khomoutov wrote:
>
> On Mon, 12 Dec 2016 03:23:21 -0800 (PST) 
> s...@infitialis.com  wrote: 
>
> > Hello, 
> > 
> > I love the pure-Go compiler & tool-chain, especially how effortless 
> > it makes cross-compiling from our Linux development server for our 
> > estate of Windows PCs. 
> > 
> > It even made me feel like it was worth the effort to create a DLL 
> > wrapper for SQLite3, so we can use it without CGo by bundling the 
> > pre-build DLL. Plus I already have to bundle several other DLLs 
> > anyway, so this deployment method wasn't as much of an issue as the 
> > build process. 
> > 
> > I've just put an early test version online 
> > here: https://github.com/iamacarpet/go-sqlite3-win64 
> > 
> > Ideally I'd like to tweak it to worth with 32bit Windows too (should 
> > be fairly easy), plus Linux (which seems a bit more difficult). 
> > 
> > From what I've seen, dlopen is only supported via CGo 
> > (e.g. https://github.com/rainycape/dl). 
> > 
> > Does anyone have advice on calling C shared libraries on Linux using 
> > pure-Go, like we can call DLLs on Windows? 
>
> AFAIK, dlopen() requires cgo simply due to the fact it's not just a 
> thin wrapper around some syscall (like, say, open() is) but it's 
> actually implemented in libc.  So I think what you can do is to 
> start with [1] and chase the code paths from there. 
>
> Note that surely other libc implementations exist, such as muzzle and 
> ulibc, and they could have simpler implementations.  (Maybe, I'm not 
> sure.) 
>
> 1. https://github.com/lattera/glibc/blob/master/dlfcn/dlopen.c 
>
>

-- 
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: SQLite3 Support without CGo

[sam]

If anyone is interested, I've opened a ticket on GitHub 
(https://github.com/golang/go/issues/18296).

Please drop by and show your support.

On Monday, December 12, 2016 at 11:28:19 PM UTC, brainman wrote:
>
> I was toying with this idea myself.
>
> Maybe even going all the way with "pure" Go version - with something 
> similar to https://github.com/nkbai/go-memorydll :-)
>
> Alex
>

-- 
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: bufio.Reader.Buffered returns 0

[Sam]

Thanks Marvin, I think I understand now.
Sorry Ian I didn't even notice, but still...
I was using a net.Conn as the underlying reader. What I really needed was
the Peek() function but the documentation for Buffered() made it seem more
appropriate. I only needed to know the number of bytes received over the
connection before evicting and interpreting them.

intBytes, err := reader.Peek(4)
if err == nil {

// Decode integer

reader.Discard(4)

}

   -Sam

On Mon, Dec 16, 2019 at 7:27 AM Marvin Renich  wrote:

> * Ian Lance Taylor  [191215 23:05]:
> > The Buffered method [snip] tells you how
> > many bytes you can Read without causing a call to the underlying
> > Reader.
>
> I think this would be a significant improvement over the current
> ambiguous documentation.  It should adequately dispel any unrealistic
> expectations on the part of programmers who are reading the
> documentation.
>
> ...Marvin
>
> --
> 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/1smBsPOdFT0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20191216122707.4nx3gueuibk4dpua%40basil.wdw
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAFr%2B4KQe%3D4B%2BHF0k9y72RaW0NYZ_N2Jvap_moWtSdWiHmbDaLQ%40mail.gmail.com.

Re: [go-nuts] [Question] database/sql

[Sam Whited]

On Thu, Feb 8, 2018, at 07:28, Mandolyte wrote:
> I'd like to use the same program against multiple databases and set the 
> driver by configuration. But since the driver is in the source code, I 
> don't see a way to do that.
> 
> In other words, I don't want to include this in my code:
> 
> > import (
> > _ "github.com/lib/pq"
> > )
> 
> 
> I want to load it at run time. Is this possible?

If you are accessing your datastore through a common interface instead of 
making SQL queries directly, you could have each separate database you want to 
support be a different plugin (https://godoc.org/plugin)  that implements your 
datastore abstraction and load the correct plugin at runtime.

It hardly seems worth the complexity or maintainability cost though.

—Sam

-- 
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] Go += Package Versioning

[sam boyer]

Unfortunately, the rules also create some new perverse incentives, with 
some, IMO, nastier failure modes and remediations. That's one of the things 
i'll be elaborating on in my doc (hopefully) next week.

That said, one of the points Russ and i agree on is that dep does allow 
more expressiveness than is wise.

On Tuesday, February 20, 2018 at 1:55:59 PM UTC-5, David Anderson wrote:
>
> I love this. I want it now.
>
> I've struggled with `glide` and `dep` dependency hell a lot in my Go 
> projects (especially those that use the Kubernetes client library, which 
> abuses "I, the library author, can define byzantine constraints on my 
> users" to the extreme). The way I've described it informally is that 
> traditional "arbitrary version selection" algorithms create the wrong 
> incentive structure for library authors, in the sense that they have all 
> the power to lock versions arbitrarily, but bear none of the pain 
> associated with their decisions - instead, the binary author at the apex of 
> the dependency tree gets that pain. "Authority without responsibility" is 
> the death of many incentive structures.
>
> The proposed rules around semver and minimal version selection address 
> every pain point I've had so far, by aligning available authority with the 
> responsibility of the library authors: tell me what versions definitely 
> will *not* work, and I'll take it from there.
>
> Questions that arose during reading:
>
>- In the "defining Go modules" section, you say: "Although semantic 
>versions are strongly preferred, referring to specific commits will be 
>supported as well." Then, you specify that such commits order before 
>v0.0.0. To me, this suggests that this feature will be useless, because 
> any 
>non-trivial example will have *some* semver constraint somewhere in 
>the dependency tree, such that in practice commit-hash versions will 
> always 
>be overridden by minimal version selection. I don't have a solution to 
> this 
>(other than removing support for commit-hash versions), but it seems like 
>it's something to think about
>   - One alternative I considered, but discarded, was to order all 
>   tags and commits by their date, and run minimal version selection on 
> that. 
>   However, this doesn't work because semver tag dates don't grow 
>   monotonically - you might have 0.1.2 released after 0.2.0, which leads 
> to 
>   confusing behavior to the user - why did 0.2.0 get selected when 0.1.2 
> was 
>   a "better" minimal version?
>- Modules as zip archives: how do I discover which versions are 
>available? Minimal version selection seems to rely on being able to list 
>the version continuum for a module, so that constraints can be applied. 
>What's the expected way to do that?
>- Writing module files sounds like a job for a machine, in cases where 
>I don't care which version gets used. Can `goimports` (or a new sibling 
>tool) be taught to update module definitions based on my code?
>- No GOPATH required: YES! Thank you. I share Zellyn's question on 
>what happens to `go install` in this world. Does it go away? Does it 
>install to some new $GOBINARYINSTALL or somesuch?
>
> Haven't read the vgo tour yet, it may answer some of these. I may be back 
> with more :)
>
> - Dave
>
>
> On Tue, Feb 20, 2018 at 9:20 AM, Russ Cox > 
> wrote:
>
>> Hi everyone,
>>
>> I have a new blog post you might be interested in.
>> https://research.swtch.com/vgo.
>>
>> I'll try to watch this thread to answer any questions.
>>
>> Best,
>> 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...@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] Go += Package Versioning

[Sam Whited]

On Wed, Feb 21, 2018, at 13:49, Peter Bourgon wrote:
> > If not,  do I maintain separate /v2 and /v3 trees in my directory and 
> > copy/paste changes between them when I want to release security fixes as a 
> > point release?
> 
> Yes, this is what vgo expects.

This (and the other alternatives) seem like they break most common source 
control work flows to me. Any time we force users to change their workflow, I 
suspect we risk having to back track later. Even in cases where it may be 
better (eg. GOPATH which, like many people, I fought against when I first 
started using Go, but later came to love) if you force developers to 
drastically change their work flow, many of them will either push back, or, if 
it's only convention as this is, simply won't do it.

—Sam

-- 
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] Go += Package Versioning

[Sam Whited]

Something that is still unclear to me even after reading todays post is how I 
would manage the various package import paths created by the import 
compatibility rule.
The way this is currently done is through tools such as gopkg.in, will the 
import path be modified and rewritten by a package server in the future?
If not,  do I maintain separate /v2 and /v3 trees in my directory and 
copy/paste changes between them when I want to release security fixes as a 
point release?
Do I maintain separate branches that have a single /v2 or /v3 tree (if so, 
cherry-picking changes between them will be very difficult)?
Do I maintain separate repos and cherry pick or copy/paste files between them?

None of these sound especially appealing except perhapse having a server handle 
it for me, but this makes hosting my own packages harder.

—Sam

-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] Go += Package Versioning

[Sam Whited]

On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote:
> But wait. Wasn't there a mention of archive downloads instead of relying on
> the different VCS's?
> 
> In the GitHub case I guess it amount to downloading releases (or any commit
> I guess) as a zip or tarball.

My understanding was that the path is still relavant, so you'd need a /v2 
directory inside the zip file, which means you probably need it in your source 
code. However, if that is incorrect it fixes the problem.

—Sam

-- 
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] Go += Package Versioning

[Sam Whited]

On Wed, Feb 21, 2018, at 14:57, Russ Cox wrote:
> My plan is that this is in one of tomorrows' post. Sorry for seeming like
> I'm withholding information. I'm posting as they are finished. :-)

Sounds good, I look forward to reading it and continuing to digest the 
proposal. I've had a hard time coming to grips with all the implications of 
this proposal (it being a radical departure from the current state of the art), 
but the detailed posts have been very helpful; thanks for writing about it!

—Sam

-- 
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] What's the best way to maintain a package repository that have the major version in the import path?

[Sam Whited]

On Wed, Feb 21, 2018, at 22:35, alex.rou...@gmail.com wrote:
> vgo suggested that package developers put the major version into the import 
> path e.g. foo/v1. 
> However dealing with a VCS like git, this thought occur to me, what would 
> it look like when the project needs to move from v1 to v2?

This wasn't clear to me either, but it was pointed out that you can just change 
the "module" line in your go.mod file, eg.

module "example.net/mypackage/v2"

and you don't have to actually create a /v2 tree or move your code around at 
all.

—Sam

-- 
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 += Package Versioning

[Sam Whited]

On Sat, Feb 24, 2018, at 21:44, Sean Russell wrote:
> I'm working on adding support for Bitbucket, per your comment in #23950 
> <https://github.com/golang/go/issues/23950>.  I'm struggling a bit with 
> executing the tests in x/vgo -- should I expect vgo test to work?  I feel 
> like I'm missing something obvious.

FYI, there is an active CL for this here: https://golang.org/cl/95578

—Sam

-- 
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] How to refactor out this function

[Sam Whited]

You'd want to use a function that returns another function and takes the 
dependencies as arguments, something like this:

func Sender(b *B) func(m *tb.Message) {
return func(m *tb.Message) {
b.Send(m.Sender, "hello world")
}
}

s := Sender(b)
b.Handle("/hello", s)
b.Handle("/hi", s)


—Sam

On Tue, Aug 7, 2018, at 07:29, Tong Sun wrote:
> Hi, 
> 
> Consider this function:
> 
>   b.Handle("/hello", func(m *tb.Message) {
>   b.Send(m.Sender, "hello world")
>   })
> 
> 
> I tried to refactor the above function to func sayHi(m *tb.Message) {...}, 
>  so that I can give an alias to the above /hello command (say to define a 
> /hi command), but found that I cannot use bwithin it any more.
> 
> So, how to refactor out this function?


-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] buffer.WriteString Error case

[Sam Whited]

On Tue, Aug 7, 2018, at 19:43, Ian Lance Taylor wrote:
> So that it implements the (unexported) interface io.stringWriter.

I've wondered about this for a while; I find myself creating a StringWriter 
interface frequently in various projects. With all the other great standard 
interfaces in the io package, I wonder why this one wasn't exported?

—Sam

-- 
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: Nil Channels and Case Evaluation

[Sam Whited]

On Wed, Aug 8, 2018, at 04:40, Jan Mercl wrote:
> On Wed, Aug 8, 2018 at 11:15 AM Kaveh Shahbazian 
> wrote:
> 
> > But the error message (no cases) is confusing and unclear because
> obviously there is a case there.
> 
> I don't think it's confusing. The run-time message obviously does not talk
> about the compile-time case presence but about no case the select statement
> can, at run-time, randomly select one.

This doesn't seem obvious to me. It says "no cases" not "no selectable cases". 
While I would expect a compile time error if no case statements was the actual 
problem, I probably would have assumed that this meant that at first too.

—Sam

-- 
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] Host two distinct modules in one git repo?

[Sam Whited]

On Wed, Aug 8, 2018, at 11:29, Paul Jolly wrote:
> And incidentally, #modules on Gophers Slack will likely be a better
> place to work things through; it's got a great number of people
> helping/responding.

This thread is of great importance to a lot of people in the community, and the 
information you can get from it is very important. Please do not move it to a 
closed system like Slack. Not everyone can get a Slack account to participate, 
or even read any discussion that happens there. I for one would like to 
continue being able to see this discussion.

—Sam

-- 
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] Host two distinct modules in one git repo?

[Sam Whited]

On Wed, Aug 8, 2018, at 11:46, Paul Jolly wrote:
> My suggestion would be that, in cases such as this thread, any
> answers/insights derived from Slack be reported back to the go-nuts
> thread, for the benefit of anyone else following along. This also has
> the benefit of cutting out any noise along the road to those
> answers/insights.

This still doesn't allow people who may have something to contribute to 
participate. You're doing yourself a disservice by limiting the discussion to a 
smaller audience.

Chat in general isn't a good medium for this sort of things because you limit 
responses primarily to those in the same couple of timezones and who happen to 
not be busy, etc. and Slack is even worse by virtue of being impossible to use 
for a large number of people (for accessibility or legal reasons).

—Sam

-- 
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 this a go fmt bug? map[string]int{...}

[Sam Whited]

I can't reproduce this behavior. What version of Go are you running?

On Thu, Aug 9, 2018, at 14:27, russo...@gmail.com wrote:
> With the following code, running go fmt shows different behavior depending 
> on the (1) length of the keys, and (2) the order of the keys.
> 
> var m_19_chars = map[string]int{
>  "i":   0,
>  "iii": 0,
>  "iii": 0,
> }
> var m_18_chars = map[string]int{
>  "i":  0,
>  "iii":0,
>  "ii": 0,
> }
> var m_19_chars_reorder = map[string]int{
>  "i": 0,
>  "iii": 0,
>  "iii": 0,
> }
> 
> 
> In the 1st map, the unexpected behavior is that the first two values are 
> indented a different amount than the third.
> 
> In the 2nd map, the large key is reduced to 18 chars long.  All keys are 
> indented evenly, as expected.
> 
> In the 3rd map, the large key is now 19 chars long again, but is listed 
> second.  Now all 3 values are indented differently.
> 
> -- 
> 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.


-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] Re: Ternary ... again

[Sam Vilain]

I haven't seen all the discussion referenced, but I remember digging deep into the python language archives where Guido and others eventually relented and added ternaries (with the syntax "a if val else b"). I can't remember the argument which swung the consensus but the arguments against seem remarkably similar.Go does have a one-line ternary:var result = map[bool]string{false: "a", true: "b"}[test]It's less of a hack if you declare the lookup "table" separately.SamOn Aug 14, 2018 9:52 PM, Agniva De Sarker  wrote:Your answer is here - https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann  wrote:I’m new to Go and I imagine the idea of adding a ternary operator to Go has been discussed many times. Rather than repeat that, can someone point me to a discussion about why Go doesn’t add this? I’m struggling to understand why it is desirable to write code like this:

var color
if temperature > 100 {
    color = “red”
} else {
    color = “blue”
}

Instead of this:

var color = temperature > 100 ? “red” : “blue”

Is the ternary really so confusing that it justifies writing 6 lines of code instead of 1? I realize I could eliminate two lines like the following, but this isn’t a good idea if the values come from function calls since there would sometimes be needless function calls.

var color = “blue”
if temperature > 100 {
    color = “red”
}

---
R. Mark Volkmann
Object Computing, Inc.



-- 
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+unsubscribe@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: Ternary ... again

[Sam Vilain]

Looking back at the PEP ( https://www.python.org/dev/peps/pep-0308/ ), it
seems that the main argument was that people were working around the lack
of it in ways that led to subtle bugs using 'and' and 'or'.  I seem to have
inadvertently demonstrated that it's possible to do this in an obfuscated
(and not 0-alloc) way in go, so in principle this same argument applies
:-).  But unless my crazy ternary operator catches on (I assure you, I only
*very* rarely use it in real code), this argument can be considered moot.

To me the biggest reason to want a ternary operator is to make it easier on
the reader of the code.  If there's anything that go and python have in
common, it's that both languages are designed to be easy to read (though
with notable differences in emphasis about what makes it easy), and also
relatively easy to tell whether code is correct.

With a ternary, it's very clear that after the statement, the assignment
has occurred.

result = test ? "a" : "b"

With an `if' statement, you have to read a bit more:

var result string
if test {
  result = "a"
} else {
  result = "b"
}

In most cases the analysis is very simple to tell that both code branches
assign to `result'.  But there's a problem with this.  This is only easy to
see if someone doesn't then come along and insert extra code into those
nice welcoming code blocks:

var result string
if test {
  result = "a"
  // insert code here
  funcCall()
} else {
  // insert other code here
  funcCall2()
  result = "b"
}

As a result, as the code is modified, the condition that 'result has a
value' is not held and you end up with the zero value instead of something
you expected.

Of course it's not as bad as in python or C because there is a separate `='
and `:=' operator, but as you can see above, this doesn't always come into
play.  If you're assigning more than just an immediate constant, you
probably don't want to start with `:=' and then re-assign based on the
conditional.

It also gets much more complicated to follow for cases where you might want
to use a nested or chained ternary expression, or a more complicated value
construction which has many ternaries within it.

I've lost count of the times I've had to change:

return FooBar{
Field: blah,
}

To:

var foo FooBar
if someCond {
foo.Field = blah
} else {
foo.Field = bar
}
return foo

In my experience code is clearer and easier to read if it does *not*
contain re-assignments and branches, and temporary variables used only
once.  With a ternary operator, you can code like that for cases where it
makes sense.  I would much rather write:

return FooBar{
Field: someCond ? blah : bar,
}

my 2¢,
Sam


On Wed, Aug 15, 2018 at 1:13 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> In my opinion Python serves as a poor argument here. I tend to use Python
> as a example of a grab-bag language that adds any feature anyone considers
> useful - without considering the cost. An Anti-Go, if you will :)
> Gustavo Niemeyer actually wrote this up pretty well:
> https://blog.labix.org/2012/06/26/less-is-more-and-
> is-not-always-straightforward
>
> So, from my perspective, if you tell me "Python did not have ternary
> operators, but after long and hard discussions, they caved", what I'm
> hearing is "even *Python* didn't really need them". ;)
>
> (Disclaimer: This isn't meant as a dig at Python. I think Python is a
> great language. But its design goals are very different from Go's)
>
> On Wed, Aug 15, 2018 at 8:33 AM Sam Vilain  wrote:
>
>> I haven't seen all the discussion referenced, but I remember digging deep
>> into the python language archives where Guido and others eventually
>> relented and added ternaries (with the syntax "a if val else b"). I can't
>> remember the argument which swung the consensus but the arguments against
>> seem remarkably similar.
>>
>> Go does have a one-line ternary:
>>
>> var result = map[bool]string{false: "a", true: "b"}[test]
>>
>> It's less of a hack if you declare the lookup "table" separately.
>>
>> Sam
>>
>> On Aug 14, 2018 9:52 PM, Agniva De Sarker 
>> wrote:
>>
>> Your answer is here - https://tip.golang.org/doc/
>> faq#Does_Go_have_a_ternary_form.
>>
>>
>> On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann wrote:
>>
>> I’m new to Go and I imagine the idea of adding a ternary operator to Go
>> has been discussed many times. Rather than repeat that, can someone point
>> me to a discussion about why Go doesn’t add this? I’m struggli

Re: [go-nuts] Local cache of dependencies

[Sam Vilain]

Check out vendetta - it uses git submodules, so you keep a cache of the 3rd party repo in git but not the actual content. You get small repos and reproducible builds.SamOn Aug 22, 2018 3:25 PM, Conor Hackett  wrote:Hey Guys,So, adding your "vendor" directory to SCM is a contentious topic at best.I personally would rather not vendor the dependencies but I do need to keep the required code in my control and I consider third party repos out of my control.Similar to how maven works (and others I am sure), is there some tooling that will enable me to cache/store/save third party dependencies on my local machine/server etc in order toa) reduce operational risk of a repo/code disappearingb) potentially speeding up build timeThis post is more of a sanity check -- I have been searching for such tooling for a while now and am about to spin up a new project do something along these lines.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+unsubscribe@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] How to deal with binaries compilation with go modules enabled?

[Sam Whited]

FWIW, I have the same issue (I have to unset GO111MODULE before attempting to 
fetch a binary or before building Go) and there appear to be several comments 
on the closed issue suggesting that this is still a problem:

https://golang.org/issues/26639

I just tested this on tip (currently devel +360771e422) but haven't dug in 
further.

—Sam

On Thu, Aug 30, 2018, at 13:29, Denis Cheremisov wrote:
> strange, still the same
> 
> $ go get -x -u golang.org/x/tools/cmd/goimports 
> go: cannot find main module; see 'go help modules'
> 
> I am using 
> 
> $ go version
> go version go1.11 linux/amd64
> 
> with
> 
> export GO111MODULE=on
> 
> 
> 
> четверг, 30 августа 2018 г., 18:21:45 UTC+3 пользователь Ian Davis написал:
> >
> >
> > On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote:
> >
> > Hi!
> > With Go 1.10 and earlier one can install binaries via regular `go get`, `go 
> > get golang.org/x/tools/cmd/goimports` for instance.
> > It doesn't work with Go modules enabled:
> >
> > $ go get golang.org/x/tools/cmd/goimports
> > go: cannot find main module; see 'go help modules'
> >
> > this is an obvious usability downgrade. I wonder if someone knows about 
> > some sort of replacement for the functionality?
> >
> >
> > It should still work (and does for me).
> >
> > Can you try go get -x -u golang.org/x/tools/cmd/goimports and see what 
> > the output prints about the problem.
> >
> >
> >
> 
> -- 
> 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.


-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] Panic getting swallowed by defer in Go 1.11

[Sam Whited]

On Mon, Sep 3, 2018, at 04:10, ama...@naucera.net wrote:
> type S []int
> 
> func (s *S) Last() int {
> return (*s)[len(*s) - 1]
> }

On an unrelated matter, the extra indirection is (probably) not what you want 
here, slices are already a pointer type. For more information see 
https://blog.golang.org/go-slices-usage-and-internals.

That is to say, the following works in more or less the same way (and is much 
easier to read):

func (s S) Last() int {
return s[len(s)-1]
}

Apologies if this is something you're already aware of; for future generations 
finding this thread I wanted to mention it.

—Sam

-- 
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] go module for library developer workflow

[Sam Whited]

On Tue, Sep 4, 2018, at 09:58, Yulrizka wrote:
> What is the recommended workflow to easily develop new functionality for 
> lib 'a'?

Add a replace directive to your go.mod file in 'b' while you are developing:

replace github.com/my/a => /home/me/Projects/wherever/a

Unfortunately, you'll have to be careful not to accidentally commit this line.

—Sam

-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] help seek: creating and using go package

[Sam Whited]

On Tue, Sep 4, 2018, at 01:33, Sayan Shankhari wrote:
> Probably I am making some nonsense post here and disturbing you but as a 
> beginner, I want to know how in Go I can implement the following. If I can 
> not, please suggest me suitable solution:

Not at all; welcome! If you're just getting started with Go, I recommend that 
you take the tour (https://tour.golang.org). This probably covers most of what 
you want.


> 1. Create a package "myNum"

This is a good resource for getting started with creating Go packages: 
https://golang.org/doc/code.html

It's a tiny bit out of date, there are some experimental features in Go 1.11 
that make using GOPATH obsolete, but it will still work for now.

> 2. containing data type like:
> type Num struct {
> n, d int // numerator, denominator
> }
> 3. and a function to print like
> func printMyNum(x Num) {
> fmt.Println("the fractional number is: %d/%d", x.n, x.d)
> }

Looks like you've already done this, good job :)



In Go, the case of the first letter of an identifier determines if it's 
exported or not.
In your code "Num" will be exported (it can be used from another package), but 
its fields are not (so you won't be able to set "n" or "d" from another 
package). Similarly, "printMyNum" will not be exported, so you won't be able to 
call it from another package.

Here is a more detailed explanation: 
https://stackoverflow.com/questions/38616687/which-way-to-name-a-function-in-go-camelcase-or-semi-camelcase/38617771#38617771

And here is a nice post about how to name things: 
https://blog.golang.org/package-names


I hope that's helpful. Welcome to Go!

—Sam

-- 
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: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu

[Sam Whited]

On Wed, Sep 5, 2018, at 15:04, peterGo wrote:
> Print the draft documents from Firefox Quantum 61.0.1 (64-bit) for Mozilla 
> Firefox for Ubuntu canonical - 1.0. 

I'm using Firefox 63.0a1 nightly cut 2018-08-19 and am also getting only one 
page; I had to download a new browser to print.

—Sam

-- 
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] A thought on contracts

[Sam Vilain]

Is that the go team's job, though?  It's about go and automatically inferring duck types, so surely we should really be asking DuckDuckGo.Sam



-- 
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: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu

[Sam Whited]

On Wed, Sep 5, 2018, at 20:28, peterGo wrote:
> What happenned when you followed the instructions I gave to Christophe?

I believe this is exactly what I was doing before; I don't love having to use 
the simplify option though, so it's possible I left it off and didn't notice. 
I'll try again at some point and follow up if something was off.


—Sam

-- 
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] Go 2 Draft Design Question : Error Handling

[Sam Whited]

On Sat, Sep 8, 2018, at 12:41, Henry wrote:
> I have read the Go 2 Draft Design about Error Handling. You can read about 
> it here Go 2 Draft Designs 
> <https://go.googlesource.com/proposal/+/master/design/go2draft.md>. The 
> draft suggested something like this:
> 
> func CopyFile(src, dst string) throws error {
> r := os.Open(src)
> defer r.Close()
> 
> w := os.Create(dst)
> io.Copy(w, r)
> w.Close()
> }

You may need to go back and read that page again; this example is from the 
problem statement of the overview document. The actual draft design does not 
include any such syntax.

The document you want to read can be found here: 
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

—Sam

-- 
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] Operator Overloading Implies Generics?

[Sam Whited]

On September 9, 2018 1:43:09 PM UTC, robert engels  
wrote:
>I think the lack of method overload is a poor choice.
>
> …
>
>I would much rather write
>
>NewCircle([]Point)
>NewCircle(center Point,radius int)
>
>than
>
>NewCircleFromPoints
>NewCircleFromCenterWithRadius
>
>and this is just a very simple example.


Allowing this would also open us up to a lot of Java-like ambiguity:


func Foo(i int) {…}
func Foo(i ...int) {…}

Foo(1) // Which function signature does this match?

—Sam

-- 
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 it needed to close a HTTP request body ?

[Sam Whited]

On Mon, Sep 10, 2018, at 09:27, Pierre Durand wrote:
> When I learned Go a few years ago, I was told to always defer/close the 
> HTTP request body, otherwise it will cause a resource leak.
> 
> But today I read this: https://golang.org/pkg/net/http/#Request.Body
> // The Server will close the request body. The ServeHTTP
> // Handler does not need to.
> 
> Am I misunderstanding something ?

The rule is that HTTP *clients* must close the *response* body. Servers handle 
closing the request body themselves.

—Sam

-- 
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] Golang equivalent of Python's context manager

[Sam Whited]

On Wed, Sep 12, 2018, at 14:12, Mirko Friedenhagen wrote:
> However, coming from Java lately, retrieving a DB-connection from a pool, 
> opening a transaction and committing/aborting and returningafterwards seems 
> something which could be handled with such a construct. How would you do 
> this in Golang?

I frequently do something similar to this:

https://gist.github.com/SamWhited/d81d081aed0351a1c1d128acf3a16b5c

(there may be some extra parameters, I cut out some row-level-security stuff 
from something being used in prod and pasted everything into the gist without 
really checking it)

—Sam

-- 
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 it possible to build a module without a hosted repository?

[Sam Whited]

On Fri, Sep 14, 2018, at 20:32, K Davidson wrote:
> Is there a way that I can build my package as a module without having to 
> host it on the internet?

I've found myself just making up fake import statements. While you're 
prototyping it doesn't hurt:

package main // import "golang.org/totally-official-and-real"

—Sam

-- 
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] Getting Go module versions from Git Log

[Sam Whited]

Hi all,

Here's a quick Git config for getting go module meta-versions from Git Log 
output, hopefully its useful to someone else who was getting frustrated by 
trying to make up v0.0.0 versions:

https://blog.samwhited.com/2018/09/go-module-versions-from-git-log/

—Sam

-- 
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] Compatibility between golang.org/x/crypto/argon2 and the legacy one

[Sam Whited]

On Thu, Oct 11, 2018, at 11:37, Thomas Bruyelle wrote: 
> I want to update my authentication code by using 
> golang.org/x/crypto/argon2, as a replacement of 
> github.com/tvdburgt/go-argon2 which uses the legacy C lib under the hood 
> through CGO.
> The main benefit is of course to drop the usage of CGO.
> 
> But I encounter a serious issue, with the same inputs (password, salt, 
> times, threads, memory), the 2 libraries give me 2 different hashes. 
> That means it's impossible for me to migrate, or else I have to ask all my 
> users to regenerate their passwords, which is not acceptable for me.

The x/crypto/argon2 package implements version 13, if you add "Version:  
Version13," to your context they should be the same. The docs claim this is the 
default for the legacy version, but they appear to be wrong.

—Sam

-- 
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: Compatibility between golang.org/x/crypto/argon2 and the legacy one

[Sam Whited]

On Thu, Oct 11, 2018, at 13:56, Thomas Bruyelle wrote:
> Unfortunately, because of that version mismatch, all my users' hashes were 
> created with a version not supported by golang.org/x/crypto/argon2, so I 
> can't migrate :/

I hope no problems are ever discovered in Argon2 then, it's generally a good 
idea to have some sort of system for migrating hashes :)

For example, when the user next logs in you could verify that he hash is 
correct, but also calculate the new hash and update it and set a prefix or a 
bit in the database somewhere saying that they're on "hash mechanism v2". 
There's no need to force reset every password all at once since this isn't a 
security issue.

—Sam

-- 
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: Compatibility between golang.org/x/crypto/argon2 and the legacy one

[Sam Whited]

On Thu, Oct 11, 2018, at 14:14, Thomas Bruyelle wrote:
> That say, the downside is I have to keep both hash system, until all users
> connect, which can take a long time, or can never happen!

Or at least until enough users have updated that you don't mind forcing the 
rest to update their password if they ever log in again.

—Sam

-- 
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] Temporary files in go

[Sam Whited]

On Thu, Oct 11, 2018, at 18:48, Greg Saylor wrote:
> 1. Create a temporary file and squirrel away the file handle
> 2. Unlink the temporary file by name
> 3. Various functions would write stuff to the file
> 4. If the programs completes to some successful state, create a hardlink to 
> the file handle with the final filename

The golang.org/x/sys/unix [1] package gives you a lower level interface that 
might be familiar to you if you're used to using C. Something like this is 
probably similar to what you were doing (though you'll need /proc mounted, I'm 
not sure if there's a better way to do that):

oldfd, err := unix.Open(".", unix.O_TMPFILE|unix.O_RDWR, 
unix.S_IRUSR|unix.S_IWUSR)
if err != nil {
panic(err)
}

f := os.NewFile(uintptr(oldfd), "myoldfile")
_, err = f.Write([]byte("Hello, World"))
if err != nil {
panic(err)
}

dir, err := os.Open(".")
if err != nil {
panic(err)
}
procdir, err := os.Open("/proc/self/fd/")
if err != nil {
panic(err)
}

err = unix.Linkat(int(procdir.Fd()), strconv.Itoa(oldfd), 
int(dir.Fd()), "mynewfile", unix.AT_SYMLINK_FOLLOW)
if err != nil {
panic(err)
}

—Sam

[1]: https://godoc.org/golang.org/x/sys/unix

-- 
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] Having trouble installing golint

[Sam Whited]

As the error says, you need to use golang.org/x/lint/golint:

go get -u -v golang.org/x/lint/golint

—Sam

On Wed, Oct 17, 2018, at 10:12, gary.willoug...@victoriaplumb.com wrote:
> I'm having trouble installing golint. Any idea what the problem could be?
> 
> $ go get -u -v github.com/golang/lint/golint
> github.com/golang/lint (download)
> package github.com/golang/lint/golint: code in directory /home/gary/Code/go/
> src/github.com/golang/lint/golint expects import "golang.org/x/lint/golint"
> 
> -- 
> 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.


-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] Having trouble installing golint

[Sam Whited]

TL;DR — you don't need to run the second command, just the first one.

I'm sorry for being unclear. Go get looks up packages by their import path. The 
import path of golint is "golang.org/x/lint/golint", so the second command you 
ran with the github URL will never work since that is the repo, not the package 
path. When you run go get golang.org/x/lint/golint it will look up the repo, 
discover that it lives at GitHub, clone it, and build it.

If you don't specify another package import path and you host your source on 
GitHub the github.com url is the default one, which may be why you are 
confused. However, golint specifies a custom import path 
(golang.org/x/lint/golint) so you need to use that.

—Sam

On Wed, Oct 17, 2018, at 14:48, 'kalekold' via golang-nuts wrote:
> I've already tried that and the original command still fails.
> 
> $ go get -u -v golang.org/x/lint/golint
> Fetching https://golang.org/x/lint/golint?go-get=1
> Parsing meta tags from https://golang.org/x/lint/golint?go-get=1 (status 
> code 200)
> get "golang.org/x/lint/golint": found meta tag get.metaImport{Prefix:
> "golang.org/x/lint", VCS:"git", 
> RepoRoot:"https://go.googlesource.com/lint"} 
> at https://golang.org/x/lint/golint?go-get=1
> get "golang.org/x/lint/golint": verifying non-authoritative meta tag
> Fetching https://golang.org/x/lint?go-get=1
> Parsing meta tags from https://golang.org/x/lint?go-get=1 (status code 
> 200)
> golang.org/x/lint (download)
> Fetching https://golang.org/x/lint?go-get=1
> Parsing meta tags from https://golang.org/x/lint?go-get=1 (status code 
> 200)
> get "golang.org/x/lint": found meta tag get.metaImport{Prefix:
> "golang.org/x/lint", VCS:"git", 
> RepoRoot:"https://go.googlesource.com/lint"} 
> at https://golang.org/x/lint?go-get=1
> Fetching https://golang.org/x/tools/go/ast/astutil?go-get=1
> Parsing meta tags from 
> https://golang.org/x/tools/go/ast/astutil?go-get=1 
> (status code 200)
> get "golang.org/x/tools/go/ast/astutil": found meta tag get.metaImport{
> Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:
> "https://go.googlesource.com/tools"} at https:
> //golang.org/x/tools/go/ast/astutil?go-get=1
> get "golang.org/x/tools/go/ast/astutil": verifying non-authoritative 
> meta 
> tag
> Fetching https://golang.org/x/tools?go-get=1
> Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 
> 200)
> golang.org/x/tools (download)
> Fetching https://golang.org/x/tools/go/gcexportdata?go-get=1
> Parsing meta tags from 
> https://golang.org/x/tools/go/gcexportdata?go-get=1 
> (status code 200)
> get "golang.org/x/tools/go/gcexportdata": found meta tag get.metaImport{
> Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:
> "https://go.googlesource.com/tools"} at https:
> //golang.org/x/tools/go/gcexportdata?go-get=1
> get "golang.org/x/tools/go/gcexportdata": verifying non-authoritative 
> meta 
> tag
> Fetching https://golang.org/x/tools/go/internal/gcimporter?go-get=1
> Parsing meta tags from 
> https://golang.org/x/tools/go/internal/gcimporter?go-get=1 
> (status code 200)
> get "golang.org/x/tools/go/internal/gcimporter": found meta tag get.
> metaImport{Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:
> "https://go.googlesource.com/tools"} at https:
> //golang.org/x/tools/go/internal/gcimporter?go-get=1
> get "golang.org/x/tools/go/internal/gcimporter": verifying non-
> authoritative 
> meta tag
> 
> $ go get -u -v github.com/golang/lint/golint
> github.com/golang/lint (download)
> package github.com/golang/lint/golint: code in directory /media/Data/
> Projects/Go/src/github.com/golang/lint/golint expects import 
> "golang.org/x/lint/golint"
> 
> 
> On Wednesday, 17 October 2018 17:53:50 UTC+1, Sam Whited wrote:
> >
> > As the error says, you need to use golang.org/x/lint/golint: 
> >
> > go get -u -v golang.org/x/lint/golint 
> >
> > —Sam 
> >
> > On Wed, Oct 17, 2018, at 10:12, gary.wi...@victoriaplumb.com  
> > wrote: 
> > > I'm having trouble installing golint. Any idea what the problem could 
> > be? 
> > > 
> > > $ go get -u -v github.com/golang/lint/golint 
> > > github.com/golang/lint (download) 
> > > package github.com/golang/lint/golint: code in directory 
> > /home/gary/Code/go/ 
> > > src/github.com/golang/lint/golint expects import "
> > golang.org/x/lint/golint" 
> > > 
> > > -- 
> > > You receiv

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

[Sam Mortimer]

On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote:
>
> The question is: is anybody actually doing this?  Is anybody seriously 
> thinking about it? 
>
> Ian 
>

Unhelpfully, I imagine it unlikely that anyone distributing binary go 
packages reads golang-dev or golang-nuts.

-Sam.

-- 
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] go src organization question

[Sam Whited]

On Sun, Oct 21, 2018, at 11:31, Sankar wrote:
> For such a hybrid requirement, what is the most recommended way to import 
> and structure our libraries and the source directories, to work with go 
> modules?

A single module at the root of the project should give you what you want. 
Create the file: ~/go/src/gitlab.com/example/go.mod
and then add the line: 

module gitlab.com/example

and build. Everything should work and the local copy of your libraries will be 
used because they are in the same module.

—Sam

-- 
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] database for protobuf - profanedb or similar

[Sam Whited]

On Tue, Oct 30, 2018, at 13:48, Tharaneedharan Vilwanathan wrote:
> I am looking for a database for protobuf, preferably the one that fits Go
> environment better. I located profanedb. I am wondering if anyone tried it
> with Go and if there is any example code that I can take a look at. Also,
> please let me know if there is anything else I should try too.

I'm not sure what you mean by "fits the Go environment", but PostgreSQL is very 
reliable and could easily hold protobufs in the BYTEA type, or of course the 
JSON representation in the JSONB type. The lib/pq [1] driver is very good.

I tend to think that choosing a niche database for a specific serialization 
format is a bad idea; instead think about your application and what you care 
about (speed, reliability, etc.), and about the general type of data you'll be 
storing (is it time series, highly relational, etc.) then pick something that's 
well tested and proven which meets your criteria.

—Sam

[1]: https://godoc.org/github.com/lib/pq

-- 
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: integration tests and using atom

[Sam Whited]

On Thu, Nov 8, 2018, at 13:49, S Ahmed wrote:
> Is there a way to ignore certain tests like my integration tests that setup
> db etc. and are long running?

I like to add a build tag to my integration tests, something like:

// +build integration

Then when I want to run them:

go test -tags "integration"

Sometimes I also use T.Short() and `go test -short' with this if some tests 
take a lot longer to run and should only happen in CI or only run before a 
release build, etc. but I don't like to use it to separate integration tests 
from unit tests since I might have short/long tests in both categories.

—Sam

-- 
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] what does the "replace" in go.mod mean?

[Sam Whited]

On Sat, Nov 10, 2018, at 09:46, Paul Jolly wrote:
> > 2. "Why doesn't "go build" run "go mod tidy" automatically?
> 
> It does in as much as adding missing dependencies are concerned, but
> doesn't do the tidying (removal) in go.{mod,sum} that go mod tidy
> does.

I don't think this is true (unless this has been fixed, I can't upgrade to 
check right this moment), go build respects build constraints (eg. you won't 
get dependencies that only exist in tests), so even if you're just talking 
about adding missing dependencies, build won't necessarily help you.

I've noticed this causing a lot of confusion in libraries moving to modules 
where dependencies get left out because they're hidden behind a build tag, or 
only get added when tests are run.

—Sam

-- 
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] what does the "replace" in go.mod mean?

[Sam Whited]

On Sat, Nov 10, 2018, at 10:39, Paul Jolly wrote:
> I don't think there's anything wrong with this distinction - when you
> say "unless this has been fixed", are you suggesting the behaviour is
> wrong or could be improved in some respect?

I've just seen several projects do this wrong because they don't know about go 
mod tidy so they build, let CI run tests (and don't notice that the file has 
changed in CI), and call it a day never knowing that they're missing 
dependencies. Since I can't imagine why you'd want to have partial dependencies 
in the go.mod file (and even if you do, it's probably not nearly as common as 
wanting all of them), the default behavior of go build seems wrong to me.

—Sam

-- 
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] what does the "replace" in go.mod mean?

[Sam Whited]

On Sat, Nov 10, 2018, at 11:00, Paul Jolly wrote:
> > I've just seen several projects do this wrong because they don't know about 
> > go mod tidy so they build, let CI run tests (and don't notice that the file 
> > has changed in CI), and call it a day never knowing that they're missing 
> > dependencies. Since I can't imagine why you'd want to have partial 
> > dependencies in the go.mod file (and even if you do, it's probably not 
> > nearly as common as wanting all of them), the default behavior of go build 
> > seems wrong to me.
> 
> Equally, I'm not sure that I would expect a command that is subject to
> build constraints to do something beyond those constraints, which is
> exactly what would happen under such a proposal.

Maybe it's just me (and projects like the Stripe SDK and Blackfriday), but 
that's exactly what I would expect. Building source files is subject to build 
constraints, generating a go.mod isn't (or shouldn't be; unless there's some 
reason I'm missing why you'd want a go.mod file that's specific to an 
individual build with all its constraints?).

—Sam

-- 
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] Unable to view go-review.googlesource.com on Firefox 60.x

[Sam Whited]

FWIW, I'm on 65 nightly and haven't noticed any problems (including back when 
63 was the nightly release).

—Sam

On Fri, Nov 16, 2018, at 09:22, Ian Davis wrote:
> Hi all,
> 
> Since upgrading to Firefox 60.3 on Linux I am unable to view any pages 
> on https://go-review.googlesource.com/ and I wondered if anyone else was 
> seeing this problem or if it's an issue with my setup?
> 
> Chromium renders the pages fine. When I view source with Firefox I see 
> the following:  which might be a clue to someone.
> 
> 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.


-- 
Sam Whited
s...@samwhited.com

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

Re: [go-nuts] Append array to slice of slice behavior puzzles me

[Sam Mortimer]

On Wednesday, November 21, 2018 at 2:38:42 PM UTC-8, Sun Frank wrote:
>
> Perfect! Thank you so much for your answer and explanation, : )
>

It is, unfortunately, a very common "gotcha".  More discussion can be found 
here: https://github.com/golang/go/issues/20733

Cheers,
-Sam.


 

> Best Regards
>
> Mail : eliteg...@gmail.com 
> Mobile : 0422 118 452
> TechBlog : http://elitegoblin.github.io
> GitHub: http://github.com/eliteGoblin/
>
>
> andrey mirtchovski > 于2018年11月22日周四 
> 上午9:22写道：
>
>> this is a case of a variable being reused during a range loop.
>> essentially k[:] is optimized to something resembling &k (a pointer to
>> the memory location of the backing array) which is appended as such to
>> the [][]int variable. the next iteration it is the same variable in
>> memory, however it's pointing to a different backing array. the
>> address of that variable is added to [][]int again. in order to avoid
>> this you will have to redeclare k inside the loop to ensure a new
>> backing array is used when adding to the slice of slices.
>>
>> maybe the easiest way to explain this is to point you towards this
>> blog post: https://blog.golang.org/go-slices-usage-and-internals and
>> to note that the for loop in your example expands/unrolls to something
>> like this, which breaks what you considered to "work" in your original
>> example:
>>
>> a1 := [3]int{1, 2, 3}
>> a2 := [3]int{4, 5, 6}
>> a3 := [3]int{7, 8, 9}
>>
>> s := make([][]int, 0)
>> a := a1
>> s = append(s, a[:])
>> a = a2
>> s = append(s, a[:])
>> a = a3
>> s = append(s, a[:])
>>
>> fmt.Println(s)
>> On Wed, Nov 21, 2018 at 2:41 PM Sun Frank > > wrote:
>> >
>> > Hi guys, I came across some code that surprised me, but I could not 
>> figured out why it behave like this,
>> >
>> > s := make([][]int, 0)
>> > a1 := [3]int{1, 2, 3}
>> > a2 := [3]int{4, 5, 6}
>> > s = append(s, a1[:])
>> > s = append(s, a2[:])
>> > fmt.Println(s)
>> >
>> > mp := make(map[[3]int]bool)
>> > mp[[3]int{1, 2, 3}] = true
>> > mp[[3]int{4, 5, 6}] = true
>> > mp[[3]int{7, 8, 9}] = true
>> > res := make([][]int, 0)
>> > for k := range mp {
>> > fmt.Printf("key is %+v\n", k[:])
>> > res = append(res, k[:])
>> > fmt.Printf("after append: %+v\n", res)
>> > }
>> >
>> >  or on playground
>> >
>> > the output is:
>> >
>> > [[1 2 3] [4 5 6]]   // this is as expected
>> > key is [1 2 3]
>> > after append: [[1 2 3]]
>> > key is [4 5 6]
>> > after append: [[4 5 6] [4 5 6]]  // Why it get this not [[1 2 3] [4 5 
>> 6]]
>> > key is [7 8 9]
>> > after append: [[7 8 9] [7 8 9] [7 8 9]] // why even this?
>> >
>> >
>> > any thoughts?
>> >
>> >
>> > 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...@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] Simple Go http daemon under systemd

[Sam Whited]

On Thu, Nov 22, 2018, at 21:14, Tong Sun wrote:
> and it needs to be working under systemd. 
> …
> but there is no mentioning of how it can work under systemd, which could 
> be 
> troublesome, 
> like the question I found at why systemd cannot start golang web app 
> <https://stackoverflow.com/questions/37297714/why-systemd-cannot-start-golang-web-app>

I'm not really sure what you're asking, Go binaries aren't doing anything 
special and systemd can start them just like any other program. Are you looking 
for an example service/socket file that lets you bind to port 443, or wondering 
what type of service to use? Or are you getting some other kind of error?

—Sam

-- 
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] Syntax highlighting (again) [WAS go language sensitive editor?]

[Sam Whited]

On Fri, Nov 23, 2018, at 17:06, Jay Ts wrote:
> Nowadays I use vim 
> because there are a few nice things about it that aren't in vi. At least, 
> vim is ok after you turn off syntax highlighting and all the other newbie 
> crutches. :-P Seriously, how many people can't read or write in English (or 
> their native language) if the verbs, nouns, and prepositions are the same 
> color? I don't get it.

Okay, I'll bite: Anyone can still read code without syntax highlighting, it 
doesn't provide any information that's not already there. It just provides 
another dimension of visibility to that information so that you can make 
certain judgements quicker. If the compiler gives you a worthless error message 
and you don't know why something isn't working, you might be able to see at a 
glance that a multi-line string isn't terminated when everything is in string 
color instead of scrolling up several hundred lines wondering why it said the 
file ended early. It's not a crutch, as it probably doesn't help you if you 
can't walk already.

—Sam

-- 
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] [Go2] move everything to gopath so goroot isn't required anymore

[Sam Whited]

There has been some discussion of making packages in the standard library into 
modules (once that's the default versioning system) which could be versioned 
separately from Go so that fixes could be released without having to wait on 
the full Go release cycle. I can't find a link at the moment, but the Go team 
has mentioned the possibility of doing this.

—Sam

On Sun, Dec 2, 2018, at 21:04, Gert wrote:
> Can we move stdlib (goroot) to gopath in Go2? On install you can do go get 
> -u stdlib to download the stdlib into gopath. Basically getting rid of 
> goroot.

-- 
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] Getting .slide of Golang Talks

[Sam Whited]

On Mon, Dec 3, 2018, at 10:28, Andrew Frances wrote:
> Is it possible to get the .slide files for the
> Golang Talks https://talks.golang.org/ so I can have more examples (I don't
> really need all the accompanying files)?

https://github.com/golang/talks

-- 
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: json and interface unmarshalling

[Sam Whited]

Hi,

In the future, please don't apply formatting when you're emailing code. Lots of 
people will have lots of different mail clients, and it's not always obvious 
how the colors will interact or whether they'll be readable against different 
backgrounds, or by people with various visual disabilities.

Plain text emails are your friend; everyone's individual client (including 
yours when you're composing it, probably) can style those in such a way that 
they'll be able to read it.

Thanks,
Sam

On Fri, Dec 14, 2018, at 13:24, Darko Luketic wrote:
> Of course after I ask my question I find the answer on my own.
> It's always like this.
> 
> The solution is to change
> 
> type MessageRequest struct {
>Typestring  `json:"type"`
>Payload json.RawMessage `json:"payload"`
> }
> 
> 
> So the payload isn't unmarshalled.
> 
> Now, after the MessageRequest is unmarshalled I can check for the type and 
> then
> 
> payload := new(model.ChatMessage)
> if e := json.Unmarshal(m.Payload, payload); e != nil {
>logrus.Error(e)
>return
> }
> 
> 
> 
> On Friday, December 14, 2018 at 8:17:25 PM UTC+1, Darko Luketic wrote:
> >
> > Hello,
> >
> > I'm sending messages over websocket.
> > I have a "generic" MessageRequest and MessageResponse struct.
> >
> > type MessageRequest struct {
> >Typestring  `json:"type"`
> >Payload interface{} `json:"payload"`
> > }
> >
> > type MessageResponse struct {
> >Typestring  `json:"type"`
> >Payload interface{} `json:"payload"`
> > }
> >
> >
> >
> > I'm trying to unmarshall this.
> >
> > m := new(MessageRequest)
> > if e := json.Unmarshal(msg, m); e != nil {
> >logrus.Error(e)
> >return
> > }
> >
> >
> > Then I switch by MessageRequest.Type to know what kind of message was sent 
> > by the client.
> >
> > However, when I do something like
> > payload, ok := m.Payload.(*MessageRequest)
> > if !ok {
> > //error
> > }
> >
> > It isn't compatible to type *MessageRequest
> > As a workaround I could imagine marshalling the interface again, then 
> > unmarshalling into the correct message payload type (e.g. ChatMessage)
> > But that is unnecessary overhead. However it beats marshalling into 
> > map[string]interface and manually assigning values in terms of code 
> > readability.
> >
> > tmp, e := json.Marshal(m.Payload)
> > if e != nil {
> >logrus.Error(e)
> >return
> > }
> > payload := new(model.ChatMessage)
> > if e := json.Unmarshal(tmp, payload); e != nil {
> >logrus.Error(e)
> >return
> > }
> >
> >
> >
> > vs
> >
> > pmap, ok := m.Payload.(map[string]interface{})
> > if !ok {
> >logrus.Error("can not convert to map[string]interface{}")
> >return
> > }
> > payload := new(model.ChatMessage)
> > user := pmap["user"].(string)
> > payload.User = user
> >
> > message := pmap["message"].(string)
> > payload.Message = message
> >
> > tme := pmap["time"].(string)
> > tmee, e := time.Parse(time.RFC3339, tme)
> > if e != nil {
> >logrus.Error("time parse error")
> >return
> > }
> > payload.Time = tmee
> >
> >
> > Is there a better solution to solve this?
> >
> >
> 
> -- 
> 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.


-- 
Sam Whited
s...@samwhited.com

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

[go-nuts] Language line in go.mod

[Sam Whited]

Hi all,

I've been asked multiple times recently to point people to documentation for 
the language line in a go.mod file (eg. the `go 1.12' line that's added by 
recent builds), but I haven't been able to find any on the wiki or in `go help 
modules` or similar, just the occasional list discussion.

Is this documented anywhere and I'm just missing it?

Thanks,
Sam

-- 
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] Language line in go.mod

[Sam Whited]

On Tue, Dec 18, 2018, at 10:13, Ian Lance Taylor wrote:
> https://tip.golang.org/cmd/go/#hdr-The_go_mod_file

Ah thanks! I wouldn't have ever thought to look there for info on the mod file. 
I'll pass that along.

—Sam

-- 
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] tool to automatically refresh godoc ?

[Sam Whited]

On Fri, Dec 21, 2018, at 14:48, Beoran wrote:
> Not go specific, there are inotifywait and entr 
> http://eradman.com/entrproject/.

Or a post-push hook on the server where the repos live if you're using Git.

—Sam

-- 
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] go modules go build fails - normal go build with $GOPATH set works

[Sam Whited]

This sounds like the version is mismatched. Is the gopath version a newer 
commit (with api changes) than the tag being picked in the go.mod file? I have 
this quite frequently with golang.org/x/text which was last released some time 
ago and have to use a replace directive to get a more up to date version and 
fix the build

—Sam


On December 25, 2018 8:10:08 PM UTC, robr...@gmail.com wrote:
>I have been testing out the new go modules feature.  Our application 
>compiles/installs without problems using the normal $GOPATH way and
>have 
>been using this for a while now.   trying go modules produces the same 
>error over and over 
>
>Steps I followed
>
>unset $GOPATH just to be safe 
>
>1) git clone github project 
>
>2) go mod init 
>
>3) go build 
>
>
>and after some output where I can see it getting all the dependencies I
>
>keep getting 
>
>random.go:14:10: assignment mismatch: 2 variables but 1 values
>random.go:29:10: assignment mismatch: 2 variables but 1 values
>
>Again reverting back to the normal $GOPATH way everything compiles fine
>and 
>I can start the binary. 

-- 
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: Secure password hashing algorithm in go.

[Sam Whited]

On Mon, Jan 7, 2019, at 07:58, minfo...@arcor.de wrote:
> I've often encountered demands for password encryption, where simple string 
> hashing would suffice.

You should never encrypt passwords; encryption implies that you can get the 
original password back out, it's a two way street.
Some form of hashing is always what you want (of course, you can't just hash 
and call it a day; there's still more work to do).

> Speed-wise FNV-1a is barely to beat. Add some magic number to the 
> result and you are good enough.
> The algo fits in a single handful of lines.

You also don't want speed when hashing passwords, this is why all the methods 
other people have been listing (I use Argon2 or PBKDF.2 depending on the 
application, personally) are actually a type of hash called a Key-derivation 
function (KDF).  FNV-1 is not a cryptographic hash function and is not suitable 
for password storage.

OWASP has a good overview of password storage if you're interested: 
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

—Sam

-- 
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] Transferring host's go-mod-download cache into docker container

[Sam Whited]

On Fri, Jan 11, 2019, at 23:03, grego...@unity3d.com wrote:
> But now, I don't know how I can essentially copy the mod cache (or 
> whatever the right term is) like I'd have copied the vendor directory.

If you're suggesting that you already have the module cached on the machine 
that builds your containers, the cache lives at ~/go/pkg/mod by default so you 
could probably copy that tree into your build container.

—Sam

-- 
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] When to use interfaces?

[Sam Whited]

On Fri, Jan 18, 2019, at 18:06, 伊藤和也 wrote:
> When to use interfaces?

Reading this chapter in Effective Go might help. You can find answers to many 
of your questions there.

https://golang.org/doc/effective_go.html#interfaces_and_types

—Sam

-- 
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: multiple binaries from a single directory with go modules?

[Sam Whited]

On Sat, Jan 19, 2019, at 01:12, Tyler Compton wrote:
> What alternative do you recommend?

Use what you're comfortable with. Make is a great tool, and doesn't appear to 
be the problem here.

—Sam

-- 
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 the type of a variable with interface{} "nil"?

[Sam Whited]

On Mon, Jan 21, 2019, at 00:39, 伊藤和也 wrote:
> I checked the type of the variable "v" with interface{} using TypeOf 
> function in reflect package but it returned "nil".
> var v interface{}
> fmt.Println(reflect.TypeOf(v))
> 

That is what the reflect.TypeOf function is supposed to do. The docs 
specifically mention this: https://godoc.org/reflect#TypeOf

—Sam

-- 
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] How concatenate more type of formatting for the same variable (fmt.Printf)

[Sam Whited]

On Tue, Jan 22, 2019, at 03:26, Antonio Romeo Riga wrote:
> I would like to do something like that
> fmt.Printf("%-15v %5.2f %5.2f" , coin, piggyBank)
> 
> %-15v and %5.2f should change the variable 'coin'.

If you want the first two verbs to both affect "coin" in your example, use 
bracket notation:

fmt.Printf("%-15[1]v %5.2[1]f %5.2[2]f", coin, piggyBank)

To find this in the documentation (it's a long read and easy to skip over) 
search for "Explicit argument indexes".


I wasn't entirely sure what you were asking, so if this wasn't what you were 
trying to figure out I apologize.

—Sam

-- 
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: Is it possible to export a variable from main package? If impossible, why?

[Sam Whited]

On Thu, Jan 24, 2019, at 07:00, 伊藤和也 wrote:
> Is it possible?
> package main
> 
> var Number int = 100
> func main() {}
> 
> package hello
> 
> import "fmt"
> 
> func abc() {
>fmt.Println(Number)
> }2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
> > package main
> > 
> > var Number int = 100
> > 
> > func main() {
> > 
> > }

No, if you simply try this you'll see that you get an error:

import "main" is a program, not an importable package

—Sam

-- 
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] Go Module File

[Sam Whited]

On Sun, Jan 27, 2019, at 11:24, Kaveh Shahbazian wrote:
> Where can I find the complete reference for Go module files (go.mod)?
> 
> I am particularly interested in getting fluent in using local 
> packages/sub-packages and also redirecting import paths - for example 
> for times I need to use a fork.

I'm glad I'm not the only one who had a hard time finding this:

https://tip.golang.org/cmd/go/#hdr-The_go_mod_file

—Sam

-- 
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] go install touches the result file even if no changes

[Sam Whited]

On Mon, Jan 28, 2019, at 19:44, 'Tim Hockin' via golang-nuts wrote:
> People already chide me for my affinity for baroque
> Makefiles...

I use bmake too; and here I was all this time thinking that the "b" stood for 
"BSD".

—Sam

-- 
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] Alternative of defer?

[Sam Whited]

It's not pretty, but if you absolutely must write this code and can't refactor 
it, you can always use a closure to scope the defer:

lock1.Lock()
err = func() error {
  defer lock1.Unlock()
  return performOperation1()
}()
if err != nil {
  return err
}
performExpensiveOperation2()

On Fri, Feb 8, 2019, at 18:28, vincent163 wrote:
> I am thinking about how to write programs like this:
> `
> lock1.Lock()
> err = performOperation1()
> if err != nil {
>  lock1.Unlock()
>  return err
> }
> lock1.Unlock()
> performExpensiveOperation2()
> `
> 
> The lock1 must be locked while performing operation1, and I need to use 
> its result to perform operation2. Since operation2 is expensive, I 
> don't want to hold the lock while performing it, and lock1.Unlock() 
> needs to be called before calling operation2.
> Go's defer mechanism doesn't seem to handle this case well since the 
> resource is used only within a block and not throughout the function. 
> Is there a recommended way to write programs in this case?
> I know I could wrap the lock block in a closure, but that creates a 
> completely new scope, so I can't return directly or break out of a loop 
> within the closure, etc.
>  
> 
> 
>  -- 
>  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.
>

-- 
Sam Whited

-- 
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] inverse of time.Duration?

[Sam Whited]

On Fri, Feb 15, 2019, at 20:00, Burak Serdar wrote:
> rate=1.0/double(dur)

nit: s/double/float64/

—Sam

-- 
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: Unmarshal nested XML value from dynamic XML document

[Sam Whited]

Your function appears to return error text, but it will be much more clear 
what's going on when reading the code if you encode your intent in the return 
type and return an error instead of a string (which gives me no information 
about what that string is supposed to represent: is it an error? is it some 
XML?). fmt.Errorf can be used for this, also just return the io.EOF directly.

—Sam

On Sun, Feb 24, 2019, at 17:28, Steffen Wentzel wrote:
> Thanks for the response. I was hoping it would be possible with just 
> xml.Unmarshal.
> 
> I now have this implementation - any comments on that? (I'm okay with 
> returning the error inline, it's just for logging purposes):
> 
> Playground: https://play.golang.org/p/6J8XndWdlv_N
> 
> `
> func id2(axl []byte) string {
>  dec := xml.NewDecoder(bytes.NewReader(axl))
>  for {
>  tok, err := dec.Token()
>  if err != nil {
>  if err == io.EOF {
>  return "token not found"
>  }
>  return fmt.Sprintf("error decoding XML: %v", err)
> 
>  }
>  if tok, ok := tok.(xml.StartElement); ok {
>  if tok.Name.Local == "return" {
>  var id string
>  err := dec.DecodeElement(&id, &tok)
>  if err != nil {
>  return fmt.Sprintf("error decoding return element: %v", err)
>  }
>  return id
>  }
>  }
>  }
> }
> `
> 
> 
> 
> Am Samstag, 23. Februar 2019 20:53:07 UTC+1 schrieb Tamás Gulácsi:Walk 
> over it usin xml.Decoder.Token, and UnmarshalElement when found a 
> StartToken with a proper Name.Local.
>  
> 
> 
>  -- 
>  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.
>

-- 
Sam Whited

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

[Sam Whited]

On Mon, Mar 18, 2019, at 06:24, Nada Saif wrote:
> I am learning to Go. For packages, do I need to use GitHub?
> I tried to build two packages one accessing functions from the other.

Welcome! You can use whatever repository hosting you want, and even use your 
own domain name with it!
I encourage using alternatives; the less we tie the Go ecosystem to GitHub the 
better.

For more information on repository lookup, custom domains, and special casing 
of some of the bigger repo hosting services see:

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

—Sam

-- 
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] Go command support for "make"

[Sam Whited]

On Wed, Mar 20, 2019, at 05:05, Lucio wrote:
> What I just realised is that my Makefile/mkfile-foo isn't sufficient
> to *do something* with such information, but at this point I'm willing
> to cross that bridge when I come to it. For now, having a "go status
> infernal/package", say, even if it provides a single reply:
> "updated=yes", for example (someone here will think of a better
> approach, no doubt) will be a useful start. Obviously, the command is
> run in a directory other than the one being verified.

Make files are meant to check if one file is newer than another, not the
output of a command. If you want to see if your dependencies have been
updated or not, check if the file that contains those dependencies has
been updated (eg. go.mod or Gopkg.toml). If you want to check if local
files have been updated, list those local files. Something like this is
a good start for a Go project (assuming you want to depend on all .go
files in the project, which may or may not be a good assumption
depending on the project).

GOFILES!=find . -name '*.go'

    yourbinary:
go.mod $(GOFILES) go build -o $@

—Sam

-- 
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] SourceHut Terraform Provider and HTTP API SDK

[Sam Whited]

Hi all,

I've been working on a Terraform provider for SourceHut [1] (previously
known as sr.ht) and, as part of this work, an HTTP API SDK in Go.
Both are available on SourceHut itself:

  - https://git.sr.ht/~samwhited/terraform-provider-sourcehut
  - https://git.sr.ht/~samwhited/sourcehut-go/

I'd love to get your feedback or contributions.
The SourceHut APIs are still very limited and new, and will likely
change, so be warned that things may break going forward until SourceHut
itself stabilizes.
Also note that the documentation may not render correctly on GDDO until
some pending changes [2] are merged.


—Sam


[1]: https://sourcehut.org/
[2]: https://golang.org/cl/168065

-- 
Sam Whited

-- 
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] OCSP revocation checking before completing TLS handshake

[Sam Whited]

On Thu, Apr 11, 2019, at 15:49, erikssonfili...@gmail.com wrote:
> Using Go's standard TLS library this does not seem possible, as
> tls.Dial does not seem to do any OCSP checking. Another possible
> workaround would be to fetch the server certificate without
> performing a handshake, then check revocation status, and if status
> is OK, redo the handshake using tls.Dial, but I couldn't find a way
> to do it in Go.

You can use golang.org/x/crypto/ocsp [1] and create your own
dialer which performs an OCSP request. You can also use this to
parse any stapled responses which are returned by crypto/tls's
OCSPResponse() method.

[1]: https://godoc.org/golang.org/x/crypto/ocsp

—Sam

-- 
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] built-in alternative to bcrypt?

[Sam Whited]

On Mon, Apr 22, 2019, at 10:14, whitehexagon via golang-nuts wrote:
> I am concerned about the Go binary size, since I'm already at 15MB! So
> I'm trying to limit external dependencies as much as possible.

Staying in the standard library won't help you here. You'll still
have to link in the code you use regardless of where it comes from
(the entire standard library isn't linked into your binary, just
whatever you use).

As someone else mentioned, argon2 is probably what you want [1]. It's
the current OWASP recommendation [2].

—Sam

[1]: https://godoc.org/golang.org/x/crypto/argon2
[2]: 
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md#leverage-an-adaptive-one-way-function

-- 
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: built-in alternative to bcrypt?

[Sam Whited]

On Mon, Apr 22, 2019, at 20:18, whitehexagon via golang-nuts wrote:
> Also good to know only what I'm using gets linked in, but then the
> size of 'hello world' is even more surprising.

That's because the runtime is being linked in. Go requires, among other
things, a garbage collector and goroutine scheduler. These things are
always linked in because you're always using them.

> The argon2 looks interesting, but it sounds like it could be very
> memory heavy. The code I'm porting is running on a PAAS/SAAS setup,
> and that might have cost implications exceeding the worth of my low
> value data. But I will also have a look then at the sha3 that was
> mentioned, now that I know the 'x' stuff is internally produced by the
> same team!

Being memory heavy is the point; you don't want a fast hash to protect
your users data or if the hashes ever get stolen it's much easier for an
attacker to brute force them. SHA3 is a great hash, but it is not
appropriate for password storage. Please don't put your users passwords
at risk just to lower your operating overhead.

> I get the impression from some of the info I'm going through, that
> since I'm running on hosted systems, which optionally also have
> encrypted file systems, that some of the brute force defense stuff
> might be less applicable?

This is not true. An encrypted filesystem only prevents your database
from being stolen by eg. someone coming into your datacenter and running
off with your hard disk. It is no substitute for storing passwords
correctly.

> ie unless the database is physically stolen from some nuclear bunker
> somewhere in the world, and decrypted, and my noddy system is deemed
> worth hacking, it's probably pretty safe already.

Please don't put your users passwords at risk because you think
something you've done is "good enough". Always follow password storage
best practices.

> So the main attack vector would be multiple login attempts, which I
> can detect fairly easily. for example, 5 failed logins and the account
> is locked...

That's one way, and you should be doing that. However, you are human and
will make mistakes so another attack vector is someone managing to dump
your database, or getting in some otherway and downloading it.

> I was also thinking in this case I could use a client side hash so
> that the backend system never see's a plain text password. I realise
> of course that the hash becomes the password, but at least the hosted
> environments would never see clear text before reaching my hosted hash
> stuff. ie clients that reuse 123456 for everything :)

This generally isn't necessary and probably doesn't add much since
you're not likely to have your passwords stolen out of memory. Just
follow industry standard best practices.

—Sam

-- 
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] golang-codereview - purpose

[Sam Whited]

On Sat, Jul 22, 2017, at 18:42, Ulderico Cirello wrote:
> Does anyone here really read it? Or just a subset of it? if so, how do
> you manage it?

I read it (or skim the subject lines anyways); it's nice to know what
changes people are submitting. I also filter for a few specific things
that I'd like to review or follow more closely.

—Sam

-- 
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: golang-codereview - purpose

[Sam Whited]

On Sat, Jul 22, 2017, at 20:59, Ulderico Cirello wrote:
> Just confirming, you read all of it?

I do not read every single comment and try-bot-starting message on every
single CL, but I at least look at what CLs are being proposed. So I more
or less read the first message in every thread.

—Sam

-- 
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: [Blog] Context should go away for Go 2

[Sam Whited]

On Mon, Aug 7, 2017, at 11:33, Uli Kunitz wrote:
> I assume here that the proposal is not to change io.Reader but to …

There is no proposal. This was briefly discussed in the contributors
summit, but the underlying issues are not necessarily well understood.
Blog posts like this one help us all understand those issues better.
Apologies if I made it sound like this was something that was going to
happen in the contributors summit post; everything at the summit was
just a discussion which, for the most part, avoided concrete solutions.

—Sam

-- 
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 2.0 proposal: context scoped variables

[Sam Vilain]

bject("args", args))
...
}


It's quite easy to see here that the logging.Logger variable might be being 
used uninitialized.  It also looks awkward.

To compare this to the logging pattern I described in my advent calendar 
post;

func betterFunc(ctx context.Context, args... interface{}) {
logging.WithContext(ctx).Info("in betterFunc()", 
zap.Object("args",args))
...
}

This pattern should hide this, enabling APIs like this:

func goodFunc(args... interface{}) {
logging.Info("in betterFunc()", zap.Object("args",args))
...
}


As this is less awkward than the 'uninitialized context variable' use case, 
I would hope that this style would become more natural and popular than the 
anti-pattern of required context variables.

*Context Cancellation*

This system could be used to re-implement context cancellation; using the 
example from the context documentation:

func Stream(ctx context.Context, out chan<- Value) error {
for {
v, err := DoSomething(ctx)
if err != nil {
return err
}
select {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}
}
}

This could be written as (assuming the convention is that cancellation 
happens via a context variable in the sync package):

func Stream(out chan<- Value) error {
context var sync.Done
for {
v, err := DoSomething()
if err != nil {
return err
}
select {
case <-sync.Done:
return ctx.Err()
case out <- v:
}
}
}

*Prior Art & Approaches in other languages*

As far as I know, only Perl 6 has this concept as an explicit language 
feature, also called "context variables" at some point (IIRC), which it now 
calls "the * twigil <https://docs.perl6.org/language/variables#The_*_Twigil>
".

Comments/thoughts welcome!
Sam 

-- 
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: [Blog] Context should go away for Go 2

[Sam Vilain]

On Monday, 7 August 2017 09:06:23 UTC-7, Daniel Theophanes wrote:
>
> In the projects I've worked on the switch to Context has been a huge win 
> all across the board. I think it would be sweet to find an effect way to 
> make io.Reader take a context (I often want just that, and when I really 
> need it the solution tends to be more inefficient then it could be).
>

Right; the blocking-style interface of io.Reader is a problem here; I 
didn't really consider this, but my proposal (on its own thread) solves 
this problem; readers that know how can read from the sync.Done channel 
(which would have to be a 'close on cancel' type channel to allow multiple 
readers).
 

> As for Context.Values, I think you are dismissive of the real use-cases 
> without giving proper weight to them. It can be abused. Just like 
> go-routines and channels. I'm not saying we can't do better then the 
> current implementation, we probably can if the benefit is seen as worth the 
> cost of the change.
>

+1.  I used the values interface first and found it much better than adding 
extra parameters to every function, or passing around large interface types 
with a bunch of getter methods.

You're saying context is viral. It is. Just like errors are viral. Once you 
> start returning them you need to propagate them back. Having a context 
> argument is saying "this function, or something this function calls may 
> block for undisclosed amounts of time and we need to know when to stop 
> blocking and back out." 
>

Or "this function wants to log or profile some inner function" or "this 
function wants to use cached objects read within the same transaction".

In my experience, in real server applications you always want these 
abilities, but few structure their code to include context arguments. The 
status quo is that logging is almost always really bad in Go server 
applications.  Caching values read within a transaction is too hard so 
you'll make more DB calls than necessary.  Profiling never covers the 
tightest loops in your code.  This should be easy to add to an existing 
application without massive refactoring.
 

> There might be a better way to do ctx (and maybe errors) if the language 
> was adjusted; I'm fairly sure go-routine local storage isn't the answer but 
> maybe something else would be. Maybe you could create an Arena with a 
> context and a pattern for returning execution on error and an Arena could 
> use multiple go-routines and such. However I think where you would need to 
> start is a named real experience building and maintaining a solution in Go 
> that gets real use. Then look at it and see where it was painful and how it 
> was so.
>

"Goroutine Local Storage" is bad in my opinion because it's effectively a 
global, even if it is private to the goroutine.  I believe context.Context 
is the right pattern, in that values are rolled back as the call stack 
unwinds, and building it inside the runtime allows performance 
optimizations (variable elimination, slot unrolling, combination of context 
values into per-scope arenas) which would otherwise be impractical or ugly.

Sam

-- 
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] Built-in log Package

[Sam Vilain]

The main problem with the Printf-style interface is that it's not worth
building real applications with.  For anything with non-trivial logging
needs, you need:

* tagging of log lines with identifiers such as PID, host, request ID, etc
* structured for easier downstream analysis by tools like the ELK stack and
common commercial systems like splunk

What I've had to do to achieve this is to pass an alternate writer to the
"standard log" interface expected by various libraries (eg, Sarama) and add
PID and host tagging to that.   Writing things in terms of "prefix"
represents a very limited view of log correlation; it worked for syslog
perhaps but the world has moved on.  Log levels are also mostly useless.

The right API to me is probably somewhere between logrus and Uber's zap.
These systems are in more widespread use with a different set of
priorities, and it would be good to be able to plug into those (and see
also my context suggestion which could let these libraries automatically
connect with a configured logger)

Sam


On Mon, Aug 14, 2017 at 9:36 AM, dc0d  wrote:

> Some packages tried that approach, adding levels as prefixes (which I
> prefer to defining methods). But did not get enough attention.
>
> Whatever approach that may get chosen for a logging package, the logger
> struct should implement some Logger interface and should accept an instance
> of another object which also implements the Logger interface.
>
> This way it will be possible to not only handle the log entries at lower
> layers but also to have a hierarchy of loggers to the top (where logging is
> happening) which can behave differently based on the (conceptual) context -
> choosing the formatters, the destinations or notifying another system.
>
> And levels could be expanded to tags. A tagged entry can be processed
> based on its tags (including a concept like level) - but it seems (sadly)
> that levels are more wide-spread than just being a tag.
>
> That sort of interface, is what I would like to see. And you are right
> about that there is no conclusive agreement on what it should like.
>
> Another question that I failed to answer properly (by myself) is: are
> metrics same as logs? Or they are a higher level concept (which also can be
> logged)? And should logging be in charge of delivering metrics (seems it
> can be)?
>
>
> On Monday, August 14, 2017 at 6:30:19 PM UTC+4:30, Peter Mogensen wrote:
>>
>>
>>
>> On 2017-08-14 11:04, dc0d wrote:
>> > That may be (still IMH-Experience in the majority of cases, this is the
>> > proper default to go).
>> >
>> > But the main concern to express here is, the default logger should
>> > accept an interface like /Output/ instead of /io.Writer/.
>>
>> I would agree, if not for the fact that there seem to be very little
>> consensus on exactly what such an interface should look like.
>>
>> systemd support a very simple (but useful) interface for leveled
>> logging. Just prefix what you write to stdout or stderr with "" where
>> X is the syslog log-level. Systemd takes care of anything else.
>> Exactly this is pretty much impossible to do efficiently with many
>> log-packages, including the stdlib "log".
>>
>> /Peter
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> 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: [Blog] Context should go away for Go 2

[Sam Vilain]

Interesting, Alex - almost identical to my recent proposal
<https://groups.google.com/forum/#!msg/golang-nuts/o3fFHNhiNQs/bAyb_5dOCAAJ>,
with similar conclusions about a cancellation variable.  The main
difference is that in my proposal you have to declare it in each scope
where you'd use it, which means by default it gets the zero value - but
they're both scoped by the call stack with a new value on re-assignment,
and named by a package.  I could get behind either.

Sam

On Sun, Aug 13, 2017 at 11:08 PM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> For the general interest: I wrote up my thoughts on this in a lengthy blog
> post:
> Why context.Value matters and how to improve it
> <https://blog.merovius.de/2017/08/14/why-context-value-matters-and-how-to-improve-it.html>
> In particular, I sketch a design how context.Value could be made a
> language-level feature removing most of the disadvantages often ascribed to
> it. With this I am trying to put a more concrete face to the ideas behind
> the suggestion of using goroutine-local storage or the like to solve the
> issues. While I can't speak for others, I see similar ideas hinted at in
> this thread.
>
> I hope this can help to steer the discussion into the more helpful
> underlying questions, instead of getting hung up on details of the current
> implementation.
>
> On Sat, Aug 12, 2017 at 12:59 AM, Sam Vilain  wrote:
>
>> On Monday, 7 August 2017 09:06:23 UTC-7, Daniel Theophanes wrote:
>>>
>>> In the projects I've worked on the switch to Context has been a huge win
>>> all across the board. I think it would be sweet to find an effect way to
>>> make io.Reader take a context (I often want just that, and when I really
>>> need it the solution tends to be more inefficient then it could be).
>>>
>>
>> Right; the blocking-style interface of io.Reader is a problem here; I
>> didn't really consider this, but my proposal (on its own thread) solves
>> this problem; readers that know how can read from the sync.Done channel
>> (which would have to be a 'close on cancel' type channel to allow multiple
>> readers).
>>
>>
>>> As for Context.Values, I think you are dismissive of the real use-cases
>>> without giving proper weight to them. It can be abused. Just like
>>> go-routines and channels. I'm not saying we can't do better then the
>>> current implementation, we probably can if the benefit is seen as worth the
>>> cost of the change.
>>>
>>
>> +1.  I used the values interface first and found it much better than
>> adding extra parameters to every function, or passing around large
>> interface types with a bunch of getter methods.
>>
>> You're saying context is viral. It is. Just like errors are viral. Once
>>> you start returning them you need to propagate them back. Having a context
>>> argument is saying "this function, or something this function calls may
>>> block for undisclosed amounts of time and we need to know when to stop
>>> blocking and back out."
>>>
>>
>> Or "this function wants to log or profile some inner function" or "this
>> function wants to use cached objects read within the same transaction".
>>
>> In my experience, in real server applications you always want these
>> abilities, but few structure their code to include context arguments. The
>> status quo is that logging is almost always really bad in Go server
>> applications.  Caching values read within a transaction is too hard so
>> you'll make more DB calls than necessary.  Profiling never covers the
>> tightest loops in your code.  This should be easy to add to an existing
>> application without massive refactoring.
>>
>>
>>> There might be a better way to do ctx (and maybe errors) if the language
>>> was adjusted; I'm fairly sure go-routine local storage isn't the answer but
>>> maybe something else would be. Maybe you could create an Arena with a
>>> context and a pattern for returning execution on error and an Arena could
>>> use multiple go-routines and such. However I think where you would need to
>>> start is a named real experience building and maintaining a solution in Go
>>> that gets real use. Then look at it and see where it was painful and how it
>>> was so.
>>>
>>
>> "Goroutine Local Storage" is bad in my opinion because it's effectively a
>> global, even if it is private to the goroutine.  I believe
>> context.Context is the right pattern,

Re: [go-nuts] Built-in log Package

[Sam Vilain]

On 8/15/17 7:14 AM, Chris Hines wrote:
I would be curious what you think of github.com/go-kit/kit/log (and 
related "sub"-packages). See my talk about it's design here:


Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw
Slides: https://speakerdeck.com/chrishines/go-kit-log-package

I can see what you're going for with that, and in a way it's 
demonstrating some sugar issues in go.  For some reason, folk expect to 
be able to write logging statements without an awful lot of unsightly 
brackets and constructors :-).


To quickly round them up, this module uses what I consider to be Perl 
5-esque "slurpy hashes":


// Unstructured
log.Printf("HTTP server listening on %s", addr)

// Structured
logger.Log("transport","HTTP","addr", 
addr,"msg","listening")<https://github.com/go-kit/kit/tree/master/log#usage>

Whereas logrus steers you towards a map[string]interface{}:

func  main() {
  log.WithFields(log.Fields{
"animal":"walrus",
  }).Info("A walrus appears")
}

And zap uses type-safe individual field constructors:

logger.Info("failed to fetch URL",
  // Structured context as strongly typed Field values.
  zap.String("url", url),
  zap.Int("attempt",3),
  zap.Duration("backoff", time.Second),
)

Of these, I lean towards the zap style because it's not significantly 
more verbose (IMHO), it's more type safe, and faster.


However, the syntax sugar issue has meant that zap now also have a 
similar interface to kit:


sugar  :=  logger.Sugar()
sugar.Infow("failed to fetch URL",
  // Structured context as loosely typed key-value pairs.
  "url", url,
  "attempt",3,
  "backoff", time.Second,
)


One common element is the ability to create a logger with tags pre-built:

// kit  
logger = log.With(logger,"instance_id",123)

// logrus
logger = logrus.WithFields(logrus.Fields{"instance_id": 123})

// zap
logger = logger.With(zap.Int("instance_id", 123))


IMHO appropriate use of this feature is critical to sane log analysis as 
soon as your app gets non-trivial: distributed, sharded, microservices, 
async, etc - non-linear, multiuser and multicore: it can simply save you 
down the track if you tag the request ID, customer ID, and particularly 
the value of a loop variable for log statements inside inner loops.


So I guess, what I found was that once I did that using zap, I really 
don't care that much about the syntax sugar.  I would write things like:


for i, v := range arr {
   logger := logger.With(zap.Int("itemIdx", i))

   if err := v.Process(); err != nil {
   logger.Error("failed to process", zap.Object("error", err))
   }
}

And so the individual log statements don't go over the magic length at 
which blub programmers scoff, turn up their noses and say, "see, this is 
why go is so much worse than blub".  It's also a good abstraction.  And 
did I mention it's fast?  I really like the way that it never combines 
the log line into something heavy like a map[string]interface{}, and 
that it just logs its fields in the order they were passed - so it's 
more like a traditional log line, just with JSON boundaries.


So anyway, yeah that's where I stand on that API - I can see how you got 
there, and I watched a structured logging talk at GopherCon 2016 which 
set me down this path, but after investigation I just couldn't trade 
performance, memory efficiency and a good abstraction for a little 
syntax sugar.


I'm not quite sure what the language or stdlib could do to make this 
better, other than shipping something like zap in stdlib.  It's never 
really appropriate to use anything other than stdlib logging to log with 
in a library, and that's the nub of the problem: it means libraries will 
pretty much always have unstructured logging. The best you can do is to 
log each "printf" argument to its own field, but that's not a very good 
answer especially with the "message" is "%s: %s %s" or something.


Sam

--
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: Golang 1.9 failing with excelize (simple case works under 1.8.3)

[Sam Whited]

On Mon, Aug 28, 2017, at 22:59, silviucap...@gmail.com wrote:
> Interesting... For this portion of code:
> 
> https://github.com/360EntSecGroup-Skylar/excelize/blob/master/rows.go#L76-L85
> 
> The xml decoder returns row and col token types for  1.8.3 but rushes
> into 
> an EOF for 1.9

In Go 1.8 the patch in 02240408a1 was ported to restore error masking
behavior from 1.7 (which is why you get output in 1.8). I don't see that
patch in 1.9.

See also https://golang.org/issue/19333

—Sam

-- 
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] Help, using fmt.Sprint

[Sam Whited]

On Fri, Sep 1, 2017, at 10:00, Tong Sun wrote:
> For normal Go way, should I name the string function `*String*()` or `
> *ToString*()`? 

If you want your type to satisfy the `fmt.Stringer' interface
(https://godoc.org/fmt#Stringer) the method should be named `String'.

—Sam

-- 
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] Choosing a framework

[Sam Whited]

Here is a list of useful components that I sometimes reach for when I
need to do something in HTTP land that requires that I leave the comfort
and safety of the standard library but don't want to get locked into a
"framework". There may be better implementations of some of these, but
the ones listed here are often "good enough" in my book:

- https://godoc.org/golang.org/x/net/xsrftoken
- https://godoc.org/golang.org/x/oauth2
- https://godoc.org/golang.org/x/oauth2/jwt
- https://godoc.org/golang.org/x/oauth2/jws
- https://godoc.org/golang.org/x/net/netutil (contains a method for
limiting simultaneous connections)
- https://godoc.org/golang.org/x/net/websocket (though I've heard that
some people prefer https://godoc.org/github.com/gorilla/websocket)
- https://godoc.org/golang.org/x/time/rate (rate limiter)
- https://godoc.org/golang.org/x/net/trace (request tracing)
- https://godoc.org/golang.org/x/text/secure/precis (Unicode safety)

—Sam

-- 
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] Simple web crawler question. How to avoid crawling visited links?

[Sam Vilain]

Why not be even more concurrent?Pass "to visit" links to a channel.Reader of channel holds the map, de-dupes and passes to worker channel.Multiple workers dequeue the channel and feed back into the "to visit" channel.SamOn Sep 24, 2017 10:13 AM, Michael Jones  wrote:you must remember where you've been. for example, you might:a. convert each candidate URL to a canonical form (absolute path)b. look for canonical url in a map before visiting. If it was not there, insert and visit, if it was there, do nothingthis is enough.On Sun, Sep 24, 2017 at 4:05 AM,   wrote:Hi I am learning Golang concurrency and trying to build a simple Website crawler. I managed to crawl all the links of the pages of any depth of website. But I still have one problem to tackle: how to avoid crawling visited links that are previously crawled?Here is my code. Hope you guys can shed some light. Thank you in advance.package main

import (
"fmt"
"log"
"net/http"
"os"
"strings"

"golang.org/x/net/html"
)

func main() {
if len(os.Args) != 2 {
fmt.Println("Usage: crawl [URL].")
}

url := os.Args[1]
if !strings.HasPrefix(url, "http://") {
url = "http://" + url
}

for link := range newCrawl(url, 1) {
fmt.Println(link)
}
}

func newCrawl(url string, num int) chan string {
ch := make(chan string, 20)

go func() {
crawl(url, 1, ch)
close(ch)
}()

return ch
}

func crawl(url string, n int, ch chan string) {
if n < 1 {
return
}
resp, err := http.Get(url)
if err != nil {
log.Fatalf("Can not reach the site. Error = %v\n", err)
os.Exit(1)
}

b := resp.Body
defer b.Close()

z := html.NewTokenizer(b)

nextN := n - 1
for {
token := z.Next()

switch token {
case html.ErrorToken:
return
case html.StartTagToken:
current := z.Token()
if current.Data != "a" {
continue
}
result, ok := getHrefTag(current)
if !ok {
continue
}

hasProto := strings.HasPrefix(result, "http")
if hasProto {
done := make(chan struct{})
go func() {
crawl(result, nextN, ch)
close(done)
}()
<-done
ch <- result
}
}
}
}

func getHrefTag(token html.Token) (result string, ok bool) {
for _, a := range token.Attr {
if a.Key == "href" {
result = a.Val
ok = true
break
}
}
return
}



-- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-- Michael T. Jonesmichael.jones@gmail.com




-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@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] XML unmarshaller cannot handle space padded numbers

[Sam Whited]

On Fri, Sep 29, 2017, at 10:00, Per Persson wrote:
> I made a commit 
> <https://github.com/md2perpe/go/commit/3d58d7cb9947709c94b309b504c1deca5bfd9143>
>  
> that I was about to make into a pull request, but then I saw the 
> contribution information and now I'm not sure where to propose the
> change.

Welcome!

Go uses Gerrit [1] for code review and changes. Instructions for getting
started can be found in the Contribution Guide [2]. Don't be offended if
it takes people a while to get to reviewing your change request, or if
they leave lots of comments and ask questions. Sometimes people are
busy, and everyone just wants to make sure Go code remains high quality.

Thanks, and good luck! I look forward to seeing your contribution!

—Sam

[1]: https://go-review.googlesource.com
[2]: https://golang.org/doc/contribute.html

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