Re: Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Bakul Shah]

On Thu, 08 Feb 2018 16:17:08 +1100 Rob Pike  wrote:
Rob Pike writes:
> 
> Isn't the visitor pattern just a way to implement type switch in languages
> that don't implement type switch?
> 
> That's certainly how I saw it when using C++. Go has a type switch, and so
> has no need for the visitor pattern, a perfect example of the principle
> that a design pattern is just a way to work around shortcomings in the
> language.

In Go you can implement the visitor pattern without using a
type switch. This allows you to add new type of objects
without changing any other code -- just add the functions you
need.  See below.

Having had to debug someone else's C++ code which made heavy
of the visitor pattern, I can tell you it was quite difficult
to understand, particularly as it had global side-effects and
as it was beaten into shape over time, the code had gotten
quite messy[1].

My advice to C++/Java refugees: don't use the visitor pattern.
And if you do, don't have side-effects or complicated logic!
Actually don't use any GoF patterns! Go has its own idioms.

Example: // Just sketching the idea... 

type Node struct {
kids[]*Node
val Value
}

type Visitor interface {
func Visit(val interface{})
}

func (t *Tree) Walk(Visitor v) {
v.Visit(t.val)
for _, k := range t.kids {
k.walk(v)
}
}

type V1 struct {
}

type Stringer interface {
String() string
}

type Sizer interface {
Size() int
}

func (v1 V1)Visit(val interface{}) {
v, ok := val.(Stringer)
if !ok { panic("...") }
fmt.Println(v.String())
}

type V2 struct{
}

func (v2 V2)Visit(val interface{}) {
v, ok := val.(Sizer)
if !ok { panic("...") }
fmt.Println(v.Size())
}

var v1 V1
var v2 V2

...
t *Tree
...
t.walk(v1)
t.walk(v2)

[1] I ended up rewriting it from scratch by simply observing
its behavior. There were many other problems as well such as
linear search and what not.  The rewrite took fraction of a
second and cut down everyone's build time by 3 minutes!

-- 
You received this message because you are subscribed 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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Rob Pike]

Isn't the visitor pattern just a way to implement type switch in languages
that don't implement type switch?

That's certainly how I saw it when using C++. Go has a type switch, and so
has no need for the visitor pattern, a perfect example of the principle
that a design pattern is just a way to work around shortcomings in the
language.

-rob


On Thu, Feb 8, 2018 at 2:14 PM, Josh Humphries 
wrote:

> FWIW, it looks like someone else has gone through this exercise:
> https://github.com/tmrts/go-patterns
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> On Fri, Feb 2, 2018 at 12:03 PM,  wrote:
>
>> I’m looking at patterns summarized on Wikipedia from “Design Patterns:
>> Elements of Reusable Object-Oriented Software” and writing out a few as the
>> equivalent in Go.
>>
>> Visitor: https://play.golang.org/p/A5tNzxMmetH
>>
>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>
>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>
>> Facade: https://play.golang.org/p/forPdwy9VCi
>>
>> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>>
>> I’m curious how more experienced people rank these and the other patterns.
>>
>> Matt
>>
>> --
>> You received this message because you are subscribed 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.
>

-- 
You received this message because you are subscribed 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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Josh Humphries]

FWIW, it looks like someone else has gone through this exercise:
https://github.com/tmrts/go-patterns


*Josh Humphries*
jh...@bluegosling.com

On Fri, Feb 2, 2018 at 12:03 PM,  wrote:

> I’m looking at patterns summarized on Wikipedia from “Design Patterns:
> Elements of Reusable Object-Oriented Software” and writing out a few as the
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>
> Matt
>
> --
> You received this message because you are subscribed 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] Re: Unexpect deadlock on select multi channel ?

[Damon Zhao]

Got it, thx~

在 2018年2月7日星期三 UTC+8下午11:25:24，matthe...@gmail.com写道：
>
> The select already received in that case and is waiting to send, but the 
> select has to be re-entered for the next receive to happen.
>
> Matt
>
> On Wednesday, February 7, 2018 at 9:22:31 AM UTC-6, Damon Zhao wrote:
>>
>> I know wrap with a goroutine can fix it. I just wonder why must use an 
>> extra goroutine?
>>
>> 在 2018年2月7日星期三 UTC+8下午11:00:25，matthe...@gmail.com写道：
>>>
>>> Desynchronizing "case idle <- <-source:" fixes it:
>>>
>>> case v := <-source:
>>> go func () { idle <- v }()
>>>
>>> I added a counter to break after a number of loops since it goes 
>>> infinitely: https://play.golang.org/p/aZbmTKvpxcD
>>>
>>> Matt
>>>
>>> On Wednesday, February 7, 2018 at 8:38:41 AM UTC-6, Damon Zhao wrote:

 Please answer these questions before submitting your issue. Thanks!
 What version of Go are you using (go version)?

 go version go1.9.3 darwin/amd64
 Does this issue reproduce with the latest release?

 yes
 What operating system and processor architecture are you using (go env
 )?
 GOARCH="amd64"
 GOBIN=""
 GOEXE=""
 GOHOSTARCH="amd64"
 GOHOSTOS="darwin"
 GOOS="darwin"
 GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
 GORACE=""
 GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
 GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/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/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/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"

 What did you do?

 code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
 https://github.com/golang/go/issues/23728#issuecomment-363771924)


 code2: https://play.golang.org/p/fJXhK8w22uu

 Above code2 sometimes run perfect and sometimes deadlock on my machine.


 



 But if I put it in a goroutine, the result is confused:


 https://play.golang.org/p/oUmMr8TM2sz  success

 https://play.golang.org/p/54eLI7x5FwD failed


 notice line 25 when I use

 ```

 case worker := <-source:

 idle <- worker

 ```

 instead of:

 ```

 case idle <- <-source:

 ```

 it works.
 What did you expect to see?

 I think it should not deadlock.
 What did you see instead?
 deadlock sometimes.




-- 
You received this message because you are subscribed 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] Wrapping executable that takes input and output files such that it uses stdin and stdout instead (using named pipes)

[Or Rikon]

Hi!

I asked this previously on Stack Overflow but so far have not received a 
response, so I figured I will try here as well.

I'm trying to wrap an executable that takes an input and output file paths 
as arguments, such that it will be possible to provide the input and output 
as stdin and stdout.

I've written a short script in Go that attempts to do this, but for some 
reason which eludes me, it hangs forever.


Here is the script:


package main
import (
"bytes"
"io"
"log"
"os"
"strings"
"syscall"

"golang.org/x/sync/errgroup")
/*
Expected behavior:

# Terminal 1
$ go run main.go

# Terminal 2
$ cat inPipe > outPipe

The go program is writing to inPipe and reading from outPipe

Actual behavior: The program stalls
*/

func main() {
eg := {}

inPipe := "inPipe"
outPipe := "outPipe"

if err := syscall.Mkfifo(inPipe, 0644); err != nil {
log.Fatal(err)
}
defer os.Remove(inPipe)

if err := syscall.Mkfifo(outPipe, 0644); err != nil {
log.Fatal(err)
}
defer os.Remove(outPipe)

fIn, err := os.OpenFile(inPipe, os.O_WRONLY, os.ModeNamedPipe)
if err != nil {
log.Fatal(err)
}
defer fIn.Close()

eg.Go(func() error {
_, err := io.Copy(fIn, strings.NewReader("123"))
return err
})

fOut, err := os.OpenFile(outPipe, os.O_RDONLY, os.ModeNamedPipe)
if err != nil {
log.Fatal(err)
}
defer fOut.Close()

buf := {}

eg.Go(func() error {
_, err := io.Copy(buf, fOut)
return err
})

if err := eg.Wait(); err != nil {
log.Fatal(err)
}

if _, err := io.Copy(os.Stdout, buf); err != nil {
log.Fatal(err)
}}

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

[go-nuts] Why is there no standard `uuid` package?

[高橋誠二]

Recently satori/go.uuid took a breaking change of API, and some of 
frameworks which depend on the package.
And google/uuid is unstable.

Why Go doesn't have an official uuid package?
Is there any load map to develop google/uuid and merge it to Go itself?

-- 
You received this message because you are subscribed 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 to install Go SDK 1.9.61 or newer?

[Bryan]

I'm trying to install Go SDK 1.9.61 or newer on osX 10.11.6 

I'm am trying to figure out how to use the Delve debugger and the Atom 
go-debug plugin to work with GAE.

The --go_debugger flag was added in Go SDK 1.9.61

$ sudo gcloud version

Password:

Google Cloud SDK 188.0.0

app-engine-go 

app-engine-python 1.9.66

bq 2.0.28

core 2018.02.02

gcloud 

gsutil 4.28



I've searched the source code in for "go_debugger":
~/google-cloud-sdk/platform/google_appengine/

and could not find "go_debugger" so I assume I have the wrong version.

How do I install Go SDK 1.9.61 ?

-- 
You received this message because you are subscribed 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] Differentiating between reader and writer errors

[Justin Azoff]

>
>
> r, _ = Filter(r, query)
> w = LastErrorWrapper(w)
> _, err = io.Copy(w, r)
> if err != nil and w.LastError != nil { # error writing to output, 
> abort.
>

I got halfway through implementing a "LastErrorWrapper" and realized it 
looked familiar.. that's because it's described in

https://blog.golang.org/errors-are-values

and as it mentions, bufio.Writer already implements exactly the feature I 
need. 

Changing my example query function to look like

func runQuery(query string, w io.Writer) {
docs, present := index[query]
if !present {
fmt.Fprintf(w, "No results\n")
}
for _, d := range docs {
bw := bufio.NewWriter(w)
err := dump(d, bw)
if bw.Flush() != nil {
log.Printf("Error dumping document %d while writing: %v", d, 
bw.Flush())
return
}
if err != nil {
log.Printf("Error dumping document %d: %v", d, err)
}
}
}

appears to do everything I need.  errors from one document are skipped, but 
an error inside the writer is fatal.


-- 
You received this message because you are subscribed 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] Blocking reflect.Value{}.Call()

[snadrus]

I realize that private functions of another package are not reachable by 
reflection, but I'm looking for a way to ensure a public 
interface-or-struct's function can be fully back-traced statically. 

An interface function like 
Query(sql string, args ...interface{}) Result  
is an SQL injection risk if it can be called via reflection. This includes 
the sqlx library simply being part of a program.

My goal: to enhance SafeSQL to fully backtrace and know certainly that 
there are no SQL injection risks.

Alternative: I can add a comment to the functions I write:
// Reflection Calls Disallowed

But compiler assurance of this would be nice.

-- 
You received this message because you are subscribed 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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[roger peppe]

As someone totally unfamiliar with the GoF patterns, hre's my take.
I looked at the wikipedia articles and tried to work out what
problem I thought the pattern was trying to address and then
wrote some Go code to do that. I'm generally in agreement
with those who say that these patterns are there largely to avoid
the pitfalls of languages with class-based inheritance.

abstract factory https://play.golang.org/p/syHr7QJ9e2q
- anything in Go that returns an interface rather than a concrete type
could be considered an abstract factory.

facade https://play.golang.org/p/U6DSg5pDC0w
- any type that has another type as a member and not much
significant logic in its own methods could be considered a facade.

proxy https://golang.org/pkg/bufio/#NewReader
- any Go function that takes an interface and returns a
value that implements the same interface could be considered
a proxy.

factory method: https://play.golang.org/p/AmQ7lQHAPDy
- any function or method that creates and returns an object could
be considered a factory. Go doesn't have constructors so this
is just normal.

visitor: https://play.golang.org/p/w74EhhuAhT5
- I'm not sure that this is a great pattern. Doing a callback for every
object in a hierarchy seems fine, but requiring a different method
to be implemented for each kind of object seems unnecessary - if
you add another kind of object, then all the code using the visitor
will break (but that could also be considered an advantage, I guess,
as it means your clients are forced to consider all possible kinds).

On 6 February 2018 at 23:30,   wrote:
>> Your visitor pattern here seems to not be a "visitor" pattern. I would
>> think that the Go equivalent would define an interface, and visit based on
>> that interface.
>
>
> Here’s what the Wikipedia article says:
>
>> In essence, the visitor allows adding new virtual functions to a family of
>> classes, without modifying the classes. Instead, a visitor class is created
>> that implements all of the appropriate specializations of the virtual
>> function. The visitor takes the instance reference as input, and implements
>> the goal through double dispatch.
>
>
> In my Go conversion the family of classes is the File type. The virtual
> function Accept is added to the family without defining behavior. The
> Dispatcher is interchangeable and implements Accept for each type of File.
>
> There's a good possibility that I misunderstood the source example, but I'm
> not sure why this isn't a visitor pattern.
>
>> This isn't really an example of a factory method, because it isn't
>> instantiating things of different types.
>
>
> Vars of func types is like a set of classes with only methods. Lately I've
> been looking at func types and closures as a pattern that's superior to
> interface in some cases.
>
>> I didn't look at all your examples, but in most cases, it seems like error
>> handling, which would be an important part of a Go example, is completely
>> absent in the examples given here.
>
>
> Once I dig out the book I’ll try to put together closer to idiomatic
> examples.
>
> Thanks,
> Matt
>
> On Monday, February 5, 2018 at 11:36:42 AM UTC-6, Eric Johnson wrote:
>>
>> An interesting idea. Some thoughts
>>
>> On Friday, February 2, 2018 at 9:03:54 AM UTC-8, matthe...@gmail.com
>> wrote:
>>>
>>> I’m looking at patterns summarized on Wikipedia from “Design Patterns:
>>> Elements of Reusable Object-Oriented Software” and writing out a few as the
>>> equivalent in Go.
>>>
>>> Visitor: https://play.golang.org/p/A5tNzxMmetH
>>
>>
>> Your visitor pattern here seems to not be a "visitor" pattern. I would
>> think that the Go equivalent would define an interface, and visit based on
>> that interface.
>>
>>>
>>>
>>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>>
>>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>
>>
>> This isn't really an example of a factory method, because it isn't
>> instantiating things of different types.
>>
>>>
>>>
>>> Facade: https://play.golang.org/p/forPdwy9VCi
>>
>>
>>>
>>>
>>> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>>>
>>> I’m curious how more experienced people rank these and the other
>>> patterns.
>>
>>
>> I didn't look at all your examples, but in most cases, it seems like error
>> handling, which would be an important part of a Go example, is completely
>> absent in the examples given here.
>>
>> Eric
>>
>>>
>>>
>>> Matt
>
> --
> You received this message because you are subscribed 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 

[go-nuts] Re: [security] Go 1.8.7, Go 1.9.4, and Go 1.10rc2 are released

[Nathan Kerr]

I updated my release related resources with these releases:

   - When Should You Upgrade Go? 
   
   - Go Release Timeline 
   
Nathan

On Wednesday, February 7, 2018 at 1:15:13 PM UTC-7, Andrew Bonventre wrote:
>
> Hi gophers,
>
> We have just released Go 1.8.7, Go 1.9.4, and Go 1.10rc2, to address a 
> recently-reported security issue. We recommend that all users update to one 
> of these releases (if you’re not sure which, choose Go 1.9.4).
>
> By using the clang or gcc plugin mechanism, it was possible for an 
> attacker to trick the “go get” command into executing arbitrary code. The 
> go command now restricts the set of allowed host compiler and linker 
> arguments in cgo source files to a list of allowed flags, in particular 
> disallowing -fplugin= and -plugin=. 
>
> The issue is CVE-2018-6574 and Go issue golang.org/issue/23672. See the 
> Go issue for details.
>
> Thanks to Christopher Brown of Mattermost for reporting this problem.
>
> Downloads are available at https://golang.org/dl for all supported 
> platforms.
>
> Cheers,
> Andy (on behalf of the Go team)
>
>

-- 
You received this message because you are subscribed 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] [security] Go 1.8.7, Go 1.9.4, and Go 1.10rc2 are released

[Andrew Bonventre]

Hi gophers,

We have just released Go 1.8.7, Go 1.9.4, and Go 1.10rc2, to address a
recently-reported security issue. We recommend that all users update to one
of these releases (if you’re not sure which, choose Go 1.9.4).

By using the clang or gcc plugin mechanism, it was possible for an attacker
to trick the “go get” command into executing arbitrary code. The go command
now restricts the set of allowed host compiler and linker arguments in cgo
source files to a list of allowed flags, in particular disallowing
-fplugin= and -plugin=.

The issue is CVE-2018-6574 and Go issue golang.org/issue/23672. See the Go
issue for details.

Thanks to Christopher Brown of Mattermost for reporting this problem.

Downloads are available at https://golang.org/dl for all supported
platforms.

Cheers,
Andy (on behalf of the Go team)

-- 
You received this message because you are subscribed 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] ANN: gijit, a Go interpreter

[Jason E. Aten]

https://github.com/gijit/gi

My interactive Go REPL, gijit, is quite useful now. It has structs, 
pointers, defer, and interfaces implemented.  You can call into native Go 
packages.

Enjoy,

Jason

-- 
You received this message because you are subscribed 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] Asymmetrical I/O load on single TCP connection

[Everton Marques]

Hi,

I wrote a simple utility https://github.com/udhos/goben to test TCP 
throughput between two hosts.
At each endpoint, the tool spawns two goroutines: one for reading from 
net.TCPConn as fast as possible, other for writing into it as fast as 
possible.
However I'm consistently obtaining uneven rates like these:

2018/02/06 23:13:47 report clientReader rate:  20089 Mbps 125557 calls/s
2018/02/06 23:13:47 report clientWriter rate:417 Mbps   2606 calls/s
2018/02/06 23:13:49 report clientReader rate:  18245 Mbps 114039 calls/s
2018/02/06 23:13:50 report clientWriter rate:   1295 Mbps   8097 calls/s
2018/02/06 23:13:51 report clientReader rate:  19722 Mbps 123263 calls/s
2018/02/06 23:13:52 report clientWriter rate:   2179 Mbps  13620 calls/s
2018/02/06 23:13:53 report clientReader rate:  15851 Mbps  99077 calls/s
2018/02/06 23:13:54 report clientWriter rate:   4274 Mbps  26718 calls/s

Notice the input rate (reader) is way higher than output rate (writer).

For comparison, this is the result from a single-threaded tool written in C 
(https://github.com/udhos/nepim):

 kbps_in   kbps_outrcv/ssnd/s
  3 cur 8 8873837.00 8950252.00 47920.50 34142.50
  3 cur 6 8655077.00 8654946.00 47166.50 33016.00
  3 cur 4 8773173.00 8772125.00 47800.50 33463.00
  3 cur 2 8700428.00 8700690.00 47408.50 33190.50
  3 avg 0 8730680.00 8745727.00 47481.90 33362.30
  3 min 0 8655077.00 8654946.00 47166.50 33016.00
  3 max 0 8873837.00 8950252.00 47920.50 34142.50

I guess I'm hitting some goroutine scheduling issue?

How can I improve scheduling fairness (?) in order to get similar loads on 
both directions?

Thanks,
Everton

-- 
You received this message because you are subscribed 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: Unexpect deadlock on select multi channel ?

[buaa . cch]

sorry for misunderstanfing.. this is not a bug...

-- 
You received this message because you are subscribed 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] Cloud Functions Golang Support

[matthewjuran]

https://groups.google.com/forum/#!forum/gce-discussion may be a better 
place to ask this question.

Here are the other GCP groups: https://cloud.google.com/support/docs/groups

Matt

On Wednesday, February 7, 2018 at 11:13:26 AM UTC-6, Sankar wrote:
>
> Hey Googlers,
>
> Any help on this ? I would love to choose GCE, but will have to go with 
> AWS if there are no updates here. Thanks.
>
> 31 ஜன., 2018 முற்பகல் 12:08 அன்று, "Sankar"  > எழுதியது:
>
>> Hi
>>
>> When is Golang support for Cloud functions in GCP expected ? I am 
>> starting off a new project and would love to use GCP over AWS, but lambda 
>> already supports Golang. Is there an approximate ETA for Golang in Google 
>> Cloud functions ?
>>
>> Thanks.
>>
>> -- 
>> 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/62ec2LsSXtQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] Cloud Functions Golang Support

[Sankar P]

Hey Googlers,

Any help on this ? I would love to choose GCE, but will have to go with AWS
if there are no updates here. Thanks.

31 ஜன., 2018 முற்பகல் 12:08 அன்று, "Sankar" 
எழுதியது:

> Hi
>
> When is Golang support for Cloud functions in GCP expected ? I am starting
> off a new project and would love to use GCP over AWS, but lambda already
> supports Golang. Is there an approximate ETA for Golang in Google Cloud
> functions ?
>
> Thanks.
>
> --
> 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/62ec2LsSXtQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: Unexpect deadlock on select multi channel ?

[buaa . cch]

I think this is a bug, I change the logic of main goroutine and the other 
goroutine, then the deadlock disappeared
```go
package main

import (
"fmt"
"time"
)

var (
source = make(chan int)
idle   = make(chan int, 1)
)

func main() {
go func() {
for {
select {
case worker := <-source:
idle <- worker

case worker := <-idle:
fmt.Println(worker)
go func() {
time.Sleep(time.Second)
idle <- 1

}()
}
}

}()
for i := 0; i < 2; i++ {
source <- i

}

time.Sleep(time.Second * 10)

}

```

在 2018年2月7日星期三 UTC+8下午10:38:41，Damon Zhao写道：
>
> Please answer these questions before submitting your issue. Thanks!
> What version of Go are you using (go version)?
>
> go version go1.9.3 darwin/amd64
> Does this issue reproduce with the latest release?
>
> yes
> What operating system and processor architecture are you using (go env)?
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
> GORACE=""
> GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
> GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/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/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/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"
>
> What did you do?
>
> code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
> https://github.com/golang/go/issues/23728#issuecomment-363771924)
>
>
> code2: https://play.golang.org/p/fJXhK8w22uu
>
> Above code2 sometimes run perfect and sometimes deadlock on my machine.
>
>
> 
>
>
>
> But if I put it in a goroutine, the result is confused:
>
>
> https://play.golang.org/p/oUmMr8TM2sz  success
>
> https://play.golang.org/p/54eLI7x5FwD failed
>
>
> notice line 25 when I use
>
> ```
>
> case worker := <-source:
>
> idle <- worker
>
> ```
>
> instead of:
>
> ```
>
> case idle <- <-source:
>
> ```
>
> it works.
> What did you expect to see?
>
> I think it should not deadlock.
> What did you see instead?
> deadlock sometimes.
>
>
>

-- 
You received this message because you are subscribed 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] Unexpect deadlock on select multi channel

[Ian Lance Taylor]

On Wed, Feb 7, 2018 at 6:24 AM, Damon Zhao  wrote:
> Anybody help with this issue (still not solved but I cannot reopen it)
>
> https://github.com/golang/go/issues/23728

The select statement works pseudo-randomly.  You are sending two
values on source.  When the select statement chooses `worker :=
<-source` twice in a row at the start of the program, the second time
blocks sending to idle.

Ian

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

[go-nuts] Re: Unexpect deadlock on select multi channel ?

[matthewjuran]

The select already received in that case and is waiting to send, but the 
select has to be re-entered for the next receive to happen.

Matt

On Wednesday, February 7, 2018 at 9:22:31 AM UTC-6, Damon Zhao wrote:
>
> I know wrap with a goroutine can fix it. I just wonder why must use an 
> extra goroutine?
>
> 在 2018年2月7日星期三 UTC+8下午11:00:25，matthe...@gmail.com写道：
>>
>> Desynchronizing "case idle <- <-source:" fixes it:
>>
>> case v := <-source:
>> go func () { idle <- v }()
>>
>> I added a counter to break after a number of loops since it goes 
>> infinitely: https://play.golang.org/p/aZbmTKvpxcD
>>
>> Matt
>>
>> On Wednesday, February 7, 2018 at 8:38:41 AM UTC-6, Damon Zhao wrote:
>>>
>>> Please answer these questions before submitting your issue. Thanks!
>>> What version of Go are you using (go version)?
>>>
>>> go version go1.9.3 darwin/amd64
>>> Does this issue reproduce with the latest release?
>>>
>>> yes
>>> What operating system and processor architecture are you using (go env)?
>>> GOARCH="amd64"
>>> GOBIN=""
>>> GOEXE=""
>>> GOHOSTARCH="amd64"
>>> GOHOSTOS="darwin"
>>> GOOS="darwin"
>>> GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
>>> GORACE=""
>>> GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
>>> GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/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/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/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"
>>>
>>> What did you do?
>>>
>>> code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
>>> https://github.com/golang/go/issues/23728#issuecomment-363771924)
>>>
>>>
>>> code2: https://play.golang.org/p/fJXhK8w22uu
>>>
>>> Above code2 sometimes run perfect and sometimes deadlock on my machine.
>>>
>>>
>>> 
>>>
>>>
>>>
>>> But if I put it in a goroutine, the result is confused:
>>>
>>>
>>> https://play.golang.org/p/oUmMr8TM2sz  success
>>>
>>> https://play.golang.org/p/54eLI7x5FwD failed
>>>
>>>
>>> notice line 25 when I use
>>>
>>> ```
>>>
>>> case worker := <-source:
>>>
>>> idle <- worker
>>>
>>> ```
>>>
>>> instead of:
>>>
>>> ```
>>>
>>> case idle <- <-source:
>>>
>>> ```
>>>
>>> it works.
>>> What did you expect to see?
>>>
>>> I think it should not deadlock.
>>> What did you see instead?
>>> deadlock sometimes.
>>>
>>>
>>>

-- 
You received this message because you are subscribed 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: Unexpect deadlock on select multi channel ?

[Damon Zhao]

I know wrap with a goroutine can fix it. I just wonder why must use an 
extra goroutine?

在 2018年2月7日星期三 UTC+8下午11:00:25，matthe...@gmail.com写道：
>
> Desynchronizing "case idle <- <-source:" fixes it:
>
> case v := <-source:
> go func () { idle <- v }()
>
> I added a counter to break after a number of loops since it goes 
> infinitely: https://play.golang.org/p/aZbmTKvpxcD
>
> Matt
>
> On Wednesday, February 7, 2018 at 8:38:41 AM UTC-6, Damon Zhao wrote:
>>
>> Please answer these questions before submitting your issue. Thanks!
>> What version of Go are you using (go version)?
>>
>> go version go1.9.3 darwin/amd64
>> Does this issue reproduce with the latest release?
>>
>> yes
>> What operating system and processor architecture are you using (go env)?
>> GOARCH="amd64"
>> GOBIN=""
>> GOEXE=""
>> GOHOSTARCH="amd64"
>> GOHOSTOS="darwin"
>> GOOS="darwin"
>> GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
>> GORACE=""
>> GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
>> GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/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/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/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"
>>
>> What did you do?
>>
>> code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
>> https://github.com/golang/go/issues/23728#issuecomment-363771924)
>>
>>
>> code2: https://play.golang.org/p/fJXhK8w22uu
>>
>> Above code2 sometimes run perfect and sometimes deadlock on my machine.
>>
>>
>> 
>>
>>
>>
>> But if I put it in a goroutine, the result is confused:
>>
>>
>> https://play.golang.org/p/oUmMr8TM2sz  success
>>
>> https://play.golang.org/p/54eLI7x5FwD failed
>>
>>
>> notice line 25 when I use
>>
>> ```
>>
>> case worker := <-source:
>>
>> idle <- worker
>>
>> ```
>>
>> instead of:
>>
>> ```
>>
>> case idle <- <-source:
>>
>> ```
>>
>> it works.
>> What did you expect to see?
>>
>> I think it should not deadlock.
>> What did you see instead?
>> deadlock sometimes.
>>
>>
>>

-- 
You received this message because you are subscribed 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: Unexpect deadlock on select multi channel ?

[matthewjuran]

Desynchronizing "case idle <- <-source:" fixes it:

case v := <-source:
go func () { idle <- v }()

I added a counter to break after a number of loops since it goes 
infinitely: https://play.golang.org/p/aZbmTKvpxcD

Matt

On Wednesday, February 7, 2018 at 8:38:41 AM UTC-6, Damon Zhao wrote:
>
> Please answer these questions before submitting your issue. Thanks!
> What version of Go are you using (go version)?
>
> go version go1.9.3 darwin/amd64
> Does this issue reproduce with the latest release?
>
> yes
> What operating system and processor architecture are you using (go env)?
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
> GORACE=""
> GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
> GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/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/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/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"
>
> What did you do?
>
> code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
> https://github.com/golang/go/issues/23728#issuecomment-363771924)
>
>
> code2: https://play.golang.org/p/fJXhK8w22uu
>
> Above code2 sometimes run perfect and sometimes deadlock on my machine.
>
>
> 
>
>
>
> But if I put it in a goroutine, the result is confused:
>
>
> https://play.golang.org/p/oUmMr8TM2sz  success
>
> https://play.golang.org/p/54eLI7x5FwD failed
>
>
> notice line 25 when I use
>
> ```
>
> case worker := <-source:
>
> idle <- worker
>
> ```
>
> instead of:
>
> ```
>
> case idle <- <-source:
>
> ```
>
> it works.
> What did you expect to see?
>
> I think it should not deadlock.
> What did you see instead?
> deadlock sometimes.
>
>
>

-- 
You received this message because you are subscribed 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] Unexpect deadlock on select multi channel ?

[Damon Zhao]

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?

go version go1.9.3 darwin/amd64
Does this issue reproduce with the latest release?

yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/ariesdevil/Dropbox/workspace/go_workspace"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.9.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.9.3/libexec/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/h2/xl15t9g94tgfwclshzl086bhgp/T/go-build125147941=/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"

What did you do?

code1: play.golang.org/p/8rcO11QS8un (@ianlancetaylor answerd at 
https://github.com/golang/go/issues/23728#issuecomment-363771924)


code2: https://play.golang.org/p/fJXhK8w22uu

Above code2 sometimes run perfect and sometimes deadlock on my machine.





But if I put it in a goroutine, the result is confused:


https://play.golang.org/p/oUmMr8TM2sz  success

https://play.golang.org/p/54eLI7x5FwD failed


notice line 25 when I use

```

case worker := <-source:

idle <- worker

```

instead of:

```

case idle <- <-source:

```

it works.
What did you expect to see?

I think it should not deadlock.
What did you see instead?
deadlock sometimes.


-- 
You received this message because you are subscribed 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] Unexpect deadlock on select multi channel

[Damon Zhao]

Anybody help with this issue (still not solved but I cannot reopen it)

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

-- 
You received this message because you are subscribed 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] Differentiating between reader and writer errors

[Justin Azoff]

On Wednesday, February 7, 2018 at 8:54:12 AM UTC-5, Jakob Borg wrote:
>
> On 7 Feb 2018, at 14:45, Justin Azoff  
> wrote:
>
>
> Is there some way to inspect that error to figure out that it was related 
> to reading from 'gr' and not writing to /dev/null?
>
>
> Two options that come to mind are
>
>  - handling the copy yourself so you get separate Read() and Write() calls 
> and can handle their returns accordingly
>

Yes.. I see one easy way to do this.. right now the backend interface I 
came up with uses

Filter(reader io.Reader, query string, writer io.Writer) error 

But if I changed that to

Filter(reader io.Reader, query string) (io.Reader, error)

I could do all the copying in one place, and really easily differentiate 
between a read error and a write error.  I think this is also the more 
elegant interface.  The 'backends' are really responsible for reading from 
the log files and shouldn't be concerned with output.

 - wrapping the writer in a type that wraps the Write() call and retains 
> any error returned. You can then ask the writer if it encountered an error 
> after getting an error return from io.Copy.
>

So simple!  This would probably work for the Reader side too. 
 

> I’m sure there are other ways.
>
 
Indeed!  I think my mistake was the Filter interface.. having it be 
responsible for both filtering and writing is probably what caused this 
issue.  If Filter just returns a filtered Reader I'm left with an io.Reader 
and an io.Writer that I can deal with separately.  I think the ultimate 
solution will be a combination of both.. Simplify the interface and wrap 
the Writer with a struct that remembers the last error.  Then I think i 
would look something like

r, _ = Filter(r, query)
w = LastErrorWrapper(w)
_, err = io.Copy(w, r)
if err != nil and w.LastError != nil { # error writing to output, abort.

-- 
You received this message because you are subscribed 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] Differentiating between reader and writer errors

[Jakob Borg]

On 7 Feb 2018, at 14:45, Justin Azoff 
> wrote:

Is there some way to inspect that error to figure out that it was related to 
reading from 'gr' and not writing to /dev/null?

Two options that come to mind are

 - handling the copy yourself so you get separate Read() and Write() calls and 
can handle their returns accordingly

 - wrapping the writer in a type that wraps the Write() call and retains any 
error returned. You can then ask the writer if it encountered an error after 
getting an error return from io.Copy.

I’m sure there are other ways.

//jb

-- 
You received this message because you are subscribed 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: Differentiating between reader and writer errors

[Justin Azoff]

On Wednesday, February 7, 2018 at 1:26:46 AM UTC-5, Tamás Gulácsi wrote:
>
> backend.FilterIPs should return differentiable error - whether this is a 
> transient or a permanent error.
> I'd use github.com/pkg/errors:
>
> var ErrTransient = errors.New("transient error")
>
>
Nice, thanks.. this is along the lines of what i was thinking I needed to 
do.  There's a slight complication.. Maybe this is a better example:

https://play.golang.org/p/y_zo_RfL5Dr

it creates a gzipped buffer, truncates it slightly so the read fails, and 
then tries copying it to dev null. io.Copy returns: "unexpected EOF"
 
Is there some way to inspect that error to figure out that it was related 
to reading from 'gr' and not writing to /dev/null?

In this example I would want errors related to the reader to be wrapped as 
transient and errors related to the writer to be fatal, but there's a bit 
of a catch-22 in that I don't know how to tell which I have so I can 
properly wrap the error.

Checking for exactly ErrUnexpectedEOF could work in this exact case, but 
would miss others like gzip.ErrChecksum .

In my head I need something like

if err.(???).ReadWriter() == gr { # error related to the reader, 
transient.

-- 
You received this message because you are subscribed 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] Golang Microservices Software Engineering & Team Leadership Opportunities £Significant Package OR Day Rate Contract - London W5 or EC2 based

[stuartroe1976]

Hello everyone,

I am currently representing a world leading & multi-channel fashion 
retailer who are seeking talented Software Engineers, at Mid, Senior & Lead 
levels, to help them adopt the cloud and implement Infrastructure as code 
using Golang and Microservices. These roles can be based at either their 
West London (W5) or City (EC2) offices.

My client operate with the latest Agile methodologies including TDD, BDD 
and Continuous Integration. If you have a minimum of 6 mths Golang 
development experience and a desire to work within a modern, forward 
thinking & cutting edge development environment then his could be a 
wonderful opportunity for you. Other key technologies include 
Infrastructure as Code, Java, AWS, Terraform, Lambda, RDS, ECS, Kubernetes, 
Microservices, CI Concourse, Mysql, Nosql and Message Queues. 

Based in either Hanger Lane W5 or Shoreditch EC2 these roles come with a 
superb basic salary (OR day rate) , fantastic pension contribution & a raft 
of other corporate benefits including a modern flexible work environment. 

If you would like to find out more please email me 
"stu...@caerusaconsulting.co.uk" and I will forward a full specification 
for your review including package details.

Applications from exceptional day rate contractors are also welcomed...

Kind Regards

Stuart Roe

-- 
You received this message because you are subscribed 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: About golang.org/x/net/prox and cancellation

[Juliusz Chroboczek]

> unlike net.Dialer, there is no DialContext method for proxy.Dialer.

That turns out to be issue #19354.

-- 
You received this message because you are subscribed 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] Debug high GC pause frequency issue

[Vladimir Varankin]

> The CPU profiler told me that the program is spending a lot of time doing 
GC (obviously), and memory profiler is telling me there is a huge amount of 
memory allocated for json encoding/decoding, which is inevitable for 
business logic.

Even though Go is GC based language, Go prefers object re-using to prevent 
extra allocations as much as possible. Check if there are parts of the 
codebase that allocates a lot on the hot path, and if object pooling, 
preallocations, etc, might be applied there.

You may start by switching to alternative json marshallers 
– mailru/easyjson or json-iterator – if this is your case. They were 
developed to handle these particular issues of Go's encoding/json.

On Tuesday, February 6, 2018 at 3:45:56 PM UTC+1, Bob Cao wrote:
>
> Hi Lan
>
> I have used memory profiler and CPU profiler. 
>
> The CPU profiler told me that the program is spending a lot of time doing 
> GC (obviously), and memory profiler is telling me there is a huge amount of 
> memory allocated for json encoding/decoding, which is inevitable for 
> business logic.
>
> And the issue is, it used to be fine. The codebase has been in production 
> for a long time and the average GC per minute used to around 30 per minute, 
> and very stable.
>
> Is there any tip on how should one solve such problems?
>
> Thanks a lot!
>
> On Tuesday, 6 February 2018 22:40:07 UTC+8, Ian Lance Taylor wrote:
>>
>> On Tue, Feb 6, 2018 at 12:58 AM, Bob Cao  wrote: 
>> > 
>> > I have a program whose GC pause frequency will quickly go from 40 calls 
>> per 
>> > minute to 2000 calls per minute in a matter of hours, and the issue is 
>> kind 
>> > of random on production. 
>> > 
>> > Is there any advice on how to spot the cause of the issue? 
>>
>> Use the memory profiler.  See 
>> https://blog.golang.org/profiling-go-programs for some background. 
>>
>> 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] Re: Relaxing rules on slice comparison: would it make sense?

[Peter Waller]

On 6 February 2018 at 21:25,  wrote:

> What do you mean by a "slice pointer key" ?
>
>
> map[*[]Something]string
>
> Then map consumers can do key comparisons. I originally used this for an
> unordered set type.
>

 I'm sure you are aware of the distinction but it might not be clear for
others reading: this does "byte slice identity", but doesn't actually
compare the contents of slices.

Consider https://play.golang.org/p/gjZx8nGK8EB :

foo := []int{1, 2, 3}
bar := []int{1, 2, 3}
m := map[*[]int]bool{}
m[] = true
m[] = true

Then you'd have len(m) == 2, even though foo and bar are the same.

The neat thing about rog's trick is that in that case you'd only have one:
the two slices would be equal owing to their contents, not where the slice
happens to live in memory (not to be confused with "where the backing array
of the slice lives in memory").

-- 
You received this message because you are subscribed 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.