[go-nuts] Re: Small complete examples which show the power of Go?

[anupam . kapoor]

,
| I always liked Rob Pike's concurrent prime seive:
| https://play.golang.org/p/9U22NfrXeq
`
i think what you are looking for is an elegant paper by doug-mcllroy
called "squinting at power series"

which bring the power of channels etc to stream processing...

--
kind regards
anupam

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Proposal: radix sort in /x/exp

[Randall Farmer]

Hi!

I'd like to propose adding an /x/exp package with in-place radix sort.
Maybe someday something like it gets into stdlib and backs sort.Ints and
company (great!), maybe not (works for me, just the review's worth it). I'm
posting here rather than opening a GitHub issue because earlier this year
other folks opened a related issue (github.com/golang/go/issues/14653) and
people there suggested taking discussion here.

As background, last year I put out github.com/twotwotwo/sorts. To use its
in-place radix sorts, you implement sort.Interface + a Key(int) method
returning a (u)int64, string, or []byte sort key at an index. In timings I
ran at the time, the ns/op delta with one goroutine was -38% for sorting
11M English strings (Wikipedia titles) and -71% for Benchmark1e6. It can do
parallel sorts too, which got a roughly -80% wall-time delta for both
strings (with 8 procs) and ints (with 2). More data from back then is at
http://bit.ly/2biQpDz . Haven't rerun all that but the order of magnitude
of the differences has been the same with current compilers and the
shellsort change.

Those sorts are in-place, there's no reflect/unsafe, and it can sort
[]MyThing not just []int/[]string (or non-slices, anything satisfying the
iface). It's got full test coverage from tests from the stdlib and new
ones. I think those things distinguish it from many of the past ideas re:
sorting. I'm not proposing that package for Go--busy API, trying to do too
much at once, some weird internals--but maybe it helps show the idea's
viable.

I think, in general, a great thing about Go is most stdlib packages scale
well--net/http's still a good pick when you get real traffic, say. Adding
stdlib sorts that are faster for large collections seems in that spirit.
They'd be no more niche than, say, index/suffixarray or big.Float. (I love
that Go has those, 'cause they're cool fundamental capabilities; I'm just
saying maybe faster sorts for larger datasets are, too.) I know arguments
against--don't add APIs just for constant-factor speedups, most data's
small, etc.--so maybe there's no real chance stdlib ever gets sort/radix or
such, but I figure I might as well make a pitch for it.

Experimenting, I pulled out *just* an in-place serial uint64 sort and it's
about as much code as stdlib's hybrid sort. I wrote helpers to adapt it to
sorting other types. (Even strings, via abbreviated-key sorting which
bit.ly/2biZ737 explains better than I can. That's faster in tests *and*
simpler than my "real" string sort, but allocates a big []uint64 so eh.)
Parallel sorts, a proper in-place string sort, etc. could each be tackled
independently. My scratchpad's at godoc.org/github.com/twotwotwo/sort/radix
but don't take my futzing around there too seriously (and *no one* use it
for real; breaking the API is the point of it and I didn't bring over the
test suite!).

Stepping back, I'm flexible on where to start, if there's anything to start
on. I should probably hear about the threshold question of whether radix or
parallel sorts are non-starters for the Go project (meaning, even /x/)
before getting deeper in the weeds. I may seem to answer stuff at 1/8 speed
because of life and work, but interested in what folks have to say.

Thanks for reading!

Randall

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 wait for http.ListenAndServeTLS()

[Dave Cheney]

Alternatively, make a connection to your server locally to check it is 
listening, the fire off the browser. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 wait for http.ListenAndServeTLS()

[Dave Cheney]

Listen and serve is just a wrapper around serve with a provided listener. 
Create the listener then pass it to serve, at that point you know the socket is 
open and will accept connections into its backlog.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] goroutine 17 [syscall, 214 minutes, locked to thread]

[Lime Shi]

And which bulitin package will call cgo or runtime.LockOSThread. In my 
project, I used packages net, io, sync.

在 2016年8月16日星期二 UTC+8上午1:15:29，Ian Lance Taylor写道：
>
> On Mon, Aug 15, 2016 at 1:21 AM,   
> wrote: 
> > 
> > In goroutine stack dump there is a dead lock. 
> > 
> > goroutine 17 [syscall, 214 minutes, locked to thread]: 
> > runtime.goexit() 
> > /root/go/src/runtime/asm_amd64.s:1998 +0x1 
> > 
> > 
> > No more information, just this. I don't know how to debug it. Somebody 
> can 
> > help me? 
>
> That is not a deadlock, at least not a deadlock in the Go program.  It 
> is normal for a goroutine to be locked to a thread.  It can happen 
> because of cgo, or because the code called runtime.LockOSThread.  It 
> is not a problem.  The problem is that the thread has not made any 
> progress for 214 minutes; what that is depends on what it is doing. 
>
> If this is repeatable, can you get a stack trace with the environment 
> variable GOTRACEBACK=system ? 
>
> 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] Go 1.7 is released

[Chris Broadfoot]

Thanks, it has been added here: https://golang.org/project/

On Mon, Aug 15, 2016 at 5:25 PM, chai2010  wrote:

> and http://127.0.0.1:6060/project/ #release history page have no Go1.7
> release notes.
>
> 2016-08-16 8:20 GMT+08:00 Chris Broadfoot :
>
>> Thanks for flagging it. I'm re-building the zip file and it should be
>> available at golang.org/dl soon.
>>
>> On Mon, Aug 15, 2016 at 5:03 PM, chai2010  wrote:
>>
>>> go1.7.windows-amd64.zip missing.
>>>
>>> 2016-08-16 7:28 GMT+08:00 Chris Broadfoot :
>>>
 Hello gophers,

 We just released Go 1.7.

 You can read the announcement blog post here:
   https://blog.golang.org/go1.7

 You can download binary and source distributions from our download page:
   https://golang.org/dl/

 To compile from source using a Git checkout, update to the release with
 "git checkout go1.7" and build as usual.

 To find out what has changed, read the release notes:
   https://golang.org/doc/go1.7

 Thanks to everyone who contributed to the release.

 Chris

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

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

>>>
>>>
>>>
>>> --
>>> https://github.com/golang-china/gopl-zh
>>> https://github.com/golang-china
>>> https://github.com/chai2010
>>>
>>
>>
>
>
> --
> https://github.com/golang-china/gopl-zh
> https://github.com/golang-china
> https://github.com/chai2010
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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.7 is released

[chai2010]

and http://127.0.0.1:6060/project/ #release history page have no Go1.7
release notes.

2016-08-16 8:20 GMT+08:00 Chris Broadfoot :

> Thanks for flagging it. I'm re-building the zip file and it should be
> available at golang.org/dl soon.
>
> On Mon, Aug 15, 2016 at 5:03 PM, chai2010  wrote:
>
>> go1.7.windows-amd64.zip missing.
>>
>> 2016-08-16 7:28 GMT+08:00 Chris Broadfoot :
>>
>>> Hello gophers,
>>>
>>> We just released Go 1.7.
>>>
>>> You can read the announcement blog post here:
>>>   https://blog.golang.org/go1.7
>>>
>>> You can download binary and source distributions from our download page:
>>>   https://golang.org/dl/
>>>
>>> To compile from source using a Git checkout, update to the release with
>>> "git checkout go1.7" and build as usual.
>>>
>>> To find out what has changed, read the release notes:
>>>   https://golang.org/doc/go1.7
>>>
>>> Thanks to everyone who contributed to the release.
>>>
>>> Chris
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> https://github.com/golang-china/gopl-zh
>> https://github.com/golang-china
>> https://github.com/chai2010
>>
>
>


-- 
https://github.com/golang-china/gopl-zh
https://github.com/golang-china
https://github.com/chai2010

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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.7 is released

[chai2010]

go1.7.windows-amd64.zip missing.

2016-08-16 7:28 GMT+08:00 Chris Broadfoot :

> Hello gophers,
>
> We just released Go 1.7.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.7
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with
> "git checkout go1.7" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.7
>
> Thanks to everyone who contributed to the release.
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
https://github.com/golang-china/gopl-zh
https://github.com/golang-china
https://github.com/chai2010

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Meet runtime.typedslicecopy: nosplit stack overflow error when cross platform compiling.

[brainman]

On Saturday, 13 August 2016 12:52:23 UTC+10, Dorival Pedroso wrote:
>
> Any ideas?
>

Maybe it is issue https://github.com/golang/go/issues/16180 ?

Alex 

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

[go-nuts] Go 1.7 is released

[Chris Broadfoot]

Hello gophers,

We just released Go 1.7.

You can read the announcement blog post here:
  https://blog.golang.org/go1.7

You can download binary and source distributions from our download page:
  https://golang.org/dl/

To compile from source using a Git checkout, update to the release with 
"git checkout go1.7" and build as usual.

To find out what has changed, read the release notes:
  https://golang.org/doc/go1.7

Thanks to everyone who contributed to the release.

Chris

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

[go-nuts] Re: Increase speed of repeated builds

[Dave Cheney]

With that many deps, the linking numbers could be expected, Go 1.7 improves 
this significantly.

I cannot explain the compilation time for the package. I recommend waiting 
til the end of the day and upgrading to Go 1.7 as it us unlikely that any 
fix for this will be backported to Go1.6.x


On Tuesday, 16 August 2016 07:43:41 UTC+10, James Pettyjohn wrote:
>
> No, it's some hundreds of strings across that whole package, none longer 
> than 100 characters. No giant static XML strings or the like.
>
> Thinking it might be telling to see dependency information I ran into 
> (your) articles on golang dependency tools 
> , so if it's 
> of any note:
>
> go list -f '{{ join .Imports "\n" }}' site_www2 | wc -l
>   93
> go list -f '{{ join .Deps "\n" }}' site_www2 | wc -l
>  257
>
> Don't know that this is very telling. 
>
> Is there another important metric as far as go compilation? Or another 
> compiler option to see numbers branches or the like which could point up 
> something?
>
>
> On Monday, August 15, 2016 at 1:40:19 PM UTC-7, Dave Cheney wrote:
>>
>> That looks like the case.
>>
>> Do you include a large amount of static data in the site_www2 package? 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Increase speed of repeated builds

[James Pettyjohn]

No, it's some hundreds of strings across that whole package, none longer 
than 100 characters. No giant static XML strings or the like.

Thinking it might be telling to see dependency information I ran into 
(your) articles on golang dependency tools 
, so if it's of 
any note:

go list -f '{{ join .Imports "\n" }}' site_www2 | wc -l
  93
go list -f '{{ join .Deps "\n" }}' site_www2 | wc -l
 257

Don't know that this is very telling. 

Is there another important metric as far as go compilation? Or another 
compiler option to see numbers branches or the like which could point up 
something?


On Monday, August 15, 2016 at 1:40:19 PM UTC-7, Dave Cheney wrote:
>
> That looks like the case.
>
> Do you include a large amount of static data in the site_www2 package? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Ideas for a Go interpeter, feedback requested

[Rob Pike]

Sounds a lot like the Newsqueak implementation.
https://swtch.com/~rsc/thread/newsquimpl.pdf

On Tue, Aug 16, 2016 at 6:33 AM, Lars Tørnes Hansen 
wrote:

> My thought about a Go interrpreter.
>
> I had thought of making a Go transpiler using either the D programming
> language, or the Julia programming language as the target.
>
> Julia is very interesting. It is using the LLVM JIT. In the Julia REPL it
> is very easy to show the machine code or LLVM bitcode for some function, so
> i guess running a per line bunch of LLVM bit code is possible.
> Julia can call C code with no glue code.
>
> Implementation ideas
>
>  * Interpreter is stack less (each go routine is a pointer to a struct of
> type GoRoutine)
>  * Switching between Go routines is then copy go routine pointer to the
> wait or run queue, and take one pointer from the run queue, and resume
> execution.
>  * If all go routines are deadlocked, then the run queue will be empty.
> The scheduler will then panic = Show an error in the REPL. The user can now
> poke around, and *read* (not write) go routine states/variables. An
> interpreter vet tool (build into the interpreter)  could maybe do some
> interesting stuff, now that all states and variables are frozen in time.
>
>
> Den mandag den 7. september 2015 kl. 06.49.03 UTC+2 skrev Elliott Stoneham:
>>
>> I’ve been working with Sebastien Binet to develop some initial ideas for
>> a Go interpreter, we’d welcome some feedback.
>>
>>
>> You can see the document at https://docs.google.com/docume
>> nt/d/1Hvxf6NMPaCUd-1iqm_968SuHN1Vf8dLZQyHjvPyVE0Q/edit?usp=sharing
>>
>> There is also a reddit entry at https://www.reddit.com/r/go
>> lang/comments/3jx2bb/proposal_for_a_go_interpreter/?ref=
>> share_source=link
>>
>> Thank you for your interest.
>>
>> Elliott
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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: Increase speed of repeated builds

[Dave Cheney]

That looks like the case.

Do you include a large amount of static data in the site_www2 package? 

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

Re: [go-nuts] runtime.Caller ->

[Ian Lance Taylor]

On Mon, Aug 15, 2016 at 10:51 AM, Tim Hockin  wrote:
> OK, is there ANY heuristic I can rely on find the "real" call frame?

I don't know.  Sorry.  As I said earlier, I don't have a good answer here.

You should open an issue for this.  For some reason it has not been a
problem, perhaps because most code doesn't use the wrapper methods
much.  One reliable approach you could take would be to not call
runtime.Callers(1) from a value method or from a method in a type that
you embed into another type.  But I understand that that is not a
satisfactory answer.

Ian


> On Mon, Aug 15, 2016 at 10:17 AM, Ian Lance Taylor  wrote:
>> On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin  wrote:
>>> Can I rely on "" not changing?
>>
>> I'm sorry, that's a hard question to answer, because other compilers
>> do not use that string.
>>
>> There are no plans to change that string for the gc toolchain.
>>
>> Ian
>>
>>> On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Taylor  wrote:
 On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin  wrote:
> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor  wrote:
>> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin  wrote:
>>> Edit:  It looks like this has more to do with being an interface
>>> method than an embedded type.
>>>
>>> https://play.golang.org/p/I5XPdWR_O0
>>
>> Hmmm, you're right.  It only happens for a value method.
>
> Is this likely to change? I.e. can I hardcode "2" or should I actually
> write the loop to climb frames?  Is there a limit to the number of
> frames I should inspect before I give up?  Is the string
> "" stable?

 Well, unfortunately, it's different for different compilers.  I don't
 have a good answer here.  Except to say that you should never need
 more than 2 frames; it should never be the case that autogenerated
 code calls autogenerated code.

 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] [ANN] gopkg.in/warnings.v0 -- error handling with non-fatal errors (warnings)

[speter . go1]

Package warnings implements error handling with non-fatal errors (warnings).

import path:   "gopkg.in/warnings.v0"
package docs:  https://godoc.org/gopkg.in/warnings.v0 
issues:https://github.com/go-warnings/warnings/issues
pull requests: https://github.com/go-warnings/warnings/pulls

A recurring pattern in Go programming is the following:

 func myfunc(params) error {
 if err := doSomething(...); err != nil {
 return err
 }
 if err := doSomethingElse(...); err != nil {
 return err
 }
 if ok := doAnotherThing(...); !ok {
 return errors.New("my error")
 }
 ...
 return nil
 }

This pattern allows interrupting the flow on any received error. But what if
there are errors that should be noted but still not fatal, for which the 
flow
should not be interrupted? Implementing such logic at each if statement 
would
make the code complex and the flow much harder to follow.

Package warnings provides the Collector type and a clean and simple pattern
for achieving such logic. The Collector takes care of deciding when to break
the flow and when to continue, collecting any non-fatal errors (warnings)
along the way. The only requirement is that fatal and non-fatal errors can 
be
distinguished programmatically; that is a function such as

 IsFatal(error) bool

must be implemented. The following is an example of what the above snippet
could look like using the warnings package:

 import "gopkg.in/warnings.v0"

 func isFatal(err error) bool {
 _, ok := err.(WarningType)
 return !ok
 }

 func myfunc(params) error {
 c := warnings.NewCollector(isFatal)
 c.FatalWithWarnings = true
 if err := c.Collect(doSomething()); err != nil {
 return err
 }
 if err := c.Collect(doSomethingElse(...)); err != nil {
 return err
 }
 if ok := doAnotherThing(...); !ok {
 if err := c.Collect(errors.New("my error")); err != nil {
 return err
 }
 }
 ...
 return c.Done()
 }

For an example of a non-trivial code base using this library, see
gopkg.in/gcfg.v1

Rules for using warnings

 - ensure that warnings are programmatically distinguishable from fatal
   errors (i.e. implement an isFatal function and any necessary error types)
 - ensure that there is a single Collector instance for a call of each
   exported function
 - ensure that all errors (fatal or warning) are fed through Collect
 - ensure that every time an error is returned, it is one returned by a
   Collector (from Collect or Done)
 - ensure that Collect is never called after Done

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

Re: [go-nuts] runtime.Caller ->

['Tim Hockin' via golang-nuts]

OK, is there ANY heuristic I can rely on find the "real" call frame?

On Mon, Aug 15, 2016 at 10:17 AM, Ian Lance Taylor  wrote:
> On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin  wrote:
>> Can I rely on "" not changing?
>
> I'm sorry, that's a hard question to answer, because other compilers
> do not use that string.
>
> There are no plans to change that string for the gc toolchain.
>
> Ian
>
>> On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Taylor  wrote:
>>> On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin  wrote:
 On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor  wrote:
> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin  wrote:
>> Edit:  It looks like this has more to do with being an interface
>> method than an embedded type.
>>
>> https://play.golang.org/p/I5XPdWR_O0
>
> Hmmm, you're right.  It only happens for a value method.

 Is this likely to change? I.e. can I hardcode "2" or should I actually
 write the loop to climb frames?  Is there a limit to the number of
 frames I should inspect before I give up?  Is the string
 "" stable?
>>>
>>> Well, unfortunately, it's different for different compilers.  I don't
>>> have a good answer here.  Except to say that you should never need
>>> more than 2 frames; it should never be the case that autogenerated
>>> code calls autogenerated code.
>>>
>>> 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] runtime.Caller ->

[Ian Lance Taylor]

On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin  wrote:
> Can I rely on "" not changing?

I'm sorry, that's a hard question to answer, because other compilers
do not use that string.

There are no plans to change that string for the gc toolchain.

Ian

> On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Taylor  wrote:
>> On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin  wrote:
>>> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor  wrote:
 On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin  wrote:
> Edit:  It looks like this has more to do with being an interface
> method than an embedded type.
>
> https://play.golang.org/p/I5XPdWR_O0

 Hmmm, you're right.  It only happens for a value method.
>>>
>>> Is this likely to change? I.e. can I hardcode "2" or should I actually
>>> write the loop to climb frames?  Is there a limit to the number of
>>> frames I should inspect before I give up?  Is the string
>>> "" stable?
>>
>> Well, unfortunately, it's different for different compilers.  I don't
>> have a good answer here.  Except to say that you should never need
>> more than 2 frames; it should never be the case that autogenerated
>> code calls autogenerated code.
>>
>> 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] goroutine 17 [syscall, 214 minutes, locked to thread]

[Ian Lance Taylor]

On Mon, Aug 15, 2016 at 1:21 AM,   wrote:
>
> In goroutine stack dump there is a dead lock.
>
> goroutine 17 [syscall, 214 minutes, locked to thread]:
> runtime.goexit()
> /root/go/src/runtime/asm_amd64.s:1998 +0x1
>
>
> No more information, just this. I don't know how to debug it. Somebody can
> help me?

That is not a deadlock, at least not a deadlock in the Go program.  It
is normal for a goroutine to be locked to a thread.  It can happen
because of cgo, or because the code called runtime.LockOSThread.  It
is not a problem.  The problem is that the thread has not made any
progress for 214 minutes; what that is depends on what it is doing.

If this is repeatable, can you get a stack trace with the environment
variable GOTRACEBACK=system ?

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: Wxwidgets ， Best GUI package for Golang！

[dfab1954]

Anyone have experience with this wxGo?   If so,  would you recommend for a 
commercial application?


On Sunday, August 14, 2016 at 3:06:38 PM UTC-4, unx...@gmail.com wrote:

> https://github.com/dontpanic92/wxGo
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] map values visibility when the map is populated in a goroutine yet used in another ?

[atd...@gmail.com]

Which I should have read more carefully.

Thank you!

On Monday, August 15, 2016 at 5:57:13 PM UTC+2, Jan Mercl wrote:
>
> On Mon, Aug 15, 2016 at 5:28 PM atd...@gmail.com  > wrote:
>
> > Is there an happen/before edge between spawning a goroutine and the map 
> operations ?
>
> Yes: https://golang.org/ref/mem#tmp_5
>
>
> -- 
>
> -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] map values visibility when the map is populated in a goroutine yet used in another ?

[Jan Mercl]

On Mon, Aug 15, 2016 at 5:28 PM atd...@gmail.com  wrote:

> Is there an happen/before edge between spawning a goroutine and the map
operations ?

Yes: https://golang.org/ref/mem#tmp_5


-- 

-j

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

[go-nuts] Re: goroutine 17 [syscall, 214 minutes, locked to thread]

[Lime Shi]

The go version is 1.6, and the full log is 
here, https://github.com/shiyanhui/dht/issues/6#issuecomment-239743849

在 2016年8月15日星期一 UTC+8下午11:01:35，Lime Shi写道：
>
> Hi, 
>
> In goroutine stack dump there is a dead lock. 
>
> goroutine 17 [syscall, 214 minutes, locked to thread]:
> runtime.goexit()
> /root/go/src/runtime/asm_amd64.s:1998 +0x1
>
>
> No more information, just this. I don't know how to debug it. Somebody can 
> help me?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] map values visibility when the map is populated in a goroutine yet used in another ?

[atd...@gmail.com]

Let's say I have a map in one goroutine that I populate.

Then I make a copy of this map by ranging over its keys/values and pass the 
variable holding the map copy to another goroutine.

Will the values in the copy be necessary visible to the last goroutine?

Is there an happen/before edge between spawning a goroutine and the map 
operations ?

Thanks.

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

[go-nuts] goroutine 17 [syscall, 214 minutes, locked to thread]

[lime . syh]

Hi, 

In goroutine stack dump there is a dead lock. 

goroutine 17 [syscall, 214 minutes, locked to thread]:
runtime.goexit()
/root/go/src/runtime/asm_amd64.s:1998 +0x1


No more information, just this. I don't know how to debug it. Somebody can 
help me?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Using go tool pprof with a header

[Victor Blomqvist]

My problem is this:
I have a go web app where I want to use the net/pprof package. The 
application itself is protected by a Apache server which keeps session, and 
sets a authorized header with the permissions the user should have. Then 
the go code will read the http header and depending on its value decide 
what Im allowed to look at. So let say to access /very-secret/x it will 
check that I have "superadmin" in the http header.

If I access /debug/pprof from a browser its all good, I have my session and 
the header will be set correctly by Apache. 

However, now I want to access /debug/pprof with `go tool pprof`. Is it 
possible to somehow call it with specific header? something like `go tool 
pprof -H webauth=superuser http://mypage`?

Thanks!
/Victor

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: const values of any types can't be compared to interface{} values?

[adonovan via golang-nuts]

On Monday, 1 August 2016 17:53:59 UTC+1, T L wrote:
>
>
> ex:
>
> package main
>>
>> func main() {
>> // error: illegal constant expression: *int == interface {}
>> _ = (*int)(nil) == interface{}(nil)
>> }
>
>
This is a compiler bug (https://github.com/golang/go/issues/16702).  Thanks 
for reporting it.

alan


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: golang.org/x/tools/go/loader: file names of parsed *ast.File

[adonovan via golang-nuts]

On Saturday, 13 August 2016 22:27:42 UTC+1, Paul Jolly wrote:
>
> On Saturday, 13 August 2016 21:58:37 UTC+1, Paul Jolly wrote:
>>
>> Am I missing something obvious here?
>>
>
> Please excuse the reply to self, but I have discovered what I was missing.
>
> For the sake of completeness, here is how the equivalent mapping is 
> achieved in golang.org/x/tools/go/loader world:
>
> import (
> "go/ast"
> "go/parser"
> "golang.org/x/tools/go/loader"
> )
>
>
> conf := loader.Config{
> ParserMode: parser.AllErrors | parser.ParseComments,
> Cwd:path,
> }
>
> ...
>
> conf.CreateFromFilenames(path, toParse...)
>
> prog, err := conf.Load()
> if err != nil {
> panic(err)
> }
>
> At this point conf.CreatePkgs (type []loader.PkgSpec) and prog.Created 
> (type []*loader.PackageInfo) correspond to each other.
>
> For each (loader.PkgSpec, *loader.PackageInfo) pairing, say pkgSpec and 
> pkgInfo, then pkgSpec.Filenames (type []string) and pkgInfo (type 
> []*ast.File) again correspond, which gives us the required mapping.
>

You can obtain the name of the file from which the *ast.File f was parsed 
using the following expression: prog.Fset.Position(f.Pos()).Filename

cheers
alan

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Wxwidgets ， Best GUI package for Golang！

[Peter Howard]

This shows how to make a standalone gui program with Go that uses html5 and 
Bootstrap css, but with all the resources compiled into the Go executable.

https://github.com/peterhoward42/godesktopgui

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