Re: [go-nuts] Re: [Blog] Context should go away for Go 2

[as . utf8]

Threads are the structural and functional loci of execution on some operating 
systems, data stored in a box accessible to each thread makes sense when you 
obey the constraint that the things in that box are to be used for that thread 
exclusively. 

Goroutines are different, they function like threads but have different 
structure. Structurally, they are not intended to preserve state accessible to 
the user. Goroutines are light, and I suspect that the idiom of goroutine local 
storage is incompatible to the design of the language: anonymous loci of flow 
control communicating through channels as conduits. 

If I could wish for an idiom taken from operating systems, TLS/GLS wouldn't be 
my first choice. I see namespaces serving a similar role on Plan9. The ability 
to share a namespace with the child or parent process. Namespaces include the 
environment and allow the caller too configure what resources a process has 
access to upon execution. Such an addition would also violate the unwritten 
rule of anonymous processes, but context is already doing that. The difference 
is that context is based on what is being executed (what function is called) 
and not where (which goroutine). Contexts are like function namespaces. They 
even have a map of arbitrary key-values. 

The exercise is to find a way to make this feel natural to the language, and 
apply such an approach to functions instead of processes, threads, or 
goroutines.

-- 
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] [CGO] how to pass a 2d slice to C?

[jianzhangbjz]

But, if I can not change the C client, how to implement it? the C client as 
the following. As described on the above, I have to change the ` int**
 _levelmatrix` argument, right?
bool test_settopologyresource(bsagomodule* _self, char* _nodename,
   int _resourceindex, char** _nameunits, int** _levelmatrix) {
   printf("\n set topology resource-> node:%s, resource index:%d", _nodename
, _resourceindex);
   bool result = settopologyresource(_self->client, _nodename, 
_resourceindex, _nameunits, _levelmatrix);
   return result;
}



在 2017年8月7日星期一 UTC+8下午10:14:44，Konstantin Khomoutov写道：
>
> On Mon, Aug 07, 2017 at 06:25:48AM -0700, jianzh...@gmail.com 
>  wrote: 
>
> > Thank you very much for your patience and help. I got it and will try it 
> > later. :) 
>
> Glad to help! 
>
> > > > golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
> > > >levelmatrix := make([][]C.int, len(golevelmatrix)) 
> > > >for i, _ := range golevelmatrix { 
> > > >levelmatrix[i] = make([]C.int, len(golevelmatrix[i])) 
> > > >for j, _ := range golevelmatrix[i] { 
> > > >levelmatrix[i][j] = C.int(golevelmatrix[i][j]) 
> > > >} 
> > > >} 
> [...] 
>
> I'd like to reiterate more precisely: your client is expecting a 
> multi-dimensional array which, in C, would be a contiguous region of 
> memory.  The Go's [][]C.int is a slice of individual []C.int slices. 
> Hence when you pass [0][0] to your C client, it receives the 
> address of the first element of the first slice, and the only valid 
> region of memory to access via that pointer is that element and all the 
> element following it up to (but not including) the length of the first 
> slice. 
>
> As soon as the C client attempts to access any memory region other than 
> that, it may read/write random memory and even invalid memory (at the 
> addressed which are not allocated/mapped) -- in which case you get 
> SIGSEGV or the like. 
>
>

-- 
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] [CGO] how to pass a 2d slice to C?

[jianzhangbjz]

Thanks! As my example on the above, I have to change the C client (change 
`int** _levelmatrix` argument to `int* _levelmatrix`), right? 

在 2017年8月7日星期一 UTC+8下午10:14:44，Konstantin Khomoutov写道：
>
> On Mon, Aug 07, 2017 at 06:25:48AM -0700, jianzh...@gmail.com 
>  wrote: 
>
> > Thank you very much for your patience and help. I got it and will try it 
> > later. :) 
>
> Glad to help! 
>
> > > > golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
> > > >levelmatrix := make([][]C.int, len(golevelmatrix)) 
> > > >for i, _ := range golevelmatrix { 
> > > >levelmatrix[i] = make([]C.int, len(golevelmatrix[i])) 
> > > >for j, _ := range golevelmatrix[i] { 
> > > >levelmatrix[i][j] = C.int(golevelmatrix[i][j]) 
> > > >} 
> > > >} 
> [...] 
>
> I'd like to reiterate more precisely: your client is expecting a 
> multi-dimensional array which, in C, would be a contiguous region of 
> memory.  The Go's [][]C.int is a slice of individual []C.int slices. 
> Hence when you pass [0][0] to your C client, it receives the 
> address of the first element of the first slice, and the only valid 
> region of memory to access via that pointer is that element and all the 
> element following it up to (but not including) the length of the first 
> slice. 
>
> As soon as the C client attempts to access any memory region other than 
> that, it may read/write random memory and even invalid memory (at the 
> addressed which are not allocated/mapped) -- in which case you get 
> SIGSEGV or the like. 
>
>

-- 
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] Offline Go Documentation Tools

[me]

On Monday, July 24, 2017 at 2:52:48 PM UTC-6, Rob 'Commander' Pike wrote:
>
> The "go doc" (distinct from "godoc") command works fine offline. It fact 
> it never goes on line.
>
> -rob
>
>
That's a good tip, I might be even able to use that and pipe it into an 
editor Memo/Edit widget for instant help with an F1 shortcut. Some editors 
have "tools" that you can pipe the output of a process into a status memo 
based on the context (current selected item in editor or cursor). Just 
running it at a command line and reading it like a man page is an option, 
but, I'll likely want something a bit more than that, such as a pop up 
window when I hit F1 or a shortcut.

-- 
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] Offline Go Documentation Tools

[me]

On Monday, July 24, 2017 at 10:46:31 AM UTC-6, Tyler Compton wrote:
>
> For cursor-sensitive help dialogs, you may find Language Server 
> Protocol[1] interesting. It provides what you're looking for in Visual 
> Studio Code with Go today, and will help provide that functionality to 
> editors like [Neo]vim in the future.
>
> 1. http://langserver.org/
>

That's interesting!
Is Visual Studio Code a .Net app that takes up lots of memory and CPU?
I find Visual Studio a memory hog/cpu hog at times and do not like editing 
in it if I do not have to.
However, the "Code" edition could be trimmed down to be quicker, and 
smaller foot print, but only an experienced user would know.

If that does not work, maybe I'll one day take LSP (above) and implement it 
into one of my own editors.

 

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

[Linker]

Hi, Daniel!
Do you know Goroutine local storage  ?
How about replace Context with the Goroutine local storage
 ?

On Tue, Aug 8, 2017 at 12:06 AM, Daniel Theophanes 
wrote:

> Hello Micha,
>
> I'm not seeing any experiences (project building/maintaining) you are
> reporting on.
>
> 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).
>
> Note, Context isn't just useful for servers. It is useful for any
> application. Desktop applications with GUIs, services/daemons, web
> services. In other words, if your application does an operation that could
> block (file IO, network IO, running executable) and you either have a
> halting program or a program you want to be responsive, Context is
> exceptionally useful.
>
> 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.
>
> 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." 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.
>
> Lastly as an aside, github emoji reactions are fine for what they are. But
> they are not an engineering argument one way or another. Last time I
> checked no one is running a popularity contest.
>
> Thanks, -Daniel
>
>
> On Monday, August 7, 2017 at 6:40:05 AM UTC-7, Michal Strba wrote:
>>
>> Hi everyone!
>>
>> I've written a blog post called 'Context should go away for Go 2':
>>
>> https://faiface.github.io/post/context-should-go-away-go2/
>>
>> The post is about the cancelation problem in Go, how context package
>> solves it, why context package is bad anyway, and that Go 2 should do
>> something about it. Hope you enjoy reading ;)
>>
>> PS: I'm not sure if this post is acceptable for an experience report. If
>> you think it is / isn't, let me know.
>>
>> Michal Štrba
>>
> --
> 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.
>



-- 


*Regards,Linker linlinker.m@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] built tests fail on sierra 10.12.6

[Bakul Shah]

How to debug these issues?

$ cd /usr/local/go/src
$ ./all.bash
...
ok  cmd/vet 2.859s
ok  cmd/vet/internal/cfg0.012s
2017/08/07 15:19:58 Failed: exit status 1

The same thing happens either with the HEAD branch or go1.9rc2
(and also earlier).  In addition go1.9rc2 has this failure:

ok  crypto/tls  0.453s
--- FAIL: TestSystemRoots (0.57s)
root_darwin_test.go:31: cgo sys roots: 67.37748ms
root_darwin_test.go:32: non-cgo sys roots: 498.322315ms
root_darwin_test.go:44: got 168 roots
root_darwin_test.go:44: got 420 roots
root_darwin_test.go:73: insufficient overlap between cgo and non-cgo 
roots; want at least 210, have 168
FAIL
FAILcrypto/x509 1.461s

FYI:

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bakul/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 
-fdebug-prefix-map=/var/folders/h_/8gwgdzhx4bz92b3hybwgz534gn/T/go-build152554474=/tmp/go-build
 -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

$ uname -a
Darwin mob.bitblocks.com 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 
17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

$ git cat-file -p HEAD
tree e22f8125b5061144ea4a7e6bb958a149bfa09816
parent cff0de3da338f8aa4682253a9cc045bd70a8c9c4
author Chris Broadfoot  1502133786 -0700
committer Chris Broadfoot  1502137741 +

[release-branch.go1.9] go1.9rc2

$ git cat-file -p master

tree 0c3db3ff24ad5a0b45c5e34e0747eefd3d09ebec
parent 380525598ca917fe3226842f91695f4851b34e89
author Keith Randall  1501952321 -0700
committer Keith Randall  1502087082 +

runtime: mapassign_* should use typedmemmove to update keys

We need to make sure that when the key contains a pointer, we use
a write barrier to update the key.

Also mapdelete_* should use typedmemclr.

Fixes #21297

Thanks!

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

Re: [go-nuts] Re: How to automatically get all dependencies (even for tests)?

[Sebastien Binet]

On Mon, Aug 7, 2017 at 5:05 PM,  wrote:

> An easy way around this is to just import the package with an underscore
> before it in your main file. I only had one test package I needed so this
> worked well for me.
>
> i.e _"github.com/some/thing"
>
> On Monday, August 6, 2012 at 12:15:30 AM UTC-5, Steven Degutis wrote:
>>
>> `go get` and `go get .` skip any dependencies that are in test files. Is
>> there something analogous to this command but takes into account test files?
>
>
go get -t foo/bar/...

should work.

-s

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

[go-nuts] Go 1.9 Release Candidate 2 is released

[Chris Broadfoot]

Hello gophers,

We have just released go1.9rc2, a release candidate of Go 1.9.
It is cut from release-branch.go1.9 at the revision tagged go1.9rc2.

Thank you to everyone who has helped to test Go 1.9 so far.
We still need more people to test, especially on production workloads.
Your help is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.9rc2
is by using this tool:
https://godoc.org/golang.org/x/build/version/go1.9rc2

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.9rc2

To find out what has changed in Go 1.9, read the draft release notes:
https://tip.golang.org/doc/go1.9

Documentation for Go 1.9 is available at:
https://tip.golang.org/

Cheers,
Chris

-- 
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: Concurrency Testimonial

[ojucie]

Cecil, never mind the low response count for your testimonial. We are happy 
for you and feel your pleasure, believe me. Go concurrency support is 
really that awesome.
A lot of people don't jump to respond to you just because we are used to 
this superb tool. Fast and easy.
What amuses me the most is that many developers don't even have a clue 
about it.  8^)

-- 
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: runtime.GOOS case

[Eric Brown]

Appreciate the reply, guys.  Also, Chris, it's not usually a problem... I 
just prefer to keep the compiled file size and resources minimal; 
therefore, don't like to import packages unless absolutely necessary.

On Monday, August 7, 2017 at 4:12:03 PM UTC-5, James Bardin wrote:
>
> They will always be lowercase, as the values are all defined in the code
>
> const GOOS = `android`
> const GOOS = `darwin`
> const GOOS = `dragonfly`
> const GOOS = `freebsd`
> const GOOS = `linux`
> const GOOS = `nacl`
> const GOOS = `netbsd`
> const GOOS = `openbsd`
> const GOOS = `plan9`
> const GOOS = `solaris`
> const GOOS = `windows`
>
> But it's usually better to rely on build constraints rather than 
> conditionals at runtime. 
>
>
>
> On Monday, August 7, 2017 at 5:00:24 PM UTC-4, Eric Brown wrote:
>>
>> This may be a completely stupid or trivial question; however...
>>
>> I currently use this on some old code I'm working on and trying to clean 
>> things up:
>>
>> switch os := strings.ToLower(runtime.GOOS); os {
>> case "windows":
>>// do windows stuff here
>> case "linux":
>>// do linux stuff here
>>
>> default:
>>// do default stuff here
>>
>> }
>>
>>
>> I hate to import the entire strings package just to ensure that switch 
>> will work.  Does anybody know if runtime.GOOS will always return a 
>> lowercase value so I don't have to import the strings package just for this 
>> single check?  All I can find is that GOOS returns (sys 
>> .GOOS 
>> )...
>> I'd rather be safe than sorry.
>>
>

-- 
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: runtime.GOOS case

[Dave Cheney]

the GOOS values are case sensitive and currently all specified to be lower 
case; GOOS=linux != GOOS=Linux. You don't need to ToLower a runtime.GOOS as

a. that would mean your Go installation was built with the wrong value
b. by working around this it would hide the problem until it was harder to 
fix.

On Tuesday, 8 August 2017 07:00:24 UTC+10, Eric Brown wrote:
>
> This may be a completely stupid or trivial question; however...
>
> I currently use this on some old code I'm working on and trying to clean 
> things up:
>
> switch os := strings.ToLower(runtime.GOOS); os {
> case "windows":
>// do windows stuff here
> case "linux":
>// do linux stuff here
>
> default:
>// do default stuff here
>
> }
>
>
> I hate to import the entire strings package just to ensure that switch 
> will work.  Does anybody know if runtime.GOOS will always return a 
> lowercase value so I don't have to import the strings package just for this 
> single check?  All I can find is that GOOS returns (sys 
> .GOOS 
> )...
> I'd rather be safe than sorry.
>

-- 
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: runtime.GOOS case

[James Bardin]

They will always be lowercase, as the values are all defined in the code

const GOOS = `android`
const GOOS = `darwin`
const GOOS = `dragonfly`
const GOOS = `freebsd`
const GOOS = `linux`
const GOOS = `nacl`
const GOOS = `netbsd`
const GOOS = `openbsd`
const GOOS = `plan9`
const GOOS = `solaris`
const GOOS = `windows`

But it's usually better to rely on build constraints rather than 
conditionals at runtime. 



On Monday, August 7, 2017 at 5:00:24 PM UTC-4, Eric Brown wrote:
>
> This may be a completely stupid or trivial question; however...
>
> I currently use this on some old code I'm working on and trying to clean 
> things up:
>
> switch os := strings.ToLower(runtime.GOOS); os {
> case "windows":
>// do windows stuff here
> case "linux":
>// do linux stuff here
>
> default:
>// do default stuff here
>
> }
>
>
> I hate to import the entire strings package just to ensure that switch 
> will work.  Does anybody know if runtime.GOOS will always return a 
> lowercase value so I don't have to import the strings package just for this 
> single check?  All I can find is that GOOS returns (sys 
> .GOOS 
> )...
> I'd rather be safe than sorry.
>

-- 
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] runtime.GOOS case

[Chris Manghane]

You can see how the different runtime.GOOS values are defined in the
OS-specific runtime files like
https://github.com/golang/go/blob/master/src/runtime/internal/sys/zgoos_windows.go.
They happen to be lowercase, but I don't know anything that guarantees that
in any future.

Curious though, why does it matter if you import the strings package for a
single check? That's surprising to me.

On Mon, Aug 7, 2017 at 2:00 PM, Eric Brown  wrote:

> This may be a completely stupid or trivial question; however...
>
> I currently use this on some old code I'm working on and trying to clean
> things up:
>
> switch os := strings.ToLower(runtime.GOOS); os {
> case "windows":
>// do windows stuff here
> case "linux":
>// do linux stuff here
>
> default:
>// do default stuff here
>
> }
>
>
> I hate to import the entire strings package just to ensure that switch
> will work.  Does anybody know if runtime.GOOS will always return a
> lowercase value so I don't have to import the strings package just for this
> single check?  All I can find is that GOOS returns (sys
> .GOOS
> )...
> I'd rather be safe than sorry.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] runtime.GOOS case

[Eric Brown]

This may be a completely stupid or trivial question; however...

I currently use this on some old code I'm working on and trying to clean 
things up:

switch os := strings.ToLower(runtime.GOOS); os {
case "windows":
   // do windows stuff here
case "linux":
   // do linux stuff here

default:
   // do default stuff here

}


I hate to import the entire strings package just to ensure that switch will 
work.  Does anybody know if runtime.GOOS will always return a lowercase 
value so I don't have to import the strings package just for this single 
check?  All I can find is that GOOS returns (sys 
.GOOS 
)...
I'd rather be safe than sorry.

-- 
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: [Go2] Reflect

[roger peppe]

On 7 Aug 2017 20:35, "Gert"  wrote:


On Monday, August 7, 2017 at 5:59:15 PM UTC+2, rog wrote:
>
> What is this supposed to do? What does it do if the value
> isn't an integer?


Same error as you do int("4")


Um, have you tried that? It's a compiler error.



> Are you thinking that it would be the same as fmt.Println("value:",
> r.Interface().(int)) ?
>

Nope more that it acts as a basic type like a int(4) so that reflect is the
same as any other basic types float int byte string etc


What do you mean by that? The same in what respects?

-- 
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] [Go2] append

[Jan Mercl]

On Mon, Aug 7, 2017 at 9:52 PM Gert  wrote:

> Exactly, pretty sure some day if Go get used in a power plant or
something we will have a outage for bugs like this that fly under the radar
so easily passing all tooling, error checks and probably unit tests too :)

Detecting the buggy case, unfortunately, requires first to solve the
halting problem. So revisit this one afterwards ;-)

-- 

-j

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

Re: [go-nuts] [Go2] append

[Gert]

On Monday, August 7, 2017 at 9:39:06 PM UTC+2, Jan Mercl wrote:
>
>
> Does this code really output what you want it to output? 
> https://play.golang.org/p/DWQXtkGByv
>
> Assigning the result value of append to a different variable than its 
> first argument is completely valid, but one has to be really sure why to do 
> that. Did you mean https://play.golang.org/p/-OMw3qGYjU ?
>
>
Exactly, pretty sure some day if Go get used in a power plant or something 
we will have a outage for bugs like this that fly under the radar so easily 
passing all tooling, error checks and probably unit tests too :) 

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

[Jan Mercl]

On Mon, Aug 7, 2017 at 9:23 PM Gert  wrote:

> Can append or the compiler be made to prevent or warn for bugs like this?

No. Slice is a value and append accepts s not  as its first argument.
That means the new slice value need be returned for code that uses the
resulting slice, which is the case most often seen.

> func main() {
> a := []byte("Help")
> b := append(a, []byte(" Me ")...)
> c := append(a, []byte(" Her")...)
> fmt.Println(string(a), "-", string(b), "-", string(c))
> }

Does this code really output what you want it to output?
https://play.golang.org/p/DWQXtkGByv

Assigning the result value of append to a different variable than its first
argument is completely valid, but one has to be really sure why to do that.
Did you mean https://play.golang.org/p/-OMw3qGYjU ?

-- 

-j

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

Re: [go-nuts] Re: [Go2] Reflect

[Gert]

On Monday, August 7, 2017 at 5:59:15 PM UTC+2, rog wrote: 
>
> What is this supposed to do? What does it do if the value 
> isn't an integer? 


Same error as you do int("4") 
  

> Are you thinking that it would be the same as fmt.Println("value:", 
> r.Interface().(int)) ? 
>

Nope more that it acts as a basic type like a int(4) so that reflect is the 
same as any other basic types float int byte string 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.

[go-nuts] [Go2] append

[Gert]

Can append or the compiler be made to prevent or warn for bugs like this?

package main

import (
"fmt"
)

func main() {
a := []byte("Help")
b := append(a, []byte(" Me ")...)
c := append(a, []byte(" Her")...)
fmt.Println(string(a), "-", string(b), "-", string(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: [Blog] Context should go away for Go 2

[Uli Kunitz]

I assume here that the proposal is not to change io.Reader but to create a 
new interface, maybe context.Reader. There are lot of uses of io.Reader 
where the Read operations will not block and therefore no context is 
necessary. A context.Reader would also require a wrapper function that 
converts a context.Reader to an io.Reader.

On Monday, August 7, 2017 at 6:06:23 PM UTC+2, Daniel Theophanes wrote:

> Hello Micha,
>
> I'm not seeing any experiences (project building/maintaining) you are 
> reporting on.
>
> 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).
>
> Note, Context isn't just useful for servers. It is useful for any 
> application. Desktop applications with GUIs, services/daemons, web 
> services. In other words, if your application does an operation that could 
> block (file IO, network IO, running executable) and you either have a 
> halting program or a program you want to be responsive, Context is 
> exceptionally useful.
>
> 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.
>
> 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." 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.
>
> Lastly as an aside, github emoji reactions are fine for what they are. But 
> they are not an engineering argument one way or another. Last time I 
> checked no one is running a popularity contest.
>
> Thanks, -Daniel
>
>
> On Monday, August 7, 2017 at 6:40:05 AM UTC-7, Michal Strba wrote:
>>
>> Hi everyone!
>>
>> I've written a blog post called 'Context should go away for Go 2':
>>
>> https://faiface.github.io/post/context-should-go-away-go2/
>>
>> The post is about the cancelation problem in Go, how context package 
>> solves it, why context package is bad anyway, and that Go 2 should do 
>> something about it. Hope you enjoy reading ;)
>>
>> PS: I'm not sure if this post is acceptable for an experience report. If 
>> you think it is / isn't, let me know.
>>
>> Michal Štrba
>>
>

-- 
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] "find" for Slices like "append"

[Jan Mercl]

On Mon, Aug 7, 2017 at 4:23 PM  wrote:

> 2) find(sliceB, item_i_look_for) int, -1 for not found

See https://golang.org/pkg/sort/#Search and friends

-- 

-j

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

[go-nuts] Re: [Blog] Context should go away for Go 2

[Daniel Theophanes]

Hello Micha,

I'm not seeing any experiences (project building/maintaining) you are 
reporting on.

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

Note, Context isn't just useful for servers. It is useful for any 
application. Desktop applications with GUIs, services/daemons, web 
services. In other words, if your application does an operation that could 
block (file IO, network IO, running executable) and you either have a 
halting program or a program you want to be responsive, Context is 
exceptionally useful.

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.

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

Lastly as an aside, github emoji reactions are fine for what they are. But 
they are not an engineering argument one way or another. Last time I 
checked no one is running a popularity contest.

Thanks, -Daniel


On Monday, August 7, 2017 at 6:40:05 AM UTC-7, Michal Strba wrote:
>
> Hi everyone!
>
> I've written a blog post called 'Context should go away for Go 2':
>
> https://faiface.github.io/post/context-should-go-away-go2/
>
> The post is about the cancelation problem in Go, how context package 
> solves it, why context package is bad anyway, and that Go 2 should do 
> something about it. Hope you enjoy reading ;)
>
> PS: I'm not sure if this post is acceptable for an experience report. If 
> you think it is / isn't, let me know.
>
> Michal Štrba
>

-- 
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: [Go2] Reflect

[roger peppe]

On 7 August 2017 at 16:22, Gert Cuykens  wrote:
> On Mon, Aug 7, 2017 at 12:03 PM, roger peppe  wrote:
>> ISTM that the only thing you're suggesting is to change
>> the spelling of "reflect.ValueOf" to "reflect".
>>
>> I don't understand what semantics you'd expect
>>
>> fmt.Println("value:", r.Value(int))
>>
>> to have. What's the parameter to that Value method?
>>
>
> Merge ValueOf and TypeOf into one reflect() build in

reflect.TypeOf is strictly a convenience anyway - you can
always write reflect.ValueOf(x).Type() instead.

So this suggestion is just equivalent to doing:

   func reflect(x interface{}) reflect.Value {
return reflect.ValueOf(x)
   }

(except you can't do that, because reflect is the name of the
package, which is an issue with your suggestion too).

> (and make the
> reflect type transform easier with other types fmt.Println("value:",
> int(r.Value))

What is this supposed to do? What does it do if the value
isn't an integer?

Are you thinking that it would be the same as fmt.Println("value:",
r.Interface().(int)) ?

-- 
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] "find" for Slices like "append"

[martin . rode]

>
>
> Because it's easy to write a short correct find loop for the type you 
> are using, but a good implementation of append is a much larger 
> function.  See also http://www.airs.com/blog/archives/559 . 
>

So "append" is already done. May I propose to implement a generic "find" 
function?

That should be possible without coming up with good general generics 
support, shouldn't it? 

In my everyday programming life a check if an item is inside an Array is 
very common. Often this
is even built-in syntax (like in Python "if a in array...").

I will have a hard time selling this missing feature to my team.

Martin

>
>

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

[Linker]

Do you know Goroutine local storage  ?

On Mon, Aug 7, 2017 at 11:20 PM,  wrote:

> I also dont want to see context everywhere. At the same time, I don't want
> it to be obfuscated in a confusing way.
>
> ctx is an unfortunate initialism and context.Context package stuttering
> doesn't help.
>
> I suppose you could stuff a pointer on the stack pointing to a potential
> context and then provide a built-in to access this structure. But that
> already sounds confusing and easy to ignore, and you've added a few bytes
> of overhead to each function call by providing an auxillary argument to
> every function and method.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Regards,Linker linlinker.m@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Repository of self-contained functions

[Michael Jones]

i have the same. Like HAKMEM, just not as smart.

On Mon, Aug 7, 2017 at 8:22 AM, Shawn Milochik  wrote:

> I like *idea* of that idea, but I suspect that the implementation
> wouldn't work out.
>
> As the Go Proverb says: "A little copying is better than a little
> dependency."
>
> I have a similar repo for my personal use, but I copy/paste from it rather
> than import it. It's a modern version of the folder we all keep on our hard
> drives of useful little snippets.
> https://github.com/shawnmilo/uhf
>
> If we did have a community version of that, like a wiki or "cookbook"
> site, that would be cool for browsing and copy/paste, though. Just not
> actual importing.
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Repository of self-contained functions

[Shawn Milochik]

I like *idea* of that idea, but I suspect that the implementation wouldn't
work out.

As the Go Proverb says: "A little copying is better than a little
dependency."

I have a similar repo for my personal use, but I copy/paste from it rather
than import it. It's a modern version of the folder we all keep on our hard
drives of useful little snippets.
https://github.com/shawnmilo/uhf

If we did have a community version of that, like a wiki or "cookbook" site,
that would be cool for browsing and copy/paste, though. Just not actual
importing.

-- 
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: [Go2] Reflect

[Gert Cuykens]

On Mon, Aug 7, 2017 at 12:03 PM, roger peppe  wrote:
> ISTM that the only thing you're suggesting is to change
> the spelling of "reflect.ValueOf" to "reflect".
>
> I don't understand what semantics you'd expect
>
> fmt.Println("value:", r.Value(int))
>
> to have. What's the parameter to that Value method?
>

Merge ValueOf and TypeOf into one reflect() build in and make the
reflect type transform easier with other types fmt.Println("value:",
int(r.Value))

-- 
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 to automatically get all dependencies (even for tests)?

[bhperry94]

An easy way around this is to just import the package with an underscore 
before it in your main file. I only had one test package I needed so this 
worked well for me.

i.e _"github.com/some/thing"

On Monday, August 6, 2012 at 12:15:30 AM UTC-5, Steven Degutis wrote:
>
> `go get` and `go get .` skip any dependencies that are in test files. Is 
> there something analogous to this command but takes into account test files?
>
> -Steven
>

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

[as . utf8]

I also dont want to see context everywhere. At the same time, I don't want it 
to be obfuscated in a confusing way. 

ctx is an unfortunate initialism and context.Context package stuttering doesn't 
help. 

I suppose you could stuff a pointer on the stack pointing to a potential 
context and then provide a built-in to access this structure. But that already 
sounds confusing and easy to ignore, and you've added a few bytes of overhead 
to each function call by providing an auxillary argument to every function and 
method.

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

[go-nuts] Repository of self-contained functions

[Lukas Senger]

Hi everybody,

I've had this idea rolling around in my head for a while now and I'm not
sure if it is worth diving into.

What do you think of importing single functions from an online
repository of functions that anybody can contribute to. Functions would
be uniquely identified by their hash (after gofmt) so you could do stuff
like this:

package main

import example "funcservice.com/somehash"

func main() {
example.SomeFunc()
}

where somehash either points to a single function or a collection of
functions (to save on import aliases) and be certain that SomeFunc never
changes (unless someone hacks funcservice.com). Basically the idea is to
encourage writing and sharing simple self-contained functions.

Apart from security implications and implementation details, is this
something anybody could see themselves using in personal or professional
projects?

--Lukas

-- 
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] "find" for Slices like "append"

[Ian Lance Taylor]

On Mon, Aug 7, 2017 at 7:44 AM,   wrote:
>>
>> > 2) find(sliceB, item_i_look_for) int, -1 for not found
>> >
>> > Why can I not find easily search for an item inside a Slice. Every other
>> > language I know has this. And I need this in a generic form.
>>
>> As you have probably heard, Go does not have generics.  Sorry.  The
>> loop that you need to write is fairly short.
>
>
> The loop might be short, but I need to know the type of the items in my
> Slice.
>
> So I need a loop for every datatype!?

Yes.

> And I need to name it for each type differently?

Yes.

> Why?

Because Go does not have generics.  There has been a enormous amount
of discussion on this in the past that I won't try to summarize here.
You could read https://golang.org/issue/15292.

> All I want to be able to do is to find an item in a Slice.
>
> Why does "append" work with all types then?

Because it's easy to write a short correct find loop for the type you
are using, but a good implementation of append is a much larger
function.  See also http://www.airs.com/blog/archives/559 .

Ian

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

Re: [go-nuts] "find" for Slices like "append"

[martin . rode]

>
>
> > Why can I not append something to a Slice in place, why does it have to 
> > return a new Slice? 
>
> https://blog.golang.org/slices 
>
> Ok, I will check that, thx.
 

>
> > 2) find(sliceB, item_i_look_for) int, -1 for not found 
> > 
> > Why can I not find easily search for an item inside a Slice. Every other 
> > language I know has this. And I need this in a generic form. 
>
> As you have probably heard, Go does not have generics.  Sorry.  The 
> loop that you need to write is fairly short.


The loop might be short, but I need to know the type of the items in my 
Slice.

So I need a loop for every datatype!? 

And I need to name it for each type differently? 

Why? 

All I want to be able to do is to find an item in a Slice. 

Why does "append" work with all types then?

Martin
 

-- 
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] Broken Link in Go Assembly Guide

[John McKown]

On Sun, Aug 6, 2017 at 11:59 PM, Ben Reed  wrote:

> Hi... I was looking at the Go Assembly Guide ( http://itty.be/5rhhz ),
> and I keep trying to refer to Plan 9 Assembly.  I'm unfamiliar with this,
> and so I keep trying to go to 9p.io.  The link is broken though. Does
> anyone know where I can get an overview of this assembler?
>

​Google search showed up:

https://9p.io/sys/doc/asm.html (which I did get to just fine)
https://golang.org/doc/asm (also got to with no problems)
https://golang.org/doc/asm (appears to have the same content as previous
hit)
​

-- 
If you look around the poker table & don't see an obvious sucker, it's you.

Maranatha! <><
John McKown

-- 
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] "find" for Slices like "append"

[Ian Lance Taylor]

On Mon, Aug 7, 2017 at 6:45 AM,   wrote:
> Being fairly new to Go, I am trying to evaluate if it s possible and worth
> to move our huge C++ codebase over to Go.
>
> 1) append(sliceA, my_new_item) sliceA
>
> Why can I not append something to a Slice in place, why does it have to
> return a new Slice?

https://blog.golang.org/slices


> 2) find(sliceB, item_i_look_for) int, -1 for not found
>
> Why can I not find easily search for an item inside a Slice. Every other
> language I know has this. And I need this in a generic form.

As you have probably heard, Go does not have generics.  Sorry.  The
loop that you need to write is fairly short.

Ian

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

[go-nuts] Broken Link in Go Assembly Guide

[Ben Reed]

Hi... I was looking at the Go Assembly Guide ( http://itty.be/5rhhz ), and 
I keep trying to refer to Plan 9 Assembly.  I'm unfamiliar with this, and 
so I keep trying to go to 9p.io.  The link is broken though. Does anyone 
know where I can get an overview of this assembler?

-- 
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] "find" for Slices like "append"

[martin . rode]

Being fairly new to Go, I am trying to evaluate if it s possible and worth 
to move our huge C++ codebase over to Go.

1) append(sliceA, my_new_item) sliceA

Why can I not append something to a Slice in place, why does it have to 
return a new Slice?

2) find(sliceB, item_i_look_for) int, -1 for not found

Why can I not find easily search for an item inside a Slice. Every other 
language I know has this. And I need this in a generic form.

Or am I missing something entirely here?

Best
Martin

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

[go-nuts] Re: why do we need generic thread.

[adam.azarchs via golang-nuts]

Personally I don't think a completely, um, generic version of generics is 
needed.  But something like a list comprehension, possibly specifically 
limited to "select"/"map" type comprehensions which do not change slice or 
map length, would be invaluable.  There's already a lot of special magic 
around slices and maps, so adding more wouldn't be as world-changing as 
adding it everywhere else (in both good and bad ways), while enabling one 
to write a lot of useful list-processing utilities once instead of several 
times.  Since most of real-life software engineering turns into list 
processing at some point, that would be super nice.

On Friday, August 4, 2017 at 9:30:43 PM UTC-7, Lucio wrote:
>
> We know how to deal with that without generics. But how would you define 
> generics to address that more elegantly than you would with already 
> available Go constructs (type assertions)?
>
> Lucio.
>
> On Saturday, 5 August 2017 01:48:28 UTC+2, T L wrote:
>>
>> A case:
>>
>> func iterateAndCopy(slice []T, p *T) {
>> for _, v := range slice {
>> *p = v
>> }
>> }
>>
>> func Benchmark_CopyCosts(b *testing.B) {
>> b.Run("bool-4", func(b *testing.B){
>> iterateAndCopy(make([]bool, 4), new(bool))
>> })
>> b.Run("int32-4", func(b *testing.B){
>> iterateAndCopy(make([]int32, 4), new(int32))
>> })
>> b.Run("int64-4", func(b *testing.B){
>> iterateAndCopy(make([]int64, 4), new(int64))
>> })
>> b.Run("[128]int-4", func(b *testing.B){
>> iterateAndCopy(make([][128]int64, 4), new([128]int64))
>> })
>> b.Run("struct{a,b,c,d int32}-100", func(b *testing.B){
>> iterateAndCopy(make([]struct{a,b,c,d int32}, 100), 
>> new(struct{a,b,c,d int32}))
>> })
>> b.Run("bool-100", func(b *testing.B){
>> iterateAndCopy(make([]bool, 100), new(bool))
>> })
>> b.Run("int32-100", func(b *testing.B){
>> iterateAndCopy(make([]int32, 100), new(int32))
>> })
>> b.Run("int64-100", func(b *testing.B){
>> iterateAndCopy(make([]int64, 100), new(int64))
>> })
>> b.Run("[128]int-100", func(b *testing.B){
>> iterateAndCopy(make([][128]int64, 100), new([128]int64))
>> })
>> b.Run("struct{a,b,c,d int32}-100", func(b *testing.B){
>> iterateAndCopy(make([]struct{a,b,c,d int32}, 100), 
>> new(struct{a,b,c,d int32}))
>> })
>> }
>>
>

-- 
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] [CGO] how to pass a 2d slice to C?

[Konstantin Khomoutov]

On Mon, Aug 07, 2017 at 06:25:48AM -0700, jianzhang...@gmail.com wrote:

> Thank you very much for your patience and help. I got it and will try it 
> later. :)

Glad to help!

> > > golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
> > >levelmatrix := make([][]C.int, len(golevelmatrix)) 
> > >for i, _ := range golevelmatrix { 
> > >levelmatrix[i] = make([]C.int, len(golevelmatrix[i])) 
> > >for j, _ := range golevelmatrix[i] { 
> > >levelmatrix[i][j] = C.int(golevelmatrix[i][j]) 
> > >} 
> > >} 
[...]

I'd like to reiterate more precisely: your client is expecting a
multi-dimensional array which, in C, would be a contiguous region of
memory.  The Go's [][]C.int is a slice of individual []C.int slices.
Hence when you pass [0][0] to your C client, it receives the
address of the first element of the first slice, and the only valid
region of memory to access via that pointer is that element and all the
element following it up to (but not including) the length of the first slice.

As soon as the C client attempts to access any memory region other than
that, it may read/write random memory and even invalid memory (at the
addressed which are not allocated/mapped) -- in which case you get
SIGSEGV or the like.

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

[faiface2202]

Hi everyone!

I've written a blog post called 'Context should go away for Go 2':

https://faiface.github.io/post/context-should-go-away-go2/

The post is about the cancelation problem in Go, how context package solves 
it, why context package is bad anyway, and that Go 2 should do something 
about it. Hope you enjoy reading ;)

PS: I'm not sure if this post is acceptable for an experience report. If 
you think it is / isn't, let me know.

Michal Štrba

-- 
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] [CGO] how to pass a 2d slice to C?

[jianzhangbjz]

Thank you very much for your patience and help. I got it and will try it 
later. :)

在 2017年8月7日星期一 UTC+8下午3:52:43，Konstantin Khomoutov写道：
>
> On Sun, Aug 06, 2017 at 07:08:03PM -0700, jianzh...@gmail.com 
>  wrote: 
>
> > Thanks your reply, I also used this way, but it still not work. code as 
> the 
> > following. 
> > 
> > gonameunits := []string{"gpu0", "gpu1", "gpu2", "gpu3"} 
> >nameunits := make([]*C.char, len(gonameunits)) 
> >for i, _ := range gonameunits { 
> >nameunits[i] = C.CString(gonameunits[i]) 
> >defer C.free(unsafe.Pointer(nameunits[i])) 
> >} 
> >fmt.Println("nameunits:", nameunits) 
>
> This looks correct... 
>
> > golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}} 
> >levelmatrix := make([][]C.int, len(golevelmatrix)) 
> >for i, _ := range golevelmatrix { 
> >levelmatrix[i] = make([]C.int, len(golevelmatrix[i])) 
> >for j, _ := range golevelmatrix[i] { 
> >levelmatrix[i][j] = C.int(golevelmatrix[i][j]) 
> >} 
> >} 
>
> ...but this is not: remember that in Go, the type []T denotes *a slice* of 
> elements of type T.  A slice is a dynamic construct which is a view into 
> underlying array, and as such it itself consists of a pointer into that 
> array's contents, the current length of the slice and the capacity of 
> it. 
>
> >fmt.Println("levelmatrix:", levelmatrix) 
> > 
> > C.test_settopologyresource(mod, C.CString("node1"), C.int(2), 
> (**C.char 
> > )(unsafe.Pointer([0])), 
> (**C.int)(unsafe.Pointer([0][0 
> > ]))) 
>
> That thing about slices means that passing a pointer to a single slice 
> element to C is OK; passing a pointer to an Nth element of a slice to C 
> and expecting it to access it and the elements following it up to the 
> slice's length is also OK but interpreting a slice of slices (which 
> [][]*C.int really is) is wrong: it's not represented by a contiguous 
> array: it's a slice of N independent slices -- each backed by its 
> independent array. 
>
> So what you really want is something like: 
>
> 1. Know the dimensions of your matrix (let's denote them by N and M). 
> 2. Allocate a slice of the length N*M. 
> 3. Fill it up with the values from your source slice of slices. 
> 4. Pass the pointer to the array to C. 
>
> Like this (untested, may not even compile): 
>
>   n := len(golevelmatrix) 
>   m := 0 
>   for _, row := range golevelmatrix { 
> if len(row) > m { 
>   m = len(row) 
> } 
>   } 
>   
>   a := make([]int, n*m) 
>   i := 0 
>   for _, row := range golevelmatrix { 
> for j, v := range row { 
> a[i*n+j] = v 
> } 
> i++ 
>   } 
>
>   C.my_func([0]) 
>
>

-- 
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: [Go2] Reflect

[roger peppe]

On 6 August 2017 at 21:51, Gert  wrote:
> Yes but its the way it's done that i think could be made more
> straightforward, why not merge ValueOf and TypeOf in a build in intermediate
> reflect type as in for example int(4) but then reflect(4)

ISTM that the only thing you're suggesting is to change
the spelling of "reflect.ValueOf" to "reflect".

I don't understand what semantics you'd expect

fmt.Println("value:", r.Value(int))

to have. What's the parameter to that Value method?

>
> On Sunday, August 6, 2017 at 5:57:40 PM UTC+2, Rich wrote:
>>
>> I don't understand... doesn't Reflect already do this?
>> https://play.golang.org/p/CIm7aISztv
>>
>>
>> On Saturday, August 5, 2017 at 12:58:52 PM UTC-4, Gert wrote:
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "reflect"
>>> )
>>>
>>> func main() {
>>> x := 4
>>> v1 := reflect.ValueOf(x)
>>> fmt.Println("type:", v1.Type())
>>> v2 := reflect.TypeOf(x)
>>> fmt.Println("type:", v2)
>>> }
>>>
>>> Kan we have something like this instead please
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "reflect"
>>> )
>>>
>>> func main() {
>>> x := 4
>>> r := reflect(x)
>>> fmt.Println("type:", r.Type())
>>> fmt.Println("value:", r.Value(int))
>>> }
>>>
>>> Reflect should be a generic way of Go2, but everytime i need to reflect
>>> around a Go1 interface i want to go on a vacation...
>>>
> --
> 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] Realizing SSD random read IOPS

[Manish Rai Jain]

Hey folks,

Just wanted to update the status of this.

During Gophercon, I happened to meet Russ Cox and asked him the same
question. If File::Read blocks goroutines, which then spawn new OS threads,
in a long running job, there should be plenty of OS threads created
already, so the random read throughput should increase over time and
stabilize to the maximum possible value. But, that's not what I see in my
benchmarks.

And his explanation was that the GOMAXPROCS in a way acts like a
multiplexer. From docs, "the GOMAXPROCS variable limits the number of
operating system threads that can execute user-level Go code
simultaneously." Which basically means, all reads must first be run only
via GOMAXPROCS number of goroutines, before switching over to some OS
thread (not really a switch, but conceptually speaking). This introduces a
bottleneck for throughput.

I re-ran my benchmarks with a much higher GOMAXPROCS and was able to then
achieve the maximum throughput. The numbers are here:
https://github.com/dgraph-io/badger-bench/blob/master/randread/maxprocs.txt
To summarize these benchmarks, Linux fio achieves 118K IOPS, and with
GOMAXPROCS=64/128, I'm able to achieve 105K IOPS, which is close enough.
Win!

Regarding the point about using io_submit etc., instead of goroutines; I
managed to find a library which does that, but it performed worse than just
using goroutines.
https://github.com/traetox/goaio/issues/3
>From what I gather (talking to Russ and Ian), whatever work is going on
in user space, the same work has to happen in kernel space; so there's not
much benefit here.

Overall, with GOMAXPROCS set to a higher value (as I've done in Dgraph
),
one can get the advertised SSD throughput using goroutines.

Thanks, Ian, Russ and the Go community in helping solve this problem!

On Sat, May 20, 2017 at 5:31 AM, Ian Lance Taylor  wrote:

> On Fri, May 19, 2017 at 3:26 AM, Manish Rai Jain 
> wrote:
> >
> >> It's not obvious to me that io_submit would be a win for normal
> > programs, but if anybody wants to try it out and see that would be
> > great.
> >
> > Yeah, my hunch is that the cost of threads context switching is going to
> be
> > a hindrance to achieving the true throughput of SSDs. So, I'd like to
> try it
> > out. A few guiding pointers would be useful:
> >
> > - This can be done directly via Syscall and Syscall6, is that right? Or
> > should I use Cgo?
>
> You should be able to use syscall.Syscall.
>
> > - I see SYS_IO_SUBMIT in syscall package. But, no aio_context_t, or
> iocbpp
> > structs in the package.
> > - Similarly, other structs for io_getevents etc.
> > - What's the best way to generate them, so syscall.Syscall would accept
> > these?
>
> The simplest way is to get them via cgo.  The better way is to add
> them to the x/sys/unix package as described at
> https://github.com/golang/sys/blob/master/unix/README.md .
>
> Ian
>

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

Re: [go-nuts] [CGO] how to pass a 2d slice to C?

[Konstantin Khomoutov]

On Sun, Aug 06, 2017 at 07:08:03PM -0700, jianzhang...@gmail.com wrote:

> Thanks your reply, I also used this way, but it still not work. code as the 
> following.
> 
> gonameunits := []string{"gpu0", "gpu1", "gpu2", "gpu3"}
>nameunits := make([]*C.char, len(gonameunits))
>for i, _ := range gonameunits {
>nameunits[i] = C.CString(gonameunits[i])
>defer C.free(unsafe.Pointer(nameunits[i]))
>}
>fmt.Println("nameunits:", nameunits)

This looks correct...

> golevelmatrix := [][]int{{1}, {3, 3}, {3, 3, 2}}
>levelmatrix := make([][]C.int, len(golevelmatrix))
>for i, _ := range golevelmatrix {
>levelmatrix[i] = make([]C.int, len(golevelmatrix[i]))
>for j, _ := range golevelmatrix[i] {
>levelmatrix[i][j] = C.int(golevelmatrix[i][j])
>}
>}

...but this is not: remember that in Go, the type []T denotes *a slice* of
elements of type T.  A slice is a dynamic construct which is a view into
underlying array, and as such it itself consists of a pointer into that
array's contents, the current length of the slice and the capacity of
it.

>fmt.Println("levelmatrix:", levelmatrix)
> 
> C.test_settopologyresource(mod, C.CString("node1"), C.int(2), (**C.char
> )(unsafe.Pointer([0])), (**C.int)(unsafe.Pointer([0][0
> ])))

That thing about slices means that passing a pointer to a single slice
element to C is OK; passing a pointer to an Nth element of a slice to C
and expecting it to access it and the elements following it up to the
slice's length is also OK but interpreting a slice of slices (which
[][]*C.int really is) is wrong: it's not represented by a contiguous
array: it's a slice of N independent slices -- each backed by its
independent array.

So what you really want is something like:

1. Know the dimensions of your matrix (let's denote them by N and M).
2. Allocate a slice of the length N*M.
3. Fill it up with the values from your source slice of slices.
4. Pass the pointer to the array to C.

Like this (untested, may not even compile):

  n := len(golevelmatrix)
  m := 0
  for _, row := range golevelmatrix {
if len(row) > m {
  m = len(row)
}
  }
  
  a := make([]int, n*m)
  i := 0
  for _, row := range golevelmatrix {
for j, v := range row {
a[i*n+j] = v
}
i++
  }

  C.my_func([0])

-- 
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: Goroutines chan to get data at specific time

[desaiabhijit]

looks better solution to restrict goroutines to continue it's pending work

Thanks for the reply


On Monday, August 7, 2017 at 8:21:09 AM UTC+5:30, Timothy Raymond wrote:
>
> I'm not entirely sure, but my intuition says that using `time.After` like 
> that with pending sends from another goroutine will cause that goroutine to 
> leak. A better solution may be to use the `WithTimeout` functionality of 
> the `context` package and then periodically check the `Done()` channel to 
> see if the timeout has expired. It works something like this if you imagine 
> `HeavyWork` is a call to an external API: 
> https://play.golang.org/p/DRtgNBLnE5 .
>
> On Sunday, August 6, 2017 at 3:53:36 AM UTC-4, Abhijit Desai wrote:
>>
>> Can you please help with below code to get output at specific cutoff time 
>> and exit
>>
>> Thanks in advance
>>
>> Abhi
>>
>>
>>
>> package main
>>
>> import "time"
>> import "fmt"
>>
>> func main() {
>>
>> c1 := make(chan string)
>> 
>> go func() { //Sending data after certain time
>>   
>> c1 <- "result 1"
>>
>> time.Sleep(time.Second * 1)
>> c1 <- "result 2 afer 1 sec"
>>
>> time.Sleep(time.Second * 1)
>> c1 <- "result 2 afer 2 sec"
>>
>> time.Sleep(time.Second * 1)
>> c1 <- "result 2 afer 3 sec"
>>
>> time.Sleep(time.Second * 1)
>> c1 <- "result 2 afer 4 sec"
>>
>> time.Sleep(time.Second * 1)
>> c1 <- "result 2 afer 5 sec"
>> }()
>>
>> select {
>> case <-time.After(time.Second * 4): { //cut off 4s and return the 
>> value
>> res := <-c1
>> fmt.Println(res)  // expecting result "result 2 afer 3 sec" 
>> but returning "result 1"
>> }
>> }
>> }
>>
>

-- 
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: Goroutines chan to get data at specific time

[John Souvestre]

I’m not sure exactly what you are trying to accomplish, but I suspect that this 
article would help you.

 

https://blog.golang.org/go-concurrency-patterns-timing-out-and

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of desaiabhi...@gmail.com
Sent: 2017 August 06, Sun 09:58
To: golang-nuts
Subject: [go-nuts] Re: Goroutines chan to get data at specific time

 

yes this is what I want.. 

 

Need to access web service multiple times to get the entire data unless return 
status is not "completed" But same time I need timeout

 

Thanks for the help

 

Thanks

 

Abhi

On Sunday, August 6, 2017 at 7:48:05 PM UTC+5:30, snmed wrote:

I still no get the idea behind your requirement, in your example you calling 
the web service 6 times in sequential manner and then write it to the channel.

But again you can only write once to a channel with a capacity of one, as long 
as you not read from the same channel and you still read it in the select 
statement.

That means all other calls to 'GetPartWebServiceData()' in the goroutine are 
blocked until that read in the select statement happens. In your case it is 
always the first

value written to the channel.

 

I try to give you a solution with although i'm not completely understand your 
requirements:

 

Here a working sequential solution: https://play.golang.org/p/2qohwIjP96


I hope that helps

 

Cheers snmed

Am Sonntag, 6. August 2017 13:05:11 UTC+2 schrieb Abhijit Desai:

Requirement is to collect the data with in cuttoff time say 3 sec by invoking 
web service multiple times and return only latest invoked data

 

c1 <- "result 1" // In real scenario this taking almost 1 seconds as in real 
scenario it's taking Part chunk of data from Web Service

 

Something like... Expecting data from c1 <- GetPartWebServiceData("request 3") 
//at least I should get this data!?

 

 

package main

 

import "time"

import "fmt"

 

func main() {

 

c1 := make(chan string, 1)



go func() {

  

c1 <- GetPartWebServiceData("request 1") //say try 6 times

c1 <- GetPartWebServiceData("request 2")

c1 <- GetPartWebServiceData("request 3") //at least I should get this 
data!?

c1 <- GetPartWebServiceData("request 4")

c1 <- GetPartWebServiceData("request 5")

c1 <- GetPartWebServiceData("request 6")

}()

 

select {

case res := <-c1: //here program get out without waiting 3 seconds 
because it got the data

fmt.Println(res)

case <-time.After(time.Second * 4):

fmt.Println("timeout")

}

}

 

func GetPartWebServiceData(request string) string{

time.Sleep(time.Second * 1) // Time Consuming work returning part value

partResponse := "Response for " + request  //some response

return partResponse

}

 

 

 

On Sunday, August 6, 2017 at 4:03:08 PM UTC+5:30, snmed wrote:

Hi 

What are you trying to solve? Your channel has a capacity of 1, the first write 
to c1 is successful but the second write to c1 is blocked until it has been 
read in the select statement. And therefore you print the first value written 
to c1.

I recommend you to read this https://golang.org/doc/effective_go.html#channels 
documentation about channels.

Cheers snmed

-- 
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] Goroutines chan to get data at specific time

[Konstantin Khomoutov]

On Sun, Aug 06, 2017 at 12:53:08AM -0700, desaiabhi...@gmail.com wrote:

> Can you please help with below code to get output at specific cutoff time 
> and exit
[...]
> c1 := make(chan string)
> 
> go func() { //Sending data after certain time
>   
> c1 <- "result 1"
> 
> time.Sleep(time.Second * 1)
> c1 <- "result 2 afer 1 sec"
> 
> time.Sleep(time.Second * 1)
> c1 <- "result 2 afer 2 sec"
> 
> time.Sleep(time.Second * 1)
> c1 <- "result 2 afer 3 sec"
> 
> time.Sleep(time.Second * 1)
> c1 <- "result 2 afer 4 sec"
> 
> time.Sleep(time.Second * 1)
> c1 <- "result 2 afer 5 sec"
> }()
> 
> select {
> case <-time.After(time.Second * 4): { //cut off 4s and return the 
> value
> res := <-c1
> fmt.Println(res)  // expecting result "result 2 afer 3 sec" but 
> returning "result 1"
> }
> }
> }

You have created a channel of capacity 0, which means that as soon as
some goroutine sends to the channel it blocks until another goroutine
reads from it.  What's more, any other goroutines which attempt to send
to that channel while the first goroutine is blocked waiting for the
value it's sending to be received, gets blocked, too.

So, in your example the goroutine which sends gets blocked in

  c1 <- "result 1"

and is suspended by the scheduler.

The main goroutine which performs select waits for the timer to fire and
then reads from c1 hereby unblocking the background goroutine and
allowing its send operation to proceed.

After that the background goroutine continues to work and then at some
indeterminate point gets reaped by the Go runtime which kills all the
active goroutine when the goroutine running main() exits.

-- 
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] all goroutines are asleep - deadlock!

[Konstantin Khomoutov]

On Fri, Aug 04, 2017 at 08:11:45AM -0700, prankpla...@gmail.com wrote:

[...]
> func fact_worker(fact_resp_chan chan string, x int) {
> defer wg.Done()
> response := factorial(x)
> fact_resp_chan <-  fmt.Sprintf("Factorial of %d is : %d", x, response)
> }
[...]

Please also consider naming your identifiers consistently with what the
Go itself and the community uses — for instance, [1, 2].

That is, use factWorker and factRespChan.

"Snake case" (foo_bar) is not used in Go code.

1. https://golang.org/doc/effective_go.html#names
2. https://blog.golang.org/package-names

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