[go-nuts] Golang 1.9 release ETA update?

Hi guys I see there's three issues still pending in the 1.9 milestone. The one being at test case failure on darwin which now has a skip in and the other two are doc fixes, so I was wondering if we have a likely release date yet? The reason I ask is our production system is being hit regularly

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

Its likely this is because the idx in a range is just that, its the index of the processing element and not a loop iteration variable. As range never processes an element past the end of the slice, there's no way for it to get set to N, hence the difference in semantics from a normal for i :=

Re: [go-nuts] Anyone using https://github.com/knq/xo?

We use it, but due to working with a legacy schema we've had to make some internal changes to it to ensure we get decent go structures. You can see the sort of things we've really quickly hacked into it, not had time to upstream, here: https://github.com/stevenh/xo/commits/mysql-primary-keys

Re: [go-nuts] Perl die("") equivalent for Go?

log.Fatal() is what u want On Fri, 30 Jun 2017 at 18:32, Andrew Pennebaker wrote: > For command line applications, it's often useful to terminate with a > one-line string message, without presenting a stack trace. Could Go get a > die-like standard function for this? > > panic() and log.Panic()

Re: [go-nuts] Base64

Might want to ask on a java mailing list not a golang one ;-) On 24/06/2017 13:09, Manish Asolkar wrote: hi, I have two Window machines one has *Server 2008 R2* and another on has *Server 2012 R2* with same *JDK version 1.8.* I am working on a financial application where I receive a base64

Re: [go-nuts] Windows - syscall.GetProcessTimes() always shows 0 values.

All depends on what your going to end up doing. If code will deal with processes other than itself then pid is arguably easier to deal with, however if you only ever deal with your process then I would have the NewProcInfo method just setup the handle as you had it (reducing the number of sysc

Re: [go-nuts] Windows - syscall.GetProcessTimes() always shows 0 values.

Your main problem is the fact that the Windows time interval is 16ms by default. It uses this value for its internal timers and thread time quantum, which effectively means you won't see any changes until they have added up to a min of 16ms. You can see this by changing the 16ms in the following e

Re: [go-nuts] Go Socket vs C Socket for single-threaded/single CPU socket programming

Why do you say it will be single threaded? I ask as even with a single core multiple threads can be beneficial. Even with GOMAXPROCS=1 the go runtime will multiplex multiple requests efficiently without you thinking about it. On Fri, 26 May 2017 at 19:32, wrote: > This might be a silly questi

Re: [go-nuts] Goroutine leak?

Just add defer timer.Stop() after NewTimer... instead of explicit time.Stop() in the done case. On 04/05/2017 17:50, yuri.shakhma...@gmail.com wrote: Hello, all! There is a part of code:... // RunTimeout runs the given command with the given timeout. // If the command times out, it attempts t

Re: [go-nuts] Unexpected behavior with panic/defer/recover

You second example isn't calling recover inside the defer. See: https://golang.org/pkg/builtin/#recover On 28/03/2017 23:00, Stefan Engstrom wrote: Playing with recovery from a panic - this code does what i expect: (https://play.golang.org/p/p5KvOYc1sx) | packagemain import"fmt" func main(){

Re: [go-nuts] How to return a Go struct to C

The following may help: http://feisky.xyz/2016/04/19/cgo-in-go-1-6/ On 20/03/2017 13:25, Song Liu wrote: Hi, I have a shared lib as bellow: | /* #include structMedia{ char*Name; char*Path; uint64_tSize; }; */ import"C" //exportGetMediaFromDB funcGetMediaFromDB(filename*C.char)*C.struct_Media{

Re: [go-nuts] Expression evaluation with side effects

Think the following section should explain the strange behaviour you're seeing: https://golang.org/ref/spec#Order_of_evaluation On 19/03/2017 22:59, Jan Mercl wrote: While trying to resolve a failing (C) test case[0] I encountered a (Go) behavior I do not understand. This code[1] pack

Re: [go-nuts] errors.New("...") vs package level error vars

Internal errors are one of my pet peeves about the core go libs, as you say they are inconsistent and you end up doing all sorts of string checks which are not only hackey but are very fragile too. We had a break in our code due to just this when updating to 1.8. There are very few reason why

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

my post. - Matt On Wednesday, February 22, 2017 at 3:45:24 PM UTC-5, Steven Hartland wrote: It's required for read only in some situations too, for example we use it here to listen for process exit codes. http://man7.org/linux/man-pages/man7/netlink.7.html &

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

is probably why I haven't run into any issues. On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven Hartland wrote: One thing you don't mention, which we found particularly frustrating with netlink, is that using it can often need cap_net_admin :( On 22/02/201

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

One thing you don't mention, which we found particularly frustrating with netlink, is that using it can often need cap_net_admin :( On 22/02/2017 17:38, Matt Layher wrote: Hey all, I recently spent some time working with Linux's netlink IPC mechanism in Go. Because I had a hard time finding

Re: [go-nuts] Early hooking runtime - making libcontainer cross compilable

On 17/02/2017 22:36, Ian Lance Taylor wrote: On Fri, Feb 17, 2017 at 1:55 PM, Steven Hartland wrote: Recently we started adding support to our systems for opencontainers via libcontainer however due to its use of C code for the early hooking this means we now can't cross-compile our cod

[go-nuts] Early hooking runtime - making libcontainer cross compilable

Recently we started adding support to our systems for opencontainers via libcontainer however due to its use of C code for the early hooking this means we now can't cross-compile our code any more, which is a PITA. The main reason for this is the early hooking required to perform setns as deta

Re: [go-nuts] Re: is it possible to speed up type assertion?

On 02/02/2017 09:27, Ian Davis wrote: On Thu, 2 Feb 2017, at 09:20 AM, T L wrote: On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote: Hi, I can not really reproduce your results. I rewrote your code to use the builtin benchmarking: http://sprunge.us/IfQc Gi

Re: [go-nuts] Go 1.7.5 and Go 1.8rc3 are released

doesn't Il giorno venerdì 27 gennaio 2017 15:58:20 UTC+1, Steven Hartland ha scritto: Hi guys first off thanks for 1.7.5! Having reviewed the changes for the 1.7.5 milestone <https://github.com/golang/go/issues?q=milestone%3AGo1.7.5>, which is the link provided for more in

Re: [go-nuts] Go 1.7.5 and Go 1.8rc3 are released

Hi guys first off thanks for 1.7.5! Having reviewed the changes for the 1.7.5 milestone , which is the link provided for more info from the release notes, I feel that the its not as easy to follow as they have been for other milestones

Re: [go-nuts] err variable shadowing — is it a bad practice?

I believe vet shadow is known to have issues and is quite picky ;-) Your first one I'd say could be classed as bug as you're clearly declaring n however I'd guess this is due to the for loop as declaring n out of the loop eliminating the short declaration will fix it. This is confirmed by elim

Re: [go-nuts] Re: Best practice when creating temporary files

program may crash at any moment and leave something > around. This is why the OS cleans up /tmp. > > Thomas > > On Mon, Nov 21, 2016 at 9:01 AM Steven Hartland > wrote: > >> That's a bad assumption, you should always clean up after yourself. >> >> >>

Re: [go-nuts] Re: Best practice when creating temporary files

That's a bad assumption, you should always clean up after yourself. On 21/11/2016 16:57, Val wrote: OK, I had overlooked the fact that cleanup is important to you, which makes sense for security and to save disk space early. TempFile, TempDir don't do the cleanup, but the OS will sooner or late

Re: [go-nuts] Re: [ANN] lint - Run linters as part of go test

Watch out, as some of those have broken vendor support. Here's notes we've made in the past (might be out of date) * Disable gotype, errcheck, dupl and structcheck as they are awful. * Disable interfacer and gas as they too picky. * Disable gofmt as its redundant and also sometimes gets false

[go-nuts] Function passing fails to perform type coercion to interface

I was playing with a design today where I had a number of types which match an interface and was surprised that I couldn't make use of this fact in passing their new functions into a method. It seems that even though the returned type matches the interface within the function argument go doesn

Re: [go-nuts] HTTP2 package suddenly breaking all builds

http2 is now built in so yo don't need the x version? Alternatively it may be expecting you to be on go v1.7 and you're still using an older version? On 30/09/2016 11:16, alex.bread...@leadinglocally.com wrote: All my packages are unable to build because of this error /home/alex/go/src/golan

[go-nuts] slice expansion in templates

Is there anyway to pass a slice to a varadic golang function in a template? In straight go it would simply be myfunc(myslice...) but in templates this possible? Regards Steve -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscr

Re: [go-nuts] [ANN] google.golang.org/cloud import paths removed

The links on the docs for this are currently broken e.g. https://cloud.google.com/go/apis points to https://godoc.org/google.golang.org/cloud On 13/09/2016 12:59, jba via golang-nuts wrote: As was announced six weeks ago, the Google Cloud API clients, formerly residing at google.golang.org/clo

Re: [go-nuts] Are receivers from a channel fifo?

On 21/08/2016 21:51, Jan Mercl wrote: On Sun, Aug 21, 2016, 22:43 Steven Hartland <mailto:ste...@multiplay.co.uk>> wrote: If I have multiple goroutines reading from a channel are they guaranteed to be FIFO i.e. is the handler that requested the read first guaranteed to get

[go-nuts] Are receivers from a channel fifo?

If I have multiple goroutines reading from a channel are they guaranteed to be FIFO i.e. is the handler that requested the read first guaranteed to get the first value, second to get the second and so on? Regards Steve -- You received this message because you are subscribed to the Goog

[go-nuts] Massive go test gotcha - it runs each package in parallel

We've just been caught out by what I'd say is a massive gotcha about go test! When invoked with multiple packages the tests for said packages run in parallel! While this is fine if the tests themselves are totally self contained, with no external dependencies, if they do well all bets are of

Re: [go-nuts] Re: Go 1.7 Release Candidate 3 is released

Thanks Chris appreciated :) On 22/07/2016 02:47, Chris Broadfoot wrote: A couple people requested a changelog between release candidates. I'll try to remember to include that for the 1.8 release candidates (we don't plan to do a 1.7rc4). GitHub has a nice view for commits between refs. Here'

Re: [go-nuts] Different result in go1.6.3 and 1.7rc2

Could this be related to: "The pure Go name resolution implementation now respects nsswitch.conf's stated preference for the priority of DNS lookups compared to local file (that is, /etc/hosts) lookups." On 20/07/2016 08:20, Runix wrote: I use the library github.com/jmckaskill/gokerb/khttp in

Re: [go-nuts] exec.Cmd: if the child forks Wait may hang forever

If your forked process still has stdin / stdout open then I would say this is expected. You could confirm this by adding the following to the python script. import sys ... if pid == 0: sys.stdin.close() sys.stdout.close() On 13/07/2016 21:50, noxiouz wrote: Good day! I faced a corner ca

Re: [go-nuts] filepath.Join

Are the unexported methods OS specific? On 13/07/2016 20:56, Anmol Sethi wrote: Why does filepath.Join only call to the unexported join? Why not just export the unexported join? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

<    1   2