[go-nuts] Re: Graphing libraries in golang

[Egon]

On Friday, 29 September 2017 08:42:50 UTC+3, Vikram Rawat wrote:
>
> By graphing I actually meant *data visualization libraries*
>
> SVGO would be so hard to pass a data to and design even the basic and 
> simple *BARCHART*
>
> other ones don't have enough documentation to understand how it works.
>

https://github.com/gonum/plot/wiki/Example-plots
 

>
> and The reason I am trying GO is that R is slow. There is no point in 
> calling R from Go.
>
>
> *So is there any package that is implemented in base GO with the speed of 
> GO and worth learning.*
>
>

-- 
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: Graphing libraries in golang

[Vikram Rawat]

>
> By graphing I actually meant *data visualization libraries*

SVGO would be so hard to pass a data to and design even the basic and 
simple *BARCHART*

other ones don't have enough documentation to understand how it works.

and The reason I am trying GO is that R is slow. There is no point in 
calling R from Go.


*So is there any package that is implemented in base GO with the speed of 
GO and worth learning.*

-- 
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] internal/poll.runtime_pollWait problem on RHEL with 3.10.0-327.el7.x86_64

[Dan Kortschak]

I have just tried replicating the issue today and this time, one
machine passes everything, while the other does not. I am beginning to
suspect that file system loads may be a possible cause (the head node
is quiet, but the file system is shared across many nodes in both
cases).

The newer machine is 3.10.0-514.2.2.el7.x86_64 (also RHEL7).

I will raise this internally and get back to the issue if they don't
think this is the case. Unfortunately the two machines are under
different management, so it may be difficult to get a clear idea of
what's going on.

There are a variety of test goroutines in the stack trace (as is the
case with the original) the test you point out is not consistently in
the stack trace for either version. The stack trace for 1.8.3 is pasted
below.

Running `go test -cpuprofile errors.prof -o myerrors.test errors`
passes without event.

Dan

stack trace for go1.8.3:
```
panic: test timed out after 3m0s

goroutine 303 [running]:
testing.startAlarm.func1()
/home/users/dkortschak/go/src/testing/testing.go:1023 +0xf9
created by time.goFunc
/home/users/dkortschak/go/src/time/sleep.go:170 +0x44

goroutine 1 [chan receive]:
testing.(*T).Run(0xc42017b860, 0x9306f0, 0x13, 0x959468, 0xc4200f3b01)
/home/users/dkortschak/go/src/testing/testing.go:698 +0x2f4
testing.runTests.func1(0xc42017b860)
/home/users/dkortschak/go/src/testing/testing.go:882 +0x67
testing.tRunner(0xc42017b860, 0xc4200f3c40)
/home/users/dkortschak/go/src/testing/testing.go:657 +0x96
testing.runTests(0xc42016da60, 0xb749e0, 0xd3, 0xd3, 0xc4201c20f0)
/home/users/dkortschak/go/src/testing/testing.go:888 +0x2c1
testing.(*M).Run(0xc420273f20, 0x4)
/home/users/dkortschak/go/src/testing/testing.go:822 +0xfc
cmd/go_test.TestMain(0xc4200f3f20)
/home/users/dkortschak/go/src/cmd/go/go_test.go:119 +0x14a
main.main()
cmd/go/_test/_testmain.go:462 +0xf7

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/home/users/dkortschak/go/src/runtime/asm_amd64.s:2197 +0x1

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/home/users/dkortschak/go/src/runtime/sigqueue.go:116 +0x104
os/signal.loop()
/home/users/dkortschak/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.1
/home/users/dkortschak/go/src/os/signal/signal_unix.go:28 +0x41

goroutine 37 [chan receive]:
testing.(*T).Parallel(0xc4201f6dd0)
/home/users/dkortschak/go/src/testing/testing.go:589 +0x160
cmd/go_test.(*testgoData).parallel(0xc4201e0a00)
/home/users/dkortschak/go/src/cmd/go/go_test.go:188 +0xdb
cmd/go_test.TestFileLineInErrorMessages(0xc4201f6dd0)
/home/users/dkortschak/go/src/cmd/go/go_test.go:623 +0x6c
testing.tRunner(0xc4201f6dd0, 0x958fe0)
/home/users/dkortschak/go/src/testing/testing.go:657 +0x96
created by testing.(*T).Run
/home/users/dkortschak/go/src/testing/testing.go:697 +0x2ca

goroutine 38 [chan receive]:
testing.(*T).Parallel(0xc4201f6ea0)
/home/users/dkortschak/go/src/testing/testing.go:589 +0x160
cmd/go_test.(*testgoData).parallel(0xc4201e0b40)
/home/users/dkortschak/go/src/cmd/go/go_test.go:188 +0xdb
cmd/go_test.TestProgramNameInCrashMessages(0xc4201f6ea0)
/home/users/dkortschak/go/src/cmd/go/go_test.go:637 +0x6c
testing.tRunner(0xc4201f6ea0, 0x9593e8)
/home/users/dkortschak/go/src/testing/testing.go:657 +0x96
created by testing.(*T).Run
/home/users/dkortschak/go/src/testing/testing.go:697 +0x2ca

goroutine 47 [chan receive]:
testing.(*T).Parallel(0xc4201f7ee0)
/home/users/dkortschak/go/src/testing/testing.go:589 +0x160
cmd/go_test.(*testgoData).parallel(0xc4201e12c0)
/home/users/dkortschak/go/src/cmd/go/go_test.go:188 +0xdb
cmd/go_test.TestGoInstallRebuildsStalePackagesInOtherGOPATH(0xc4201f7ee
0)
/home/users/dkortschak/go/src/cmd/go/go_test.go:829 +0x7d
testing.tRunner(0xc4201f7ee0, 0x959120)
/home/users/dkortschak/go/src/testing/testing.go:657 +0x96
created by testing.(*T).Run
/home/users/dkortschak/go/src/testing/testing.go:697 +0x2ca

goroutine 89 [chan receive]:
testing.(*T).Parallel(0xc4203ccc30)
/home/users/dkortschak/go/src/testing/testing.go:589 +0x160
cmd/go_test.(*testgoData).parallel(0xc4201e17c0)
/home/users/dkortschak/go/src/cmd/go/go_test.go:188 +0xdb
cmd/go_test.TestGoInstallDetectsRemovedFilesInPackageMain(0xc4203ccc30)
/home/users/dkortschak/go/src/cmd/go/go_test.go:928 +0x6c
testing.tRunner(0xc4203ccc30, 0x959100)
/home/users/dkortschak/go/src/testing/testing.go:657 +0x96
created by testing.(*T).Run
/home/users/dkortschak/go/src/testing/testing.go:697 +0x2ca

goroutine 48 [chan receive]:
testing.(*T).Parallel(0xc4203cc000)
/home/users/dkortschak/go/src/testing/testing.go:589 +0x160
cmd/go_test.(*testgoData).parallel(0xc4201e1400)
/home/users/dkortschak/go/src/cmd/go/go_test.go:188 +0xdb
cmd/go_test.TestGoInstallDetectsRemovedFiles(0xc4203cc000)
 

Re: [go-nuts] Building golang libraries

[desaiabhijit]

Thanks Ian

Can you please provide command line to build executable using library 

go build -linkshared main.go 

-linkshared not supported on darwin/amd64


*doesn't work*

Thanks for the help

Rgds

On Friday, September 29, 2017 at 9:55:53 AM UTC+5:30, Ian Lance Taylor 
wrote:
>
> On Thu, Sep 28, 2017 at 9:21 PM,   
> wrote: 
> > 
> > Want to create libraries ( static or dynamic ) so that that I don't want 
> to 
> > compile every time when I build my executable 
> > 
> > "github.com/everjit/Ion" <--- should not refer to code rather it should 
> > refer to build library like .so or .dll ( in windows ) and will provide 
> that 
> > to go build command line. 
> > 
> > package main 
> > 
> > import ( 
> > "github.com/everjit/Ion" 
> > "strings" 
> > } 
> > 
> > func main(){ 
> > Ion.Invoke() 
> > } 
> > 
> > Please help 
>
> To create static libraries, run `go install`.  For example, `go 
> install github.com/everjit/lon` . 
>
> 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] Building golang libraries

[Ian Lance Taylor]

On Thu, Sep 28, 2017 at 9:21 PM,   wrote:
>
> Want to create libraries ( static or dynamic ) so that that I don't want to
> compile every time when I build my executable
>
> "github.com/everjit/Ion" <--- should not refer to code rather it should
> refer to build library like .so or .dll ( in windows ) and will provide that
> to go build command line.
>
> package main
>
> import (
> "github.com/everjit/Ion"
> "strings"
> }
>
> func main(){
> Ion.Invoke()
> }
>
> Please help

To create static libraries, run `go install`.  For example, `go
install github.com/everjit/lon`.

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] internal/poll.runtime_pollWait problem on RHEL with 3.10.0-327.el7.x86_64

[Ian Lance Taylor]

On Thu, Sep 28, 2017 at 5:40 PM, Dan Kortschak
 wrote:
>
> I can replicate this on another newer RHEL machine. In both cases the
> machines are quiet (they are the head nodes of HPC infrastructure and
> don't see a great deal of work due to the HPC use policy.
>
> I have tried building previous versions and see similar though
> different failures going back to 1.7 (where I stopped). In those cases
> there is also a timeout, and waiting for things seems also to be the
> issue.
>
> Should I file an issue? Suggested title? Should I post stack traces for
> previous versions?

Yes, please file an issue.

Are the other failures also in
TestGoTestCpuprofileDashOControlsBinaryLocation?  Try running the
commands I mentioned above and see what happens.

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] Building golang libraries

[desaiabhijit]

Want to create libraries ( static or dynamic ) so that that I don't want to 
compile every time when I build my executable

"github.com/everjit/Ion" <--- should not refer to code rather it should 
refer to build library like .so or .dll ( in windows ) and will provide 
that to go build command line.

package main

import (
"github.com/everjit/Ion"
"strings"
}

func main(){
Ion.Invoke()
}

Please help

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] go test fails - appear that it misses capturing stdout

[Ayan George]

On 09/28/2017 07:29 PM, gocss wrote:
> first the code follow by output from 'go test -v'
> 

Also, you can sort of fix this by copying os.Stdout within the example
instead of the global var () section like:

// this does not fail because iowr is a copy of os.Stdout after
// it has been 'hijacked'.
func ExampleX1() {
var iowr io.Writer = os.Stdout
Trace = log.New(iowr, "trace:", 0)
Trace.Println("123")
// Output: trace:123
}

-- 
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] Needing some explanation of a compile time error

[Dan Kortschak]

StringChan and StringSendingChan are named types and so you will need a
conversion. It would be easier though to just not declare types here.
You don't need them.

https://play.golang.org/p/0dBHgsaP0v

On Thu, 2017-09-28 at 17:19 -0700, lmumar wrote:
> Hi all,
> 
> Good day to you all. I just recently coded again in Go after trying
> out 
> other languages. I went back to Go because it's easy and
> straightforward. I 
> was going through a tutorial related to channels and tried something 
> different by declaring my channels with type statement but I hit a
> compile 
> time error. I apologize in advance if this has been asked before, but
> you 
> can see what I'm trying to do in this link - 
> https://play.golang.org/p/Dmv5WKFXqu
> 
> 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] internal/poll.runtime_pollWait problem on RHEL with 3.10.0-327.el7.x86_64

[Dan Kortschak]

I can replicate this on another newer RHEL machine. In both cases the
machines are quiet (they are the head nodes of HPC infrastructure and
don't see a great deal of work due to the HPC use policy.

I have tried building previous versions and see similar though
different failures going back to 1.7 (where I stopped). In those cases
there is also a timeout, and waiting for things seems also to be the
issue.

Should I file an issue? Suggested title? Should I post stack traces for
previous versions?

thanks

On Thu, 2017-09-28 at 10:11 -0700, Ian Lance Taylor wrote:
> On Wed, Sep 27, 2017 at 10:20 PM, Dan Kortschak
>  wrote:
> > 
> > 
> > I am seeing all.bash fail when testing cmd/go with a likely cause
> > being
> > internal/poll.runtime_pollWait.
> > 
> > I'm trying to build go1.9 (with a change to the heap size), but
> > all.bash fails as shown below. Is this a known problem? and if it
> > is,
> > is there a workaround.
> This is not a known problem.
> 
> It does not look like the problem has anything to do with
> runtime_pollWait.  The test being run is
> TestGoTestCpuprofileDashOControlsBinaryLocation in cmd/go/go_test.go.
> That test runs the go tool itself, specifically running `go test
> -cpuprofile errors.prof -o myerrors.test errors`.  The stack trace
> you
> included (thanks for doing that) shows that cmd/go/go_test.go is
> waiting for that execution to complete.
> 
> There is an overall timeout of 3 minutes.  If your machine is slow
> for
> some reason it is possible that the cmd/go tests are simply timing
> out.  Or, it is possible that the execution invoked by
> TestGoTestCpuprofileDashOControlsBinaryLocation is hanging for some
> reason, though I don't know why that would happen.
> 
> 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] Needing some explanation of a compile time error

[lmumar]

Hi all,

Good day to you all. I just recently coded again in Go after trying out 
other languages. I went back to Go because it's easy and straightforward. I 
was going through a tutorial related to channels and tried something 
different by declaring my channels with type statement but I hit a compile 
time error. I apologize in advance if this has been asked before, but you 
can see what I'm trying to do in this link - 
https://play.golang.org/p/Dmv5WKFXqu

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] go test fails - appear that it misses capturing stdout

[Ayan George]

On 09/28/2017 07:29 PM, gocss wrote:
> first the code follow by output from 'go test -v'
> 

Take a look at src/testing/example.go around line 15.

The testing code temporarily re-assigns os.Stdout for the duration of
the Example.  It sets it to one of the end of a pipe that it uses to
capture the output of anything that writes to os.Stdout.

Since you are logging to a copy of os.Stdout, your first test wirtes to
a copy of os.Stdout and thus escapes/avoids having it's output captured
by go test.

I think the short answer is: don't do that?

-ayan

-- 
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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Yaroslav Molochko]

thanks!

On Friday, September 29, 2017 at 2:36:06 AM UTC+3, Steven Hartland wrote:
>
> Which then calls the function your in, which then creates another 
> variable BOOM!
>
> On 29/09/2017 00:15, Yaroslav Molochko wrote:
>
> But I'm using other variable not the one I'm unmarshaling to:  
>
> var ts Result
> err := json.Unmarshal(b, )
>
>
>
> On Friday, September 29, 2017 at 2:10:25 AM UTC+3, Steven Hartland wrote: 
>>
>> You created an infinite recursion by calling Unmarshal on the same type 
>> your unmarshalling, hence the stack overflow error.
>>
>> On 28/09/2017 23:59, Yaroslav Molochko wrote:
>>
>> Here is the code which runs:
>>
>> https://play.golang.org/p/ds3KZspFvE
>>
>> If you press play, it will work fine and gives an expected output, 
>>
>>  as soon as you uncomment  this part:
>> /*
>> func (u *Result) UnmarshalJSON(b []byte) error {
>> var ts Result
>> err := json.Unmarshal(b, )
>> if err != nil {
>> fmt.Println(err)
>> }
>> return nil
>> }
>> */
>>
>> which basically does nothing, you will get:
>> https://play.golang.org/p/Y9NTzpwyQy
>>
>>
>> runtime: goroutine stack exceeds 25000-byte limit
>> fatal error: stack overflow
>>
>> runtime stack:
>> runtime.throw(0x122c5a, 0xe)
>>  /usr/local/go/src/runtime/panic.go:605 +0x100
>> runtime.newstack(0x0, 0x0)
>>  /usr/local/go/src/runtime/stack.go:1050 +0x960
>> runtime.morestack()
>>  /usr/local/go/src/runtime/asm_amd64p32.s:378 +0xa0
>>
>>
>> Anyone knows how to solve it? 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@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...@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] Variable JSON format parsing, any best practice?

[Yaroslav Molochko]

I have following json messages:

{"status":"success","data":["val1","val2","val3"]}
{"status":"success","data":{"resultType":"vector","result":[{"metric":{"host_name":"hss4"},"value":[1504157313.787,"24"]},{"metric":{"host_name":"hss508"},"value":[1504157313.787,"32"]}]}}

where *data* can have several formats:
first one can be interpreted as:

[]string

second line's data can be parsed as:

type Data struct {
ResultType string   `json:"resultType"`
Resultstruct {

Metric map[string]string `json:"metric"`
Values Values`json:"values,omitempty"`
Value  interface{}   `json:"value,omitempty"`

}
}

I need to parse those JSON strings, how can I do that? I've tried to make 
some parser function, the only way I come to was to create some custom 
unmarshaling function, which unmarshals one type, and if there is no such 
thing tries to unmarshal using another struct. 
I believe there must be some other way around to make it more straight 
forward. 

Any suggestions will be highly appreciated. 

-- 
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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Steven Hartland]

Which then calls the function your in, which then creates another 
variable BOOM!


On 29/09/2017 00:15, Yaroslav Molochko wrote:

But I'm using other variable not the one I'm unmarshaling to:

var ts Result
err := json.Unmarshal(b, )



On Friday, September 29, 2017 at 2:10:25 AM UTC+3, Steven Hartland wrote:

You created an infinite recursion by calling Unmarshal on the same
type your unmarshalling, hence the stack overflow error.

On 28/09/2017 23:59, Yaroslav Molochko wrote:

Here is the code which runs:

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


If you press play, it will work fine and gives an expected output,

 as soon as you uncomment  this part:
/*
func (u *Result) UnmarshalJSON(b []byte) error {
var ts Result
err := json.Unmarshal(b, )
if err != nil {
fmt.Println(err)
}
return nil
}
*/

which basically does nothing, you will get:
https://play.golang.org/p/Y9NTzpwyQy



runtime: goroutine stack exceeds 25000-byte limit fatal
error: stack overflow runtime stack: runtime.throw(0x122c5a, 0xe)
/usr/local/go/src/runtime/panic.go:605 +0x100
runtime.newstack(0x0, 0x0)
/usr/local/go/src/runtime/stack.go:1050 +0x960
runtime.morestack() /usr/local/go/src/runtime/asm_amd64p32.s:378
+0xa0

Anyone knows how to solve it?
-- 
You received this message because you are subscribed to the

Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to golang-nuts...@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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Yaroslav Molochko]

But I'm using other variable not the one I'm unmarshaling to: 

var ts Result
err := json.Unmarshal(b, )



On Friday, September 29, 2017 at 2:10:25 AM UTC+3, Steven Hartland wrote:
>
> You created an infinite recursion by calling Unmarshal on the same type 
> your unmarshalling, hence the stack overflow error.
>
> On 28/09/2017 23:59, Yaroslav Molochko wrote:
>
> Here is the code which runs:
>
> https://play.golang.org/p/ds3KZspFvE
>
> If you press play, it will work fine and gives an expected output, 
>
>  as soon as you uncomment  this part:
> /*
> func (u *Result) UnmarshalJSON(b []byte) error {
> var ts Result
> err := json.Unmarshal(b, )
> if err != nil {
> fmt.Println(err)
> }
> return nil
> }
> */
>
> which basically does nothing, you will get:
> https://play.golang.org/p/Y9NTzpwyQy
>
>
> runtime: goroutine stack exceeds 25000-byte limit
> fatal error: stack overflow
>
> runtime stack:
> runtime.throw(0x122c5a, 0xe)
>   /usr/local/go/src/runtime/panic.go:605 +0x100
> runtime.newstack(0x0, 0x0)
>   /usr/local/go/src/runtime/stack.go:1050 +0x960
> runtime.morestack()
>   /usr/local/go/src/runtime/asm_amd64p32.s:378 +0xa0
>
>
> Anyone knows how to solve it? 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Steven Hartland]

You created an infinite recursion by calling Unmarshal on the same type 
your unmarshalling, hence the stack overflow error.


On 28/09/2017 23:59, Yaroslav Molochko wrote:

Here is the code which runs:

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

If you press play, it will work fine and gives an expected output,

 as soon as you uncomment  this part:
/*
func (u *Result) UnmarshalJSON(b []byte) error {
var ts Result
err := json.Unmarshal(b, )
if err != nil {
fmt.Println(err)
}
return nil
}
*/

which basically does nothing, you will get:
https://play.golang.org/p/Y9NTzpwyQy


runtime: goroutine stack exceeds 25000-byte limit fatal error: 
stack overflow runtime stack: runtime.throw(0x122c5a, 0xe) 
/usr/local/go/src/runtime/panic.go:605 +0x100 runtime.newstack(0x0, 
0x0) /usr/local/go/src/runtime/stack.go:1050 +0x960 
runtime.morestack() /usr/local/go/src/runtime/asm_amd64p32.s:378 +0xa0


Anyone knows how to solve it?
--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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] Weird stack overflow error for struct with interface in it (a golang bug? )

[Yaroslav Molochko]

Here is the code which runs:

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

If you press play, it will work fine and gives an expected output, 

 as soon as you uncomment  this part:
/*
func (u *Result) UnmarshalJSON(b []byte) error {
var ts Result
err := json.Unmarshal(b, )
if err != nil {
fmt.Println(err)
}
return nil
}
*/

which basically does nothing, you will get:
https://play.golang.org/p/Y9NTzpwyQy


runtime: goroutine stack exceeds 25000-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0x122c5a, 0xe)
/usr/local/go/src/runtime/panic.go:605 +0x100
runtime.newstack(0x0, 0x0)
/usr/local/go/src/runtime/stack.go:1050 +0x960
runtime.morestack()
/usr/local/go/src/runtime/asm_amd64p32.s:378 +0xa0


Anyone knows how to solve it? 

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

Re: [go-nuts] tagging releases of x/crypto

[Ian Lance Taylor]

On Thu, Sep 28, 2017 at 1:34 PM, Peter Moody  wrote:
>
> Would you be amenable to to CL's that just add tags (can
> go.googlesource.com handle CLs like that?)

I don't know.  That is one thing to find out, somehow.

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: Defer with anon func and func literal

[John Jeffery]

If you want an anonymous defer function to have the same effect as a 
separate function, ensure that they accept the same parameters. To continue 
your example, this third version produces the same result as your first 
version, but uses an anonymous defer function.

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

func foo() {
var err error

defer func(err error) {
if err == nil {
println("err is nil")
} else {
println(err.Error())
}
}(err)

err = errors.New("hello")

return
}

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

Re: [go-nuts] tagging releases of x/crypto

['Peter Moody' via golang-nuts]

On Thu, Sep 28, 2017 at 1:23 PM, Ian Lance Taylor  wrote:
> On Thu, Sep 28, 2017 at 1:12 PM, Peter Moody  wrote:
>> following on up on this. Is there anything that would help make my case?
>>
>> is this a case of "the ship has already sailed", nobody wants to take
>> the time to maintain tags in the future, etc? we could potentially
>> fork stuff internally and add tags ourselves, but that comes with all
>> of the obvious problems and probably lots of non-obvious ones as well.
>
> As you suggest, I don't know that anyone is going to volunteer to take
> the time to maintain semantic versioning tags for this repo.  If there
> is a way that the tags can be contributed using the usual contribution
> process, and if there is some documented set of guidelines for when
> the tag should change, then perhaps we could handle it that way.  If
> we have to rely on a specific maintainer doing it, then I don't know
> who that would be.

there are guidelines for semantic versioning, and when major, minor or
patch level versions should change (and what customers can expect from
those changes).

Would you be amenable to to CL's that just add tags (can
go.googlesource.com handle CLs like that?)

if I'm the only person in the greater go ecosystem who cares about
semvers on x/crypto then it's probably not worth the time because I
don't check back in often enough to reliably know when tags should be
cut.

> Ian
>
>
>
>
>> On Tue, Sep 19, 2017 at 8:46 PM, Peter Moody  wrote:
>>> On Tue, Sep 19, 2017 at 5:42 PM, Ian Lance Taylor  wrote:
 On Tue, Sep 19, 2017 at 9:36 AM, 'Peter Moody' via golang-nuts
  wrote:
>
> We're big consumers of the x/crypto packages, but the lack of semantic
> versioning tags means that our dependency management tools can easily
> pull in incompatible versions when we update.
>
> what would it take to start tagging releases of x/crypto?

 How do these problems show up?
>>>
>>> by way of example:
>>>
>>> library L1 depends on x/crypto/ssh post 527d12e (introduction of the
>>> IsHostAuthority)
>>> library L2 depends on x/crypto/ssh, no version tag
>>> service S depends on L1 and L2
>>>
>>> we use glide, and depending on the ordering of how glide determines
>>> dependent versions (and what may or may not be in a local cache), the
>>> version of x/crypto that's included the final glide.lock may or may
>>> not have contain a version of the ssh library has IsHostAuthority.
>>>
>>> Now, we can pin L1 to master, but there aren't any api compatibility
>>> guarantees when one is pinned to master. Alternatively, we can pin L1
>>> to 527d12e, but we're in a bad spot if L2 depends on a feature that's
>>> introduced after 527d12e
>>>
 How would the problems be fixed by adding semantic versioning?
>>>
>>> assuming x/crypto at the IsHostAuthority change is tagged at 1.0 and
>>> the new feature needed by L2 is pinned at something later, adding
>>> semantic versioning to x/crypto allows us to do something like
>>>
>>> pin L1 to ^1
>>> pin L2 to ~1.1
>>>
>>> now glide can know that anything that satisfies L2 will satisfy L1.
>>>
>>> there are obviously corner cases where you can make the semantic
>>> versioning barf (someone needs to do work if L2 wants to pin to ^2 for
>>> instance, but a major version bump implies an incompatible api change
>>> so that should be somewhat expected) but this at least allows services
>>> and libraries to reason about the stability of an api at a version.
>>>
>>> Cheers,
>>> peter
>>>
 (I'm not opposed to semantic versioning but I don't really understand
 how it would help here.)

 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] tagging releases of x/crypto

[Ian Lance Taylor]

On Thu, Sep 28, 2017 at 1:12 PM, Peter Moody  wrote:
> following on up on this. Is there anything that would help make my case?
>
> is this a case of "the ship has already sailed", nobody wants to take
> the time to maintain tags in the future, etc? we could potentially
> fork stuff internally and add tags ourselves, but that comes with all
> of the obvious problems and probably lots of non-obvious ones as well.

As you suggest, I don't know that anyone is going to volunteer to take
the time to maintain semantic versioning tags for this repo.  If there
is a way that the tags can be contributed using the usual contribution
process, and if there is some documented set of guidelines for when
the tag should change, then perhaps we could handle it that way.  If
we have to rely on a specific maintainer doing it, then I don't know
who that would be.

Ian




> On Tue, Sep 19, 2017 at 8:46 PM, Peter Moody  wrote:
>> On Tue, Sep 19, 2017 at 5:42 PM, Ian Lance Taylor  wrote:
>>> On Tue, Sep 19, 2017 at 9:36 AM, 'Peter Moody' via golang-nuts
>>>  wrote:

 We're big consumers of the x/crypto packages, but the lack of semantic
 versioning tags means that our dependency management tools can easily
 pull in incompatible versions when we update.

 what would it take to start tagging releases of x/crypto?
>>>
>>> How do these problems show up?
>>
>> by way of example:
>>
>> library L1 depends on x/crypto/ssh post 527d12e (introduction of the
>> IsHostAuthority)
>> library L2 depends on x/crypto/ssh, no version tag
>> service S depends on L1 and L2
>>
>> we use glide, and depending on the ordering of how glide determines
>> dependent versions (and what may or may not be in a local cache), the
>> version of x/crypto that's included the final glide.lock may or may
>> not have contain a version of the ssh library has IsHostAuthority.
>>
>> Now, we can pin L1 to master, but there aren't any api compatibility
>> guarantees when one is pinned to master. Alternatively, we can pin L1
>> to 527d12e, but we're in a bad spot if L2 depends on a feature that's
>> introduced after 527d12e
>>
>>> How would the problems be fixed by adding semantic versioning?
>>
>> assuming x/crypto at the IsHostAuthority change is tagged at 1.0 and
>> the new feature needed by L2 is pinned at something later, adding
>> semantic versioning to x/crypto allows us to do something like
>>
>> pin L1 to ^1
>> pin L2 to ~1.1
>>
>> now glide can know that anything that satisfies L2 will satisfy L1.
>>
>> there are obviously corner cases where you can make the semantic
>> versioning barf (someone needs to do work if L2 wants to pin to ^2 for
>> instance, but a major version bump implies an incompatible api change
>> so that should be somewhat expected) but this at least allows services
>> and libraries to reason about the stability of an api at a version.
>>
>> Cheers,
>> peter
>>
>>> (I'm not opposed to semantic versioning but I don't really understand
>>> how it would help here.)
>>>
>>> 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] tagging releases of x/crypto

['Peter Moody' via golang-nuts]

following on up on this. Is there anything that would help make my case?

is this a case of "the ship has already sailed", nobody wants to take
the time to maintain tags in the future, etc? we could potentially
fork stuff internally and add tags ourselves, but that comes with all
of the obvious problems and probably lots of non-obvious ones as well.

On Tue, Sep 19, 2017 at 8:46 PM, Peter Moody  wrote:
> On Tue, Sep 19, 2017 at 5:42 PM, Ian Lance Taylor  wrote:
>> On Tue, Sep 19, 2017 at 9:36 AM, 'Peter Moody' via golang-nuts
>>  wrote:
>>>
>>> We're big consumers of the x/crypto packages, but the lack of semantic
>>> versioning tags means that our dependency management tools can easily
>>> pull in incompatible versions when we update.
>>>
>>> what would it take to start tagging releases of x/crypto?
>>
>> How do these problems show up?
>
> by way of example:
>
> library L1 depends on x/crypto/ssh post 527d12e (introduction of the
> IsHostAuthority)
> library L2 depends on x/crypto/ssh, no version tag
> service S depends on L1 and L2
>
> we use glide, and depending on the ordering of how glide determines
> dependent versions (and what may or may not be in a local cache), the
> version of x/crypto that's included the final glide.lock may or may
> not have contain a version of the ssh library has IsHostAuthority.
>
> Now, we can pin L1 to master, but there aren't any api compatibility
> guarantees when one is pinned to master. Alternatively, we can pin L1
> to 527d12e, but we're in a bad spot if L2 depends on a feature that's
> introduced after 527d12e
>
>> How would the problems be fixed by adding semantic versioning?
>
> assuming x/crypto at the IsHostAuthority change is tagged at 1.0 and
> the new feature needed by L2 is pinned at something later, adding
> semantic versioning to x/crypto allows us to do something like
>
> pin L1 to ^1
> pin L2 to ~1.1
>
> now glide can know that anything that satisfies L2 will satisfy L1.
>
> there are obviously corner cases where you can make the semantic
> versioning barf (someone needs to do work if L2 wants to pin to ^2 for
> instance, but a major version bump implies an incompatible api change
> so that should be somewhat expected) but this at least allows services
> and libraries to reason about the stability of an api at a version.
>
> Cheers,
> peter
>
>> (I'm not opposed to semantic versioning but I don't really understand
>> how it would help here.)
>>
>> 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] internal/poll.runtime_pollWait problem on RHEL with 3.10.0-327.el7.x86_64

[Ian Lance Taylor]

On Wed, Sep 27, 2017 at 10:20 PM, Dan Kortschak
 wrote:
>
> I am seeing all.bash fail when testing cmd/go with a likely cause being
> internal/poll.runtime_pollWait.
>
> I'm trying to build go1.9 (with a change to the heap size), but
> all.bash fails as shown below. Is this a known problem? and if it is,
> is there a workaround.

This is not a known problem.

It does not look like the problem has anything to do with
runtime_pollWait.  The test being run is
TestGoTestCpuprofileDashOControlsBinaryLocation in cmd/go/go_test.go.
That test runs the go tool itself, specifically running `go test
-cpuprofile errors.prof -o myerrors.test errors`.  The stack trace you
included (thanks for doing that) shows that cmd/go/go_test.go is
waiting for that execution to complete.

There is an overall timeout of 3 minutes.  If your machine is slow for
some reason it is possible that the cmd/go tests are simply timing
out.  Or, it is possible that the execution invoked by
TestGoTestCpuprofileDashOControlsBinaryLocation is hanging for some
reason, though I don't know why that would happen.

Ian




> thanks
>
> ```
> panic: test timed out after 3m0s
>
> goroutine 249 [running]:
> testing.startAlarm.func1()
> /home/users/dkortschak/go/src/testing/testing.go:1145 +0xf9
> created by time.goFunc
> /home/users/dkortschak/go/src/time/sleep.go:170 +0x44
>
> goroutine 1 [chan receive]:
> testing.(*T).Run(0xc8401ca000, 0x929b65, 0x2f, 0x945350, 0x48d701)
> /home/users/dkortschak/go/src/testing/testing.go:790 +0x2fc
> testing.runTests.func1(0xc8401ca000)
> /home/users/dkortschak/go/src/testing/testing.go:1004 +0x64
> testing.tRunner(0xc8401ca000, 0xc840157b80)
> /home/users/dkortschak/go/src/testing/testing.go:746 +0xd0
> testing.runTests(0xc840109000, 0xb94920, 0xd7, 0xd7, 0x91ed9c)
> /home/users/dkortschak/go/src/testing/testing.go:1002 +0x2d8
> testing.(*M).Run(0xc84007df18, 0x4)
> /home/users/dkortschak/go/src/testing/testing.go:921 +0x111
> cmd/go_test.TestMain(0xc840157f18)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:141 +0x150
> main.main()
> cmd/go/_test/_testmain.go:472 +0xdb
>
> goroutine 5 [syscall, 1 minutes]:
> os/signal.signal_recv(0x0)
> /home/users/dkortschak/go/src/runtime/sigqueue.go:131 +0xa6
> os/signal.loop()
> /home/users/dkortschak/go/src/os/signal/signal_unix.go:22 +0x22
> created by os/signal.init.0
> /home/users/dkortschak/go/src/os/signal/signal_unix.go:28 +0x41
>
> goroutine 9 [chan receive, 1 minutes]:
> testing.(*T).Parallel(0xc8401ca0f0)
> /home/users/dkortschak/go/src/testing/testing.go:677 +0x127
> cmd/go_test.(*testgoData).parallel(0xc8400b7b80)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:218 +0x382
> cmd/go_test.TestFileLineInErrorMessages(0xc8401ca0f0)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:667 +0x6c
> testing.tRunner(0xc8401ca0f0, 0x9451b8)
> /home/users/dkortschak/go/src/testing/testing.go:746 +0xd0
> created by testing.(*T).Run
> /home/users/dkortschak/go/src/testing/testing.go:789 +0x2de
>
> goroutine 10 [chan receive, 1 minutes]:
> testing.(*T).Parallel(0xc8401ca1e0)
> /home/users/dkortschak/go/src/testing/testing.go:677 +0x127
> cmd/go_test.(*testgoData).parallel(0xc8400b7cc0)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:218 +0x382
> cmd/go_test.TestProgramNameInCrashMessages(0xc8401ca1e0)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:681 +0x6c
> testing.tRunner(0xc8401ca1e0, 0x945600)
> /home/users/dkortschak/go/src/testing/testing.go:746 +0xd0
> created by testing.(*T).Run
> /home/users/dkortschak/go/src/testing/testing.go:789 +0x2de
>
> goroutine 16 [chan receive, 1 minutes]:
> testing.(*T).Parallel(0xc8401ca3c0)
> /home/users/dkortschak/go/src/testing/testing.go:677 +0x127
> cmd/go_test.(*testgoData).parallel(0xc8403ee000)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:218 +0x382
> cmd/go_test.TestGoInstallRebuildsStalePackagesInOtherGOPATH(0xc8401ca3c
> 0)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:873 +0x7d
> testing.tRunner(0xc8401ca3c0, 0x945300)
> /home/users/dkortschak/go/src/testing/testing.go:746 +0xd0
> created by testing.(*T).Run
> /home/users/dkortschak/go/src/testing/testing.go:789 +0x2de
>
> goroutine 65 [chan receive, 1 minutes]:
> testing.(*T).Parallel(0xc8401ca4b0)
> /home/users/dkortschak/go/src/testing/testing.go:677 +0x127
> cmd/go_test.(*testgoData).parallel(0xc8403ee140)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:218 +0x382
> cmd/go_test.TestGoInstallDetectsRemovedFiles(0xc8401ca4b0)
> /home/users/dkortschak/go/src/cmd/go/go_test.go:903 +0x6c
> testing.tRunner(0xc8401ca4b0, 0x9452e8)
> /home/users/dkortschak/go/src/testing/testing.go:746 +0xd0
> created by testing.(*T).Run
> /home/users/dkortschak/go/src/testing/testing.go:789 +0x2de
>
> 

Re: [go-nuts] Defer with anon func and func literal

[Marvin Renich]

* Karan Chaudhary  [170928 08:50]:
> I'm trying to find rationale for this:  why is "defer foo(x)" treated 
> differently than "defer func() { foo(x) }" by the language designers?

Here is what the language spec says:

  Each time a "defer" statement executes, the function value and
  parameters to the call are evaluated as usual and saved anew but the
  actual function is not invoked.

So, in the first case, the address of foo is saved along with the
current value of x.  The variable x is not part of a closure involving
foo.

In the second case, the address of a closure, the anonymous func, is
saved; it has no function arguments to evaluate.  This closure includes
the variable x from the surrounding scope.  So when the deferred closure
is executed, the value of x at this later time is used.

Does this explain it?

...Marvin

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

Re: [go-nuts] Re: How to read multi-page TIFF image?

[Michael Jones]

thanks, i'll make notes there

On Wed, Sep 27, 2017 at 11:01 PM, Nigel Tao  wrote:

> On Thu, Sep 28, 2017 at 10:28 AM, Michael Jones 
> wrote:
> > Not quite related, but if changes are going to happen, I want to add (or
> see
> > someone add) colorspace tags to the PNG code and the TIFF code.
>
> It's not exactly what you're asking for, but there are already issues
> https://github.com/golang/go/issues/11420 "x/image/draw: color
> space-correct interpolation" and
> https://github.com/golang/go/issues/20613 "image/png: don't ignore PNG
> gAMA chunk". There might be other issues filed, I didn't do an
> exhaustive search.
>



-- 
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] Re: go 1.9 go test build fail on // Output:

[Ayan George]

gocss  wrote:

> good catch  however the thing that made it not obvious
> is that is it built without the // Output:   line ... 
> Running go test -work  can show why it fails ... further this does make 
> sense too
> that no such testing args should be in an 'Example' program.

Just out of curiosity, how might you use a testing.T value in an Example type
test?  Off the top of my head t.Log()/t.Logf() are the only things I can think
of.

> I think the test apparatus should fail or warn in either case.

If you ran go vet -tests, It would have complained but I think its output is
also a little cryptic and it doesn't appear to check for "// Output:" comments
Either way, go vet would have helped you here:

$ go vet -tests
ex_test.go:7: ExampleNew should be niladic

I also I think reading the testing docs and a careful read of the error text
explains almost as clearly as go vet:

> /tmp/go-build584983468/csspc/alog/_test/_testmain.go:30:22: cannot use 
> alog.ExampleNew (type func(*testing.T)) as type func() in field value

I agree that this was probably annoying and hard to catch. I think you solved
it correctly by either reading the docs or asking for help and I doubt you'll
ever make this mistake again.

Maybe you should also add go vet to your toolbox if it isn't already there?

-ayan

-- 
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] `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[David Collier-Brown]

Indeed: a monotonic increasing number is a good thing, but I wouldn't try 
to make it an actual time, just a relative time-like-thingie  that _you_ 
define with the properties you need and that you can implement.

--dave

On Wednesday, September 27, 2017 at 6:55:37 AM UTC-4, Dave Cheney wrote:
>
> Using monotonic time for implementing a distributed locking system 
> seems fraught with difficulties. 
>  supported kernels. 
>
>

-- 
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] Defer with anon func and func literal

[Jan Mercl]

On Thu, Sep 28, 2017 at 2:50 PM Karan Chaudhary  wrote:

> I'm trying to find rationale for this: why is "defer foo(x)" treated
differently than "defer func() { foo(x) }" by the language designers?

They are not treated differently. The defered functions are different.


-- 

-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] Defer with anon func and func literal

[Karan Chaudhary]

I see.

I'm trying to find rationale for this:  why is "defer foo(x)" treated 
differently than "defer func() { foo(x) }" by the language designers?

On Thursday, 28 September 2017 17:57:45 UTC+5:30, Jan Mercl wrote:
>
> On Thu, Sep 28, 2017 at 2:18 PM Karan Chaudhary  > wrote:
>
> That's expected, the specs say that execution of the defer statement 
> evaluates the arguments of the deferred function.
>
> -- 
>
> -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] Defer with anon func and func literal

[Jan Mercl]

On Thu, Sep 28, 2017 at 2:18 PM Karan Chaudhary  wrote:

That's expected, the specs say that execution of the defer statement
evaluates the arguments of the deferred function.

-- 

-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] Graphing libraries in golang

[Jan Mercl]

On Wed, Sep 27, 2017 at 5:05 PM Vikram Rawat 
wrote:

Also there's https://github.com/cznic/plot.

-- 

-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: Graphing libraries in golang

[Rich]

Not sure if this applies but I did some graphing using 
this: https://godoc.org/github.com/ajstarks/svgo  

On Wednesday, September 27, 2017 at 8:35:49 PM UTC-4, kortschak wrote:
>
> On Wed, 2017-09-27 at 08:54 -0700, Volker Dobler wrote: 
> > One from https://awesome-go.com/#science-and-data-analysis 
> > probably should fit your needs. Or try looking for R bindings and 
> > run your plots through R. 
>
>
> https://godoc.org/gonum.org/v1/plot for the first and 
> https://godoc.org/github.com/kortschak/arrgh for the second. 
>
>

-- 
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] Defer with anon func and func literal

[Karan Chaudhary]

Hi,

I have a doubt regarding use of enclosing function's variables inside 
functions used as "deferred".

If function literal is used as "deferred" func (say foo),  and it uses 
enclosing function's variable (say x) as one of its arguments, 
the value of x is "frozen" and func foo is called with that val.
While,  if anon function is used and value of x is changed after the defer 
statement,  new value
is reflected within deferred anon func.

In first case,  nil error is printed:  https://play.golang.org/p/GB5n3ECLY3

func log(err error) {
println(err)
}

func foo(){
var err error
defer log(err)
err = errors.New("hello")
return
}

In second case,  non-nil error is printed: 
 https://play.golang.org/p/bm9nRn_pid

func log(err error) {
println(err)
}

func foo(){
var err error
defer func() {
log(err)
}()
err = errors.New("hello")
return
}

Thanks,
Karan

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

Re: [go-nuts] go 1.9 go test build fail on // Output:

[Ayan George]

On 09/28/2017 08:12 AM, gocss wrote:
> go test
> # testmain
> /tmp/go-build584983468/csspc/alog/_test/_testmain.go:30:22: cannot use
> alog.ExampleNew (type func(*testing.T)) as type func() in field value
> FAIL    csspc/alog [build failed]
> 
> code follows:
> package alog
> 
> import (
>     "fmt"
>     "testing"
> )
> 
> func ExampleNew(t *testing.T) {
>     alog, err := New("alog:")
>     if err != nil {
>     t.Fatal(err)
>     }
>     fmt.Println(LogFlagsDefault)
>     alog.Debug.SetFlags(0)
>     // Output: 123
> }
> 

ExampleNew() shouldn't take a *testing.T.

Its signature should be just:

func ExampleNew() {
  ...
}

I get it. It is probably habit to add testing.T to tests. :)

-ayan

-- 
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 read multi-page TIFF image?

[Nigel Tao]

On Thu, Sep 28, 2017 at 10:28 AM, Michael Jones  wrote:
> Not quite related, but if changes are going to happen, I want to add (or see
> someone add) colorspace tags to the PNG code and the TIFF code.

It's not exactly what you're asking for, but there are already issues
https://github.com/golang/go/issues/11420 "x/image/draw: color
space-correct interpolation" and
https://github.com/golang/go/issues/20613 "image/png: don't ignore PNG
gAMA chunk". There might be other issues filed, I didn't do an
exhaustive search.

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