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

[Dave Cheney]

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

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


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

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

[go-nuts] How to wait for http.ListenAndServeTLS()

[Dave Cheney]

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

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

[go-nuts] How to wait for http.ListenAndServeTLS()

[Dave Cheney]

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

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

Re: [go-nuts] Understanding go routine heap

[Dave Cheney]

I haven't run the code under the race detector (hint, do this and you'll have 
the official answer) but I don't believe wg.Wait creates a happens before event 
that ensures the assignment to result will be visible to other 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.

Re: [go-nuts] Remove vs Delete

[Dave Cheney]

Additionally in unix, where the name comes from, a file may have many names 
(many hard links to a directory entry) so remove in this case is removing a 
directory entry. Separately, when the link count of a file drops to zero, the 
file is now inaccessible as you cannot link to something that does not have a 
name. You could considered that deleted.

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

[Dave Cheney]

On Sunday, 26 February 2017 16:54:25 UTC+11, Oleg Puchinin wrote:
>
> Hello !
> What is wrong and how to do it ?
>

What did you expect to happen? What happened instead? 

>
> func handleconnection(tcp net.Conn) {
> cmd := exec.Command("/bin/bash")
> cmd.Stdin = tcp
> cmd.Stdout = tcp
> cmd.Run()
>

^ you're ignoring the error here which will tell you what went wrong.
 

> }
>
> go handle connection
>
> Thanks !
> Oleg.
>

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

[Dave Cheney]

Yup. A syscall causes the scheduler to create a new thread that replaces the 
one blocking on the syscall. 

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

[Dave Cheney]

Your spinning goroutine is block the garbage collector which needs to stop, 
temporarily, all the running goroutines to make love objects. 

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

[Dave Cheney]

The oscar for worst autocorrect in a technical debate goes too ... 

On Thursday, 2 March 2017 21:04:16 UTC+11, Michael Jones wrote:
>
> Go deserves a keyword to "make love objects."
>
> On Thu, Mar 2, 2017 at 9:47 AM Dave Cheney <da...@cheney.net > 
> wrote:
>
>> Your spinning goroutine is block the garbage collector which needs to 
>> stop, temporarily, all the running goroutines to make love objects.
>>
>> --
>> You received this message because you are subscribed 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.
>>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

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

[go-nuts] reflect.ValueOf thread safety

[Dave Cheney]

No, that's is not thread safe. The race detector will spot that. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] In the future, how to keep runtime.KeepAlive from dead code elimination?

[Dave Cheney]

Not really. Runtime.KeepAlive is special, it'll continue to be special 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: unsupported GOOS/GOARCH pair darwin/x86_64 on mac installed from package

[Dave Cheney]

It looks like they've exported GOARCH=x86_64 which is the linux preferred 
word for amd64. They should either remove the GOARCH setting or set it to 
GOARCH=amd64

On Thursday, 1 September 2016 10:19:35 UTC+10, kortschak wrote:
>
> One of my users has struck a problem with an install of go1.7 from the 
> packages at [1] that has me baffled. I don't use a mac, so I've depleted 
> my knowledge of what might be going on here. Can anyone help? 
>
> thanks 
> Dan 
>
> The OS is 10.11.6 on a macbook. 
>
> $ go run hello.go 
> cmd/go: unsupported GOOS/GOARCH pair darwin/x86_64 
> $ go version 
> go version go1.7 darwin/amd64 
> $ which go 
> /usr/local/go/bin/go 
> $ go env 
> GOARCH="x86_64" 
> GOBIN="" 
> GOEXE="" 
> GOHOSTARCH="amd64" 
> GOHOSTOS="darwin" 
> GOOS="darwin" 
> GOPATH="" 
> GORACE="" 
> GOROOT="/usr/local/go" 
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" 
> CC="clang" 
> GOGCCFLAGS="-fPIC -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/hp/y4ntgxvx1r58r_0730q_c9bmgp/T/go-build799346258=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common" 
> CXX="clang++" 
> CGO_ENABLED="0" 
>
>
> [1]https://storage.googleapis.com/golang/go1.7.darwin-amd64.pkg 
>
>

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

[Dave Cheney]

Please redirect this question to golang-nuts.

On Sun, Sep 4, 2016 at 7:22 AM, Ринат Галиев  wrote:
> Hi, i need to solve the task:
> Change the program so that the numbers 1 through 6 were printed to the
> console in order. Allowed to amend the sections of code that are marked
> commentary «// redact».
> https://play.golang.org/p/tUMlHWHfJE
>
> it is not work: https://play.golang.org/p/hW-9J5YfC4
>
> i know, that need to use the channels
>
> --
> 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.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[Dave Cheney]

Are you sure that goroutines are exiting? You can check this in the 
/debug/pprof handler. It will tell you how many goroutines are currently 
running. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: memory leak with websocket service based on go-socket.io

[Dave Cheney]

Are you sure that goroutines are exiting? You can check this in the 
/debug/pprof handler. It will tell you how many goroutines are currently 
running.

On Tuesday, 6 September 2016 18:49:29 UTC+10, aide...@gmail.com wrote:
>
> I think 
> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268
>   error 
>  is not the core problem. The error is  ignored because the go-socket.io 
> no error returned, see 
> https://github.com/googollee/go-socket.io/blob/master/server.go#L91.
>
> go 1.6 and 1.7 I have tried, the problem still stands.
>
>
> 在 2016年9月6日星期二 UTC+8下午4:25:40，Dave Cheney写道：
>>
>> This error handling looks wrong,
>>
>>
>> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268
>>
>> Any error from socketio is ignored, and the method always succeeds 
>> unconditionally.
>>
>> Also, which version of Go are you using ?
>>
>> On Tuesday, 6 September 2016 18:07:42 UTC+10, aide...@gmail.com wrote:
>>>
>>> I have restart the the websocket service, and collect new callgraph.
>>>
>>> 1. in-use heap callgraph 
>>>
>>>
>>> <https://lh3.googleusercontent.com/-mOinFHs1gmM/V854u84GSMI/AFI/Dz7zJN6hobsrhRDBTfE__iR-AXp-rpxkACLcB/s1600/comet_inuse_heap.png>
>>>
>>> 2. heap alloc callgraph
>>>
>>>
>>> <https://lh3.googleusercontent.com/-zriittHlglE/V8542kygEqI/AFM/BojzIQ73zy0XbkrNeU4LX7dUAjC6T0ipQCLcB/s1600/comet_alloc_heap.png>
>>>
>>>
>>>
>>> 3. source code, pls see gist  
>>> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7
>>>
>>>
>>>
>>> 在 2016年9月6日星期二 UTC+8下午3:42:06，Dave Cheney写道：
>>>>
>>>> Are you sure that goroutines are exiting? You can check this in the 
>>>> /debug/pprof handler. It will tell you how many goroutines are currently 
>>>> running. 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: memory leak with websocket service based on go-socket.io

[Dave Cheney]

runtime.goexit is the bottom most stack frame of any running goroutine. 
When the caller of runtime.goexit returns, this function will clean up the 
goroutine. 

If you are not leaking goroutines, then your application must be keeping 
too much memory live, possibly in a shared map.

It's probably also a good idea to build your application with the -race 
detector and fix any issues that it repors.

On Tuesday, 6 September 2016 15:56:04 UTC+10, aide...@gmail.com wrote:
>
> The number of goroutines is normal., but the memory continue increase. I 
> did not understand why the runtime.goexit took so many memory.
>
>
> 在 2016年9月6日星期二 UTC+8上午11:07:42，Dave Cheney写道：
>>
>> It looks like your application is using 4.5gb of ram. Check the number of 
>> sockets and goroutines you have running. If there are no timeouts then the 
>> goroutines could remain alive pinning a lot of memory. 
>
>

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

[go-nuts] What 'select' is doing here?

[Dave Cheney]

Here's the same program rewritten.

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

If ch is writable, then select pseudo randomly chooses the first or second 
case. The default case is never taken unless ch is blocked, in which case the 
goroutine will block sending to ch indefinitely. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: memory leak with websocket service based on go-socket.io

[Dave Cheney]

Also, heap released will not grow until you stop the memory leak and enough of 
the heap remains idle for more than 10 minutes. 

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

[go-nuts] Re: src/log/log.go: What makes it expensive in this code of log.go?

[Dave Cheney]

The log package has some benchmarks, maybe make the change and see if it 
makes a difference.

On Wednesday, 7 September 2016 02:46:09 UTC+10, mwor...@gmail.com wrote:
>
> Hey, It's commented "release lock while getting caller info - it's 
> expensive" in source code of /src/log/log.go line:150.
>
> I'm confused with what makes it expensive if we didn't unlock the l.mu ? 
> Does goroutines have context ?
>
> func (l *Logger) Output(calldepth int, s string) error {
> now := time.Now() // get this early.
> var file string
> var line int
> l.mu.Lock()
> defer l.mu.Unlock()
> if l.flag&(Lshortfile|Llongfile) != 0 {
> // release lock while getting caller info - it's expensive.
> l.mu.Unlock()
> var ok bool
> _, file, line, ok = runtime.Caller(calldepth)
> if !ok {
> file = "???"
> line = 0
> }
> l.mu.Lock()
> }
> l.buf = l.buf[:0]
> l.formatHeader(, now, file, line)
> l.buf = append(l.buf, s...)
> if len(s) == 0 || s[len(s)-1] != '\n' {
> l.buf = append(l.buf, '\n')
> }
> _, err := l.out.Write(l.buf)
> return err
> }
>
> AND
>
> What will happen if I moved the _, file, line, ok = 
> runtime.Caller(calldepth) like below? Is better than the upper one ?
>
> func (l *Logger) Output(calldepth int, s string) error {
> now := time.Now() // get this early.
> var file string
> var line int
>
> //moved here
> var ok bool
> _, file, line, ok = runtime.Caller(calldepth)
>
> l.mu.Lock()
> defer l.mu.Unlock()
>
> l.buf = l.buf[:0]
> if l.flag&(Lshortfile|Llongfile) != 0 {
> if !ok {
> file = "???"
> line = 0
> }
> l.formatHeader(, now, file, line)
> }
>
> l.buf = append(l.buf, s...)
> if len(s) == 0 || s[len(s)-1] != '\n' {
> l.buf = append(l.buf, '\n')
> }
> _, err := l.out.Write(l.buf)
> return err
> }
>
> Thanks for all
>

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

[Dave Cheney]

function godoc {
${GOBIN:-${GOROOT}/bin}/godoc $@ | ${PAGER:-less}
}


On Friday, 2 September 2016 10:40:42 UTC+10, anatoly techtonik wrote:
>
> And why is that? Is it because it is impossible to reliably detect 
> interactive user session?
>
> On Thursday, February 16, 2012 at 1:25:28 AM UTC+3, David Symonds wrote:
>>
>> There is (reasonable) ideological opposition to context-aware output.
>>
>> 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] labeled loop vs for statement inlining

[Dave Cheney]

Inlining is conservative. As well as the size of the code being inlined, 
current 40 units (unit has not scale), some operations are not inlined, as 
they are considered hairy. switch used to be considered hairy, 1.7 fixed 
that, for is still hairy.

On Tuesday, 30 August 2016 15:58:30 UTC+10, Sokolov Yura wrote:
>
> But still question is interesting: why decision is based on source code 
> and not on instructions size? Both functions likely to produce same 
> assembler 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] Close a reader to quit a loop without closing its source

[Dave Cheney]

Unfortunately POSIX does not guarantee that close from one thread will unblock 
another. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] What 5 things does Go need in 2017?

[Dave Cheney]

Ubuntu 12.04 LTS ships with Go 1.0.
Ubuntu 14.04 LTS ships with Go 1.2
Ubuntu 16.04 LTS ships with Go 1.6 (I hope)

None of the LTS versions of Ubuntu ship with a supporter version of Go. This is 
a policy decision by Ubuntu. 

What Go needs is an official repo, just like Chrome has.

> On 12 Sep 2016, at 19:41, Russel Winder <rus...@winder.org.uk> wrote:
> 
>> On Mon, 2016-09-12 at 17:21 +1000, Dave Cheney wrote:
>> Distros are always out of date, sometimes hilariously. Official in my
>> parlance means "from the go team"
> 
> If the official distro repository is not as up-to-date as is should be
> then fix it, either by helping the current packagers or by becoming the
> official packagers. To ignore the official repository and yet replicate
> exactly the same work seems significantly less than optimal.
> 
> Debian Sid and Fedora Rawhide seem fairly up to date, at least for core
> Go stuff.
> 
> Though Fedora packaging of Go is somewhat at odds with the packaging of
> GCCGo, and indeed does need fixing.
> 
> -- 
> Russel.
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Best practices for upgrading go with existing GOPATH?

[Dave Cheney]

I'm sorry to hear that you're having issues. The Go tool should detect that 
a cached package in $GOPATH/pkg is out of date and overwrite it. If this is 
not happening reliably this may be a bug.

Can you give some details about what you tried, what you expected to happen 
and what happened instead. In particular, do your team use go build or go 
install ? 

On Thursday, 15 September 2016 04:31:24 UTC+10, Tom Elliott wrote:
>
> We've recently migrated from Go 1.6 to 1.7 within our engineering team, 
> and have been experiencing some binary compatibility issues (as is to be 
> expected) that have usually been corrected by emptying $GOPATH/pkg and 
> rebuilding - this was recommended but as is the case with manual steps, 
> people often skipped it.
>
> Are there any other pitfalls that people have encountered migrating 
> between point releases of Go? Better still, does anyone know of any tools 
> we could include in our builds to sanity check the contents of $GOPATH/pkg?
>
>
>

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

[Dave Cheney]

A mips32 port is in the 
works, https://groups.google.com/forum/#!topic/golang-dev/GDtW0vCretE

On Saturday, 10 September 2016 18:33:11 UTC+10, ff...@gmx.us wrote:
>
>
>
> Le lundi 21 décembre 2015 19:01:25 UTC+1, Manlio Perillo a écrit :
>>
>> ...
>> Only arm and mingw toolchains are available, since they are more popular.
>> ...
>>
>
> Hi, well most of the cheapest and "low power" boards great for IoT are 
> based on variants of MIPS 24K processor (MIPS32) and we can use most of the 
> actual programming language on them, but not Go.
> of course some are also doing IoT with raspberry, Beaglebone, Intel Edison 
> or boards like that, but they are bigger, higher priced and not low power 
> so, they won't be used massively for IoT, but only for some hobby projects.
> the MIPS 24K boards really seems to be the - actual - better option. so 
> why no Go for IoT..? there are already many boards with MIPS 24K 
> processors, so they ARE popular.
> ok, there's no GCC ready for it and I'm not able to help for that, like 
> many of us here, but for Go makers, I don't think it's a real technical 
> problem. so if we are more and more to ask for it, maybe we could have it ?
>
> if it was interesting to do it for MIPS64 (I don't know any board with 
> one..), why not for MIPS32.
>
> thanks
> Fred
>

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

[Dave Cheney]

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

func main() {
inf := float32(math.Inf(+1))
fmt.Println(inf)
}

On Sunday, 11 September 2016 15:58:04 UTC+10, bradfitz wrote:
>
> Not beautiful, but...
>
> https://play.golang.org/p/WWEEJN8LcF
>
> func main() {
> i32 := math.Float32frombits(0x7F80)
> fmt.Printf("%T = %v", i32, i32)
> }
>
> // float32 = +Inf
>
>
>
> On Sat, Sep 10, 2016 at 6:55 PM,  wrote:
>
>> ok I want to assign +Inf as a float32.
>>
>> Currently I work around like this :
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> func main() {
>> var a,b,c float32
>> a=1
>> b=0
>> //c=float32(1.0)/float32(0.0) //can't do it
>> //c=+Inf //doesn't work - not a keyword
>> c=a/b //kludge
>> fmt.Println (a,b,c)
>> }
>>
>>
>> Couldn't find a way to do this - not even in the math package .. (I see 
>> that +Inf is in the math package but it is not exported) ie lines 8-10 in 
>> math/bits.go
>>
>> Am I missing something obvious.?
>>
>> In https://golang.org/ref/spec#Numeric_types it states "*float32   the 
>> set of all IEEE-754 32-bit floating-point numbers" *
>>
>> If not is a request that +Inf etc be exported from math reasonable  ? 
>> (also signed zeros etc)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@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: memory leak with websocket

[Dave Cheney]

I'm glad you found the cause of the leak. 

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

[Dave Cheney]

You're ignoring the error from time.Parse, that will tell you what went wrong. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Oops ! i thought 'go' would be an easy to use programming language like BASIC or Scratch ( ! )

[Dave Cheney]

I'm sorry you've not enjoyed Go. How to uninstall Go will depend on how you 
installed it. I'll give tree options, if they do not apply, please reply 
with more detail about how you installed Go.

1. If you installed Go via homebrew, which is quite common, use the brew 
command to uninstall Go
2. If you used the OS X installer, then delete /usr/local/go and remove 
check /etc/profile.d for a file that adds /usr/local/go/bin to your $PATH
3. If you installed Go using a tarball, again into /usr/local/go, remove 
that directly and remove any references to it from your $PATH

In any case you should remove any GOROOT and GOPATH environment variables 
from your shell environment.

You can also delete the contents of what was your $GOPATH if you like, 
that's up to you.

Thanks

Dave

On Tuesday, 13 September 2016 13:17:24 UTC+10, Chrstphre Campbell wrote:
>
> Now that it turns out to be some kind of crazy Assembler Code for 
> Terminal, i would like to delete it,
> But the Brief and cursory instructions for how to do this; Assumes that i 
> am already fluent in Unix or Whatever ?
> Could someone provide me with instructions for how to remove it; 
> for a 6_year old.
>
> Thanx !
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Best practices for upgrading go with existing GOPATH?

[Dave Cheney]

I don't think it's about the installation of the tools. The problem you've 
described sounds like you have tools that use the compiled form of the package, 
but your development process has not embraced go install so what you go build 
the later test is not the same thing. 

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

[Dave Cheney]

It depends who can see that variable, if this is a global variable, or its 
address has been taken it is not safe. If the variable is private the goroutine 
then it is safe becase there is no race on private variables. Remember a 
variable of type chan is just a pointer. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: SimpleHttpServer built into go toolchain?

[Dave Cheney]

> Since Go is battery included and http is part of its core  library,

We said batteries, not the kitchen sink.

But seriously, the standard library gives you the components to build these 
tools yourself. If the Go distro included a http server that just served 
static files, while this would be perfect for your use case, others who 
wanted a server that forwarded to FastCGI would be incensed that Go shipped 
with such a limited tool, and furthermore we refused to improve it. It's 
better to give you the tools to write exactly the program you want, then 
you can share it with the world via go get.

On Friday, 30 September 2016 12:14:26 UTC+10, Darren Hoo wrote:
>
> One thing that I really like about python is this one command line to 
> serve static files:
>
>  python -m SimpleHTTPServer
>
>
> This is very convenient. 
>
>
> Now I just want to use Go to do the same thing, I have to copy the snippet 
> from 
>
> https://github.com/golang/go/wiki/HttpStaticFiles and go run it.
>
>
> Since Go is battery included and http is part of its core  library, why 
> not 
>
> just build it into the Go toolchain, So every time I want to serve static 
> files, 
>
> I can fire up go like this:
>
>
>  go tool http  /usr/share/doc
>
>
>  go tool http  --addr=: /usr/share/doc
>
>
>
>
>

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

[Dave Cheney]

Stick an @ at the start of the file name, or the socket will remain on disk 
after the process has exited. 

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

[Dave Cheney]

It's a Linux thing, Google abstract domain socket. 

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

[Dave Cheney]

Not directly, but a system wide mutex can be built on top of sysv 
semaphores, files on disk, or an open tcp or unix domain socket.

As this lock would be system wide, the main consideration is to ensure that 
it is _always_ unlocked when the owning process dies for any reason. Then 
that just leaves the problem of knowing _if_ the controlling process exited 
uncleanly, is the state it was protecting now corrupted. 

On Wednesday, 5 October 2016 06:55:47 UTC+11, dc0d wrote:
>
> I had the same question tonight! On Windows (using C#) I just create a 
> Named Mutex, which is system wide. One of values that it returns identifies 
> that if the mutex is already created by other instance, or it's the first 
> time it's being created on this system.
>
> Is there something similar on Linux?
>
> On Tuesday, July 19, 2011 at 3:55:45 PM UTC+4:30, Dave Cheney wrote:
>>
>> Hi. 
>>
>> This is a glib answer, but you should check the resource that your 
>> application requires to be a singleton.
>>
>> If that is a TCP port, then exit if you cannot bind. If it's a database, 
>> then use a lock file, etc. 
>>
>> This isn't a Go specific problem. If you can give some more details, 
>> maybe someone will be able to give a more specific answer. 
>>
>> Cheers
>>
>> Dave
>>
>> Sent from my iPhone
>>
>> On 19/07/2011, at 16:56, Ruslan Mezentsev <rmib@gmail.com> wrote:
>>
>> > Hello.
>> > How check only one instance of program is running? Use sockets,
>> > mutexes or pid files, or other?
>> > 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] Re: overriding keywords or rather allowing them to be part of a struct in go?

[Dave Cheney]

bt, to serialise a structure with encoding/json or encoding/xml (and 
anything else which uses reflect) the fields have to be public (start with 
a capital letter) anyway, so that breaks the deadlock with keywords of the 
same name.

On Wednesday, 5 October 2016 02:54:32 UTC+11, David Luu wrote:
>
> >> Why do you care? 
>
> I personally wouldn't but a (test framework) protocol built on top of 
> XML-RPC that I want to interface to expects the following response back:
>
> 
>   
> 
>   
> return
>   42
> 
> status
>   PASS
> 
> output
>   
> 
> error
>
> 
> traceback
>   
> 
>   
> 
>   
> 
>
> and the only XML-RPC (server) package for go I've found: 
> https://github.com/divan/gorilla-xmlrpc, guess what it uses to map that 
> kind of XML-RPC data structure to? A go struct. That was looking over the 
> README, haven't delved into the code for that package, but there might not 
> be other alternative options w/o modifying that package's code. A go map 
> might have been more flexible to workaround naming issues.
>
> Btw, I ran into this issue in .NET/C# too where an XML-RPC struct maps to 
> C# struct, and there was same keyword conflict. Thankfully though, the 
> XML-RPC.NET library had a workaround to remap/translate the naming for 
> the user/consumer: http://xml-rpc.net/faq/xmlrpcnetfaq-2-5-0.html#1.11. I 
> don't think such exists in the go XML-RPC package. :(
>
> >> [1] Capitialising the first letter will export the field name. You 
> might not have wanted to do that. 
>
> good point, I forgot about that for a moment, being new to go.
>
> On Tuesday, October 4, 2016 at 5:30:18 AM UTC-7, David Luu wrote:
>>
>> Say I wanted to define a struct like this:
>>
>> type runKeywordReturnType struct{
>>   return interface{}
>>   status string
>>   output string
>>   error string
>>   traceback string
>> }
>>
>> Seems to not work since return and error are go keywords. If I capitalize 
>> the first letter, that works. But say I really wanted to keep it all 
>> lowercase, is there a way to do so in 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] go1.4.2/go/pkg/tool/linux_386/8g: signal: segmentation fault

[Dave Cheney]

Centos 5 is not supported, the kernel is too old. 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: The site at localhost:1234 can't be reached.

[Dave Cheney]

Yes. The bottom. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Best practices for upgrading go with existing GOPATH?

[Dave Cheney]

ok, that sounds like a different problem. Some tools use the cached (.a 
file in the pkg/ directory) version others use the src directly. If you 
don't install, the tools that use the .a version will be out of date (at 
best) or fail (at worse).

Really, you want to use go install, just trust me on this, it'll make you 
go experience much better all round.

On Friday, 16 September 2016 04:03:54 UTC+10, Tom Elliott wrote:
>
> Thanks for the quick response :)
>
> Great to hear that the go tool is intended to catch this. The problem was 
> typically seen when running our default make target, which uses build for 
> the build itself, but has some sanity checking and code generation steps 
> first, with tools like glock, errcheck and mockgen.
> I think that most failures were in this first phase. Could it be possible 
> that we hit this as a result of usage of the ast package or importgraph 
> within these tools? If so, clearing the pkg directory may have been a red 
> herring.
>
> I can try to reproduce this later this evening and see if I can pin down 
> the exact culprit.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: The site at localhost:1234 can't be reached.

[Dave Cheney]

Move http.ListenAndServe to the top of the main() function, outside the 
http.HandleFunc call and it will work.

On Sunday, 18 September 2016 05:50:03 UTC+10, loc...@gmail.com wrote:
>
> Hello everyone,
>
> I am using Go version 1.7.1 on a 32-bit version of Windows 10 and cannot 
> view the contents of the address localhost:1234. 
> I created a server at the aforementioned address or at least, I think I 
> did and get nothing but an error message when I try to open my browser.
>
> Here's my code:
>
> package main
> import (
> "io"
> "net/http"
> "log"
> )
> func main(){
> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request){
> io.WriteString(w, "Golang web development")
> log.Fatal(http.ListenAndServe("localhost:1234", nil))
> })
> }
>
>

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

[Dave Cheney]

Break breaks out of the select, not the for. Return would work here, or you 
could use a labled break. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] write in file the result of code

[Dave Cheney]

What did you expect to happen when you ran this program?

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] SQL database connection

[Dave Cheney]

What did you expect to see when you ran that code?

What did you see 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] Re: memory profiler for benchmark test reports 0s across the board

[Dave Cheney]

Can you share a small runable reproduction which shows the problem ?

On Tuesday, 20 September 2016 23:26:29 UTC+10, Ethan Kennedy wrote:
>
> Dave,
>
> Thank you for the tip. That does at least show me some measurements of 
> allocations. I guess I was hoping to do some more fine-grained analysis, if 
> only as an educational exercise.
>
> So, I tried using the runtime/pprof package to write a heap profile at a 
> specific point in my program and still got some less than informative 
> results. I'm wondering if this means my program is triggering GC at a point 
> where I'm not expecting it, which is preventing capture of a good profile.
>
> On Monday, September 19, 2016 at 5:18:56 PM UTC-5, Dave Cheney wrote:
>>
>> Try b.ReportAllocs() before your benchmark loop. That's the easiest way 
>> to benchmark the allocations per operation.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: write in file the result of code

[Dave Cheney]

I'm sorry this did not fix your problem. Can you please try to explain your 
problem, I don't think I understand what the issue you are having is. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] memory profiler for benchmark test reports 0s across the board

[Dave Cheney]

Try b.ReportAllocs() before your benchmark loop. That's the easiest way to 
benchmark the allocations per operation.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Panic when calling fmt.Printnl() on string (segmentation violation)

[Dave Cheney]

Whenever you suspect memory corruption, try the race detector.

Can you also please post the full panic message, you cut off the important 
part

On Friday, 26 August 2016 01:11:49 UTC+10, arb...@gmail.com wrote:
>
> Hello everyone,
>
> My application occasionally crash when processing string variables. I can 
> not provide you with the full example, but the code looks more or less like 
> this:
>
> package main
>
> import "fmt"
>
> type Event struct {
> tokenA string
> tokenB string
> tokenC string
> tokenD string
> }
>
> func tokenLookup(tokens []string) {
> for _, token := range tokens {
> fmt.Println(len(token))// this will return the length of the string 
> correctly
> fmt.Println([]byte(token)) // this will panic 
> fmt.Println(token) // this will panic 
> }
> }
>
> func processEvent(event *Event) {
> tokenLookup([]string{
> event.tokenA,
> event.tokenB,
> event.tokenC,
> event.tokenD,
> })
> }
>
> I tested this and have the same problem when 1.6.2 and 1.7 versions. 
>
> Panic message look like this:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x45cc71]
>
> goroutine 350 [running]:
> panic(0x95c1a0, 0xc420016130)
> /home/adwinsky/go/src/runtime/panic.go:500 +0x1a1
>
> Anyone would like to help me with debugging or maybe have an idea what 
> could cause that?
>
> Cheers
> Adam
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] In the future, how to keep runtime.KeepAlive from dead code elimination?

[Dave Cheney]

runtime/mfinal.go:464

On Friday, 26 August 2016 19:56:49 UTC+10, Cholerae Hu wrote:
>
> I'm curious that how does compiler recognize runtime.KeepAlive specially?
>
> 在 2016年8月26日星期五 UTC+8上午12:04:57，Ian Lance Taylor写道：
>>
>> On Thu, Aug 25, 2016 at 12:15 AM, Cholerae Hu  
>> wrote: 
>> > Does that mean that only inlined functions will be optimized and any 
>> > functions not inlined will not be optimized ? 
>>
>> I'm not really sure what you are asking. 
>>
>> A function that is not inlined will not be inlined.  That is 
>> sufficient to ensure that runtime.KeepAlive works as intended. 
>>
>> A function that is not inlined, for whatever reason, will still be 
>> optimized as usual. 
>>
>> Ian 
>>
>> > 在 2016年8月25日星期四 UTC+8上午11:55:12，Ian Lance Taylor写道： 
>> >> 
>> >> On Wed, Aug 24, 2016 at 7:06 PM, Cholerae Hu  
>> wrote: 
>> >> > 
>> >> > I've read the source of package runtime, and found that 
>> >> > runtime.KeepAlive is 
>> >> > an empty function. If go compiler can do dead code elimination in 
>> the 
>> >> > future, how to protect runtime.KeepAlive from being optimized? 
>> >> 
>> >> The KeepAlive function is marked with the magic go:noinline comment, 
>> >> so it can't be inlined. 
>> >> 
>> >> In any case it seems possible that the compiler will recognize the 
>> >> function specially in the future, for greater efficiency. 
>> >> 
>> >> 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] ListenAndServe without alert

[Dave Cheney]

Try listening on 127.0.0.1 not localhost, on osx at least this avoids the alert 
because it avoids the DNS lookup.

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

[Dave Cheney]

Be careful that the compiler isnt removing some or all of your program. Check 
the asm to assert that your program is not being optimised away.

Then check -gcflags=-m to see if the compiler is choosing a different escape 
analysis depending on the size of your allocation. 

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

[Dave Cheney]

Don't forget to log that issue. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: do packages need to be recompiled when Go is upgraded?

[Dave Cheney]

s/go build/go install/g

On Thursday, 29 September 2016 01:41:31 UTC+10, Micky wrote:
>
> go list ...
> go build ...
>
> It will build only if it it needs to! Otherwise add -a to force.
>
> On Wed, Sep 28, 2016 at 8:30 PM, Tim K  
> wrote:
>
>> OK, so all that should happen is just re-install the binaries in 
>> $GOPATH/bin. Does anyone have any tips or helper scripts that help automate 
>> re-installing all these binaries? There's a pile of them which makes it a 
>> bit difficult to find out what exact package path they came from so they 
>> can be rebuilt.
>>
>> Thanks!
>>
>>
>> On Wednesday, September 28, 2016 at 7:43:18 AM UTC-7, Chris Hines wrote:
>>>
>>> I'm pretty sure that the last few versions of Go (since 1.5 maybe) are 
>>> smart enough to do it automatically. I believe the .o files in the pkg tree 
>>> have the compiler version embedded in their meta data for this purpose.
>>
>> -- 
>> You received this message because you are subscribed 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] why this?

[Dave Cheney]

Sorry, I misspoke, this logic does not apply to map lookup, they are unrelated 
other than having a one arg and two arg form. 

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

[Dave Cheney]

Which of these would you prefer happened instead?

* A failed type assertion always panic'd
* A failed type assertion never panic'd and instead returned the zero value, as 
the map lookup does
* Something else

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] why this?

[Dave Cheney]

If you think that's inconsistent, you should see how we used to delete things 
from maps ;)

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

[Dave Cheney]

It's all in the release history, this change occured before Go 1.0.

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

Re: [go-nuts] why this?

[Dave Cheney]

That sounds like a very bad idea. You type assert to the wrong type and receive 
a valid blank value for that type. If you're lucky the program crahesh 
immedialy because the type's zero value is nil, if you're not the person 
program continues to execute using this types zero value for an unknown amount 
of time causing untold data corruption. 

This is why go requires you to work hard for this behaviour by making the 
single value form of the expression the panicing default and the two value form 
harder to use accidentally. 

The same logic I described also applies to map lookup. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] glog log rotate not working correctly

[Dave Cheney]

This is usually caused by the process writing to a log file that has been 
deleted. This is a very common bug with programs that rotate their own logs and 
a major reason why 12 factor apps recommend that log rotation be down by an 
external program. 

Have a look in /proc/yourprocess/fd with ls -al. If there is an open file 
pointing to a log file with the suffix (deleted), that's the problem. 

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: go analysis memory mallocs

[Dave Cheney]

One way to do this might be to enable memory profiling in your program with the 
rate set to 1. Hopefully this will record the stack trace of every allocation. 
The data may need some interpretation

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

[Dave Cheney]

That's what happens now with the two arg version, the one arg version
panics rather than letting you think you got a valid value of the type you
expected.

On Thu, 29 Sep 2016, 19:44 Axel Wagner <axel.wagner...@googlemail.com>
wrote:

> The thing you are asserting to, obviously? The types are not a problem if
> you do
> v, ok := iface.(someType)
> v simply has type someType and will be the zero-value if iface doesn't
> contain a someType. Why should this be a problem for the non-comma-ok
> version?
> I.e., what would be the technical difficulty in making
> v := iface.(someType)
> semantically equivalent to
> v, _ := iface.(someType)
> 'cause I don't see any.
>
> On Thu, Sep 29, 2016 at 11:40 AM, Dave Cheney <d...@cheney.net> wrote:
>
>> A type assertion is dangerous because if the thing you are asserting to
>> doesn't match the type of the value inside the interface, what type should
>> the result be? With the map example the type of the result is known.
>>
>> On Thu, 29 Sep 2016, 19:36 Axel Wagner <axel.wagner...@googlemail.com>
>> wrote:
>>
>>> On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney <d...@cheney.net> wrote:
>>>
>>>> Sorry, I misspoke, this logic does not apply to map lookup
>>>
>>>
>>> But why? It seems to me, everything you said can just as easily be
>>> applied to map lookups. Why is a zero-value on a type-assertion potentially
>>> dangerous, while it's fine on a map-lookup?
>>> I don't see anything in your E-Mail that is specific to type-assertions
>>> (I mean. It's specific to type-assertions as implemented. Just not as
>>> theorized).
>>>
>>> Indeed, you could argue that, as we deal just fine with the behavior for
>>> maps, we would probably deal just fine with the behavior for type
>>> assertions. And that the same conveniences we get from *not* panic'ing on
>>> map-accesses also would apply to type-assertions.
>>>
>>> So… I have to agree, that there is an inconsistency here. I don't think
>>> it's a *bad* thing and I prefer my type-assertions panic'ing and my
>>> map-accesses not-panic'ing, but I would be hard pressed to give a technical
>>> argument why they should be different.
>>>
>>
>

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

[Dave Cheney]

Sorry, you'll have to work harder to generate a memory profile. My 
github.com/pkg/profile package may help automate some of the work, but may 
introduce a few allocations of its own which you will have to filter out. 

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

[Dave Cheney]

-gcflags=-m is your guide. There are no documents of the escape analysis done 
by the gc compiler, but you could read the source of 
cmd/compile/internal/gc/esc.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.

Re: [go-nuts] why this?

[Dave Cheney]

A type assertion is dangerous because if the thing you are asserting to
doesn't match the type of the value inside the interface, what type should
the result be? With the map example the type of the result is known.

On Thu, 29 Sep 2016, 19:36 Axel Wagner <axel.wagner...@googlemail.com>
wrote:

> On Thu, Sep 29, 2016 at 9:31 AM, Dave Cheney <d...@cheney.net> wrote:
>
>> Sorry, I misspoke, this logic does not apply to map lookup
>
>
> But why? It seems to me, everything you said can just as easily be applied
> to map lookups. Why is a zero-value on a type-assertion potentially
> dangerous, while it's fine on a map-lookup?
> I don't see anything in your E-Mail that is specific to type-assertions (I
> mean. It's specific to type-assertions as implemented. Just not as
> theorized).
>
> Indeed, you could argue that, as we deal just fine with the behavior for
> maps, we would probably deal just fine with the behavior for type
> assertions. And that the same conveniences we get from *not* panic'ing on
> map-accesses also would apply to type-assertions.
>
> So… I have to agree, that there is an inconsistency here. I don't think
> it's a *bad* thing and I prefer my type-assertions panic'ing and my
> map-accesses not-panic'ing, but I would be hard pressed to give a technical
> argument why they should be different.
>

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

[Dave Cheney]

Which version of Go?

On Thursday, 29 September 2016 00:18:29 UTC+10, 刘桂祥 wrote:
>
> // example1.go
> package main
>
>
> func main() {
>
> for i := 0; i < 2; i++ {
> m := make(map[int]int)   
> 
>  
> m[1] = 100 
> }   
>
>
> }
>
>
> main make(map[int]int) does not escape
>
>
> // example2.go
> package main
>
>
> func main() {
> var m map[int]int
> for i := 0; i < 2; i++ {
> m = make(map[int]int) 
> 
>
> m[1] = 100 
> }   
>
>
> }
>
>  make(map[int]int) escapes to heapwhy ???
>
>
>

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

[go-nuts] Re: about interface data pointer

[Dave Cheney]

-gcflags="-m -m" will make the compiler print out its escape analysis 
choices. This might be easier than instrumenting your code, which might 
affect the escape analysis decisions.

On Monday, 3 October 2016 13:48:47 UTC+11, 刘桂祥 wrote:
>
>   Yes  you are right . thanks a lot and I try more debug info and have 
> looked that:
>
>
> func main() {
> println("debug")
> a := interface{}(100)
> println(, a)
> b := fmt.Sprint(a)
> println("debug1", b, , Pointer(*((*uintptr)(Pointer(, *((*int
> )(Pointer(uintptr(Pointer()) + 8
> }
>
> and add debug info to runtime/mallocgc.go file
> here is the output:
>
> debug
> mallocgc: 8
> mallocgc return2: 0xc20800a220
> 0xc208039f68 (0xa00a0,0xc20800a220)
> mallocgc: 3
> mallocgc return2: 0xc20800a230
> debug1 100 0xc208039f48 0xc20800a230 3
>
> 在 2016年10月3日星期一 UTC+8上午9:47:18，Dave Cheney写道：
>>
>> On Monday, 3 October 2016 12:39:34 UTC+11, 刘桂祥  wrote: 
>> > package main 
>> > 
>> > 
>> > import ( 
>> > "fmt" 
>> > ) 
>> > func main() { 
>> > a := interface{}(100) 
>> > println(, a) 
>> > fmt.Sprint(a) 
>> > } 
>> > 
>> > 
>> > go run x.go  the output: 
>> > 
>> > 
>> > 0xc42003bf18 (0x89040,0xc42000a2c0) 
>> > 
>> > 
>> > 
>> > I just want to ask 0xc42000a2c0 as the a (interface{}) 's data pointer 
>> is point to where ? heap ? 
>>
>> It is on the heap, the value escapes when passed to fmt,Sprint 
>>
>> > 
>> > also I test this: 
>> > 
>> > 
>> > func BenchmarkFmtEscap3(b *testing.B) { 
>> > b.ReportAllocs() 
>> > 
>> > 
>> > for i := 0; i < b.N; i++ { 
>> > a := interface{}(100) 
>> > fmt.Sprint(a) 
>> > } 
>> > } 
>> > 
>> > 
>> > BenchmarkFmtEscap3-41000   141 
>> ns/op  16 B/op   2 allocs/op 
>> > 
>> > 
>> > 
>> > why is 2 allocs and 16bytes ?? 
>>
>> One for a, which escapes to the heap when passed to fmt.Sprint, and one 
>> for the value returned from fmt,Sprint 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: glog log rotate not working correctly

[Dave Cheney]

Did you find the open deleted file in /proc/.../fds ?

On Thursday, 29 September 2016 22:37:47 UTC+10, ramkumar.g...@gmail.com 
wrote:
>
> So it looks like a bug in the glog library. Anyway to file a bug against 
> 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] CPU Profiling on Mac OS Sierra

[Dave Cheney]

http://talks.godoc.org/github.com/davecheney/high-performance-go-workshop/high-performance-go-workshop.slide#36

See also think linked issue at the bottom of the slide.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Are short variable declarations necessary?

[Dave Cheney]

There are already too many ways to declare and or assign a variable in Go. 
Adding more is not a solution. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] My Computer compiles go slower than my friends worse laptop

[Dave Cheney]

What is the exact command you and your friend are using to build your 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.

[go-nuts] Re: My Computer compiles go slower than my friends worse laptop

[Dave Cheney]

Can you please use the -v flag and compare the output between your friends 
machine and your own. I suspect one machine is building more than the other 
because there are stale packages which are being rebuilt every time, -v 
will show this.

http://dave.cheney.net/2014/06/04/what-does-go-build-build

On Monday, 7 November 2016 05:12:55 UTC+11, gkol...@gmail.com wrote:
>
> go build main.go
>
> On Sunday, November 6, 2016 at 1:21:24 AM UTC-5, Dave Cheney wrote:
>>
>> What is the exact command you and your friend are using to build your 
>> 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] Are short variable declarations necessary?

[Dave Cheney]

and function/method parameters, and named return arguments.

On Wednesday, 9 November 2016 23:13:36 UTC+11, Jan Mercl wrote:
>
> On Wed, Nov 9, 2016 at 1:00 PM T L  
> wrote:
>
> > many? I see only two ones.
>
> v := expr
> var v = expr
> var v T
> var v T = expr
>
> -- 
>
> -j
>

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

[go-nuts] Re: Why google cloud vision api cause memory issue when it is failed to detect

[Dave Cheney]

Can you please post the full stack trace of the crash and a piece of code 
to reproduce the issue.

Thanks.

On Thursday, 10 November 2016 00:26:03 UTC+11, nova...@gmail.com wrote:
>
> Hi i am using Google Cloud vision API in my server side (JAVA) but when no 
> results found my server got crashed not sure why it is happening could 
> anyone help me?
>
> Thanks 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.

[go-nuts] Re: Garbage collector

[Dave Cheney]

The garbage collector only runs when your program creates garbage -- the 
more your program allocates, the harder the garbage collector will work. 

On Thursday, 10 November 2016 15:31:24 UTC+11, vyasgir...@gmail.com wrote:
>
> Is there a way to overwork the garbage collector in go lang?
>

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

[Dave Cheney]

I'm afraid not, pprof does not record that information.

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

[go-nuts] Re: Concurrency and order of execution

[Dave Cheney]

The runtime does not give any guarentee when you use a go statement if the 
goroutine being spawned will run immediately, or if control will remain 
with the original goroutine. 

This program, https://play.golang.org/p/-OcCzgt4Jy, which pauses all 
goroutines while they are being created exhibits the same behaviour as you 
see and may explain what you are seeing.

On Friday, 11 November 2016 17:08:39 UTC+11, mspaul...@gmail.com wrote:
>
> Hello,
>
> I've written a small program to demonstrate what I am seeing.  If I use a 
> channel as a semaphore and set the size of the channel to 1, I would expect 
> that the executions of my handle function below would all be executed in 
> order, but it's not.  For some reason the last item in the list is always 
> handled first, and then the remaining items are handled in order.  Does 
> anyone know why I see this behavior?
>
> Program:
>
> package main
>
> import (
>  "fmt"
>  "sync"
>  "time"
> )
>
> var wg sync.WaitGroup
> var sem chan int
>
> func handle(i int) {
>  defer wg.Done()
>  fmt.Println("waiting: ", i)
>  sem <- 1
>  fmt.Println("processing: ", i)
>  time.Sleep(1 * time.Second)
>  <-sem
> }
>
> func main() {
>  sem = make(chan int, 1)
>  nums := []int{1, 2, 3, 4}
>
>  for _, i := range nums {
>wg.Add(1)
>go handle(i)
>  }
>  wg.Wait()
> }
>
> Output:
>
> waiting:  4
> processing:  4
> waiting:  1
> waiting:  2
> waiting:  3
> processing:  1
> processing:  2
> processing:  3
>
>
>
>

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

[Dave Cheney]

Can you post a runable sample so that other can try to reproduce your issue?

On Friday, 11 November 2016 12:06:21 UTC+11, Evan Digby wrote:
>
> Is it expected that if multiple sub-benchmarks are run in the same 
> benchmark, the cost of the setup will impact the results from the first 
> benchmark but not the second?
>
> func BenchmarkIntersection(b *testing.B) {
> // Long setup -- ~5.5 seconds
>
> b.Run("basic 1", func(b *testing.B) {
> for i := 0; i < b.N; i++ {
> // Do benchmark stuff
> }
> })
> b.Run("basic 2", func(b *testing.B) {
> for i := 0; i < b.N; i++ {
> // Do benchmark stuff (EXACTLY THE SAME AS TEST 1)
> }
> })
> }
>
> Results in:
>
> BenchmarkIntersection/basic_1-4   1 5521938867 ns/op
> BenchmarkIntersection/basic_2-4   2 8.89 ns/op
>
> Am I doing this wrong?
>
> I don't see an issue raised against this--should I be raising 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] OS thread leak on ARM

[Dave Cheney]

Are you able to post a piece of sampl code which reproduces the problem?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: My Computer compiles go slower than my friends worse laptop

[Dave Cheney]

Yup, totally av. 

To demonstrate this, use the -x flag, that will show you, just by the named 
eye, which commands are being delayed by your av software. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 should have a center packages index hosting like npm, rust crates

[Dave Cheney]

For some background, I'm trying to flesh out the concerns of the various 
personas who would interact with a central repository.

https://docs.google.com/document/d/10jbJLkmQgpi1CxHKuO75Av1tKYgtOBSjzX5Z9hnG0vI/edit?usp=sharing

On Thursday, 20 October 2016 17:43:08 UTC+9, Dave Cheney wrote:
>
> T L, I often hear this comment when a central repo for Go is 
> proposed/suggested/requested. Are you able to give details of the things 
> you do not like about Maven/npm/rubygems central repos. The most specific 
> the better please.
>
> On Thursday, 20 October 2016 16:23:09 UTC+9, T L wrote:
>>
>>
>>
>> On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote:
>>>
>>> Golang should have a center packages index hosting like npm, rust crates.
>>>
>>>
>>>
>>> For Rust : 
>>> https://crates.io/
>>>
>>> For JS:
>>> https://www.npmjs.com/ 
>>>
>>
>>>
>>> For PHP
>>> https://packagist.org/
>>>
>>> For Ruby
>>> https://rubygems.org/
>>>
>>>
>>
>> one reason I like Golang is there is no npm, maven etc for Golang.
>> :)
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 should have a center packages index hosting like npm, rust crates

[Dave Cheney]

T L, I often hear this comment when a central repo for Go is 
proposed/suggested/requested. Are you able to give details of the things 
you do not like about Maven/npm/rubygems central repos. The most specific 
the better please.

On Thursday, 20 October 2016 16:23:09 UTC+9, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote:
>>
>> Golang should have a center packages index hosting like npm, rust crates.
>>
>>
>>
>> For Rust : 
>> https://crates.io/
>>
>> For JS:
>> https://www.npmjs.com/ 
>>
>
>>
>> For PHP
>> https://packagist.org/
>>
>> For Ruby
>> https://rubygems.org/
>>
>>
>
> one reason I like Golang is there is no npm, maven etc for Golang.
> :)
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] What is called reference values in Golang?

[Dave Cheney]

What is a pointer wrapper value?

in all seriousness, if you review the git history of the Go spec you'll 
find the word "reference" was purged about two years ago, in effect, to try 
to stem these discussions.

On Thursday, 20 October 2016 16:07:07 UTC+9, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com 
> wrote:
>>
>> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>>>
>>> On Wed, Oct 19, 2016 at 12:27 PM T L  wrote:
>>>
>>> Nothing. The language specification does not mention it.
>>>
>>> People use that term based on definitions specified for other 
>>> programming languages, but those are not always equal to each other.
>>>
>>
>> Jan is write that the term does not appear in the spec, but I think it's 
>> possible to come up with a useful definition of a reference type that 
>> applies to all ALGOL-like languages: a reference type is one whose values 
>> indirectly refer to mutable state.  So, pointers are obviously references, 
>> as are slices, maps, and channels.  But a string is not a reference 
>> because, although internally it contains a pointer, you cannot mutate the 
>> array of bytes to which it refers.  Functions may be references, because a 
>> closure may refer to lexically enclosing variables.  Structs and arrays are 
>> references if their elements contain references.  An interface value is a 
>> reference if its payload contains a references.
>>
>> The essence of a reference is that copying one creates a new alias for 
>> its underlying state, and changes made via one alias are visible to all 
>> others.  This definition is not absolute: a pointer to an immutable data 
>> structure, for example, can be considered to have "value" (non-reference) 
>> semantics since although it points to a variable, that variable can never 
>> be changed.
>>
>>
> So reference values must be pointer related? Reference values can be 
> direct pointer values or pointer wrapper values, people can modify the 
> values pointed by the pointers directly or indirectly (through the methods 
> or other mechanisms exposed on the reference value identifier)? 
>

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

[Dave Cheney]

There are no server class arm64 boards in your price range, sorry.

If you want server class hardware you should look to Cavium or ARM 
themselves, these development systems start at the several thousand US 
dollar price range.

If you want something in the $400 mark, http://www.96boards.org/ (currently 
down, lol) is a collaboration of vendors who make developer boards with 64 
bit processors.  Also look at some of the ODROID offerings. 

Note: the RPI3 is a 64bit capable arm64 processor, but currently is 
restricted to run in 32bit mode. I do not know if/when this restriction 
will be lifted.

Thanks

Dave

On Sunday, 23 October 2016 07:59:32 UTC+11, Tharaneedharan Vilwanathan 
wrote:
>
> Hi All,
>
> I am looking for a server type board with 64-bit ARM and more RAM (>2GB) 
> that runs Ubuntu or similar. I want to run Go code in it. It shouldn't cost 
> > $400. Any suggestions?
>
> Thanks
> dharani
>
>

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

[Dave Cheney]

If you want to do power comparisons you should probably do an apples to apples 
comparison. Just like you wouldn't deploy your app on an Intel netbook powered 
by an ancient celeron, you wouldn't deploy your app on a consumer level odroid 
development board.

It's also important to remember that the cpu is increasingly not the major 
consumer of power; ram, multi gigiabit NICs, pci-e cards, storage, etc all 
contribute to the power bill and frequently do not have the same number of 
power saving states available.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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-compile Go code from a x86_64 host to an Arm system (Raspberry Pi 3)

[Dave Cheney]

Yes, http://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5

On Monday, 24 October 2016 02:08:07 UTC+11, Carlos Ferreira wrote:
>
> Is there a way to cross-compile Go Code to an arm platform, for example, a 
> Raspberry Pi 3?
>
>

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

[Dave Cheney]

On Monday, 24 October 2016 09:21:14 UTC+11, Tharaneedharan Vilwanathan 
wrote:
>
> Hi Dave/All,
>
> Thanks for the details!
>
> Yes, I have been looking at AMD processor based ARM board but it looks 
> like its just not available yet! Why are ARM server boards rare? Is it 
> difficult to do?
>

There are only a few manufactures and they only sell commerically, you 
won't find them on amazon. http://www.cavium.com/ThunderX-Partners.html

RPI3 is okay but memory is too low. I have an old ODROID. Let me try to get 
> ODROID-XU4.
>

Note: RPI3 is not capable of running arm64 mode at the moment. This is a 
limitation of the kernel as shipped by the Raspberry Pi foundation.
 

>
> Ibrahim, no, I want to play with ARM. I have many intel boards.
>
> Thanks
> dharani
>
> On Sat, Oct 22, 2016 at 11:46 PM, Dave Cheney <da...@cheney.net 
> > wrote:
>
>> There are no server class arm64 boards in your price range, sorry.
>>
>> If you want server class hardware you should look to Cavium or ARM 
>> themselves, these development systems start at the several thousand US 
>> dollar price range.
>>
>> If you want something in the $400 mark, http://www.96boards.org/ 
>> (currently down, lol) is a collaboration of vendors who make developer 
>> boards with 64 bit processors.  Also look at some of the ODROID offerings. 
>>
>> Note: the RPI3 is a 64bit capable arm64 processor, but currently is 
>> restricted to run in 32bit mode. I do not know if/when this restriction 
>> will be lifted.
>>
>> Thanks
>>
>> Dave
>>
>>
>> On Sunday, 23 October 2016 07:59:32 UTC+11, Tharaneedharan Vilwanathan 
>> wrote:
>>>
>>> Hi All,
>>>
>>> I am looking for a server type board with 64-bit ARM and more RAM (>2GB) 
>>> that runs Ubuntu or similar. I want to run Go code in it. It shouldn't cost 
>>> > $400. Any suggestions?
>>>
>>> Thanks
>>> dharani
>>>
>>> -- 
>> You received this message because you are subscribed 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] Re: ARM server board

[Dave Cheney]

On Monday, 24 October 2016 09:21:14 UTC+11, Tharaneedharan Vilwanathan 
wrote:
>
> Hi Dave/All,
>
> Thanks for the details!
>
> Yes, I have been looking at AMD processor based ARM board but it looks 
> like its just not available yet! Why are ARM server boards rare? Is it 
> difficult to do?
>
> RPI3 is okay but memory is too low. I have an old ODROID. Let me try to 
> get ODROID-XU4.
>
> Ibrahim, no, I want to play with ARM. I have many intel boards.
>

Do you mean arm64 ? You won't find any arm systems with more than 2gb of 
ram because they are 32 bit systems with a 2G/2G user/kernel address space 
split.
 

>
> Thanks
> dharani
>
> On Sat, Oct 22, 2016 at 11:46 PM, Dave Cheney <da...@cheney.net 
> > wrote:
>
>> There are no server class arm64 boards in your price range, sorry.
>>
>> If you want server class hardware you should look to Cavium or ARM 
>> themselves, these development systems start at the several thousand US 
>> dollar price range.
>>
>> If you want something in the $400 mark, http://www.96boards.org/ 
>> (currently down, lol) is a collaboration of vendors who make developer 
>> boards with 64 bit processors.  Also look at some of the ODROID offerings. 
>>
>> Note: the RPI3 is a 64bit capable arm64 processor, but currently is 
>> restricted to run in 32bit mode. I do not know if/when this restriction 
>> will be lifted.
>>
>> Thanks
>>
>> Dave
>>
>>
>> On Sunday, 23 October 2016 07:59:32 UTC+11, Tharaneedharan Vilwanathan 
>> wrote:
>>>
>>> Hi All,
>>>
>>> I am looking for a server type board with 64-bit ARM and more RAM (>2GB) 
>>> that runs Ubuntu or similar. I want to run Go code in it. It shouldn't cost 
>>> > $400. Any suggestions?
>>>
>>> Thanks
>>> dharani
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[go-nuts] Is os.exec thread safe ?

[Dave Cheney]

os.Exec is thread safe.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 it possible to enable http2 and have specific TLS configuration?

[Dave Cheney]

You have to depend on golang.org/x/net/http2 to opt in 

https://github.com/davecheney/httpstat/blob/master/main.go#L252

On Wednesday, 26 October 2016 03:46:31 UTC+11, Moshe Litvin wrote:
>
> The code in net/http/transport.go (onceSetNextProtoDefaults) contain:
>
>  if t.TLSClientConfig != nil || t.Dial != nil || t.DialTLS != nil {
>  // Be conservative and don't automatically enable
>  // http2 if they've specified a custom TLS config or
>  // custom dialers. Let them opt-in themselves via
>  // http2.ConfigureTransport so we don't surprise them
>  // by modifying their tls.Config. Issue 14275.
>  return
>  }
>
>
> Stating that if you did something non-standard in the dialer or TLS you 
> don't get http2 by default.
>
> But the suggested opt-in methods does not exist (was replace by the 
> non-public http2ConfigureTransport.
>
> The net/http documentation only specify opting out, but is there a way to 
> opt-in?
>
> Moshe
>

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

[Dave Cheney]

Unless you have built Go from source and/or your user owns the path Go is 
installed in, this is one of the few cases where go build is recommended 
over go install. 

http://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5

On Wednesday, 26 October 2016 05:09:18 UTC+11, Liam wrote:
>
> I have these commands in a package script:
>
>   GOPATH="${srcdir}" go get -d -u "${_site}/${pkgname}"
>   ...
>   GOPATH="${srcdir}" GOOS=linux GOARCH=arm \
>   CC=arm-unknown-linux-gnueabihf-gcc CGO_ENABLED=1 \
>   go install -v -ldflags='-s -w -extld=$CC' "${_site}/${pkgname}"
>
>
> Results:
>
>   runtime/cgo
>   go install runtime/cgo: open /usr/lib/go/pkg/linux_arm/runtime/cgo.a: 
> permission denied
>
>
> My cgo.a files have very diff sizes:
>
>   $ ls -l /lib/go/pkg/*/runtime/cgo*
>   -rw-r--r-- 1 root root 64874 Sep  8 00:13 
> /lib/go/pkg/linux_amd64/runtime/cgo.a
>   -rw-r--r-- 1 root root 65054 Sep  8 00:18 
> /lib/go/pkg/linux_amd64_race/runtime/cgo.a
>   -rw-r--r-- 1 root root  2642 Oct 25 03:54 
> /lib/go/pkg/linux_arm/runtime/cgo.a
>
>
> I have rebuilt for linux_arm:
>
>GOOS=linux GOARCH=arm go install -v -a std
>GOOS=linux GOARCH=arm go install -v -a cmd
>
> On Arch Linux x86_64 with go1.7.1 linux/amd64
>
>

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

[Dave Cheney]

Cool. Thanks for figuring it out and posting your answer.

On Tuesday, 15 November 2016 07:28:16 UTC+11, Evan Digby wrote:
>
> Confirmed bug on my part. 
>
> When using the "..." suffix to pass a slice into a func with variadic args 
> it passes through the the original slice, rather than constructing a new 
> one. An obvious optimization, but caused my function to act differently in 
> my tests vs. a real use case.
>
> The tests pass in "[][]int64..." whereas the code using the function 
> passes several individual slices. 
>
> The function clobbers the individual slices inside.
>
> I've now added an explicit test to validate behaviour is the same passing 
> individual args vs. breaking out a slice.
>
>
> On Saturday, 12 November 2016 12:57:07 UTC-8, Evan Digby wrote:
>>
>> I think I've eyeballed a bug in my code that *might* cause this but I 
>> won't be at a computer for a day or two to verify. I'll keep here posted!
>
>

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

[Dave Cheney]

I think you problem is here

jsonReservations, err := 
jsonConvert.ReservationsJson(otherReservations)
if err != nil {
rw.WriteHeader(http.StatusExpectationFailed)
fmt.Println(err)
}

Instead try this

   if err != nil {
 http.Error(rw, err.Error(), http.StatusExpectationFailed)
 return // this is the important part
   }
   // do not allow execution to get to this line if err is != nil

On Thursday, 24 November 2016 11:44:13 UTC+11, gkol...@gmail.com wrote:
>
> Hey im running a go server locally using gorilla mux and net/http.
>
> For class we needed to create a room reservation system. I was testing the 
> application on multiple compyters on the same network but 
> when trying to create a reservation from both computer at the same time to 
> test concurrency I get a multiple write headers error. This problem does 
> not occur if i'm
> using the same computer but running on different browsers.
>
> It may help to know that the create button runs 2 ajax calls one to to 
> /readReservationByUserId as POST and to /createReservation as POST.
>
> func GetReservationsOthers(rw http.ResponseWriter, req *http.Request) {
> abstractTdg := mappers.MapperBundle.UserMapper.UserTdg.AbstractTdg
> abstractTdg.GetConnection()
> defer abstractTdg.CloseConnection()
> defer req.Body.Close()
> req.ParseForm()
>
> roomID, err := strconv.Atoi(req.FormValue("dataRoom"))
> userID, err := strconv.Atoi(req.FormValue("userID"))
> reservationsMapper := mappers.MapperBundle.ReservationMapper
> reservations, err := reservationsMapper.GetByRoomId(roomID)
>
> otherReservations := 
> reservationsMapper.FilterOutUser(reservations, userID)
>
> if err != nil {
> rw.WriteHeader(http.StatusExpectationFailed)
> fmt.Println(err)
> }
>
> jsonReservations, err := 
> jsonConvert.ReservationsJson(otherReservations)
> if err != nil {
> rw.WriteHeader(http.StatusExpectationFailed)
> fmt.Println(err)
> }
> rw.Header().Set("Content-Type", "application/json")
> rw.Write(jsonReservations)
>
> }
>
> func CreateReservation(rw http.ResponseWriter, req *http.Request) {
> abstractTdg := mappers.MapperBundle.UserMapper.UserTdg.AbstractTdg
> abstractTdg.GetConnection()
> defer abstractTdg.CloseConnection()
> req.ParseForm()
> roomId := req.FormValue("dataRoom")
> userId := req.FormValue("userID")
> startTime := req.FormValue("startTime")
> endTime := req.FormValue("endTime")
> roomIdint, _ := strconv.Atoi(roomId)
> userIDint, _ := strconv.Atoi(userId)
> startTimeformated, _ := time.Parse("2006-01-02 15:04:05", 
> startTime)
> endTimeformated, _ := time.Parse("2006-01-02 15:04:05", endTime)
> reservationMapper := mappers.MapperBundle.ReservationMapper
>
> if err := reservationMapper.Create(roomIdint, userIDint, 
> startTimeformated, endTimeformated); err != nil {
> rw.WriteHeader(http.StatusExpectationFailed)
> }
>
> rw.WriteHeader(http.StatusOK)
> bytes, _ := jsonConvert.MessageJson("Success")
> rw.Write(bytes)
> }
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Do Go Routines use continuations to allow yelding?

[Dave Cheney]

On Saturday, 26 November 2016 08:00:24 UTC+11, Roger Alsing wrote:
>
> So it works very similar to normal OS thread context switching, but more 
> explicit?
>

Yes, goroutine switching occurs a known points; effectively where the 
goroutine is blocked from proceeding; sending and receiving on channels (if 
they are full/empty respectively), trying to acquire a locked mutex, and 
performing IO. These operations happen frequently in a program that 
interacts with others so things more or less work out.
 

> The code will push all local state to the go routine stack, pop the state 
> for the next go routine and change the stack pointer?
>

The cute thing is the Go function call convention is caller save, so when a 
goroutine enters the scheduler there is no state to be saved, it's already 
saved on the stack by the normal function call convention. As Ian said 
above the scheduler just finds the SP and PC for a new goroutine and swaps 
them for the current one. The new goroutine awakes at the bottom of the 
scheduler, and returns to its original control flow.
 

>
> And this is cheaper than context switching as threads have their own 1 or 
> 4 mb stack allocated while go routines have a linked list for its stack 
> (afaik?) ?
>

Goroutines used to have a linked list of stack segments, we dropped that in 
Go 1.3 (might have been 1.2, i'd have to check), now stack segments grow 
and shrink with a cheap check in the preamble of the function; if there 
isn't enough stack to perform the function (this is known precisely at 
compile time), then the function traps into a slow path that doubles the 
stack allocation by copying the whole stack to a new area, then restarts 
the function. Stack shrinking is handled via the GC cycle when a goroutine 
has a large amount of unused stack.
 

> is that the major difference?
>

I think so, it makes goroutines cheap to create; only a few kb of initial 
stack, cheap to use; no trip through kernel space to save a lot of state, 
and trash TLB's and caches, and cheap to have many of them; in operation 
hundreds of thousands of goroutines in a busy server are the norm. This is 
also pretty much the case against threads.

Here is a presentation I gave at OSCON last year about all these 
things, https://dave.cheney.net/2015/08/08/performance-without-the-event-loop
 

>
>
> Den fredag 25 november 2016 kl. 17:34:24 UTC+1 skrev Ian Lance Taylor:
>>
>> On Fri, Nov 25, 2016 at 2:18 AM,   wrote: 
>> > I have seen a lot of confusion on how go routines actually work 
>> internally. 
>> > Will the function execution ontop of the go routine be rewritten to a 
>> statemachine with continuations in the same way as the C# async await does? 
>>
>> I do not know how C# async await works.  That said, goroutines are not 
>> rewritten to state machines. 
>>
>>
>> > If I have only 1 OS thread and 1000 go routines, obviously there must 
>> be some sort of "magic" that makes it possible to multiplex these ontop of 
>> that thread. 
>> > How do the go routines store state so that they can continue from the 
>> last execution point when they resume execution? 
>>
>> A goroutine is basically a small stack.  All the goroutine state is 
>> saved on the stack.  To switch to a different goroutine, the goroutine 
>> scheduler changes the stack pointer.  On the new goroutine, it looks 
>> like the function call into the scheduler simply returns, and the 
>> goroutine continues running. 
>>
>> This is a standard programming technique known as a "coroutine".  For 
>> Go we used the name "goroutine" because 1) it is cute; 2) goroutines 
>> have functionality not available in most coroutine libraries, such as 
>> multiplexing across many OS threads and automatic use of epoll for 
>> network connections. 
>>
>>
>> > Is it safe to say that Go gives you the exact same support as the C# 
>> (and others) async await while still writing code that looks sequential? 
>>
>> I don't know C#.  goroutines let you write code that looks sequential 
>> because it actually is sequential. 
>>
>> 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: Error Handling

[Dave Cheney]

Would a type switch do what you want ?

err := fn()
switch err := err.(type) {
case nil:
   // all good
case *MyCustomError:
   // do something custom
default:
   // unexpected error
}

On Saturday, 26 November 2016 05:07:55 UTC+11, Parveen Kumar wrote:
>
> Hi Team,
>
> I want to catch my custom error being returned from various methods and 
> based on their type i want to return http error code. is ther any generic 
> way?
>
> Regards,
> Parveen Kumar
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] err variable shadowing — is it a bad practice?

[Dave Cheney]

This is extremely common in go code, vet is being pedantic,

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

[Dave Cheney]

With a nod to Chris's excellent presentation, this may be an example of Go 
breaking its own orthogonality rules for the sake of being more consistent (the 
rule of least surprise)

There is a strong overlap between an interface with a single method and a 
function value, Tomás Senart spoke about this at last year's Gophercon, but as 
a function value cannot easily have two behaviours there is clearly a 
requirement for an interface with two or more methods (although SRP would tend 
to drive your design in the other direction, sometimes this is necessary) so an 
arbitrary restriction that an interface have more than one method would be 
surprising.

I think there is a strong parallel between this discussion and the occasional 
flair up of the "why does Go need new?" debate. The answer in both cases is 
while sometimes features appear to overlap in the simple case, they are 
actually independent. A small concession for consistency over orthogonality. 

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: Where should interfaces live?

[Dave Cheney]

My vote is for "in the package that needs them"

On Tuesday, 22 November 2016 02:30:21 UTC+11, Vorn Mom wrote:
>
> Sorry if it was asked before, but where should interfaces live?
>
>- In the package that contains an implementation of it.
>- In its own package.
>- or in the package that needs it.
>
> The standard library is not consistent.  For example:
>
>- io.Writer is defined in a package that also has an implementation, 
>io.PipeWriter.  
>- Encoding is all interfaces, defering implementation to sub-packages.
>- database/sql returns a DB struct on Open() instead of an interface.
>
> Because Go interfaces are decoupled from implementation, I think it should 
> be defined where it's needed.  So I like having my own interface for DB 
> that may only define a subset of what behaviors it provides.
>
> However, doesn't defining an interface that depends on other packages 
> decrease cohesion and leaks the abstraction?  For example,
>
> type interface DbQuery {
>   QueryRow(query string, args ...interface{}) *sql.Row
> }
>
> This interface depends on sql.Row.  This decreases cohesion because the 
> interface is now defined across packages?
>
> -Vorn
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 there is a so great performance penalty when the usage combines LockOSThread and channel?

[Dave Cheney]

Why do you want to use LockOSthread, you've proved it has a significant 
performance cost for your application.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 there is a so great performance penalty when the usage combines LockOSThread and channel?

[Dave Cheney]

Please try profiling your application, if you are on Linux perf(1) works very 
well for tracing user and system 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: Why there is a so great performance penalty when the usage combines LockOSThread and channel?

[Dave Cheney]

Related, you don't need a pointer to a chan, channels are already pointers to 
the private runtime channel type. 

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

[Dave Cheney]

Please do not reopen to a four year old thread. Instead please start a new 
thread describing the problem you have, what you tried, and what happened when 
you tried.

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.