[go-nuts] Re: [golang-dev] does net.Conn.SetDeadLine makes syscall ?

[Dave Cheney]

In this case it looks like to be correct you must set the deadline
before reading from the network, and given reading from the network
can block, the cost of setting the deadline is small.

On Sat, 6 Apr 2019 at 21:47, Santhosh T  wrote:
>
> Hi Dave,
>
> my mistake, bufr is backed by net.Conn
>
> bufr := bufio.newReader(netConn)
> for numEntries >0 {
> numEntries--
> netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> entry.decode(bufr)
> process(entry)
> }
>
> thanks
> Santhosh
>
> On Sat, Apr 6, 2019 at 4:09 PM Dave Cheney  wrote:
>>
>> Thanks for the explanation. Two things
>>
>> 1. As this is a question about how to write a Go program, you should
>> move this thread to golang-nuts, golang-dev is only for the
>> development of Go.
>> 2. From the sample code you provided, there is no call to
>> netConn.Read, so setting the deadline is unnecessary. Please move the
>> discussion to golang-nuts and consider posting a larger piece of
>> sample code that shows the interaction with the network.
>>
>> On Sat, 6 Apr 2019 at 21:27, Santhosh T  wrote:
>> >
>> > Hi Dave,
>> >
>> > I am implementing raft protocol, where leader sends bunch of entries over 
>> > net.Conn to follower.
>> >
>> > leader can send large number of entries in single net.Conn.write.
>> > if follower does not hear from leader within configured heartbeatTimeout, 
>> > it has to start election.
>> >
>> > currently follower implementation is something like this:
>> >
>> > for numEntries >0 {
>> > numEntries--
>> > netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
>> > entry.decode(bufr)
>> > process(entry)
>> > }
>> >
>> > if numEntries is say 1, i would be spending significant time in 
>> > makeing syscalls for setReaddeadline
>> > btw, i have not done any benchmark yet. I asked the question our of 
>> > curiosity.
>> >
>> > What i was planning to do to optimize it is:
>> >  as i am reading entry from bufr, in most cases the entry might be 
>> > already in the buffer. in such case
>> > i can avoid setting readDeadline. so set deadline, only when bufr calls 
>> > read on underlaying reader.
>> >
>> > hope i am clear...
>> >
>> > thanks
>> > Santhosh
>> >
>> > On Sat, Apr 6, 2019 at 2:53 PM Dave Cheney  wrote:
>> >>
>> >> Hi Santhosh,
>> >>
>> >> Calling SetDeadline does not _directly_ trigger a syscall, but it does
>> >> have several other observable side effects. What is the problem you
>> >> are facing that lead you to ask this question?
>> >>
>> >> Thanks
>> >>
>> >> Dave
>> >>
>> >> On Sat, 6 Apr 2019 at 20:20, Santhosh Kumar T  
>> >> wrote:
>> >> >
>> >> > does net.Conn.SetDeadLine makes syscall ?
>> >> >
>> >> > thanks
>> >> > santhosh
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google 
>> >> > Groups "golang-dev" group.
>> >> > To unsubscribe from this group and stop receiving emails from it, send 
>> >> > an email to golang-dev+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] Is this implementation of weak pointers safe?

[Dave Cheney]

Please don’t take os.File as justification, it’s one of the few uses of a 
finaliser in the std lib. If it were being written today I would argue that 
instead of silently closing the file, it should panic if the resource falls out 
of scope unclosed. 

As always, remember that finalisers are not guaranteed to run as they are tied 
to the gc cycle. In a well tuned application a finaliser can easily be delayed 
until the resource they are meant to mediate has been exhausted by 
overconsumption. 

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Canonical module arrangement in a multi-language project.

[Dave Cheney]

With the modules support added to Go 1.11 this should be straight forward.

Create a subdirectory for your go code inside your working copy; change 
into that and run 

go mod init example.com/your/repo

Where example.com/your/repo is a placeholder for the _prefix_ you want to 
apply to all of the packages inside your module, replace it with whatever 
makes sense for your company and project.

>From then on, your Go code can be built by changing into that subdirectory 
and running go build.

Dave

On Friday, 28 September 2018 09:48:54 UTC+10, Ian Bruene wrote:
>
>
> I am working on setting up NTPsec's build system to properly handle Go 
> code, and can only find limited information of the preferred way of 
> structuring the directory tree.
>
> Forcing the entire project into GOPATH would be sloppy and a giant kluge 
> all around.
>
> Placing the go code in a folder with no special structure (as we currently 
> do with Python), and then using relative module paths appears to work in 
> testing. However from what I gather relative module paths are a deeply 
> unkosher feature that should not be depended on.
>
> The only other way I see is simply to replicate a GOPATH directory 
> structure within the project and have the build tools define a custom 
> GOPATH. This forces a somewhat clunky directory structure on the project 
> with an otherwise unneeded src/ directory. A possible workaround would be 
> to structure the code as with Python, then have the build system copy the 
> files into a src/ directory under build/ and run with that GOPATH.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: idiomatic code to find, if executable exists in golang

[Dave Cheney]

My suggestion is, rather than seeing if an executable exists, then executing 
it. Just execute it and if there is an error just pass it back to the caller. 
The difference between I tried to run the program but it wasn’t found and I 
tried to run the program but it failed for some reason shouldn’t matter. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] idiomatic code to find, if executable exists in golang

[Dave Cheney]

Are you able to modify the original question. Why do you need to know if a 
binary exists? Presumably so you can execute it. If so then you can modify the 
original request and make the problem more tractable. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] The If Statement: Switches are better except for a single condition (change my mind)

[Dave Cheney]

On Tuesday, 25 September 2018 10:22:52 UTC+10, Louki Sumirniy wrote:
>
> Using named return values and this construction you can drop all those 
> returns in each case block to outside the block. You only need to spend an 
> extra line if you have to break out of it by return or break.
>

Go is not a language that trades clarity for brevity. 

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

[Dave Cheney]

Additions to the language are handled via a written proposal process.

https://github.com/golang/proposal/blob/master/README.md

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Using modules with go test ./...

[Dave Cheney]

Sorry, I probably wasn’t clear or didn’t understand that you were asking. I saw 
that you said GOPATH is not set, it because your code is inside $HOME/go, 
because of the rules of the default gopath introduced in 1.8, gopath IS 
actually set. 

To be extra sure, when I’m playing with go modules I use a different directory 
for my experiments, ~/devel in my case, to avoid conflicts with explicit or 
implicit gopaths

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Using modules with go test ./...

[Dave Cheney]

I think because GOPATH is not set it is defaulting to $HOME/go (see Go 1.9 
release notes, from memory). Try moving your code to another folder.



On Friday, 21 September 2018 05:21:32 UTC+10, John wrote:
>
> Just started playing with modules recently. Having an issue I don't 
> understand, wondering if anyone has seen it, the few references to the 
> error did not provide anything I saw relevant for what I'm doing.
>
> given a directory structure such as:
>
> /go/
>   src/
>   pkg/
>   bin/
>
> GOPATH NOT SET
> GO111MODULE = on
>
> If the working directory is:
> /go/src/
>
> go test ./...
>
> *Results in:*
> go: cannot determine module path for source directory /home/jdoak/go/src 
> (outside GOPATH, no import comments)
>
> This also occurs if I do:
>
> go test subdir/subdir/packagedir/...
>
> But it will work if I do:
>
> working directory: /go/src/subdir/subdir/packagedir/
>
> go test ./...
>
> I'm sure I'm doing something wrong.  If someone could enlighten 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] Re: Local variable escapes to heap

[Dave Cheney]

If you pass more -m's to the compiler it will explain why

Daves-MacBook-Pro(~/src) % go build -gcflags=-m=2 buffer.go
# command-line-arguments
./buffer.go:12:6: cannot inline main: function too complex: cost 108 
exceeds budget 80
./buffer.go:15:21: buffer escapes to heap
./buffer.go:15:21:  from Builder literal (struct literal element) at 
./buffer.go:15:14
./buffer.go:15:21:  from b (assigned) at ./buffer.go:15:4
./buffer.go:15:21:  from b.meta.Index() (receiver in indirect call) at 
./buffer.go:18:15
./buffer.go:13:6: moved to heap: buffer
:1: leaking param: .this
:1:  from .this.Index() (receiver in indirect call) at 
:1

I recommend raising a bug https://golang.org/issue/new if you feel the 
compiler could prove that main.buffer did not escape.

On Thursday, 20 September 2018 12:39:33 UTC+10, Alex Bahdanau wrote:
>
> Hi all,
>
> I've read a lot about escape analysis in golang, but still couldn't find 
> an answer to this question
> here is the sample :
>
> package main
>
> type IMeta interface {
> Index() int
> }
>
> type Builder struct {
> buf  []byte
> meta IMeta
> }
>
> func main() {
> var buffer [512]byte
>
> b := Builder{buffer[:0], nil}
>
> if b.meta != nil {
> b.meta.Index()
> }
> }
>
> escape analyzer says:
> .\main.go:15:21: buffer escapes to heap
> .\main.go:13:6: moved to heap: buffer
> :1:0: leaking param: .this
>
> Could anyone please clarify why local buffer escapes here?
>
> Thx in advance
>
>

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

Re: [go-nuts] Re: I am not in favor of generics.

[Dave Cheney]

Thank you to everyone who has contributed to this thread. 

It is time for everyone to take a break for 48 hours. After this time if you 
feel strongly that there is a point which you must continue to debate please do 
so, but be mindful that many words have already been spent in this thread and 
the points of view expressed are unlikely to change. 

Thank you

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Interaction of signals with defer

[Dave Cheney]

profile.Start() installs a ^C handler to try to make sure profiles are properly 
flushed to disk before your process goes to the bit bucket in the sky. 

> On 19 Sep 2018, at 12:23, andrey mirtchovski  wrote:
> 
> you're talking about https://github.com/pkg/profile, presumably. while
> i did find that fairly quickly and it appears to be very useful, it
> wasn't immediately obvious that it would solve my particular issue.
> unfortunately we're also averse to importing third-party packages
> without additional vetting. i ended up using the http/pprof package
> from the stdlib which gave me what i wanted.
>> On Tue, Sep 18, 2018 at 7:55 PM Dave Cheney  wrote:
>> 
>> pkg /profile will do the paperwork for you so ^C works when profiling.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and 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] Interaction of signals with defer

[Dave Cheney]

pkg /profile will do the paperwork for you so ^C works when profiling. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Tour Of go Page 8 in Basics does not work.

[Dave Cheney]

It looks like the playground has cached this error. Please raise an issue, 
https://golang.org/issue/new and someone with admin powers will delete the 
faulty entry.

On Tuesday, 18 September 2018 17:03:00 UTC+10, Reinhard Luediger wrote:
>
> Hey List,
>
> is this the right place to get the tour of go fixed? The example on the 
> following page https://tour.golang.org/basics/8 terminates unexpected 
> with error  process took to long.
>
> kind regards
>
>
> Reinhard Lüdiger
>

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

[Dave Cheney]

Assuming you are using the master branch of go-ifps-api, this request is 
failing because RequestBuilder.shell is nil. This could happen for a 
variety of reasons, perhaps the lack of error handling in NewLocalShell. 

I recommend you handle this with the ipfs developers on 
https://github.com/ipfs/go-ipfs-api/issues/125


On Tuesday, 18 September 2018 01:42:26 UTC+10, akshita babel wrote:
>
> When I am running a program which is for a web response I am getting a run 
> time error as follows:
> http: panic serving 127.0.0.1:43802: runtime error: invalid memory 
> address or nil pointer dereference
> goroutine 6 [running]:
> net/http.(*conn).serve.func1(0xc4200a4a00)
> /usr/lib/go-1.10/src/net/http/server.go:1726 +0x11b
> panic(0x9b5360, 0xd99230)
> /usr/lib/go-1.10/src/runtime/panic.go:502 +0x24a
> github.com/ipfs/go-ipfs-api.(*RequestBuilder).Send(0xc4201740a0, 
> 0xb95c60, 0xc420022100, 0x0, 0x0, 0x0)
> The code of main file is as follows:
> func main() {
>
> router := httprouter.New()
> router.RedirectTrailingSlash = true
> c := cors.New(cors.Options{
>   AllowedOrigins:   []string{"*"},
>   AllowedMethods:   []string{"GET", "POST", "OPTIONS", "Authorization"},
>   AllowedHeaders:   []string{"*"},
>   AllowCredentials: true,
> })
> router.GET("/create", StoreAndGetHash)
> router.GET("/read/:hashvalue", GetFile)
> router.GET("/appdata/:appID", ReadPeer)
> router.GET("/update", UpdateAndGetHash)
> router.GET("/createdir", GetDir)
> router.GET("/newkey", GetNewKey)
>
> log.Fatal(http.ListenAndServe(":3000", c.Handler(router)))
>
> }
>
> I am working on ubuntu
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Periodic task when time.Ticker and time.Sleep are pretty expensive

[Dave Cheney]

I've confirmed this uses 14% on a random OS X machine. Please raise a bug, 
https://golang.org/issue/new

On Monday, 17 September 2018 14:29:44 UTC+10, Robert Engels wrote:
>
> For reference, similar code under Java consumes 2.5 % CPU.
>
> I tested the Go code under OSX, and it is roughly 10%, which seems to be 
> very high. Might be because the “context switching” is performed/attributed 
> to the process (since it is internal), where for other systems it is the 
> system call only, and so most of the cost is attributed to system/kernel 
> activity.
>
>
>
> On Sep 16, 2018, at 8:47 AM, Lei Ni > 
> wrote:
>
> import (
>   "time"
> )
>
> func main() {
>   ticker := time.NewTicker(time.Millisecond)
>   defer ticker.Stop()
>   for range ticker.C {
>   }
> }
>
>
>

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

[go-nuts] Re: Ambiguity in generic interfaces

[Dave Cheney]

I think D solved this quite well

https://dlang.org/spec/template.html

In your example this might become

type Foo(type T) interface {}
type Bar(type T) interface {

Foo!(T)

}


The exclamation point makes it clear this is the application of a T to the 
existing interface type Foo(type T).

On Friday, 14 September 2018 11:32:13 UTC+10, Patrick Smith wrote:
>
> (Apologies if this has already been brought up; I don't remember seeing 
> it.)
>
> While writing a bit of sample generics code, I ran into a nasty little 
> ambiguity:
>
> type Foo(type T) interface {}
> type Bar(type T) interface {
>
> Foo(T)
>
> }
>
>
> Does this embed the interface Foo(T) into Bar(T), or does it add to the 
> method set of Bar(T) a method named Foo taking a parameter of type T?
>

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

[go-nuts] Re: go 1.11 and XP

[Dave Cheney]

Go 1.11 doesn't support XP. We don't test on XP and won't fix bugs reported 
against XP systems any more. If it's working for you, great!, but if it 
breaks, you get to keep both pieces.

Dave

On Tuesday, 11 September 2018 05:05:23 UTC+10, wilk wrote:
>
> Hi, 
>
> Go 1.11 is not more compatible with Windows XP, but is it the compilator 
> or the executable or both ? 
>
> I just tried an app (build on linux) and doesn't see any failure... 
>
> -- 
> William 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Opening brace can't be placed on a separate line killing the language for me

[Dave Cheney]

I'm sorry you feel this way.

The reality is that the format of the language is not something that is 
going to change. I personally don't like that I cannot write one liner 
functions on one line because of gofmt's preference for reformatting the 
same function over three lines -- but, I put this aside because of the 
wider benefits of having a _single_ coding style that is enforced across 
all Go code (even if someone doesn't use it, I can pass their code though 
gofmt before reading it) which makes, to some degree, the syntax melt into 
the background.

I'd encourage you to persist with Go beyond the minor syntactic issues.

Dave

On Saturday, 8 September 2018 18:09:31 UTC+10, Mohamed yousry wrote:
>
> I don't know about you guys but for me format and readability is 
> everything so when I first heard about the language that Care about that ,I 
> was interested in it , after spending 2 days learning the language  I 
> decided that I have to put my new skill under the test to only find out I 
> can't tried to Google the error andd I was shocked when I found out that I 
> can't style my code the way I want. 
> Is it that hard for them to add some kind of exception for that kind of 
> problem. 
> I wish they really fix it or if there any fix please point it out . 
>  For me the language is Dead now it was a wasted time 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Performance regression of HTTP requests since Go 1.11

[Dave Cheney]

This looks like an issue related to dns resolution in your environment with go 
1.11. 

I suggest building a reproducer using the net,Lookup* functions as the net/http 
package is not the problem. Once you have a reproduction case, please log an 
issue golang.org/issue/new 

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] Performance regression of HTTP requests since Go 1.11

[Dave Cheney]

Can you post the output from httpstat?

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

[Dave Cheney]

Hi John

Unless the variables a1, a2, a3, b1, ... are defined in the same package as 
your showBoard function, ie

var a1, a2, a3 int

then Go will report that they are undefined. Unlike some other languages, 
Go does not implicitly define a variable on first occurance. All variables 
must be defined before they are used either at the package level, as 
parameters to a function, or local variables.

If you are still stuck please try to provide a complete program, 
play.golang.org is good for this, that shows the problem you are having and 
provides a way for someone else to replicate it.

Thanks

Dave

On Monday, 3 September 2018 13:42:12 UTC+10, John wrote:
>
> I am currently making a program with variables, but when I tried to run it 
> says that the variables are not defined. So below are may code for using 
> the variable:
>
> func showBoard()  {
>  fmt.Println("  1 2 3")
>  fmt.Println("a", a1, a2, a3)
>  fmt.Println("b", b1, b2, b3)
>  fmt.Println("c", c1, c2, c3)
> }
> PS: I used the newest go version and the atom compiler
>
>   
> 
>Sincerely
>   
> 
>  John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Does runtime.RaceDisable not work in non-std library ?

[Dave Cheney]

Hi,

Can you please do two things to help with this error report.

1. Please include the entire data race report -- we need this to match up 
the line with the source code you've provided in the gist
2. Please double check that you are not copying a your sync.Pool type by 
value, this can happen if you have a type declared on sync.Pool, not 
*sync.Pool, or it could happen if you do something like this

var x sync.Pool
y := x

Thanks

Dave

On Friday, 24 August 2018 13:46:10 UTC+10, nea...@gmail.com wrote:
>
> Hi lan,
>
> The sync.Pool has memory accesses in per-p private storage. Why it not 
> reports `DATA RACE`, but it reports when I copy those code outside stdlib?
> I'm confused about this, or there is something wrong in 
> https://gist.github.com/lrita/efa8c4ae555b4b7cceee29b4ed819652 
> Thanks.
>
> 在 2018年8月24日星期五 UTC+8上午4:36:06，Ian Lance Taylor写道：
>>
>> On Thu, Aug 23, 2018 at 12:43 AM,   wrote: 
>> > package main 
>> > 
>> > import "runtime" 
>> > 
>> > var a int 
>> > 
>> > func calc() { 
>> > for i := 0; i < 10; i++ { 
>> > go func() { 
>> > for { 
>> > runtime.RaceDisable() 
>> > a++ 
>> > runtime.RaceEnable() 
>> > } 
>> > }() 
>> > 
>> > } 
>> > } 
>> > 
>> > func main() { 
>> > calc() 
>> > } 
>> > 
>> > go run -race a.go 
>>
>> Thanks for the example.  As the docs for runtime.RaceDisable say, it 
>> only applies to synchronization events, like mutex locks.  It doesn't 
>> apply to memory accesses. 
>>
>> Ian 
>>
>>
>> > 在 2018年8月22日星期三 UTC+8下午10:34:35，Ian Lance Taylor写道： 
>> >> 
>> >> On Wed, Aug 22, 2018 at 3:25 AM,   wrote: 
>> >> > 
>> >> > When I copy the sync.Pool's source code in a repo, and using 
>> >> > `//go:linkname` 
>> >> > link those runtime functions manually. 
>> >> > When I run `go test -race`, it reports `DATA RACE`. 
>> >> > But the sync.Pool with the same test case does not report  `DATA 
>> RACE`. 
>> >> > 
>> >> > Does runtime.RaceDisable not work in non-std library ? 
>> >> 
>> >> It should work.  I think you'll have to show us your 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...@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] [Bug?] Error when running "go tool cover" on package name contains dot

[Dave Cheney]

Thanks for confirming this is a regression.

On 20 August 2018 at 18:41, Shulhan  wrote:
> On Sun, 19 Aug 2018 16:13:00 -0700 (PDT)
> Dave Cheney  wrote:
>
>> Point of clarification, the package name doesn’t contain a dot, that
>> is not permitted by the syntax of the package declaration. The name
>> of the directory you placed the file in ends in .go and this is
>> confusing the tool.
>>
>
> Sorry, I write a misleading words in previous message.  I wrote
> "package name" where it should be "directory name".
>
>> If this is a regression from an earlier version of Go, please raise
>> an issue.
>>
>
> There is no problem when tested with Go v1.10.3.  I will report it
> later, thank you for checking this.

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

[go-nuts] [Bug?] Error when running "go tool cover" on package name contains dot

[Dave Cheney]

Point of clarification, the package name doesn’t contain a dot, that is not 
permitted by the syntax of the package declaration. The name of the directory 
you placed the file in ends in .go and this is confusing the tool. 

If this is a regression from an earlier version of Go, please raise an issue. 

Thanks

Dave

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

[Dave Cheney]

Thinking some more about the problem, I think your solution of reserving 
some of the deadline to handle the spanner log in the error case sounds 
like the best answer. However it does lead to questions like, if you 
reserve n seconds to log to spanner in the error path, and it takes longer 
than n, what happens to the error, is it dropped?

On Thursday, 16 August 2018 14:44:08 UTC+10, Dave Cheney wrote:
>
> What would happen if you write the error to spanner with a setting 
> context.Backgrond(), ie, no deadline? 
>
> On 16 August 2018 at 13:57, Robert Bartoszynski  wrote: 
> > Thanks. Perhaps an alternative would be for me to create a child context 
> > with a deadline of (context - x seconds) and pass that to OtherService, 
> with 
> > the expectation that there should be x seconds left over for the write 
> to 
> > spanner. 
> > 
> > On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote: 
> >> 
> >> 
> >> 
> >> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote: 
> >>> 
> >>> As an example: 
> >>> Client calls MyService with a deadline of 10 seconds. 
> >>> MyService calls OtherService as part of responding. However, the call 
> to 
> >>> OtherService times out due to the deadline in 10 seconds. 
> >>> MyService tries to log the error to Spanner; but it's still using that 
> >>> context deadline which expired. 
> >>> 
> >>> Is there a way to get a new context with an extended deadline? Are 
> there 
> >>> any issues with that approach? 
> >> 
> >> 
> >> Sure, just call context.WithDeadline(context.Background()) and use that 
> >> instead 
> >> 
> >>  The difficulty is you want the deadline of this new context to live 
> >> beyond its parent. Logically it feels like this new context is 
> subordinate 
> >> to the previous, but by design we've said that the new context is _not_ 
> >> subordinate -- the deadline does not apply to it. I think you need to 
> >> address this incongruousness before proceeding. 
> >> 
> >>> 
> >>> 
> >>> 
> >>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com 
> wrote: 
> >>>> 
> >>>> I'm working on a service that write some log info to spanner when 
> it's 
> >>>> done responding to a request. 
> >>>> However, the service uses the context's deadline to write to spanner, 
> so 
> >>>> if the deadline expires due to some long running RPC, the write to 
> spanner 
> >>>> fails (because the deadline expired), and we don't get any log info. 
> >>>> 
> >>>> What's the best practice for dealing with this situation? 
> >> 
> >> -- 
> >> 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/TUicHyvYNX0/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.

Re: [go-nuts] Re: Extending deadline for logging

[Dave Cheney]

What would happen if you write the error to spanner with a setting
context.Backgrond(), ie, no deadline?

On 16 August 2018 at 13:57, Robert Bartoszynski  wrote:
> Thanks. Perhaps an alternative would be for me to create a child context
> with a deadline of (context - x seconds) and pass that to OtherService, with
> the expectation that there should be x seconds left over for the write to
> spanner.
>
> On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote:
>>
>>
>>
>> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>>>
>>> As an example:
>>> Client calls MyService with a deadline of 10 seconds.
>>> MyService calls OtherService as part of responding. However, the call to
>>> OtherService times out due to the deadline in 10 seconds.
>>> MyService tries to log the error to Spanner; but it's still using that
>>> context deadline which expired.
>>>
>>> Is there a way to get a new context with an extended deadline? Are there
>>> any issues with that approach?
>>
>>
>> Sure, just call context.WithDeadline(context.Background()) and use that
>> instead
>>
>>  The difficulty is you want the deadline of this new context to live
>> beyond its parent. Logically it feels like this new context is subordinate
>> to the previous, but by design we've said that the new context is _not_
>> subordinate -- the deadline does not apply to it. I think you need to
>> address this incongruousness before proceeding.
>>
>>>
>>>
>>>
>>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>>>>
>>>> I'm working on a service that write some log info to spanner when it's
>>>> done responding to a request.
>>>> However, the service uses the context's deadline to write to spanner, so
>>>> if the deadline expires due to some long running RPC, the write to spanner
>>>> fails (because the deadline expired), and we don't get any log info.
>>>>
>>>> What's the best practice for dealing with this situation?
>>
>> --
>> 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/TUicHyvYNX0/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: Extending deadline for logging

[Dave Cheney]

On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>
> As an example:
> Client calls MyService with a deadline of 10 seconds.
> MyService calls OtherService as part of responding. However, the call to 
> OtherService times out due to the deadline in 10 seconds.
> MyService tries to log the error to Spanner; but it's still using that 
> context deadline which expired.
>
> Is there a way to get a new context with an extended deadline? Are there 
> any issues with that approach?
>

Sure, just call context.WithDeadline(context.Background()) and use that 
instead

 The difficulty is you want the deadline of this new context to live beyond 
its parent. Logically it feels like this new context is subordinate to the 
previous, but by design we've said that the new context is _not_ 
subordinate -- the deadline does not apply to it. I think you need to 
address this incongruousness before proceeding.
 

>
>
> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>>
>> I'm working on a service that write some log info to spanner when it's 
>> done responding to a request. 
>> However, the service uses the context's deadline to write to spanner, so 
>> if the deadline expires due to some long running RPC, the write to spanner 
>> fails (because the deadline expired), and we don't get any log info.
>>
>> What's the best practice for dealing with this situation?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Cross-compiled program for Raspberry Pi crashes

[Dave Cheney]

I don’t think that will help. The problem is not cross compilation. The problem 
is when run in a 32bit environment the offset of that field is not guaranteed 
to be aligned to 8 bytes. You’ve got a 50/50 chance that each allocation will 
be properly aligned. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Cross-compiled program for Raspberry Pi crashes

[Dave Cheney]

No, it’s not a cross compilation issue. Well, yes and no, the rpi is a 32 bit 
platform so some structures have a different size causing the offset of the 
field to be 32 but aligned, not the required 64 bit aligned. 

The play example shows the address of the field is not aligned on a 8 byte 
boundary. 

Short version, move the field to the top of the structure which is guaranteed 
to be properly aligned. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Cross-compiled program for Raspberry Pi crashes

[Dave Cheney]

This is likely to be 
issue https://github.com/golang/go/issues/599, 
https://play.golang.org/p/zZm-6zWwFoi

On Monday, 13 August 2018 01:29:43 UTC+10, Stephan Mühlstrasser wrote:
>
> Hi,
>
> I'm developing my first Go program that is supposed to upload files into a 
> Google Cloud Storage bucket from a Raspberry Pi 1. It uses the 
> https://github.com/blackjack/webcam library to grab a picture from an USB 
> camera.
>
> I can compile the program on the Raspberry Pi itself with Go 1.7.4 that 
> comes with Raspbian, and then it works as expected. However compilation on 
> the Raspberry Pi is slow and it even sometimes fails because of memory 
> shortage. Therefore I want to cross-compile on Windows.
>
> When I cross-compile the exact same source on Windows for ARM with Go 
> 1.10.3, then this binary crashes at some point on the Raspberry Pi with a 
> segmentation fault:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x11520]
>
>
> goroutine 8 [running]:
> sync/atomic.addUint64(0x1236210c, 0x8a75f371, 0xa3f9cbd6, 0xdcd30e9, 
> 0xda39e1c1)
> C:/Go/src/sync/atomic/64bit_arm.go:31 +0x4c
> go.opencensus.io/trace.(*defaultIDGenerator).NewSpanID(0x123620f0, 0x0, 
> 0x0)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:483 +0x50
> go.opencensus.io/trace.startSpanInternal(0x123202d0, 0x22, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0, 0x0, ...)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:196 +0x7c
> go.opencensus.io/trace.StartSpan(0x4c4128, 0x12795c60, 0x123202d0, 0x22, 
> 0x123798ec, 0x2, 0x2, 0x10, 0x40, 0x58f74)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:162 +0x128
> ...
>
> I'm a Go newbie, and therefore I'm not sure how to interpret this. May 
> this be a bug in the Go cross-compiler, or may this be a bug in the program 
> that only manifests itself when the program is cross-compiled with the 
> newer compiler on Windows?  How can I analyze this?
>
> Thanks
> Stephan
>

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

Re: [go-nuts] How to signal(sigint) blocking goroutine

[Dave Cheney]

The context value you pass into record isn't used and running record in its 
own goroutine doesn't really add anything because the main goroutine just 
waits for the other goroutine to exit. The exit the second goroutine will 
be at least 1 second, but could be much longer.

On Saturday, 11 August 2018 12:54:08 UTC+10, natea...@gmail.com wrote:
>
> Thanks for all the comments.  I did finally figure it out.  
> https://play.golang.org/p/ghCT6DCDLJz
>
> On lines 69-70 changed that code from and exec.Command to exec.Start 
> allowing me to sleep for the desired amount of time and then signal(sigint) 
> the command via cmd.Process.Signal(syscall.SIGINT) 
>
> Nate
>
> On Thursday, August 9, 2018 at 9:51:53 PM UTC-4, natea...@gmail.com wrote:
>>
>> https://play.golang.org/p/mr58JS4WsJV
>>
>> Okay, I realize now that I didn't do a very good job in my first post of 
>> explaining my problem, so I'll trying again.  In the above code I need to 
>> signal(sigint or sigterm) the exec.CommandContext on line 69 that is 
>> blocking so it will stop and finish the goroutine.  The goal behind the 
>> code is to set a record duration and then stop the blocking command after 
>> the record timer has been met and exit the goroutine normally.  So far I 
>> haven't been able to figure out how to signal the command to stop.  I have 
>> two tuners that can be recording a the same time, so I need them running in 
>> goroutines so the main thread can do other things.  I read through the 
>> context package that you recommended, but still can't get it to work. 
>>
>> Thanks
>>
>> On Wednesday, August 8, 2018 at 12:20:11 AM UTC-4, Ian Lance Taylor wrote:
>>>
>>> On Tue, Aug 7, 2018 at 7:02 PM,   wrote: 
>>> > 
>>> > https://play.golang.org/p/d5n9bYmya3r 
>>> > 
>>> > I'm new to the go language and trying to figure out how to sigint a 
>>> blocking 
>>> > goroutine.  in the playground code I included an infinite for loop to 
>>> > simulate the blocking. In my real world use the for block would be a 
>>> long 
>>> > running file save from an external device.  I appreciate any advice or 
>>> > direction that is given. 
>>>
>>> I'm not sure quite what you mean, but in general you can not send a 
>>> signal to a goroutine in Go.  Goroutines are not threads.  If you want 
>>> a goroutine to be interruptible, you must write the goroutine to check 
>>> whether something is trying to interrupt it; the standard library's 
>>> "context" package is often used for this purpose. 
>>>
>>> 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] go go1.10.3 fatal error: runtime: netpoll failed

[Dave Cheney]

As Ian explained on the GitHub issue you raised, RHEL5 is not supported by any 
version of Go - the 2.6.18 kernel is below our minimum requirements. 

Dave

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

[Dave Cheney]

So that it can be used interchangeably with *bufio.Writer. 

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

[go-nuts] Re: How should I avoid - literal copies lock value from

[Dave Cheney]

Pass a pointer, *Set into your Diff method. 

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

Re: [go-nuts] Performance hit when using goroutine

[Dave Cheney]

The execution tracer will show this as it tracks resources that goroutines 
block on. 

Seriously I’m just going to keep suggesting the execution tracer until you try 
it :)

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

[go-nuts] Performance hit when using goroutine

[Dave Cheney]

The best tool to investigate this problem is the execution tracer. It will show 
you the activity of goroutines over time making is easy to spot contention. 

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

[go-nuts] Re: How can I get the last followed URL use http.Client on 302 Redirections?

[Dave Cheney]

Please keep in mind that the Via header is supplied by he client (the browser) 
and there is not requirement that it maintains the full chain of custardy of 
all the urls it has passed though, nor is there any way for Go to know nor 
enforce that this list remains accurate. Sorry. 

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

Re: [go-nuts] Re: Go license and fitness for purpose

[Dave Cheney]

Thank you to all those who contributed to this thread. While many Go 
programs are written under open source licences, and many Go programmers 
contribute to open source in a professional or personal capability, it is 
now time to bring the discussion to a close as this thread has moved 
outside the scope of this mailing list.

Please feel free to continue this discussion in other forums.

Thanks

Dave

On Friday, 18 May 2018 05:39:59 UTC+10, matthe...@gmail.com wrote:
>
> Thanks for responding Michael.
>
> "decorative item not to be used off-road, in uneven terrain, or relied 
>> upon as protection in case of vehicle roll."
>
>
> The sticker I’ve been looking at says something like “modifying or 
> attaching anything to this ROPS will compromise the structure and may cause 
> injury or death” and I had a relative roll a tractor last year but is 
> luckily ok.
>
> I understand being conservative for the courts, but GCC and Go can make 
> programs for computers that can do safety applications reliably. People 
> maybe do with GCC derivatives. People do with Ada or C (and Go maybe is 
> less mistake-prone than C at the language level).
>
> Leveraging the work of an open or free project and contributing back 
> improvements found in testing seems like a good idea to me for liable 
> ventures and for the reliability of minimal liability uses that Google does 
> with Go and maybe GCC. I don’t think these compiler projects should take on 
> unnecessary liability, but one thing that can be done is to be sure there 
> aren’t any intentional mistakes, backdoors, or practical jokes as allowed 
> under the licenses. I'd like to guarantee that to liable ventures and it's 
> a free win for general purpose computing anyway.
>
> Matt
>
> On Thursday, May 17, 2018 at 12:18:30 PM UTC-5, Michael Jones wrote:
>>
>> perhaps some context will make this clearer. no reference is being made 
>> to any actual persons or events.
>>
>> 1. It is the observed habit of people (plaintiff's) bring suit in court 
>> when something goes wrong. 
>> Ex: airplane crash, dark spot on potato chip, food is too hot, etc.
>>
>> 2. Plaintiff's attorneys have developed the habit of including everyone 
>> possible in the "bag guy" list; this creates a kind of mutual fund where 
>> everyone can settle for $10,000 and that, multiplied by 100 defendants, is 
>> $1M. The attorney gets 1/3 of that, so attorneys drive nice cars and fly 
>> first class.
>> Ex: car accident with fire.: sue the car company, the airbag company, the 
>> brake pad company, the glass company, the bumper designer, , the gas 
>> station, the gas transport truck, the oil refinery,...,the tire company, 
>> the person who designed the tire treads, etc.
>>
>> 3. After 60+ years of this, everyone who is wise to the situation sells 
>> retail products that specifically disclaim every possible dangerous use, 
>> and as many kinds of critical or life-safety misuse as can be foreseen, and 
>> wholesale products where every possible liability passes to the purchaser 
>> as a condition of sale. 
>> Ex: "You agree to not use the APIs for any activities where the use or 
>> failure of the APIs could lead to death, personal injury, or environmental 
>> damage (such as the operation of nuclear facilities, air traffic control, 
>> or life support systems)."
>>
>> 4. After 40+ years of open source having an observable footprint, open 
>> source entities, corporate contributors, and individuals have found that 
>> this style of "universal disclaimer" is an important defensive bulwark. 
>> Most people would not want to lose their house and savings as the result of 
>> contributing code to a matrix library that happens to be used in the 
>> science payload of a space project where the rocket engines explode on 
>> launch and the resulting fires and fumes cause problems for miles around 
>> resulting in a class-action suit for much of Florida. (crazy made-up 
>> example but perhaps it makes clear the idea of minimizing exposure to legal 
>> risks associated in no logical way with individual action.)
>>
>> This is the context in which various excuse-laden, 
>> suitability-disclaiming, crazy-seeming license agreements arise.
>>
>> As a real example, but with the name removed, I once saw in a parking lot 
>> a new pickup truck made by a well-known Japanese car manufacturer. It had a 
>> shiny chrome tubular framework rising up from the bed of the truck just 
>> behind the cab. The framework had lights attached. It have the truck a 
>> tough, off-road character. I said to my wife, "wow, that's quite the 
>> roll-bar for a little truck. Look how thick the tubes are." She said, there 
>> is a sticker on it what does it say. We looked, it read:  "decorative item 
>> not to be used off-road, in uneven terrain, or relied upon as protection in 
>> case of vehicle roll."
>>
>> That is the real world of litigious people, 1/3 hungry attorneys, and 
>> juries that like to "do something" when there is a victim.

Re: [go-nuts] Re: go 1 on Ubuntu 18.04

[Dave Cheney]

Top tip: you never need to set GOROOT. Please don’t set GOROOT, it’ll just 
cause confusing errors for you in the future. 

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

[Dave Cheney]

This is issue https://github.com/golang/go/issues/22579

On Tuesday, 1 May 2018 20:38:26 UTC+2, xiof...@gmail.com wrote:
>
> I just discovered a problem running/compiling files that are 
> accessed/backed up by windows OneDrive
>
> (don't know when this started - worked a couple of months ago..)
>
> So I have a simple go file at
>
> C:\Users\xiool\OneDrive\go ie test.go
>
> At the command line all variants of
>
> go run C:/Users/xiool/OneDrive/go/test.go
>
> give the error
>
> package main: cannot find package "." in:
> C:\Users\xiool\OneDrive\go
>
> The files are stored offline on the computer, and simple replacements such 
> as 
>
> notepad.exe C:/Users/xiool/OneDrive/go/test.go
>
> Work as expected
>
>
> Build/install etc also fail. No issues outside the OneDrive directory. And 
> no issues a few months back.
>
> I assume this is a windows problem .. but what ??
>
> Anyone else had this.. and a fix please ??
>

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

[go-nuts] Re: Goroutines memory leak

[Dave Cheney]

The leak is here

httpClient := {Timeout: timeout, Transport: {Dial
: dialer.Dial}}

If the httpClient value goes out of scope the connections attached to that 
will leak, along with their associated goroutines.

On Monday, 30 April 2018 07:56:43 UTC+2, Tamás Gulácsi wrote:
>
> Where do you Close the dialer? Why aren't you reusing the httpClient?

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

Re: [go-nuts] How does time reported by go test relate to the wall clock time?

[Dave Cheney]

Try upgrading to go 1.10. You’ll get build and test caching for free and you’ll 
see a small variance between the timings you reported. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 list returning directory starting with underscore on Ubuntu

[Dave Cheney]

If the path start with _ then it is not within the list of directories in your 
GOPATH. 

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

[go-nuts] how do i upgrade to latest version of go?

[Dave Cheney]

It depends on how you installed ypthe previous version of go. Home brew is 
popular on the Mac so follow their instructions for upgrading a package 
installed via brew. 

If you used one of the options from the golang org website, simply remove 
/usr/local/go and follow the instruction on the website to install go 1.10.1. 

Lastly, unset GOROOT if you’ve set it.

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

[go-nuts] schollz/peerdiscovery - Pure-Go library for cross-platform local peer discovery using UDP broadcast

[Dave Cheney]

Looking at the code for Discover it is possible you are discarding several 
errors whose contents may explain the issue you see on windows. 

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

[Dave Cheney]

Try putting a blank line between your comment block and the next symbol. This 
will break the association between the comment block and the symbol and hide 
the former. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 isn't os.File an interface?

[Dave Cheney]

Please have a read of my talk on solid from 2016. 

https://dave.cheney.net/2016/08/20/solid-go-design

Tldr: define an interface with the behaviour of the os.File that your 
function/method expects. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Language is a platform, which golang still does not pay attention to !!!

[Dave Cheney]

Indeed. Please do not conflate popularity with ubiquity. Formula one is a very 
popular sport, but not everyone needs to do 180mph down the straight away for 
their daily commute. 

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

[Dave Cheney]

You can report issues with Go at this link, golang.org/issue/new. 

However, this looks like a docker weirdness so we cannot help you as the 
bug isn't in go, it's docker weirdness.

Please try their support forums, sorry I don't have those details, i've 
never tried to get support for their product.

On Wednesday, 4 April 2018 21:52:08 UTC+10, sothy shan wrote:
>
>
>
> On Tuesday, April 3, 2018 at 4:50:36 PM UTC+2, Dave Cheney wrote:
>>
>> I’ve not seen that problem before. I’d hazard a guess that it’s an 
>> incorrect go installation. Don’t set goroot, basically ever. But it’s just 
>> a guess. 
>>
> It is basically problem when I run in docker container. This is sample 
> program.
>
> ++
> package main
>
> import (
> "os"
> "runtime/pprof"  
> "runtime"
> "fmt"   
> ) 
>
> func main() {
> f,_ :=os.Create("./ipcore_blocking.prof")
> 
>  runtime.SetBlockProfileRate(1)
>   
>   defer func() {
> if err := pprof.Lookup("block").WriteTo(f,0); err 
> !=nil {
> fmt.Printf("blocking profiler statistic 
> collecition initialization failed: %v", err)
>  }
>
>  f.Close()
>  runtime.SetBlockProfileRate(0)
>}()  
> // create new channel of type int
> ch := make(chan int)
>
> // start new anonymous goroutine
> go func() {
> // send 42 to channel
> ch <- 42
> }()
> // read from channel
> <-ch
> }
> +
> When I run localhost, it workes well. when I tries to run docker 
> container, it didnt work. I can give my dockerfile here. 
> FROM golang:1.9-alpine as dev
>
> +++
> RUN apk add --no-cache --repository 
> http://dl-3.alpinelinux.org/alpine/edge/community upx
>
> WORKDIR /go/src/project
>
>
> COPY ./main.go /go/src/project
> RUN go build -o /bin/project
>
> FROM scratch
> COPY --from=dev /bin/project /bin/project
> ENTRYPOINT ["/bin/project"]
>  
> +
> I have another problem when I run in Docker with CPU profile. 
>
> In this case where to report the issues?
>
> Best regards
> Sothy
>
>>
>> Are you able to create a stand alone program that demonstrates the issue 
>> with the profile? Please consider raising a bug, golang.org/issue/new
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Scheduler discrepancy between Linux and OS X with Gosched()

[Dave Cheney]

> But is it not guaranteed that runtime.Gosched() will at least check if 
another goroutine is runnable?

It checks, but I believe that at the time that it checks there are often no 
other runnable goroutines. The execution tracer will give you the answer to 
this.

On Wednesday, 4 April 2018 04:12:40 UTC+10, brianbl...@gmail.com wrote:
>
> Hi Dave, thanks for the reply!
>
> It makes sense that the send c <- 0 is not guaranteed to transfer control 
> to the receiving goroutine. But is it not guaranteed that runtime.Gosched() 
> will at least check if another goroutine is runnable? I thought that was 
> roughly the point of runtime.Gosched(). 
>
> I see what you're saying in that when the second goroutine calls Gosched, 
> the sleep period may not be finished. But this will only waste another 100 
> microseconds by design (not 100 milliseconds), so it seems like control 
> flow should return to the main goroutine approximately when the sleep call 
> finishes.
>
> I created a simpler example, that doesn't use channels and avoids the work 
> length ambiguity, posted below. Now the secondary goroutine just does an 
> infinite loop of runtime.Gosched(). It should be instantaneous to run (and 
> is on my Mac), but it takes almost exactly 5 seconds on Ubuntu, suggesting 
> that there is some fixed 5 millisecond delay on Gosched(). And adding a 
> print above spin's Gosched makes it instantaneous.
>
> Thanks for your patience! I'm working on an application where the ~5ms 
> Gosched delay is meaningful and I am very curious to figure out what's 
> going on here. 
> package main
>
> import (
> "log"
> "runtime"
> "time"
> )
>
> func spin() {
> for {
> runtime.Gosched()
> }
> }
>
> func main() {
> runtime.GOMAXPROCS(1)
> go spin()
>
> t0 := time.Now()
> for i := 0; i < 1000; i++ {
> time.Sleep(10 * time.Microsecond)
>
> runtime.Gosched()
> }
>
> log.Printf("Finished in %v.", time.Since(t0))
> }
>
>
> On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4, brianbl...@gmail.com 
> wrote:
>>
>> I've run into some mysterious behavior, where Gosched() works as expected 
>> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
>> statement before it.
>>
>> I originally posted this on Stack Overflow but was directed here. Post: 
>> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>>
>> Any help would be greatly appreciated! Very curious what's going on here, 
>> as this behavior came up while I was trying to write a websocket broadcast 
>> server. Here's a minimal setup that reproduces the behavior:
>>
>> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
>> pushes a dummy message onto another goroutine via a channel. The second 
>> goroutine listens for new messages, and every time it gets one it does 10ms 
>> of work. So without any runtime.Gosched() calls, the program will take 
>> 10 seconds to run.
>>
>> When I add periodic runtime.Gosched() calls in the second goroutine, as 
>> expected the program runtime shrinks down to 1 second on my Mac. However, 
>> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
>> made sure to set runtime.GOMAXPROCS(1) in both cases.
>>
>> Here's where it gets really strange: if I just add a logging statement 
>> before the the runtime.Gosched() calls, then suddenly the program runs 
>> in the expected 1 second on Ubuntu as well.
>>
>>
>> package main
>> import (
>> "time"
>> "log"
>> "runtime")
>>
>> func doWork(c chan int) {
>> for {
>> <-c
>>
>> // This outer loop will take ~10ms.
>> for j := 0; j < 100 ; j++ {
>> // The following block of CPU work takes ~100 microseconds
>> for i := 0; i < 30; i++ {
>> _ = i * 17
>> }
>> // Somehow this print statement saves the day in Ubuntu
>> log.Printf("donkey")
>> runtime.Gosched()
>> }
>> }}
>>
>> func main() {
>> runtime.GOMAXPROCS(1)
>> c := make(chan int, 1000)
>> go doWork(c)
>>
>> start := time.Now().UnixNano()
>> for i := 0; i < 1000; i++ {
>> time.Sleep(1 * time.Millisecond)
>>
>> // Queue up 10ms of work in the other goroutine, which will backlog
>> // this goroutine without runtime.Gosched() calls.
>> c <- 0
>> }
>>
>> // Whole program should take about 1 second to run if the Gosched() 
>> calls 
>> // work, otherwise 10 seconds.
>> log.Printf("Finished in %f seconds.", float64(time.Now().UnixNano() - 
>> start) / 1e9)}
>>
>>
>>

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

[Dave Cheney]

I’ve not seen that problem before. I’d hazard a guess that it’s an incorrect go 
installation. Don’t set goroot, basically ever. But it’s just a guess. 

Are you able to create a stand alone program that demonstrates the issue with 
the profile? Please consider raising a bug, golang.org/issue/new

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Scheduler discrepancy between Linux and OS X with Gosched()

[Dave Cheney]

A printf, especially the first one in the program is likely to cause the 
goroutine going off to the write(2) syscall to block long enough that a new 
thread is created to replace it. Once the original thread comes back from 
the syscall it will find that it has nothing to do, as you set runtime 
Gomaxprocs to one and will be parked by the scheduler.

What your program is doing is sending a bunch of work on an _non blocking_ 
channel then printing the difference between the start time and the end 
time (btw, use t0 := time.Now(); time.Since(t0))

There is nothing in the doWork goroutine that prevents the main goroutine 
from exiting, so as soon as the scheduler is perturbed enough to schedule 
the main goroutine, your program will exit.

The take away:

runtime.Gosched is _not_ guarenteed to transfer control to a runnable 
goroutine, because it is not defined if a send, c <- 0, will transfer 
control to the receiving goroutine or not. If you're lucky then 1000 sends 
will happen without transferring control to doWork. If you are not then 
control is transferred at some point in that 1000, and because you told the 
sending goroutine to sleep for 1 millisecond between sends, when you call 
runtime.Gosched in doWork, the main goroutine was asleep (therefore not 
runnable) so there is nothign to schedule; so you waste another 100ms, then 
try again to reschedule.

Ps. The Go execution tracer will show you what is happening with your 
program. I recommend using it to get a greater understanding of your 
programs behaviour.


On Tuesday, 3 April 2018 14:56:49 UTC+10, brianbl...@gmail.com wrote:
>
> I've run into some mysterious behavior, where Gosched() works as expected 
> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
> statement before it.
>
> I originally posted this on Stack Overflow but was directed here. Post: 
> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>
> Any help would be greatly appreciated! Very curious what's going on here, 
> as this behavior came up while I was trying to write a websocket broadcast 
> server. Here's a minimal setup that reproduces the behavior:
>
> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
> pushes a dummy message onto another goroutine via a channel. The second 
> goroutine listens for new messages, and every time it gets one it does 10ms 
> of work. So without any runtime.Gosched() calls, the program will take 10 
> seconds to run.
>
> When I add periodic runtime.Gosched() calls in the second goroutine, as 
> expected the program runtime shrinks down to 1 second on my Mac. However, 
> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
> made sure to set runtime.GOMAXPROCS(1) in both cases.
>
> Here's where it gets really strange: if I just add a logging statement 
> before the the runtime.Gosched() calls, then suddenly the program runs in 
> the expected 1 second on Ubuntu as well.
>
>
> package main
> import (
> "time"
> "log"
> "runtime")
>
> func doWork(c chan int) {
> for {
> <-c
>
> // This outer loop will take ~10ms.
> for j := 0; j < 100 ; j++ {
> // The following block of CPU work takes ~100 microseconds
> for i := 0; i < 30; i++ {
> _ = i * 17
> }
> // Somehow this print statement saves the day in Ubuntu
> log.Printf("donkey")
> runtime.Gosched()
> }
> }}
>
> func main() {
> runtime.GOMAXPROCS(1)
> c := make(chan int, 1000)
> go doWork(c)
>
> start := time.Now().UnixNano()
> for i := 0; i < 1000; i++ {
> time.Sleep(1 * time.Millisecond)
>
> // Queue up 10ms of work in the other goroutine, which will backlog
> // this goroutine without runtime.Gosched() calls.
> c <- 0
> }
>
> // Whole program should take about 1 second to run if the Gosched() calls 
> // work, otherwise 10 seconds.
> log.Printf("Finished in %f seconds.", float64(time.Now().UnixNano() - 
> start) / 1e9)}
>
>
>

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

[Dave Cheney]

It looks like you’re stopping the block profile immediately after starting it.

Try github.com/pkg/profile which will take care of the plumbing for you. 

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

[Dave Cheney]

This windows build dependencies are captured 
here, https://github.com/golang/go/wiki/WindowsBuild

On Thursday, 29 March 2018 00:17:32 UTC+11, Luke Mauldin wrote:
>
> Can someone please tell me what the golang team uses as the reference 
> windows x64 compiler? I have heard references to mingw64 but it would be 
> helpful to know the exact version they are using for their unit tests on 
> Windows. I am experiencing different cgo windows behavior in 1.10 than 
> 1.9.3 and I want to verify I am using the validated windows tool chain.
>
> Luke
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Pass by value in struct not yielding expected result

[Dave Cheney]

On Wednesday, 7 March 2018 07:39:56 UTC+11, andrey mirtchovski wrote:
>
> maybe this will give you a hint: https://play.golang.org/p/ANIjc3tCdwp 
>
> maps are reference types, but they still get passed by value.
>

Maps are pointers, pointers are values. 

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

[Dave Cheney]

Under the hood go get shells out to git to fetch source code. You need to 
install git. 

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

[Dave Cheney]

I prefer the later when possible because it enables callers to use the zero 
value of a type without explicit initialisation.

On Sunday, 4 March 2018 11:37:43 UTC+11, Anmol Sethi wrote:
>
> How do you guys choose between constructors and lazy initialization?
>
> For example.
>
> Struct constructors:
>
> type meow struct {
> x http.Handler
> }
>
> func newMeow() *meow {
> return {
> x: http.NewServeMux(),
> }
> }
>
> func (m *meow) do() {
> // stuff
> }
>
>
> Lazy initialization:
>
> type meow struct {
> x http.Handler
> }
>
> func (m *meow) do() {
> if m.x == nil {
> m.x = http.NewServeMux()
> }
> // stuff
> }
>
>

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

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

[Dave Cheney]

Ahh, thank you. That was the missing piece of my understanding. 

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

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

[Dave Cheney]

I don't understand how that could happen. time.Now calls time.now (which is 
in assembly) so the former shouldn't be inlined, or omitted from profiling.

On Monday, 26 February 2018 14:02:13 UTC+11, Caleb Spare wrote:
>
> On a hunch, I profiled a benchmark which just calls time.Now in a loop. 
> Indeed: 95% of the time is attributed to runtime._System -> 
> runtime._ExternalCode.
>
> My program does collect a lot of timing information as it runs and ends up 
> calling time.Now quite a lot. I don't yet know for sure that most/all of 
> the runtime._ExternalCode that shows up in my program's profile is 
> time.Now, but that wouldn't surprise me.
>
> This makes me curious: would it be feasible to make the profiler recognize 
> a vDSO call and synthesize a more helpful stack?
>
> On Sun, Feb 25, 2018 at 3:39 PM, Ian Lance Taylor  > wrote:
>
>> On Sun, Feb 25, 2018 at 3:30 PM, Caleb Spare > > wrote:
>>
>>> There's no cgo in this program or any of its non-stdlib dependencies.
>>>
>>> The server is a static binary built with CGO_ENABLED=0.​ Can there still 
>>> be cgo code running somehow?
>>>
>>
>> No, if it's CGO_ENABLED=0, then I think cgo code can not be the problem.
>>
>> But I also can't think of any other plausible reason to have so many hits 
>> for this case.  It can happen if the profiling signal is received while 
>> executing in `gogo`, `systemstack`, `mcall`, or `morestack`.  But none of 
>> those occur all that often and they run for a short time.  It's hard to 
>> believe that they would show up when profiling a real program.  I don't 
>> know what is happening here.
>>
>> The code path you are seeing is the `n == 0` case in `sigprof` in 
>> runtime/proc.go.
>>
>> Ian
>>
>>
>>  
>>
>>> On Sun, Feb 25, 2018 at 3:05 PM, Ian Lance Taylor >> > wrote:
>>>
 On Sun, Feb 25, 2018 at 2:01 PM, Caleb Spare  wrote:

> How should I interpret runtime._System calling into 
> runtime._ExternalCode in a pprof profile?
>
> I saw this taking >10% of CPU time, so I recompiled with CGO_ENABLED=0 
> and even so I see 6.62% of time in runtime._ExternalCode.
>
> runtime._System is a root in the graph so I can't even figure out what 
> part of my code this might be related to.
>
> [image: Inline image 1]
>
>
>



 This is what you see when a profililng signal occurs while executing 
 code for which the Go runtime could not generate a traceback, and the 
 thread was not running the garbage collector.  The most common reason for 
 being unable to get a traceback is running in cgo code.

 If you are running on an ELF based system like GNU/Linux then consider, 
 for testing purposes only, importing 
 github.com/ianlancetaylor/cgosymbolizer.  No need to actually use the 
 package for anything, just do a blank import somewhere.  If you're lucky 
 that will give you a more detailed profile.

 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] Is this a bug?

[Dave Cheney]

Type C conforms to the T1 interface?

What did you expect?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Build started to fail with 1.10

[Dave Cheney]

The failing line was added in december last year,

https://github.com/golang/go/commit/7cba779cea5#diff-56c7df71bce32f8e50115128ae30941eR13

This also adds a dependency on time.h. Is time.h available in your build 
container?

On Friday, 23 February 2018 20:09:02 UTC+11, Владислав Митов wrote:
>
> Nah, it's not that - https://travis-ci.org/miracl/gomiracl/jobs/345158452. 
> If fails also in golang:latest where the yaml gotcha it's not a thing. 
> Solid suggestion though, thanks.
>
> On Friday, February 23, 2018 at 11:02:59 AM UTC+2, Владислав Митов wrote:
>>
>> Ah, I read about that but ti says `go version go1.10 linux/amd64`. I'll 
>> try putting it in quotes now.
>>
>> On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:
>>>
>>> This is almost certainly because your .travis file is specifying your 
>>> version as `1.10` vs `"1.10"`
>>>
>>> So your build is building with go 1.1 instead of 1.10.
>>>
>>> Ran into this myself this morning.
>>>
>>> -Nic
>>>
>>> On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов 
>>> wrote:

 Hey guys, 

 One of my build started failing with 1.10. Basically I'm building a 
 wrapper around a C library and it fails with: 

 # runtime/cgo
 gcc_libinit.c: In function '_cgo_try_pthread_create':
 gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
   struct timespec ts;
   ^~
 gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
 [-Werror=implicit-function-declaration]
nanosleep(, nil);
^
 gcc_libinit.c:97:18: error: unused variable 'ts' 
 [-Werror=unused-variable]
   struct timespec ts;
   ^~
 cc1: all warnings being treated as errors
 https://travis-ci.org/miracl/gomiracl/jobs/344782123

 Any hint's what's causing this? 

 Cheers, 
 Vladi

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Dero: CryptoNote protocol + smart contracts using golang

[Dave Cheney]

Is there a reason DERO chose to go with their own licence rather than a 
BSD, MIT, or Apache 2 licence?


On Monday, 19 February 2018 16:10:14 UTC+11, 867crypt...@gmail.com wrote:
>
> Hello, my name is Serena, I’m the Community Manager at a blockchain 
> project called Dero. We use a protocol called CryptoNote that was 
> originally written in C++. The developers at the Dero Project have 
> rewritten most of the (CryptoNote) codebase to golang and we would like to 
> start some discussion within the development and open source communities.
>
>
> The core cryptography and functionally (rewritten in golang) is working 
> and available on GitHub for limited evaluation and testing. We would 
> genuinely value the feedback from this community. The following is what 
> I’ve posted to a couple other communities as well. (I would like to 
> emphasize that this project is currently pre-alpha but your input (the 
> google community) in particular is important to us.)
>
>
> *DERO: Privacy + Smart Contracts*
>
>
> Dero at present is a code fork of Monero (Helium Hydra) with the Bytecoin 
> CryptoNote protocol.
>
> Dero will be a completely new blockchain technology integrating the 
> CryptoNote protocol with new smart contract controls.
>
> *Dero is being rewritten from C++ to Golang (Google Language) to bring 
> together CryptoNote and smart contracts on the Dero blockchain.*
>
>
> *CryptoNote protocol implementation in Golang is almost completed and 
> available on GitHub for basic testing/evaluation.*
>
>
> *GitHub:* https://github.com/deroproject/derosuite (Golang version for 
> testing purposes only at this time)
>
>
> *Bitcointalk:* https://bitcointalk.org/index.php?topic=2525508.0
>
>
> Dero has a very welcoming community and we would enjoy the opportunity to 
> have you join us!
>
>
> *FULL DISCLOSURE:Dero has a very welcoming community and we would enjoy 
> the opportunity to have you join us!*
>
>
> *FULL DISCLOSURE:* My name is Serena, I’m the Community Manager at the 
> Dero Project
>

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

[Dave Cheney]

I recommend watching this presentation from Russ Cox about why the Go team 
decided to rewrite the compiler from C to Go. 

https://www.youtube.com/watch?v=QIE5nV5fDwA

On Monday, 19 February 2018 11:44:23 UTC+11, Compiler wrote:
>
> Performance of C with Optimize not better of Go at more time?!
> so why re-write golang in go?
>
> On Monday, February 19, 2018 at 3:54:08 AM UTC+3:30, Compiler wrote:
>>
>> When Golang using *bootstrapping **technique* , performance not Decrease?
>>
>> On Monday, February 19, 2018 at 3:42:18 AM UTC+3:30, Compiler wrote:
>>>
>>> *bootstrapping* is the technique for producing a self-compiling compiler 
>>> 
>>>
>>> On Monday, February 19, 2018 at 3:40:54 AM UTC+3:30, Compiler wrote:

 whats difference between self-hosting compiler vs Bootstrapping 
 compiler?

 https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

 On Monday, February 19, 2018 at 3:34:48 AM UTC+3:30, Michael Jones 
 wrote:
>
> much better!  i suggest Google searches about bootstrapping, 
> self-hosting, and security.
>


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

[Dave Cheney]

If you want to learn more about the Go compiler then you must stop living 
in the past. Go 1.4 is _dead_. The current compiler is written in pure go 
and you can find the sources 
here https://github.com/golang/go/tree/master/src/cmd/compile/internal

We cannot help you use the old Go 1.4 c compiler to write a compiler. 
Someone may want to pursue that as a project, but not on this mailing list. 
This mailing list is for talking about Go. 

On Monday, 19 February 2018 10:59:32 UTC+11, Compiler wrote:
>
> I have some experience in writing lexer,parser,interpreter,optimize.
> I've also worked generate output code(example one language to another).
>
> currently example i'm design a interpreter and for final step( generate 
> output file) using another compiler.
>
> i'm want know more about compiler... and trying them.
>
> I mean the compiler : self compiler
>
> On Monday, February 19, 2018 at 3:22:27 AM UTC+3:30, Dave Cheney wrote:
>>
>> Stop.
>>
>> What do you want to do?
>>
>> Do you want to write a C compiler ?
>>
>> On Monday, 19 February 2018 10:47:24 UTC+11, Compiler wrote:
>>>
>>> https://groups.google.com/forum/#!topic/golang-nuts/24pSm-B3FqU
>>>
>>> On Monday, February 19, 2018 at 3:14:48 AM UTC+3:30, Dave Cheney wrote:
>>>>
>>>>
>>>> Who is they? Can you give some more context.
>>>>
>>>

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

[Dave Cheney]

Stop.

What do you want to do?

Do you want to write a C compiler ?

On Monday, 19 February 2018 10:47:24 UTC+11, Compiler wrote:
>
> https://groups.google.com/forum/#!topic/golang-nuts/24pSm-B3FqU
>
> On Monday, February 19, 2018 at 3:14:48 AM UTC+3:30, Dave Cheney wrote:
>>
>>
>> Who is they? Can you give some more context.
>>
>

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

[Dave Cheney]

On Monday, 19 February 2018 10:42:12 UTC+11, Compiler wrote:
>
> Assembly?!
> but not exist many `.asm` files at source.
>

By tradition assembly files have .s and .S extensions
 

> Also, I had already asked ...
>

Already asked what? It might be easier if you give more background to the 
_problem_ you want to solve rather than asking random questions without 
context.
 

> And they said they were not with the assembly and is generate executable 
> file using object file.
>

Who is they? Can you give some more context.
 

>
> On Monday, February 19, 2018 at 3:08:51 AM UTC+3:30, Dave Cheney wrote:
>>
>>
>>
>> On Monday, 19 February 2018 10:33:16 UTC+11, Compiler wrote:
>>>
>>> /go/src/cmd/cc/
>>> this directory is base of c-compiler.
>>>
>>
>> yes, that is where the shared parts of the c compiler lives, the 
>> architecture specific parts were in 5c, 6c, 8c, etc.
>>  
>>
>>>
>>> so not `.c` file in /src/.
>>>
>>
>> You can answer this question yourself by looking in the tarball. The Go 
>> 1.4 runtime was written in a mixture of Go, C, and Assembly. 
>>
>>>
>>> On Monday, February 19, 2018 at 3:01:35 AM UTC+3:30, Compiler wrote:
>>>>
>>>> mean all `.c` file in /src/ compile using own c-compiler?!
>>>>
>>>> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>>>>
>>>>> > which files require go-c compiler?
>>>>>
>>>>> The ones in the go 1.4distributuon that end in .c. 
>>>>>
>>>>

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

Re: [go-nuts] About Go Compiler!

[Dave Cheney]

In theory, yes. In practice, I doubt it.

On Monday, 19 February 2018 10:37:14 UTC+11, Compiler wrote:
>
> Can build only c(own) compiler using a c compiler(like gcc) without go 
> from this source?!
>
>
> On Monday, February 19, 2018 at 2:48:26 AM UTC+3:30, Dave Cheney wrote:
>>
>> I feel like we’ve had this same discussion a few months ago. 
>>
>> Ian has mentioned that go 1.4 is no longer in use (it exists only in a 
>> very special case or bootstrapping from source). 
>>
>> Can you please give some context to your questions so we may assist you 
>> better.
>
>

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

[Dave Cheney]

On Monday, 19 February 2018 10:33:16 UTC+11, Compiler wrote:
>
> /go/src/cmd/cc/
> this directory is base of c-compiler.
>

yes, that is where the shared parts of the c compiler lives, the 
architecture specific parts were in 5c, 6c, 8c, etc.
 

>
> so not `.c` file in /src/.
>

You can answer this question yourself by looking in the tarball. The Go 1.4 
runtime was written in a mixture of Go, C, and Assembly. 

>
> On Monday, February 19, 2018 at 3:01:35 AM UTC+3:30, Compiler wrote:
>>
>> mean all `.c` file in /src/ compile using own c-compiler?!
>>
>> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>>
>>> > which files require go-c compiler?
>>>
>>> The ones in the go 1.4distributuon that end in .c. 
>>>
>>

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

Re: [go-nuts] About Go Compiler!

[Dave Cheney]

yes, up to Go 1.4, part of the go runtime was compiled using a c compiler 
which derived from the plan 9 c compilers. In fact, the c frontend and the 
go frontend shared the same code generation backends.

On Monday, 19 February 2018 10:31:35 UTC+11, Compiler wrote:
>
> mean all `.c` file in /src/ compile using own c-compiler?!
>
> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>
>> > which files require go-c compiler?
>>
>> The ones in the go 1.4distributuon that end in .c. 
>>
>

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

Re: [go-nuts] About Go Compiler!

[Dave Cheney]

> which files require go-c compiler?

The ones in the go 1.4distributuon that end in .c. 

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

Re: [go-nuts] About Go Compiler!

[Dave Cheney]

> what files require the c compiler?

The c files in the go 1.4 distribution. 

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

[Dave Cheney]

I feel like we’ve had this same discussion a few months ago.

Ian has mentioned that go 1.4 is no longer in use (it exists only in a very 
special case or bootstrapping from source).

Can you please give some context to your questions so we may assist you better.

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

[Dave Cheney]

In Go 1.4 the project contained both .go files and .c files. It shipped 
with two compilers, a go compiler, called gc, and a c compiler called cc.

> /go/src/cmd/gc/go.y

This is the input file for the yacc grammar for the Go 1.4 go compiler 

> /go/src/cmd/cc/cc.y

This is the input file for the yacc grammar for the Go 1.4 c compiler 

The same advice applies to the other two files you mentioned.

On Monday, 19 February 2018 09:57:21 UTC+11, Compiler wrote:
>
> yeah , in go1.4 version,i want know difference between files.
> ?!
>
> On Monday, February 19, 2018 at 2:04:09 AM UTC+3:30, Ian Lance Taylor 
> wrote:
>>
>> On Sun, Feb 18, 2018 at 9:23 AM, Compiler  wrote: 
>> > #Question 
>> > 
>> > What is the difference between using the following two files? 
>> > 
>> > /go/src/cmd/gc/go.y 
>> > /go/src/cmd/cc/cc.y 
>> > 
>> > - 
>> > #Question 
>> > 
>> > What is the difference between using the following two files? 
>> > 
>> > /go/src/cmd/gc/lex.c 
>> > /go/src/cmd/cc/lex.c 
>>
>> You must be looking at a very old version of Go, as current versions 
>> of Go do not contain either file. 
>>
>> Old versions of Go shipped with a C compiler that was used to build 
>> parts of the runtime that were written in C.  Those parts were 
>> rewritten into Go, and Go no longer ships a C compiler.  Back then, 
>> the Go compiler was in cmd/gc and the C compiler was in cmd/cc. 
>>
>> 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: All Forms of Wishful Generics

[Dave Cheney]

I certainly don’t want what happened to C++ to happen to Go. If it’s a choice 
between obsolescence or being crushed under the weight of self inflicted 
complexity, I’ll gladly vote with my feet for the former. 

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

[Dave Cheney]

cgo is not go. 

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

[Dave Cheney]

Your program has a data race in the exitcode variable. 

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

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

[Dave Cheney]

Your argument that the stdlib grows a uuid package is really a call for 
stability. “3rd parties cannot provide us the stability we need, so the go team 
must”. I don’t think that is a fair expectation on the go team, especially as 
there is no clear standard for what a uuid is (having multiple inplemebtations 
pushes the discussion into the domain of the python standard library). 

I think your problems would be best solved by forking the uuid library at a 
revision that works for you, or sponsoring the development of a sufficiently 
stable uuid library. There is clearly a market for one. 

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

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

[Dave Cheney]

But that’s the problem, who’s default uuid format is chosen? And how to justify 
this over the other users who want their default to be chosen. 

The answer is as it currently stands, multiple uuid libraries exist outside the 
standard library. 

Can you tell me, in concrete terms, what are the benefits to you of a (I’m 
going to assume the one that is compatible with your project) uuid 
implementation being included in the standard library. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] net.Pipe doesn't support deadlines

[Dave Cheney]

Which version of Go are you using?

https://github.com/golang/go/blob/master/src/net/pipe.go#L224

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

[Dave Cheney]

The build system considers android and Linux to be the same for historical 
reasons. 

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

[Dave Cheney]

Hi,

Can you please provide the output from running,

go env

It looks like your GOPATH variables is either not set, or not set to the 
correct value, which in this case looks to be,

/home/vuco/repos/gopkg

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

[Dave Cheney]

Can you please provide the output from running to eng. 

It looks like your GOPATH variables is either not set, or not set to the 
correct value, which looks to be in this case

/home/vuco/repos/gopkg

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

[go-nuts] Re: Go 1.10 Beta 2 is released

[Dave Cheney]

I am running the same version and do not see that errro. Have you modified your 
ulimit? Does your machine have any sort of antivirus or monitoring software 
installed? 

In any case, I would say you can ignore that error, Go is correctly built by 
that time. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: where is the implementation of `getg`?

[Dave Cheney]

A long time ago getg was written in assembly in the runtime package. These 
days it is implemented directly as pseudo instruction in the compiler. 
Search for OpGetG in $GOROOT/src/cmd/compile/internal

On Wednesday, 17 January 2018 12:40:48 UTC+11, Jiajun Huang wrote:
>
> Hi, all:
>
>  I'm reading golang runtime implementation, I've got a function 
> definition:
>
> // getg returns the pointer to the current g.
> // The compiler rewrites calls to this function into instructions
> // that fetch the g directly (from TLS or from the dedicated register).
> func getg() *g
>
>
> So, is there any solution that I can reading what implementation does 
> the compiler rewrite? It seems that it's Assembly code.
>

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

[go-nuts] Re: How to make a TSV processing Go program that beats awk and even cut in terms of runtime?

[Dave Cheney]

> Could anybody let me know what is wrong with my go program and how to 
make it run faster?

Stop using gorun. You're timing how long it takes to compile, link, and 
then run your program.

On Wednesday, 17 January 2018 07:18:47 UTC+11, peng...@gmail.com wrote:
>
> Hi,
>
> I made the following Go program (main.go). But it is still slower than awk 
> or cut. I know that `cut` uses string manipulation tricks to make it run 
> very efficiently.
>
> https://github.com/coreutils/coreutils/blob/master/src/cut.c
>
> But I am not sure how to do the same thing in golang. Could anybody let me 
> know what is wrong with my go program and how to make it run faster?
>
> $  ./main_.sh 
> time ./main.go 10 < "$infile" > /dev/null
>
> real0m1.418s
> user0m0.976s
> sys0m0.433s
> time cut -f 10 < "$infile" > /dev/null
>
> real0m0.249s
> user0m0.219s
> sys0m0.026s
> time awk -v FS='\t' -v OFS='\t' -e '{ print $10 }' < "$infile" > /dev/null
>
> real0m1.156s
> user0m1.123s
> sys0m0.031s
>
> ==> main.go <==
> #!/usr/bin/env gorun
> // vim: set noexpandtab tabstop=2:
> package main
>
> import (
> "bufio"
> "fmt"
> "os"
> "strings"
> "strconv"
> )
>
> func main() {
> idx, _ := strconv.Atoi(os.Args[1])
> col := idx - 1
>
> scanner := bufio.NewScanner(os.Stdin)
> for scanner.Scan() {
> line := strings.TrimRight(scanner.Text(), "\n")
> fields := strings.Split(line, "\t")
> fmt.Printf("%s\n", fields[col])
> }
> }
>
> ==> main_.sh <==
> #!/usr/bin/env bash
> # vim: set noexpandtab tabstop=2:
>
> set -v
> infile=$(mktemp)
> seq 1000 | paste -s -d $'\t\t\t\t\t\t\t\t\t\n' > "$infile"
> time ./main.go 10 < "$infile" > /dev/null
> time cut -f 10 < "$infile" > /dev/null
> time awk -v FS='\t' -v OFS='\t' -e '{ print $10 }' < "$infile" > /dev/null
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] interaction of defer and named returns is too subtle and non-local

[Dave Cheney]

> The body of the two functions differs only by a single ":", and yet, the 
> output of the Printf calls differs.

This is not correct. The significant difference is one version has a named 
return value, the other does not. The named return value allows you to capture 
(by name) the return value and examine it after the function has completed, but 
before the execution of the caller has resumed. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Very simple, Td array

[Dave Cheney]

The best way to get help for this is to show us precisely what you 
did, ideally in a small complete, stand-alone, example, and tell us 
what you expected to happen, and tell us precisely what happened 
instead. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Very simple, Td array

[Dave Cheney]

>   fmt.Printf("%#v %#v\n", tr.Td, , tr.Td[0])

This line will not compile, are you sure this is the code that is executing?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Extending an existing type by embedding

[Dave Cheney]

On Friday, 5 January 2018 01:15:16 UTC+11, matthe...@gmail.com wrote:
>
> Tong, I’m glad this works for you.
>
> Dave, reading back I see that we’re giving conflicting advice on pointers 
> for MyTokenizer. While my view is that the dereferences are not necessary 
> here, perhaps you have other reasons to have a pointer in this case?
>

I was just guessing, I didn't fully understand the problem the OP was 
asking.
 

>
> Thanks,
> Matt
>
> On Wednesday, January 3, 2018 at 7:25:15 PM UTC-6, Tong Sun wrote:
>>
>> Thanks Matt -- I thought it wouldn't work, but having thinking it over, 
>> and over, now I finally make it working.
>>
>> Thanks a lot
>>
>> On Wed, Jan 3, 2018 at 9:46 AM,  wrote:
>>
>>> Ah, this kind of function signature may be better:
>>>
>>> func WalkBody(t *html.Tokenizer, w TokenVisitor) {
>>>
>>> Then you would use the regular *html.Tokenizer methods to do the walk 
>>> and pass each token to the TokenVisitor to be parsed for output depending 
>>> on which TokenVisitor was picked.
>>>
>>> Matt
>>>
>>> On Wednesday, January 3, 2018 at 8:30:14 AM UTC-6, Tong Sun wrote:



 On Wed, Jan 3, 2018 at 9:07 AM,  wrote:

>
>> Why do you need varying types if you are just using html.Tokenizer 
> methods? What is the difference between each type?
>


 The difference is the VisitToken(), using the same function of 
 `WalkBody()`, but achieving different results. 

 For example, the current output from 
 https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
  is 
 one way of abstracting the html structure, and I also planning to produce 
 text output that close to XML Outline View from Oxygen XML Editor, or 
 convert HTML to .md. 

 All of above involve walking the HTML the same way, but producing 
 results differently. 



 -- 
>>> 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/FRE_A6cNzW8/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] Extending an existing type by embedding

[Dave Cheney]

Put your methods on *MyTokenizer.

On Wednesday, 3 January 2018 14:52:41 UTC+11, Tong Sun wrote:
>
> I gave it a try, but unfortunately, it doesn't work for me. 
>
> To begin with, this works, 
>
> type MyTokenizer struct {
> *html.Tokenizer
> }
>
> func NewMyTokenizer(i io.Reader) *MyTokenizer {
>  z := html.NewTokenizer(i)
>  return {z}
> }
>
> However, 
>
> On Tue, Jan 2, 2018 at 10:26 AM,  
> wrote:
>
>> You want different tokenizer types to be used in the same WalkBody 
>> implementation. Interfaces abstract the implementation from the calling 
>> computation.
>>
>> I think Ian did answer your question.
>>
>> type TokenVisitor interface {
>> VisitToken()
>> }
>>
>> func WalkBody(of TokenVisitor) {
>> // here you call of.VisitToken()
>> }
>>
>> type MyTokenizer1 struct {
>> *html.Tokenizer
>> }
>>
>> func (the MyTokenizer1) VisitToken() {
>>
>> }
>>
>> type MyTokenizer2 struct {
>> *html.Tokenizer
>> }
>>
>> func (the MyTokenizer2) VisitToken() {
>>
>> }
>>
>> // call WalkBody somewhere with either MyTokenizer1 or MyTokenizer2
>>
>
>
> As soon as I tried above and turned 
>
> type MyTokenizer struct 
>
> to
>
> type TokenVisitor interface 
>
> everything started to break down. Here is the code that I've put together 
> so far:
>
>
> https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
>
> I got:
>
> ./htmlParserTokens2.go:82:10: z.Next undefined (type TokenVisitor has no 
> field or method Next)
>
> So let me reiterate what I hope to achieve, 
>
>
>1. extend the `html.Tokenizer` with new methods of my own
>2. while still able to access all existing html.Tokenizer methods in 
>the mean time
>3. define a function `WalkBody()` (or an interface method)
>4. in which an interface method of `VisitToken()` is used, which will 
>behave differently for different types
>
> The first two goals can be achieved by "type MyTokenizer struct", but as 
> soon as I change that to the interface type to act as the base for the 
> two different extended types, goal#2 breaks. 
>  
> So far this is only a small test example, in which 
> only z.Next(), z.Err(), z.TagName() etc are currently used. But in real 
> life I'll using all the html.Tokenizer methods, and published variables. 
> I.e., 
>
> I'm not seeing the light at the end of the tunnel where all above 4 goal 
> can be achieved together. 
>
> Seem to me some compromise has to be made, what is the least compromise to 
> make?
> Anybody can help please?
>
> Again, the code that I've put together so far is at:
>
>
> https://github.com/suntong/lang/blob/master/lang/Go/src/xml/htmlParserTokens2.go
>
> Thanks
>
>
> On Tuesday, January 2, 2018 at 8:45:56 AM UTC-6, Tong Sun wrote:
>>
>>>
>>>
>>> On Mon, Jan 1, 2018 at 9:46 PM, Tong Sun  wrote:
>>>
 Hi, 

 I think I generally understand how embedding (
 https://golang.org/doc/effective_go.html#embedding) works in GO. 
 However, when it comes to the following problem, I'm at lost again. 

 I'm trying to extend the `html.Tokenizer` with new methods of my own:

 type MyTokenizer struct {
  html.Tokenizer
 }


 func NewMyTokenizer(i io.Reader) *MyTokenizer {
  z := html.NewTokenizer(i)
  return *MyTokenizer(z)
  return {z}
 }



 so code like

  z := html.NewTokenizer(body)
 ...
 func parseBody(z *html.Tokenizer) {
   tt := z.Next()
 ...
  testt := z.Token()
 ...


 can become:

  z := NewMyTokenizer(body)
 ...
 func (z *MyTokenizer) parseBody() {
  tt := z.Next()
 ...

  testt := z.Token()
 ...




 However, I'm really struggling to make it work as I was expected. 

 Somebody help please, what's the proper way to extend a type with new 
 methods of my own, while still able to access all existing methods? 

>>>
>>>
>>> Thanks to Jason Phillips' help, the above part is solved:
>>>
>>> type MyTokenizer struct {
>>> *html.Tokenizer
>>> }
>>>
>>> func NewMyTokenizer(i io.Reader) *MyTokenizer {
>>>  z := html.NewTokenizer(i)
>>>  return {z}
>>> }
>>>
>>>  What's remaining is, 
>>>
>>> Further more, how to extend the above even further? --

 - I plan to define an interface with a new method `WalkBody()`, in 
 which a "virtual" method of `VisitToken()` is used. 
 - Then I plan to define two different type of MyTokenizer, with their 
 own `VisitToken()` methods, so the same `WalkBody()` method defined in 
 MyTokenizer will behave differently for those two different types. 

 How to architect above in Go? 

>>>
>>> I've found this afterward, 
>>>
>>> http://hackthology.com/object-oriented-inheritance-in-go.html
>>>
>>> I'll digest and try it out, and see how that can solve the above 
>>> problem, because it builds bottom up (not mid-way up). 
>>>
>>> Meanwhile, if someone can explain 

Re: [go-nuts] The o.done access on the once.Do function

[Dave Cheney]

On 29 Dec 2017, at 18:01, Caleb Spare  wrote:

>>> This expression:
>>> 
>>> atomic.StoreUint32(, 1)
>>> 
>>> does not just take the address of o.done. It also executes the
>>> StoreUint32 function, which is defined by the sync/atomic
>>> documentation to behave like '*o.done = 1'; i.e., it alters the value
>>> of o.done.
>> 
>> 
>> Respectfully I disagree, it store the value 1 at the memory address 
>> It has no defined effect on other occurrences of o.done in this, or other
>> goroutines if they have already loaded o.done.
>> 
>> I agree that i'm still talking about registers and inlining; but if there
>> were no registers, inlining, caches, or other things which are not specified
>> by the language, then there would be no data races. So here we are.
> 
> Does your argument rely on atomic.StoreUint32 being special, or would
> you also say that this program is not defined to always print 2?

I believe that program will always print 2, however when you bring multiple 
Goroutines into the mix, I’m less sure. 

> 
> https://play.golang.org/p/gk3c6X_JdmQ

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] The o.done access on the once.Do function

[Dave Cheney]

On Friday, 29 December 2017 16:55:37 UTC+11, Caleb Spare wrote:
>
> > My argument is all that 'happens-before' is a comparison of o.done == 
> > 0 happens before the address of o.done is passed to 
> > atomic.StoreUint32. The rest is just luck. 
>
> This expression: 
>
> atomic.StoreUint32(, 1) 
>
> does not just take the address of o.done. It also executes the 
> StoreUint32 function, which is defined by the sync/atomic 
> documentation to behave like '*o.done = 1'; i.e., it alters the value 
> of o.done. 


Respectfully I disagree, it store the value 1 at the memory address 
 It has no defined effect on other occurrences of o.done in this, 
or other goroutines if they have already loaded o.done. 

I agree that i'm still talking about registers and inlining; but if there 
were no registers, inlining, caches, or other things which are not 
specified by the language, then there would be no data races. So here we 
are.

 

> When I say that there's a total ordering among the reads 
> and writes within the mutex, this is the write that I'm referring to. 
>
> > I agree it should print 2, but my reading of the memory model and 
> > https://github.com/golang/go/issues/5045 doesn't give me any concrete 
> > guarantee that it must. This is why i'm not sure about the 
> > interactions between atomic and non atomic loads. 
>
> Here, too, I think we need to turn to the sync/atomic documentation, 
> which says what the effect of StoreUint32 is. The precise nature of 
> concurrent atomic operations can be left to #5045, but here we are 
> concerned with something simpler: after StoreUint32 returns 
> ("after" in a happens-before sense), are we guaranteed to read the 
> stored value? The answer must be yes. (If the answer were no, then 
> StoreUint32(p, val) would be in some sense *less atomic* than the 
> statement *p = val.) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] The o.done access on the once.Do function

[Dave Cheney]

On Fri, Dec 29, 2017 at 3:52 PM, Caleb Spare  wrote:
> My argument is made without reference to registers, liveness,
> inlining, or any of that.
>
> The memory model defines certain behavior of mutexes (intuitively,
> it's how you think they would work) and sync/atomic defines how
> StoreUint32 behaves (it's some atomic version of *o.done = 1).
>
> (There are details of how atomic ops interact with the memory model
> that haven't been formalized yet -- that's
> https://github.com/golang/go/issues/5045 -- but I don't believe that
> even matters for this.)
>
> By following the memory model rules, it seems clear that there's a
> happens-before total ordering of all the reads and writes of o.done
> *within the mutex*, and therefore the read ('if o.done == 0') must
> give the value of the previous write. Future compiler changes must
> preserve these properties, even if it's true that they only hold by
> accident today.

My argument is all that 'happens-before' is a comparison of o.done ==
0 happens before the address of o.done is passed to
atomic.StoreUint32. The rest is just luck.

>
>>>
>>> atomic.StoreUint32(, 1)
>>
>> Taking the address of the done field in the o object will have no
>> impact on the value of o.done potentially cached in a register. If
>> this code is inlined into its caller then the registerised copy of
>> o.done may be consulted again without respect to the atomic load
>> earlier in the function.
>>
>> This is probably not happening today because this function is not a
>> leaf function and is not eligible for inlining at the default
>> settings. The correctness of the function is relying on unspecified
>> compiler behaviour.
>
> Just to make sure I understand your claim: would you say that this
> program ought to be allowed to print either 1 or 2?
> https://play.golang.org/p/fdf8VeJ98Jv

I agree it should print 2, but my reading of the memory model and
https://github.com/golang/go/issues/5045 doesn't give me any concrete
guarantee that it must. This is why i'm not sure about the
interactions between atomic and non atomic loads.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] The o.done access on the once.Do function

[Dave Cheney]

On Fri, Dec 29, 2017 at 2:16 PM, Caleb Spare <cesp...@gmail.com> wrote:
> I'm quite certain that code is correct. There's no data race here
> since the write and the non-atomic read are both inside the mutex.

I don't believe so, I think this is currently safe because of the way
the compiler does not maintain any live registers across function call
boundaries, however this probably isn't a strong enough guarantee.

> The memory model rules about mutexes formalize how they serialize the
> code inside them. Because the unlock happens-before the next lock, and
> because sequential code in a single goroutine has the happens-before
> order that the source code expresses, this read:
>
> if o.done == 0

then o.done could be loaded into a register, and on some architectures
it must be loaded into a register, after this point.

>
> and this write:
>
> atomic.StoreUint32(, 1)

Taking the address of the done field in the o object will have no
impact on the value of o.done potentially cached in a register. If
this code is inlined into its caller then the registerised copy of
o.done may be consulted again without respect to the atomic load
earlier in the function.

This is probably not happening today because this function is not a
leaf function and is not eligible for inlining at the default
settings. The correctness of the function is relying on unspecified
compiler behaviour.

> are not concurrent. (This is just a slightly more precise way of
> stating the natural, intuitive behavior of a mutex.) Therefore, that
> read *must* observe the previously written value.

I don't agree, the intermixing of atomic and non atomic accesses to
this value create an ambiguity, we've had cases of this reported into
the past with other intermixing of atomic and non atomic loads.

>
> On Thu, Dec 28, 2017 at 7:11 PM, Dave Cheney <d...@cheney.net> wrote:
>> I think you are right, all access to that field should go via atomic 
>> load/store operations. I don’t think it’s safe to mix those operations wth 
>> normal loads and stores even within the same goroutine.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and 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] The o.done access on the once.Do function

[Dave Cheney]

I think you are right, all access to that field should go via atomic load/store 
operations. I don’t think it’s safe to mix those operations wth normal loads 
and stores even within the same goroutine. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 gc time STW1=>Mark=>STW2

[Dave Cheney]

Yes, please see the description of the operation of th garbage collector. 

https://github.com/golang/go/blob/master/src/runtime/mgc.go#L66

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 gc time STW1=>Mark=>STW2

[Dave Cheney]

I’m sorry I don’t understand the question you are asking but what I see from 
those gc times is your go busy() goroutine is blocking the STW1 phase because 
Go cannot currently preempt running functions. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: github repo names with "go-" prefix?

[Dave Cheney]

On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples  wrote:
> I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently dropping 
> the prefix in the actual package name) -- yet a similar naming scheme doesn't 
> seem to be commonplace among many other languages.
> 

I believe the zeitgeist originated with JavaScript.

> 
> Is this recommended somewhere?  If so, where?
>

It is not recommended for your package’s  repository or directory name to 
differ from its  package declaration. 

> 
> Conversely, is it explicitly discouraged?

Yes, for the reasons above, it’s confusing, also it’s redudant for the same 
reasons go programmers do not start interface declarations with a capital I. 

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

Re: [go-nuts] How to show reason, why code is slow.

[Dave Cheney]

Not that I’m aware of. 

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