Re: [go-nuts] Re: Go 1.16 is released

[Brad Fitzpatrick]

Elaborate?

On Tue, Feb 16, 2021 at 12:34 PM Peter Kleiweg  wrote:

> `go get` is broken. It doesn't download packages.
>
> Op dinsdag 16 februari 2021 om 20:56:37 UTC+1 schreef Alex Rakoczy:
>
>> Hello gophers,
>>
>> We just released Go 1.16
>>
>> To find out what has changed in Go 1.16, read the release notes:
>> https://golang.org/doc/go1.16
>>
>> You can download binary and source distributions from our download page:
>> https://golang.org/dl/
>>
>> If you have Go installed already, an easy way to try go1.16
>> is by using the go command:
>> $ go get golang.org/dl/go1.16
>> $ go1.16 download
>>
>> To compile from source using a Git clone, update to the release with
>> "git checkout go1.16" and build as usual.
>>
>> Thanks to everyone who contributed to the release!
>>
>> Cheers,
>> Alex and Dmitri for the Go Team
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/040e8124-7675-4767-9348-90ab88908ac8n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAFzRk03KRJ11E1KwNjXV7K5jui7uJ9Vp1N5OEppQYczD4OKJzA%40mail.gmail.com.

Re: [go-nuts] Removing Go's nacl port

[Brad Fitzpatrick]

Thanks. I left a comment about present on
https://github.com/golang/go/issues/30439#issuecomment-474542939

On Tue, Mar 19, 2019 at 11:33 AM Dan Kortschak  wrote:

> I use it for present to allow students to run code as part of lecture
> material.
>
> Dan
>
> On Tue, 2019-03-19 at 11:22 -0700, Brad Fitzpatrick wrote:
> > We plan to remove Go's Native Client (nacl) port, probably in Go
> > 1.14.
> > (It's probably too soon to remove it in Go 1.13)
> >
> > Is anybody using it? If so, how?
> >
> > We currently use it for the playground (at play.golang.org) but the
> > plan is
> > to move that to run linux/amd64 binaries under gvisor.
> >
> > We suspect we're the only user.
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Removing Go's nacl port

[Brad Fitzpatrick]

We plan to remove Go's Native Client (nacl) port, probably in Go 1.14.
(It's probably too soon to remove it in Go 1.13)

Is anybody using it? If so, how?

We currently use it for the playground (at play.golang.org) but the plan is
to move that to run linux/amd64 binaries under gvisor.

We suspect we're the only user.

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

[Brad Fitzpatrick]

Thanks for setting this up!


On Tue, Feb 12, 2019 at 4:33 PM Daniel Theophanes 
wrote:

> In order to help keep database/sql driver developers and the maintainers
> of database/sql on the same page, I'm going to start to posting issues and
> proposals to the following group:
>
> https://groups.google.com/forum/#!forum/golang-sql
>
> If you are a driver developer, I would recommend subscribing to it (if you
> aren't already).
>
> Thanks, -Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: All the Go project history, live in RAM

[Brad Fitzpatrick]

Yeah, I think that should work.

IIRC, the cache files aren't appended to, but atomically rewritten &
replaced.

So running two on the same filesystem will waste a bit of network & disk
I/O, but it should be correct.


On Sat, Apr 14, 2018 at 5:25 PM, Dmitri Shuralyov 
wrote:

> Brad, another question.
>
> I've read the documentation at https://godoc.org/golang.org/
> x/build/maintner/godata, but it doesn't make it clear: is it
> safe/supported to have more than 1 process on one machine call godata.Get
> and use returned maintner.Corpus at the same time?
>
> I know each call uses the same underlying cache directory on disk. Or is
> it unsupported/will cause data corruption and other problems?
>
> (Indirectly, I'm asking if it's safe to call maintner.NewNetworkMutationSource
> multiple times with the same cacheDir parameter.)
>
>
> On Sunday, April 30, 2017 at 5:42:03 PM UTC-4, bradfitz wrote:
>>
>> Gophers,
>>
>> Want to analyze the Go project's Git, GitHub, and Gerrit history?
>>
>> Here a package to make it easy:
>>
>>  https://godoc.org/golang.org/x/build/maintner/godata
>>
>> See the example:
>>
>> https://godoc.org/golang.org/x/build/maintner/godata#example
>> -Get--NumComments
>>
>> If you run that, it'll download 350 MB (once) and then tell you there
>> have been 111228 GitHub comments on Go repos.
>>
>> Run it again a few seconds later and the number might increase.
>>
>> The data is generally under 1 second behind reality, thanks to the
>> webhook+incoming-SMTP server we run now at https://pubsubhelper.golang
>> .org/ to get updates from GitHub & Gerrit.
>>
>> gopherbot now uses this infrastructure. See https://github.com/golang/
>> build/blob/master/cmd/gopherbot/gopherbot.go for some more examples.
>>
>> Thanks to Kevin Burke for all the help & code reviews.
>>
>> - Brad
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] goimports flag parity with gofmt

[Brad Fitzpatrick]

I'd still rather not.

But it'd be more than one change anyway. We're not just going to copy/paste
the code from gofmt into goimports if it did happen. We'd want to move the
simplify code to an x/* package (either
https://godoc.org/golang.org/x/tools/go/ast/astutil or a subdirectory
thereof) and then use it from both goimports and gofmt, which would
additionally require vendoring the simplify package into std.




On Sat, Dec 16, 2017 at 8:50 PM, <ramyane...@gmail.com> wrote:

> Brad,
>
> Would you be open to consider a PR to add the "-s" flag support to
> goimports?
>
> On Monday, June 12, 2017 at 9:56:06 AM UTC-7, bradfitz wrote:
>>
>> Use the tool that does what you want.
>>
>> We don't have to put all functionality into all binaries.
>>
>> If vim-go makes assumptions that one helper binary does all
>> functionality, yes, please fix vim-go.
>>
>> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> This is still bothering us in 2017. I'd love to be able to run goimports
>>> on save in Vim, but also would like to simplify code (-s option). I use
>>> vim-go plugin, so I guess I can submit a pull request asking the plugin to
>>> run both commands on save, but I do not understand why the workaround
>>> instead of command parity? Is it something no one has had time to look into
>>> yet or is it too hard to implement with current goimports implementation?
>>>
>>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>>>
>>>> Oh, you did update goimports.
>>>>
>>>> gofmt and goimports both had their tab options removed.
>>>>
>>>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
>>>> much it matters.  No editors really use those, do they?  If you want to do
>>>> it by hand, gofmt is still there.
>>>>
>>>>
>>>>
>>>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick <brad...@golang.org>
>>>> wrote:
>>>>
>>>>> I don't think you're running the correct binary then, because:
>>>>>
>>>>> $ rm $(which goimports)
>>>>> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
>>>>> $ goimports -h
>>>>> usage: goimports [flags] [path ...]
>>>>>   -d=false: display diffs instead of rewriting files
>>>>>   -e=false: report all errors (not just the first 10 on different
>>>>> lines)
>>>>>   -l=false: list files whose formatting differs from goimport's
>>>>>   -w=false: write result to (source) file instead of stdout
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov <v.to...@selfip.ru>
>>>>> wrote:
>>>>>
>>>>>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick <brad...@golang.org>:
>>>>>> > You're running old binaries of each.
>>>>>>
>>>>>>
>>>>>> Hmm. I'm try new goimports but nothing different:
>>>>>>
>>>>>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>>>>>> code.google.com/p/go.tools (download)
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg pull
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg tags
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg branches
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg update default
>>>>>> WORK=/tmp/go-build706264051
>>>>>> code.google.com/p/go.tools/imports
>>>>>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>>>>>> mkdir -p $WORK/code.google.com/p/go.tools/
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>>>>>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>>>>>> <http://code.google.com/p/go.tools/imports/usr/lib64/go/pkg/tool/linux_amd64/6g>
>>>>>> -o
>>>>>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>>>>>> code.google.com/p/go.tools/imports -complete -D
>>>>>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>>>>>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go
>>>>>> ./imp

Re: [go-nuts] Re: Go 1.9 Release Candidate 1 is released

[Brad Fitzpatrick]

https://tip.golang.org/doc/go1.9


On Wed, Jul 26, 2017 at 7:31 AM,  wrote:

> Great!
>
> Unfortunately, the "release notes" section points to the documentation; I
> can't find the actual release notes page.
>
>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

On Thu, Jun 15, 2017 at 8:54 AM, Michael Banzon  wrote:

> 
> does this mean that 2.0 is next?
> 
>


I gave a talk about that:

Slides:
https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMNvpo7ntqteWQfynq9hFTCkhQ/view?slide=id.p#slide=id.p

Video:
https://www.youtube.com/watch?v=4Dr8FXs9aJM


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

Re: [go-nuts] Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

On Wed, Jun 14, 2017 at 11:35 PM, Sokolov Yura 
wrote:

> So, no scalable timers in 1.9 ?
> https://go-review.googlesource.com/c/34784/15
> It's a pity.


Yes. But Aliaksandr hasn't replied to Dmitry for the past 10 days, either.

We don't ship code that hasn't made it through code review.

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

Re: [go-nuts] Re: Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

If you view the HTML source, the relevant CL numbers are in comments.


On Wed, Jun 14, 2017 at 11:02 PM,  wrote:

> Can someone elaborate more on "Large object allocation performance is
> significantly improved in applications using large (>50GB) heaps containing
> many large objects."? What PR / issue is related to this change? What are
> the numbers?
>
> On Wednesday, June 14, 2017 at 3:15:49 PM UTC-7, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We have just released go1.9beta1, a beta version of Go 1.9.
>> It is cut from the master branch at the revision tagged go1.9beta1.
>>
>> There are no known problems or regressions.
>> Please try running production load tests and your unit tests with the new
>> version.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.9beta1
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.9beta1
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.9beta1
>>
>> To find out what has changed in Go 1.9, read the draft release notes:
>> https://tip.golang.org/doc/go1.9
>>
>> Documentation for Go 1.9 is available at:
>> https://tip.golang.org/
>>
>> Cheers,
>> Chris
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: [golang-dev] Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

We use golang.org/x/build/cmd/release


On Wed, Jun 14, 2017 at 6:32 PM, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> I'm curious how you built your binaries with https://github.com/
> golang/go/issues/20284 still open. Do you not run the tests on the built
> binaries before packing them up?
>
> On 15 June 2017 at 10:15, Chris Broadfoot  wrote:
>
>> Hello gophers,
>>
>> We have just released go1.9beta1, a beta version of Go 1.9.
>> It is cut from the master branch at the revision tagged go1.9beta1.
>>
>> There are no known problems or regressions.
>> Please try running production load tests and your unit tests with the new
>> version.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.9beta1
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.9beta1
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.9beta1
>>
>> To find out what has changed in Go 1.9, read the draft release notes:
>> https://tip.golang.org/doc/go1.9
>>
>> Documentation for Go 1.9 is available at:
>> https://tip.golang.org/
>>
>> Cheers,
>> Chris
>>
>> --
>> 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.
>

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

Re: [go-nuts] Re: Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

Correct.

https://github.com/golang/go/issues/19082 remains open.

See https://dev.golang.org/release for the other bugs not yet fixed.


On Wed, Jun 14, 2017 at 5:03 PM, Ben Shi  wrote:

> still no aarch64 prebuilt binary？
>
> Ben Shi
>
> 在 2017年6月15日，06:15，Chris Broadfoot  写道：
>
> Hello gophers,
>
> We have just released go1.9beta1, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta1.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new
> version.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta1
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 is available at:
> https://tip.golang.org/
>
> Cheers,
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-announce" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-announce+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.
>

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

[Brad Fitzpatrick]

Fixed: https://golang.org/cl/45390

On Mon, Jun 12, 2017 at 10:09 AM, Chandru <chandru...@gmail.com> wrote:

> The documentation of goimports[1] says,
>
> It's a drop-in replacement for your editor's gofmt-on-save hook. "It has
> the same command-line interface as gofmt" and formats your code in the same
> way. (quotes are mine)
>
> I think this documentation needs fixing too?
>
> [1]: https://godoc.org/golang.org/x/tools/cmd/goimports
>
> --
> Chandra Sekar.S
>
> On Mon, Jun 12, 2017 at 10:25 PM, Brad Fitzpatrick <bradf...@golang.org>
> wrote:
>
>> Use the tool that does what you want.
>>
>> We don't have to put all functionality into all binaries.
>>
>> If vim-go makes assumptions that one helper binary does all
>> functionality, yes, please fix vim-go.
>>
>> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> This is still bothering us in 2017. I'd love to be able to run goimports
>>> on save in Vim, but also would like to simplify code (-s option). I use
>>> vim-go plugin, so I guess I can submit a pull request asking the plugin to
>>> run both commands on save, but I do not understand why the workaround
>>> instead of command parity? Is it something no one has had time to look into
>>> yet or is it too hard to implement with current goimports implementation?
>>>
>>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>>>
>>>> Oh, you did update goimports.
>>>>
>>>> gofmt and goimports both had their tab options removed.
>>>>
>>>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
>>>> much it matters.  No editors really use those, do they?  If you want to do
>>>> it by hand, gofmt is still there.
>>>>
>>>>
>>>>
>>>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick <brad...@golang.org>
>>>> wrote:
>>>>
>>>>> I don't think you're running the correct binary then, because:
>>>>>
>>>>> $ rm $(which goimports)
>>>>> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
>>>>> $ goimports -h
>>>>> usage: goimports [flags] [path ...]
>>>>>   -d=false: display diffs instead of rewriting files
>>>>>   -e=false: report all errors (not just the first 10 on different
>>>>> lines)
>>>>>   -l=false: list files whose formatting differs from goimport's
>>>>>   -w=false: write result to (source) file instead of stdout
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov <v.to...@selfip.ru>
>>>>> wrote:
>>>>>
>>>>>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick <brad...@golang.org>:
>>>>>> > You're running old binaries of each.
>>>>>>
>>>>>>
>>>>>> Hmm. I'm try new goimports but nothing different:
>>>>>>
>>>>>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>>>>>> code.google.com/p/go.tools (download)
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg pull
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg tags
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg branches
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>>>> hg update default
>>>>>> WORK=/tmp/go-build706264051
>>>>>> code.google.com/p/go.tools/imports
>>>>>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>>>>>> mkdir -p $WORK/code.google.com/p/go.tools/
>>>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>>>>>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>>>>>> <http://code.google.com/p/go.tools/imports/usr/lib64/go/pkg/tool/linux_amd64/6g>
>>>>>> -o
>>>>>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>>>>>> code.google.com/p/go.tools/imports -complete -D
>>>>>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>>>>>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go
>>>>>> ./imports.go
>>>>>> ./sortimports.go ./zstd

Re: [go-nuts] goimports flag parity with gofmt

[Brad Fitzpatrick]

Use the tool that does what you want.

We don't have to put all functionality into all binaries.

If vim-go makes assumptions that one helper binary does all functionality,
yes, please fix vim-go.

On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> This is still bothering us in 2017. I'd love to be able to run goimports
> on save in Vim, but also would like to simplify code (-s option). I use
> vim-go plugin, so I guess I can submit a pull request asking the plugin to
> run both commands on save, but I do not understand why the workaround
> instead of command parity? Is it something no one has had time to look into
> yet or is it too hard to implement with current goimports implementation?
>
> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>
>> Oh, you did update goimports.
>>
>> gofmt and goimports both had their tab options removed.
>>
>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how much
>> it matters.  No editors really use those, do they?  If you want to do it by
>> hand, gofmt is still there.
>>
>>
>>
>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick <brad...@golang.org>
>> wrote:
>>
>>> I don't think you're running the correct binary then, because:
>>>
>>> $ rm $(which goimports)
>>> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
>>> $ goimports -h
>>> usage: goimports [flags] [path ...]
>>>   -d=false: display diffs instead of rewriting files
>>>   -e=false: report all errors (not just the first 10 on different lines)
>>>   -l=false: list files whose formatting differs from goimport's
>>>   -w=false: write result to (source) file instead of stdout
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov <v.to...@selfip.ru>
>>> wrote:
>>>
>>>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick <brad...@golang.org>:
>>>> > You're running old binaries of each.
>>>>
>>>>
>>>> Hmm. I'm try new goimports but nothing different:
>>>>
>>>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>>>> code.google.com/p/go.tools (download)
>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>> hg pull
>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>> hg tags
>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>> hg branches
>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>>> hg update default
>>>> WORK=/tmp/go-build706264051
>>>> code.google.com/p/go.tools/imports
>>>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>>>> mkdir -p $WORK/code.google.com/p/go.tools/
>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>>>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>>>> <http://code.google.com/p/go.tools/imports/usr/lib64/go/pkg/tool/linux_amd64/6g>
>>>> -o
>>>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>>>> code.google.com/p/go.tools/imports -complete -D
>>>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>>>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go ./imports.go
>>>> ./sortimports.go ./zstdlib.go
>>>> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
>>>> $WORK/code.google.com/p/go.tools/imports.a
>>>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
>>>> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/code.google.com/p/go
>>>> .tools/
>>>> cp $WORK/code.google.com/p/go.tools/imports.a
>>>> /home/vtolstov/devel/go/pkg/linux_amd64/code.google.com/p/go
>>>> .tools/imports.a
>>>> code.google.com/p/go.tools/cmd/goimports
>>>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/
>>>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/
>>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/cmd/goimports
>>>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>>>> <http://code.google.com/p/go.tools/cmd/goimports/usr/lib64/go/pkg/tool/linux_amd64/6g>
>>>> -o
>>>> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6 -p
>>>> code.google.com/p/go.tools/cmd/goimports -complete -D
>>>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/cmd/goimports
>>>> -I <http://code.google.com/p/go.tools/cmd/goi

Re: [go-nuts] Where can I find golang library for google cloud client library for using service account

[Brad Fitzpatrick]

https://godoc.org/golang.org/x/oauth2/google


On Fri, Jun 9, 2017 at 5:20 PM,  wrote:

> I am looking for the client library for Google cloud platform (for
> compute/networking, service account etc) equivalent to amazon's
>
> github.com/aws/aws-sdk-go/service
>
> for Google cloud platform.
>
>
> After searching on the internet I could not identify and get the right 
> library.
>
> Please share the link if anyone has.
>
>
> Thank you
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Brad Fitzpatrick]

Thanks. Fixed.

We do have a list (internally, since it involves internal steps to sign the
installers using Google's signing infrastructure), so I'll make sure this
is on it.


On Thu, May 25, 2017 at 10:20 AM,  wrote:

> The Go1.8.2 and Go 1.8.3 milestones on GitHub are still open. If there's a
> manual checklist for Go releases, can someone see that closing the GitHub
> milestone is added to that checklist?
>
> On Wednesday, May 24, 2017 at 2:12:52 PM UTC-7, Chris Broadfoot wrote:
>>
>> Hi gophers,
>>
>> We have just released Go version 1.8.3, a minor point release.
>>
>> This release includes fixes to the compiler, runtime, documentation, and
>> the
>> database/sql package.
>> https://golang.org/doc/devel/release.html#go1.8.minor
>>
>> It also includes the security fix to the crypto/elliptic package from Go
>> 1.8.2.
>>
>> You can download binary and source distributions from the Go web site:
>> https://golang.org/dl/
>>
>> To compile from source using a Git clone, update to the release with "git
>> checkout go1.8.3" and build as usual.
>>
>> Thanks to everyone who contributed to the release.
>>
>> Chris
>>
> --
> 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: [golang-dev] Golang Developers @ Dallas,TX

[Brad Fitzpatrick]

[+golang-nuts, moving golang-dev to bcc]


On Wed, May 24, 2017 at 12:59 PM, Amruta Shenolikar Warkad <
amruta.shenoli...@gmail.com> wrote:

> Hi,
>
> Looking for Go Developers for a position @ Dallas,TX. Please email resumes
> to amruta.war...@resolvetech.com
>
> --
> 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: [golang-dev] Re: All the Go project history, live in RAM

[Brad Fitzpatrick]

On Thu, May 18, 2017 at 1:38 PM, Dmitri Shuralyov 
wrote:

> Another small question.
>
> https://godoc.org/golang.org/x/build/maintner#GerritProject.Server says:
>
> > Server returns the Gerrit server, such as "go.googlesource.com".
>
> I thought that go.googlesource.com was a Gitiles server, and
> go-review.googlesource.com is where the Gerrit server is (according to
> what it says on the footer). I just want to understand better, but what
> kind of server is go.googlesource.com then? Or is it multiple
> servers/protocols at same URL?
>

They're a mix and there are HTTP load balancing rules making some
go.googlesource.com endpoints go to Gerrit, so we just canonicalize them
all down to the shorter form (without "-review").


> Thinking more about it, is it Gerrit that's doing the actual git
> repository hosting, and reviews at go-review.googlesource.com, but
> Gitilies is just an HTTP frontend to display (read-only) the underlying
> Gerrit git repo?
>
> (I ask because the two may have different APIs, so I want to better
> understand what's available/possible.)
>

Ignore their underlying APIs. We should have all the data in the
maintner.Corpus data structure. If we're missing something, we can add it,
but I'm not aware of anything.

We're definitely missing some accessor methods. They're being added as
needed.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Re: All the Go project history, live in RAM

[Brad Fitzpatrick]

On Thu, May 18, 2017 at 12:57 PM, Dmitri Shuralyov 
wrote:

> The data is generally under 1 second behind reality, thanks to the
>> webhook+incoming-SMTP server we run now at https://pubsubhelper.golang.
>> org/ to get updates from GitHub & Gerrit.
>>
>
> Just a quick implementation question related to that. I understand you use
> Webhooks to get data from GitHub, and incoming-SMTP server to get updates
> from Gerrit, is that right?
>
> Are you aware of/have you considered/is it possible to use Gerrit's hooks
> to get updates from Gerrit? I.e., https://review.
> openstack.org/Documentation/config-hooks.html.
>
> I'm not proposing/suggesting anything at this time, just inquiring.
>

Gerrit's hooks only work for single-process non-load balanced installs.
They don't work for *.googlesource.com instances (Google's hosted versions
backed by Bigtable/Spanner 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go HTTP/2 behind HAProxy TLS Question

[Brad Fitzpatrick]

Why do you need HTTP/2 between HAProxy and Go? That's a low latency
connection. Are you doing push promise frames? Do those even transit
HAProxy?




On Fri, Apr 7, 2017 at 9:56 AM,  wrote:

> Hello!
>
> I'm quite new to web development and currently bumped into a problem I
> can't wrap my head around.
>
> I need to make a simple web server in Go using HTTP/2 and server will be
> deployed on Ubuntu 16.04 server behind HAProxy with TLS certificate from
> Let'sEncrypt.
>
> Here is a problem: in that setup, I don't need to setup encryption on the
> Go side (or can I even? certificate is issued using Certbot to HAProxy),
> HAProxy will take care of it, but to use HTTP/2 in my app I must use TLS
> there?
>
> What am I getting wrong?
> How to do it the right way?
>
> Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Trouble with HTTP PUT, and 100-continue

[Brad Fitzpatrick]

See https://golang.org/pkg/net/http/#Transport.ExpectContinueTimeout

The Go http package deals with 100 continue automatically.

On Sat, Apr 8, 2017 at 3:24 PM, David Peacock 
wrote:

> Hi all,
>
> I'm having difficulty implementing file upload using
> http.NewRequest("PUT").  As shown in my use case below, I'm attempting to
> open a PUT connection to a remote server, and hand over a binary file.
>
> What I am expecting after my client headers are sent is an HTTP
> 100-continue response, but instead I'm receiving back a 200 OK.
>
> https://play.golang.org/p/i1cgVH5JZd
>
> Am I going about this the right way?  Do I have some fundamental mistakes
> with what I'm doing?
>
> Any pointers would be appreciated please.
>
> Thank you,
> David
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] reading/writing after http.Handler returns

[Brad Fitzpatrick]

I'm not sure I understand what the bug report here is.

Is this https://github.com/golang/go/issues/16100 ?


On Thu, Mar 2, 2017 at 3:06 PM,  wrote:

> A few weeks ago we implemented a context that given some readClosers and
> writeClosers would track if any were idle and eventually cancel the
> context. We use this for handlers in our server.
> We seem to be having a crash though where we are effectively returning
> from a handler, and yet a read/write on a resp.Body might still be blocked
> I remember @bradfitz saying this was the only way to get out of the
> blocked read/write, should it be causing a panic (from inside the http pkg)
> if there is a read/write after the handler returns?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] ssh login failed

[Brad Fitzpatrick]

Maybe Han-Wen, copied, knows.


On Mon, Feb 6, 2017 at 7:00 PM, Robert Hsiung <xiong0...@gmail.com> wrote:

> Hi Brad:
> Thanks so much for your suggestion. I run "ssh -v" and get useful
> information as attachment.So,I modify the code,but occurred the different
> problem as below.
> ssh: handshake failed: ssh: unexpected message type 3 (expected one of [6])
>
> // ftp
>
> package main
>
>
> import (
>
> "fmt"
>
>
> "github.com/pkg/sftp"
>
> "golang.org/x/crypto/ssh"
>
> )
>
>
> func main() {
>
> c := {
>
> User: "root",
>
> Auth: []ssh.AuthMethod{
>
> ssh.Password("12345678"),
>
> },
>
> }
>
> connection, err := ssh.Dial("tcp", "192.168.44.129:22", c) // replace this
>
> if err != nil {
>
> fmt.Println(err)
>
> return
>
> }
>
>
> server, err := sftp.NewClient(connection)
>
> if err != nil {
>
> fmt.Println(err)
>
> return
>
> }
>
>
> dir, err := server.ReadDir(".")
>
> if err != nil {
>
> fmt.Println(err)
>
> return
>
> }
>
> for _, fi := range dir {
>
> fmt.Println(fi.Name())
>
> }
>
> }
>
>
> 2017-02-07 0:55 GMT+08:00 Brad Fitzpatrick <bradf...@golang.org>:
>
>> From looking at:
>>
>> ssh: unable to authenticate, attempted methods [none], no supported
>> methods remain
>>
>> It seems like your ssh server requires a different authentication mode
>> and doesn't support KeyboardInteractive (a password).
>>
>> Does the standard ssh client work? What does "ssh -v" say?
>>
>>
>> On Mon, Feb 6, 2017 at 1:25 AM, Robert Hsiung <xiong0...@gmail.com>
>> wrote:
>>
>>> Dear all:
>>> I tried to test sftp function with below coding,but occurred problem as
>>> below. Please give me suggestions. Thanks so much.
>>> ssh: handshake failed: ssh: unable to authenticate, attempted methods
>>> [none], no supported methods remain
>>>
>>> >>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "github.com/pkg/sftp"
>>> "golang.org/x/crypto/ssh"
>>> )
>>>
>>> func main() {
>>>
>>> c := {
>>> User: "root", // replace this
>>> Auth: []ssh.AuthMethod{
>>> ssh.KeyboardInteractive(func(user, instruction string, questions
>>> []string, echos []bool) ([]string, error) {
>>> // Just send the password back for all questions
>>> answers := make([]string, len(questions))
>>> for i, _ := range answers {
>>> answers[i] = "12345678" // replace this
>>> }
>>>
>>> return answers, nil
>>> }),
>>> },
>>> }
>>>
>>> connection, err := ssh.Dial("tcp", "192.168.0.1:22", c) // replace this
>>> if err != nil {
>>> fmt.Println(err)
>>> return
>>> }
>>>
>>> server, err := sftp.NewClient(connection)
>>> if err != nil {
>>> fmt.Println(err)
>>> return
>>> }
>>>
>>> dir, err := server.ReadDir(".")
>>> if err != nil {
>>> fmt.Println(err)
>>> return
>>> }
>>>
>>> for _, fi := range dir {
>>> fmt.Println(fi.Name())
>>> }
>>> }
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

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

Re: [go-nuts] ssh login failed

[Brad Fitzpatrick]

>From looking at:

ssh: unable to authenticate, attempted methods [none], no supported methods
remain

It seems like your ssh server requires a different authentication mode and
doesn't support KeyboardInteractive (a password).

Does the standard ssh client work? What does "ssh -v" say?


On Mon, Feb 6, 2017 at 1:25 AM, Robert Hsiung  wrote:

> Dear all:
> I tried to test sftp function with below coding,but occurred problem as
> below. Please give me suggestions. Thanks so much.
> ssh: handshake failed: ssh: unable to authenticate, attempted methods
> [none], no supported methods remain
>
> 
> package main
>
> import (
> "fmt"
> "github.com/pkg/sftp"
> "golang.org/x/crypto/ssh"
> )
>
> func main() {
>
> c := {
> User: "root", // replace this
> Auth: []ssh.AuthMethod{
> ssh.KeyboardInteractive(func(user, instruction string, questions
> []string, echos []bool) ([]string, error) {
> // Just send the password back for all questions
> answers := make([]string, len(questions))
> for i, _ := range answers {
> answers[i] = "12345678" // replace this
> }
>
> return answers, nil
> }),
> },
> }
>
> connection, err := ssh.Dial("tcp", "192.168.0.1:22", c) // replace this
> if err != nil {
> fmt.Println(err)
> return
> }
>
> server, err := sftp.NewClient(connection)
> if err != nil {
> fmt.Println(err)
> return
> }
>
> dir, err := server.ReadDir(".")
> if err != nil {
> fmt.Println(err)
> return
> }
>
> for _, fi := range dir {
> fmt.Println(fi.Name())
> }
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Go 1.8 Release Candidate 1 is released

[Brad Fitzpatrick]

App Engine has its own release cycle, but they're working on it.


On Tue, Jan 10, 2017 at 3:06 PM, go-guy 
wrote:

> Awesome!
>
> Is there any way that 1.8 can be made available to AppEngine when it's
> released?
>
> On Tuesday, January 10, 2017 at 3:38:03 PM UTC-5, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We have just released go1.8rc1, a release candidate of Go 1.8.
>> It is cut from release-branch.go1.8 at the revision tagged go1.8rc1.
>>
>> Thank you to everyone who has helped to test Go 1.8 so far.
>> We still need more people to test, especially on production workloads.
>> Your help is invaluable.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.8rc1
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.8rc1
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.8rc1
>>
>> To find out what has changed in Go 1.8, read the draft release notes:
>> https://beta.golang.org/doc/go1.8
>>
>> Documentation for Go 1.8 is available at:
>> https://beta.golang.org/
>>
>> Our goal is to release the final version of Go 1.8 on February 1st.
>>
>> Cheers,
>> Chris
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Brad Fitzpatrick]

Thanks!


On Fri, Dec 2, 2016 at 4:53 PM, Will Norris <w...@willnorris.com> wrote:

> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.darwin-386.pkg
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.darwin-amd64.pkg
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.freebsd-386.tar.gz
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.freebsd-amd64.tar.gz
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.linux-386.tar.gz
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.linux-amd64.tar.gz
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.src.tar.gz
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.windows-386.msi
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.windows-386.zip
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.windows-amd64.msi
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go.go1.windows-amd64.zip
>
> On Fri, Dec 2, 2016 at 4:17 PM, Brad Fitzpatrick <bradf...@golang.org>
> wrote:
>
>> I've asked for a list of our objects under that prefix.
>>
>>
>> On Thu, Dec 1, 2016 at 1:56 PM, Edward Muller <edwar...@interlix.com>
>> wrote:
>>
>>> For $reasons I need to download the original linux amd64 version of go1.
>>>
>>> Older go versions are stored under https://storage.googleapis.com
>>> /google-code-archive-downloads/v2/code.google.com/go/
>>>
>>> I have retrieved go1.0.1 (https://storage.googleapis.co
>>> m/google-code-archive-downloads/v2/code.google.com/go/go1.0.
>>> 1.linux-amd64.tar.gz) and later successfully.
>>>
>>> But I can't seem to find the right key for go1. I've tried:
>>> https://storage.googleapis.com/google-code-archive-downloads
>>> /v2/code.google.com/go/go1.linux-amd64.tar.gz
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>>> https://storage.googleapis.com/google-code-archive-downloads
>>> /v2/code.google.com/go/go1-linux-amd64.tar.gz
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>>> https://storage.googleapis.com/google-code-archive-downloads
>>> /v2/code.google.com/go/go1.0.linux-amd64.tar.gz
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>>> https://storage.googleapis.com/google-code-archive-downloads
>>> /v2/code.google.com/go/go1.0-linux-amd64.tar.gz
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>>> https://storage.googleapis.com/google-code-archive-downloads
>>> /v2/code.google.com/go/go1.0.0.linux-amd64.tar.gz
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>>> https://storage.googleapis.com/google-code-archive-downloads
>>> /v2/code.google.com/go/go1.0.0-linux-amd64.tar.gz
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>
>>>
>>> All respond with:
>>> >> encoding='UTF-8'?>NoSuchKeyThe
>>> specified key does not exist.
>>>
>>> I've also tried the getting an index (https://storage.googleapis.co
>>> m/google-code-archive-downloads/v2/code.google.com/go
>>> <https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/go/go1.0.1.linux-amd64.tar.gz>/),
>>> like you can with https://storage.googleapis.com/golang/ (where modern
>>> go releases are stored), but that just returns the same error.
>>>
>>> Can anyone point me to the right https://storage.googleapis.com url for
>>> the go1 release?
>>>
>>> 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.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] Downloading go1

[Brad Fitzpatrick]

I've asked for a list of our objects under that prefix.


On Thu, Dec 1, 2016 at 1:56 PM, Edward Muller  wrote:

> For $reasons I need to download the original linux amd64 version of go1.
>
> Older go versions are stored under https://storage.googleapis.
> com/google-code-archive-downloads/v2/code.google.com/go/
>
> I have retrieved go1.0.1 (https://storage.googleapis.
> com/google-code-archive-downloads/v2/code.google.com/
> go/go1.0.1.linux-amd64.tar.gz) and later successfully.
>
> But I can't seem to find the right key for go1. I've tried:
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go1.linux-amd64.tar.gz
> 
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go1-linux-amd64.tar.gz
> 
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go1.0.linux-amd64.tar.gz
> 
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go1.0-linux-amd64.tar.gz
> 
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go1.0.0.linux-amd64.tar.gz
> 
> https://storage.googleapis.com/google-code-archive-
> downloads/v2/code.google.com/go/go1.0.0-linux-amd64.tar.gz
> 
>
> All respond with:
> <
> Code>NoSuchKeyThe specified key does not
> exist.
>
> I've also tried the getting an index (https://storage.googleapis.
> com/google-code-archive-downloads/v2/code.google.com/go
> /),
> like you can with https://storage.googleapis.com/golang/ (where modern go
> releases are stored), but that just returns the same error.
>
> Can anyone point me to the right https://storage.googleapis.com url for
> the go1 release?
>
> 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.
>

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

[Brad Fitzpatrick]

On Thu, Nov 24, 2016 at 9:24 PM, Florian Weimer <f...@deneb.enyo.de> wrote:

> * Brad Fitzpatrick:
>
> > In light of the CEO of Reddit admitting to editing user comments (see
> > dozen news stories today), I propose we delete the /r/golang subreddit.
> >
> > That is so beyond unethical and immature,
>
> Was it immature because they didn't make any money out of it, at least
> not directly?  Modifying user-generated content without informed
> consent is standard business practice.  You must be aware of that.
> (Many people who read this will see totally misleading ads next to
> this post, for instance, and I obviously never agreed to that.)
>

That is a ridiculous argument. The two situations are not even comparable.

And if you don't like your MUA, use a different one.

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

[go-nuts] Re: Deleting the /r/golang subreddit

[Brad Fitzpatrick]

To be clear, this is just my opinion. Nothing is happening immediately
here. I want to talk with all the existing moderators first.

I also want to understand whether the Go project considers /r/golang an
official space. The fact that the sidebar says "If you encounter an issue,
please mail cond...@golang.org" suggests to me that it IS an official space.

If it's NOT an official space, and if all moderators want to leave, then
the decision is easy: give it to new moderators and let whatever happens
happen.

But if Go DOES consider it an official space, then I would argue it
shouldn't be. I no longer think the platform is a good place to be
associated with. And in this case, we need to decide what to do with
/r/golang (make it private, delete it, pass on ownership and request that
it be labeled unofficial in the sidebar, etc).

I understand there are many users there. I was one of them. There are many
things I like about the Reddit UI and voting system. I would love to see a
replacement available first before we decide on anything.

I probably should've started this thread in private with the other
moderators so I had more information to share when I mailed golang-nuts@.


On Thu, Nov 24, 2016 at 3:53 PM, Brad Fitzpatrick <bradf...@golang.org>
wrote:

> In light of the CEO of Reddit admitting to editing user comments (see
> dozen news stories today), I propose we delete the /r/golang subreddit.
>
> That is so beyond unethical and immature, I no longer want anything to do
> with that site. I will be deleting my account on Reddit after backing up my
> content, and I will no longer be a moderator of /r/golang.
>
> If other moderators of /r/golang feel strongly that it should remain, I
> suppose you're welcome to keep it going.
>
> But if the other moderators want to abandon it and focus our conversation
> elsewhere (or build a replacement), I'm happy to just delete /r/golang.
>
> Opinions?
>
>

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

[Brad Fitzpatrick]

On Thu, Nov 24, 2016 at 6:57 PM, Matt Joiner  wrote:

> I don't believe technical forum moderators should be abusing their
> position to project their ethical standpoints onto users. If users don't
> like Reddit, they can just not participate. If the moderators don't like
> it, step down.
>

The question is what to do with /r/golang when all moderators of it want to
leave.

I don't think we want an unmaintained /r/golang that looks to be an
official Go space.

When /r/news had drama and people split off, /r/uncensorednews started off
okay for a second and then turned into a clusterf*ck.

I don't want /r/golang to turn into crap while looking like it's official.

So I'd prefer /r/golang become dormant and users go to wherever they like,
be it the Go Forum, voat, or /r/unofficialgolang. Or we find an open source
Reddit clone and run an instance for just Go. There are many things I like
about the Reddit voting & thread model & UI over, say, the Go Forum.

Nothing will happen immediately, but it's clear that we now need a plan for
what to do with /r/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: Deleting the /r/golang subreddit

[Brad Fitzpatrick]

On Thu, Nov 24, 2016 at 6:57 PM, Nathaniel Nutter  wrote:

> Are all 25,171 subscribers scum and villainy?  As a someone that reads
> /r/golang I've somehow managed not to come to the same conclusion.
>

I never said 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.

[go-nuts] Re: Deleting the /r/golang subreddit

[Brad Fitzpatrick]

Agreed. Maybe we can just make an auto-reject moderator bot for it, making
sure it has no content.



On Thu, Nov 24, 2016 at 4:01 PM, Adam Langley  wrote:

> (If we just delete it, that may free the name to be squatted on by others.
> I've no knowledge of how Reddit works but setting a moderation bit or the
> like might be more effective in shutting it down.)
>

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

[Brad Fitzpatrick]

[+bketelson, dgryski]


On Thu, Nov 24, 2016 at 3:53 PM, Brad Fitzpatrick <bradf...@golang.org>
wrote:

> In light of the CEO of Reddit admitting to editing user comments (see
> dozen news stories today), I propose we delete the /r/golang subreddit.
>
> That is so beyond unethical and immature, I no longer want anything to do
> with that site. I will be deleting my account on Reddit after backing up my
> content, and I will no longer be a moderator of /r/golang.
>
> If other moderators of /r/golang feel strongly that it should remain, I
> suppose you're welcome to keep it going.
>
> But if the other moderators want to abandon it and focus our conversation
> elsewhere (or build a replacement), I'm happy to just delete /r/golang.
>
> Opinions?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] HTTP2 Runtime panic while Migrating an Application from Go 1.4.1 to 1.6.2

[Brad Fitzpatrick]

Sounds like you need to understand your defer issue before making any
changes or updating versions.

On Oct 28, 2016 6:33 AM, "Nigel Vickers"  wrote:

> Hallo Brad,
>
> ... thanks for the reply. The original post went under 6 weeks ago and I
> had forgotten it, sorry. We currently have a culprit and a work around, and
> your half right.  The postgres in the backend was running out of
> connections and the errors were not getting to the client. The culprit is
> that a defer db.Close() that was working with 1.4.2 and under certain
> conditions didn't under 1.6.2. The workaround was to explicitly close the
> database connection after every request which works but is not optimal. The
> question is why the defer no longer functioned? Previously each request
> from the client triggered the backend request to the db and completed. We
> can see when it functions but haven't found a way to trap when it should
> but didn't. We can see that the proxy is packing everything into a single
> stream but don't see the relevance. HTTP2 is new for us. If you have any
> immediate suggestions they would gratefully received. However, as Andras
> has indicated, we should be moving to Gowut 1.x.x. This means moving 7+
> LOC to a new naming system. We have been delaying hoping to use the new
> "alias" feature. This could take some months. We have a workaround and if
> the problems is present after the update we can take it up again.
>
> Rgs, Nigel Vickers
>
>
> On Thursday, 27 October 2016 23:17:38 UTC+2, bradfitz wrote:
>>
>> That isn't an http2 panic. That's just the http2 code recovering your
>> Handler's panic and printing it, the same as the http1 server does.
>>
>> Your panic is actually somewhere in:
>>
>> lib.setupC5Tab(0x7f6fbe169d20, 0xc8201b0d20, 0xc820436d98,
>> 0x7f6fbe169d20, 0xc8201b0dc0, 0x7f6fbe16a2a8, 0xc820339e60, 0x7f6fbe16a5f8,
>> 0xc8201b0e60, 0xc82047be20)
>> /home/sysop/go/src/lib/rhewocompstatus.go:1310 +0x3976
>> lib.BuildRhewoStatus.func4(0x7f6fbe117538, 0xc8205bc300)
>> /home/sysop/go/src/lib/rhewocompstatus.go:168 +0xc8
>> github.com/icza/gowut/gwu.handlerFuncWrapper.HandleEvent(0xc82040b5c0,
>> 0x7f6fbe117538, 0xc8205bc300)
>> /home/sysop/go/src/github.com/icza/gowut/gwu/event.go:441 +0x3e
>> github.com/icza/gowut/gwu.(*compImpl).dispatchEvent(0xc820158770,
>> 0x7f6fbe117538, 0xc8205bc300)
>> /home/sysop/go/src/github.com/icza/gowut/gwu/comp.go:307 +0x167
>> github.com/icza/gowut/gwu.(*timerImpl).dispatchEvent(0xc820158770,
>> 0x7f6fbe117538, 0xc8205bc300)
>> :1302 +0x60
>> github.com/icza/gowut/gwu.(*serverImpl).handleEvent(0xc82019e900,
>> 0x7f6fbe1172c0, 0xc8202fa7e0, 0x7f6fbe169998, 0xc8202b4ff0, 0x7f6fbe117170,
>> 0xc82007c2a0, 0xc820148460)
>> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:815
>> +0x103e
>> github.com/icza/gowut/gwu.(*serverImpl).serveHTTP(0xc82019e900,
>> 0x7f6fbe117170, 0xc82007c2a0, 0xc820148460)
>> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:683
>> +0x1544
>> github.com/icza/gowut/gwu.(*serverImpl).Start.func1(0x7f6fbe117170,
>> 0xc82007c2a0, 0xc820148460)
>> /home/sysop/go/src/github.com/icza/gowut/gwu/server.go:483 +0x4c
>>
>>
>> On Thu, Oct 6, 2016 at 3:29 AM, Nigel Vickers  wrote:
>>
>>> We are migrating an application from go 1.4.1 to 1.6.2. The application
>>> uses a modified Gowut 0.9 as the framework and initially moved without
>>> issue. The application server runs behind a tls sni
>>> proxy/loadbalancer(slt). While running slt at 1.4.1 and the server at 1.6.2
>>> no problems were encountered. We assume because 1.4.1 couldn’t http2. After
>>> moving the slt to 1.6.2 we are experiencing runtime panics with
>>> http2(protocol attached). Two questions:
>>>
>>> Is the statement that http2 should just run still applicable?
>>> And
>>> Are use cases that fail still of interest as issues?
>>>
>>> We have a “provisional trigger” .  A client xmlHttpRequest triggered by
>>> an attached javascript timer requests a component update and reload from
>>> the server. Currently at 10 second intervals.
>>> Irregularly, between the 90th and 99th request the server panics.
>>>
>>> We are bit stuck because we have no experience with http2. Any
>>> suggestions on how to proceed would be welcome.
>>>
>>> Nigel Vickers
>>>
>>>
>>> Rhewo Dev2016/10/05 14:14:24 serveHTTP Incoming: request Path
>>>  /mainAppWin/e
>>> Rhewo Dev2016/10/05 14:14:24 serveHTTP Incoming: request Body
>>>  &{0xc8205ba120 0xc8200f5180 false 0xc8204e8d00 false}
>>> SessionDump &{LUP_NiaDLsjBFLOpsSUKLa false {63611263456 268951715
>>> 0xf36ee0} {63611266464 12850383 0xf36ee0} map[mainAppWin:0xc8202b4ff0]
>>> map[groups:[free admin] module:Status Lang:de hiddenPan:0xc820476000
>>> ips:xx.xx.xx.xx user:fred2 auth:auth] 144000 0xc820303f20}
>>> Rhewo Dev2016/10/05 14:14:24 serveHTTP appName Parts   3 [ mainAppWin e]
>>> Rhewo Dev2016/10/05 14:14:24Event from comp: 932  event: 15
>>> 

Re: [go-nuts] os.File re-definition

[Brad Fitzpatrick]

Yeah, that'd be a fine cleanup. Want to send a change?

I believe a similar cleanup happened to the net.Conn type a number of
releases ago.



On Sat, Sep 3, 2016 at 3:49 PM, Sridhar 
wrote:

> The os.File type is re-defined across multiple files under src/os for os
> specific builds.
>
> Can this type definition be moved into src/os/File.go which currently
> contains the build-agnostic exported methods ? The definition can then be
> removed from all the individual build specific file_.go ? Will this
> break anything else ?
>
> This will clean up the documentation as well and make it build agnostic
> because currently:
>
> type File  links to  src/os/file_unix.go
> 
>
> func Create  links to src/os/file.go
> 
>
> func Open  links to src/os/file.go
> 
>
> func OpenFile  links to
> src/os/file_unix.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.
>

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

Re: [go-nuts] Go 1.7 is released

[Brad Fitzpatrick]

We a phrase as catchy as "Pics or it didn't happen" for this. "Test or it's
not trustworthy"? Needs work.


On Tue, Aug 16, 2016 at 2:16 PM, Dave Cheney  wrote:

> Until it's part of the ./all.bash test suite, it'll continue to break
> because it has never been proven to work.
>
> > On 17 Aug 2016, at 05:13, Michael Hudson-Doyle <
> michael.hud...@canonical.com> wrote:
> >
> >> On 17 August 2016 at 08:31, Dave Cheney  wrote:
> >> Stripping go binaries is not tested and known to produce broken
> binaries.
> >
> > Stripping should be fine, and any problems produced by it should be
> > reported as bugs. Please.
> >
> >> I recommend not doing this until strip/upx/whatever are tested as part
> of the unit tests which are run before each commit lands.
> >
> > upx, on the other hand, I have no idea about.
> >
> > Cheers,
> > mwh
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] http2 questions

[Brad Fitzpatrick]

http.Transports shouldn't be created inside short-lived functions. See the
docs on https://golang.org/pkg/net/http/#Transport which say:

"By default, Transport caches connections for future re-use. This may leave
many open connections when accessing many hosts. This behavior can be
managed using Transport's CloseIdleConnections method and the
MaxIdleConnsPerHost and DisableKeepAlives fields.

Transports should be reused instead of created as needed. Transports are
safe for concurrent use by multiple goroutines."

Also, the net/http package doesn't let you "create a connection" to a
server. That's a detail that's hidden away, except via
CloseIdleConnections. You just make requests & read responses.

Move your http client/transport to globals or something shared and you
should see the connection reuse you're seeking.



On Wed, Aug 10, 2016 at 3:53 PM, Jeffrey Smith 
wrote:

> I have been playing around with http2 in the latetst 1.7RC today and had a
> few questions
>
> I still had to import "golang.org/x/net/http2" and then set
> http2.ConfigureTransport to actually use http2 when creating a client. I
> was under the impression this was fixed or was I wrong?
> https://github.com/golang/go/issues/14391
>
> tr := {
> TLSClientConfig: {InsecureSkipVerify: true},
> }
> http2.ConfigureTransport(tr)
> client := {Transport: tr}
>
>
> I have the below code but it appears to leak connections whenever the 20
> second timeout is hit after connecting to a client, is there anyway to
> clean up the connection for reuse rather than creating a new one until I
> hit my open file limit?
>
> func worker(id int, jobs <-chan int, results chan<- Results) {
>
> tr := {
> TLSClientConfig: {InsecureSkipVerify:
> true},
> MaxIdleConnsPerHost: 2,
> }
> http2.ConfigureTransport(tr)
> PostClient := {Transport: tr, Timeout:
> time.Duration(20 * time.Second)}
> closeBody := false
>
> for {
> closeBody = false
> t0 := time.Now()
>
> req, err := http.NewRequest("GET",
> Url+strconv.Itoa(<-jobs), nil)
> if err != nil {
> results <- Results{0, err, "0"}
> continue
> }
> resp, err := PostClient.Do(req)
> if resp != nil {
> closeBody = true
> //defer resp.Body.Close()
> }
> t1 := time.Now()
> if err != nil {
> results <- Results{0, err, fmt.Sprintf("%v",
> t1.Sub(t0))}
> if closeBody == true {
> io.Copy(ioutil.Discard, resp.Body)
> resp.Body.Close()
> }
> continue
> }
> //discard the body so we can reuse the connections
> io.Copy(ioutil.Discard, resp.Body)
> //Close the body so we can resuse
> resp.Body.Close()
>
> results <- Results{resp.StatusCode, err, fmt.Sprintf("%v",
> t1.Sub(t0))}
> }
> }
>
> Also does anyone have any recommendations with http2 should I be creating
> one connection per server and fire all requests down that (not even sure
> how I would do this in golang) or just create a global pool and allow the
> http client deal with it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Server TCP

[Brad Fitzpatrick]

What's the "login package"?


On Wed, Aug 3, 2016 at 3:12 PM,  wrote:

> Anyone know why the tcp server closes its connection after of answer the
> login 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] http.Client returning "http2: no cached connection was available"

[Brad Fitzpatrick]

Oh, sorry, I read that as GODEBUG=http2debug=1.

Okay, I'll follow up in https://golang.org/issues/16582

On Tue, Aug 2, 2016 at 7:00 PM, Russ Amos <r...@google.com> wrote:

> Those messages aren't GODEBUG output, it's the errors printed by the
> program as received from http.Client.Get. I'll file a bug.
>
> On Tue, Aug 2, 2016 at 9:51 PM Brad Fitzpatrick <bradf...@golang.org>
> wrote:
>
>> Sorry, I don't read all of golang-nuts@ and never saw that. You could've
>> escalated, though. There are at least two bug trackers available to you:
>>
>> http://b/
>> https://github.com/golang/go/issues  (the one I prefer)
>>
>> But I think your interpretation of the the HTTP/2 client is wrong.
>>
>> If you're a video person, there's a talk on Go's HTTP client and its
>> HTTP/2<->HTTP/1<->HTTP/2 dialing sandwich...
>> https://www.youtube.com/watch?v=FARQMJndUn0
>> If you're not a video person, the slides are linked from youtube.
>>
>> Your output in this email from your program (
>> https://play.golang.org/p/zKthX7Y9RW) doesn't include any error output.
>> You can ignore the GODEBUG output. If it says there's no cached connection,
>> that means http2 has no cached connection it needs to dial (which http1
>> will do). Then http1 works as normal, unless it decides that it negotiated
>> http2, and then it goes back to http2.
>>
>> But any rate-limiting you refer to is unchanged from before, since HTTP/1
>> still dials as normal. There's an open bug to optimize it (to only start 1
>> or 2 TCP connections until we know the negotiated protocol, and then settle
>> on 6 or 1 max connections, etc), but it's no different today than Go 1.5
>> and earlier.
>>
>> In any case, if you have a reproducible bug, let's move this to a bug
>> tracker.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 2, 2016 at 6:36 PM, 'Russ Amos' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> I'm seeing "http2: no cached connection was available" failures from
>>> http.Client when I start many (~hundreds) requests at once. (This issue was
>>> also posted to golang-nuts@ in April
>>> <https://groups.google.com/d/topic/golang-nuts/0YEWYwBOJPI/discussion>,
>>> with no response)
>>>
>>> I may not understand correctly, but I thought this kind of usage was
>>> fine with HTTP 1.1 and net/http, because the spec mandates a max number of
>>> outgoing connections to any given host, so http.Client throttles open
>>> connections and effectively queues requests past that. The http2 package
>>> seems not to do the same. That might be correct according to the spec (I
>>> don't know), but makes using http.Client weird -- I need to rate limit its
>>> usage if the server is HTTP 2, but it does rate limiting for me if the
>>> server is HTTP 1.1.
>>>
>>> Is my understanding correct? Is this a bug? Is the expectation that my
>>> app should be rate limiting, regardless of server version?
>>>
>>> Also, It seems the error being returned is exported
>>> <https://godoc.org/golang.org/x/net/http2#pkg-variables> in the http2
>>> package, but is not exported in the bundled version
>>> <https://golang.org/src/net/http/h2_bundle.go#L4775> in net/http. If it
>>> was exported, I think I could at least retry on my own, but perhaps that's
>>> not the intended usage anyway.
>>>
>>> I wrote this program <https://play.golang.org/p/zKthX7Y9RW> hitting
>>> https://www.google.com/ to demonstrate -- here are a few run results:
>>>
>>> $ GODEBUG=http2client=0 go run /tmp/foo.go
>>> $ GODEBUG=http2client=0 go run /tmp/foo.go
>>> $ GODEBUG=http2client=0 go run /tmp/foo.go
>>> $ GODEBUG=http2client=0 go run /tmp/foo.go
>>> $ GODEBUG=http2client=0 go run /tmp/foo.go
>>>
>>> $ GODEBUG=http2client=1 go run /tmp/foo.go
>>> Get https://www.google.com/: http2: no cached connection was available
>>> Get https://www.google.com/: http2: no cached connection was available
>>> Get https://www.google.com/: http2: no cached connection was available
>>> ...
>>> $ GODEBUG=http2client=1 go run /tmp/foo.go
>>> Get https://www.google.com/: http2: no cached connection was available
>>> $ GODEBUG=http2client=1 go run /tmp/foo.go
>>> $ GODEBUG=http2client=1 go run /tmp/foo.go
>>> Get https://www.google.com/: http2: no cached connection was available
>>> Get https://www

Re: [go-nuts] Using golang/cmd/pprof/internal in a Go program, and/or UNIX socket support in `go tool pprof`?

[Brad Fitzpatrick]

It used to be. It was rewritten in Go.


On Mon, Aug 1, 2016 at 10:44 AM, Nathan LeClaire <nathan.lecla...@docker.com
> wrote:

> Oh, interesting call out.  Thanks Brad.  For some reason I assumed pprof
> was a more general-purpose tool written in C++.  Forget where I may have
> read that.
>
> On Mon, Aug 1, 2016 at 10:14 AM, Brad Fitzpatrick <bradf...@golang.org>
> wrote:
>
>> Note that Go's "go tool pprof" is basically just
>> https://github.com/google/pprof
>>
>> You can vendor that into the Docker daemon and have the server profile
>> itself and send the all-in-one output over the unix socket to the docker
>> command line tool, which users can then run and file a bug report with the
>> output.
>>
>>
>>
>> On Mon, Aug 1, 2016 at 10:10 AM, Nathan LeClaire <
>> nathan.lecla...@docker.com> wrote:
>>
>>> Hey Brad!
>>>
>>> Yes, end users.  Generally, we can't make assumptions about what they
>>> have installed locally (e.g. Go toolchain) and I would like to provide a
>>> way for folks to "click a button" and get a fully symbolized profile to
>>> send to us.  Doing this inside of an existing Go program would be ideal.
>>>
>>> On Sat, Jul 30, 2016 at 1:34 PM, Brad Fitzpatrick <bradf...@golang.org>
>>> wrote:
>>>
>>>> Who is your target audience for this?
>>>>
>>>> You seem to know how to do it (socat + go tool pprof), which suggests
>>>> you want end users to do this or something?
>>>>
>>>>
>>>> On Fri, Jul 29, 2016 at 3:43 PM, nathan.leclaire via golang-nuts <
>>>> golang-nuts@googlegroups.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am interested in doing performance profiling on the Docker daemon
>>>>> using the existing pprof tools and/or code inside of the internal packages
>>>>> of commands, and I was hoping to get some guidance on the challenges I've
>>>>> encountered attempting this.
>>>>>
>>>>> The Docker daemon (a Go program) exposes the pprof endpoints at
>>>>> /debug/pprof.  However, by default the Docker daemon only listens on
>>>>> a Unix domain socket to expose its HTTP API, and exposing it over a
>>>>> non-encrypted TCP port is generally inadvisable due to privilege 
>>>>> escalation
>>>>> concerns.
>>>>>
>>>>> The current most common method for accessing this pprof information
>>>>> seems to be to use socat to temporarily forward requests from the socket 
>>>>> to
>>>>> a locally listening TCP port, and use go tool pprof to collect
>>>>> profile information and analyze it.  This works OK for local development,
>>>>> but I have a few questions about how we might be able to expand support 
>>>>> for
>>>>> collecting these pprof dumps and analyzing them more easily:
>>>>>
>>>>> 1. Would a proposal be considered to add support for collecting this
>>>>> information directly through go tool pprof , e.g. go tool pprof
>>>>> unix:///var/run/docker.sock, or is it not an area of interest for the
>>>>> Go tools?  Some possible dilemmas include the unix:// protocol
>>>>> convention, which seems to be fairly Docker-unique to me and a little odd
>>>>> to conflate (transport layer vs. protocol) with http://.  I've looked
>>>>> extensively at the code and it doesn't seem to cover this today.
>>>>> 2. Is it possible to install and use go tool pprof in a minimal
>>>>> manner, i.e. without the rest of the Golang toolchain?  If so, how?
>>>>> 3. How inadvisable would it be to use the internal code for generating 
>>>>> *Profile
>>>>> and symbolizing the profiles in a 3rd party program?  Obviously due to
>>>>> the internal it's not meant to be exported but it would be very nice
>>>>> to be able to directly embed this type of code in a library-like fashion 
>>>>> to
>>>>> be able to quickly generate dumps from running daemons that could later be
>>>>> loaded with rich semantic information into go tool pprof on another
>>>>> computer (without also needing the source binary).  Naturally it's
>>>>> *possible* to just cp and vendor the code from the stdlib and work
>>>>> around this restriction, but is it advisable?
>>>>> 

Re: [go-nuts] Using golang/cmd/pprof/internal in a Go program, and/or UNIX socket support in `go tool pprof`?

[Brad Fitzpatrick]

Note that Go's "go tool pprof" is basically just
https://github.com/google/pprof

You can vendor that into the Docker daemon and have the server profile
itself and send the all-in-one output over the unix socket to the docker
command line tool, which users can then run and file a bug report with the
output.



On Mon, Aug 1, 2016 at 10:10 AM, Nathan LeClaire <nathan.lecla...@docker.com
> wrote:

> Hey Brad!
>
> Yes, end users.  Generally, we can't make assumptions about what they have
> installed locally (e.g. Go toolchain) and I would like to provide a way for
> folks to "click a button" and get a fully symbolized profile to send to
> us.  Doing this inside of an existing Go program would be ideal.
>
> On Sat, Jul 30, 2016 at 1:34 PM, Brad Fitzpatrick <bradf...@golang.org>
> wrote:
>
>> Who is your target audience for this?
>>
>> You seem to know how to do it (socat + go tool pprof), which suggests you
>> want end users to do this or something?
>>
>>
>> On Fri, Jul 29, 2016 at 3:43 PM, nathan.leclaire via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Hi all,
>>>
>>> I am interested in doing performance profiling on the Docker daemon
>>> using the existing pprof tools and/or code inside of the internal packages
>>> of commands, and I was hoping to get some guidance on the challenges I've
>>> encountered attempting this.
>>>
>>> The Docker daemon (a Go program) exposes the pprof endpoints at
>>> /debug/pprof.  However, by default the Docker daemon only listens on a
>>> Unix domain socket to expose its HTTP API, and exposing it over a
>>> non-encrypted TCP port is generally inadvisable due to privilege escalation
>>> concerns.
>>>
>>> The current most common method for accessing this pprof information
>>> seems to be to use socat to temporarily forward requests from the socket to
>>> a locally listening TCP port, and use go tool pprof to collect profile
>>> information and analyze it.  This works OK for local development, but I
>>> have a few questions about how we might be able to expand support for
>>> collecting these pprof dumps and analyzing them more easily:
>>>
>>> 1. Would a proposal be considered to add support for collecting this
>>> information directly through go tool pprof , e.g. go tool pprof
>>> unix:///var/run/docker.sock, or is it not an area of interest for the
>>> Go tools?  Some possible dilemmas include the unix:// protocol
>>> convention, which seems to be fairly Docker-unique to me and a little odd
>>> to conflate (transport layer vs. protocol) with http://.  I've looked
>>> extensively at the code and it doesn't seem to cover this today.
>>> 2. Is it possible to install and use go tool pprof in a minimal manner,
>>> i.e. without the rest of the Golang toolchain?  If so, how?
>>> 3. How inadvisable would it be to use the internal code for generating 
>>> *Profile
>>> and symbolizing the profiles in a 3rd party program?  Obviously due to
>>> the internal it's not meant to be exported but it would be very nice to
>>> be able to directly embed this type of code in a library-like fashion to be
>>> able to quickly generate dumps from running daemons that could later be
>>> loaded with rich semantic information into go tool pprof on another
>>> computer (without also needing the source binary).  Naturally it's
>>> *possible* to just cp and vendor the code from the stdlib and work
>>> around this restriction, but is it advisable?
>>> 4. Any other ideas for getting a easily importable stand-alone *.pb.gz
>>> pprof output from inside of an exiting Go program (separate from the one
>>> that is being profiled)?  I had an idea to make a minimal Go program (or
>>> embed in an existing one) which might be quite good at this, but getting
>>> richly annotated information (including symbols, etc.) via HTTP alone
>>> without any of the surrounding internal code to process it has proven a lot
>>> trickier than I naively assumed at first.
>>>
>>> Thanks all, and thanks of course for go tool pprof in the first place,
>>> it's a really excellent tool.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

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

Re: [go-nuts] How Go GC perform with 128GB+ heap

[Brad Fitzpatrick]

On Sun, Jul 31, 2016 at 9:13 AM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Sun, Jul 31, 2016 at 5:44 PM Brad Fitzpatrick <bradf...@golang.org>
> wrote:
>
> > You should expect at most 10ms pauses for large heaps as of Go 1.6, and
> especially in Go 1.7.
>
> I'm assuming those 10ms are valid for most/typical programs and that the
> worst case of some, still perfectly reasonable programs[0], cannot be
> guaranteed to be on average that low[1]. Is that assumption correct?
>

The design specifies a 10ms worst case STW pause for all types of load.

If needed, your program's allocations (producing your example of a 32GB
singly-linked list) will start participating in small pieces of the
concurrent garbage collection themselves, thus slowing down the rate of
allocation and speeding up the collection.

If you have a program that exhibits over 10ms pauses, Rick & Austin would
be interested in debugging it. They have such worst-case programs
themselves which they run regularly but still enjoy bug reports. Include
the output of GODEBUG=gctrace=1 in your bug report.

Go 1.5 had the 10ms goal but had known deficiencies late in the cycle which
prevented it from hitting the goal in some extreme cases. Go 1.6 fixed
those, but some other rare cases were found which prevented hitting the
10ms goal in other extreme cases. Go 1.7 fixed most of those and started
working more on throughput, using less CPU to achieve the same goal. An
additional optimization atop the existing design is potentially landing in
Go 1.8.

The GC people can correct me if I got this wrong.


>   [0]: Let's imagine for example a program repeatedly producing a tiny
> sized node single linked list of size, say 32GB, doing something with it
> and throwing it away afterwards for the GC to deal with it.
>   [1]: Or the pause must move instead to malloc waiting for the GC to free
> memory, so technically it's not [directly] a GC pause.
>
> --
>
> -j
>

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

Re: [go-nuts] Why does Golang disallow compare two interface values if their interface types are not in the superset/subset relation?

[Brad Fitzpatrick]

Interface values are comparable. If they have different concrete types,
they compare to false.

See https://golang.org/ref/spec#Comparison_operators

On Sat, Jul 30, 2016 at 10:33 PM, T L  wrote:

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

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

Re: [go-nuts] How Go GC perform with 128GB+ heap

[Brad Fitzpatrick]

You should expect at most 10ms pauses for large heaps as of Go 1.6, and
especially in Go 1.7.

See https://talks.golang.org/2016/state-of-go.slide#37 (for Go 1.6; Go 1.7
is more consistently lower)


On Sat, Jul 30, 2016 at 8:31 PM,  wrote:

> I'm starting a proof of concept project to the company i work. The project
> is a http proxy with a smart layer of cache (Varnish, Nginx and others
> don't work because we have business rules on cache invalidation) for a very
> big microservice architecture (300+ services).
>
> We have 2x128GB machines available today for this project.
> I don't have any doubt that Go has amazing performance, used in other
> projects, and they are rock solid, very fast and consuming very little
> memory.
> But i'm afraid to use Go at this project because of the GC. I'm planning
> to use all the available memory on cache. Isn't all this memory on heap be
> a problem?
>
> It's a new area to me, store tons of GB in a GC language.
> What is my options? Use a []byte and or mmap to stay out of GC?
> Lots and lots of code to reimplement this datastructures on top of slices
> just to avoid the GC, not counting all the encoding/decoding to get/set the
> values.
>
> Stick with the raw slices?
> Didn't used Cgo before, but it is a viable option?
> Or should i go 100% offheap with something like Rust or C?
>
> I hope to add as little overhead as possible.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Using golang/cmd/pprof/internal in a Go program, and/or UNIX socket support in `go tool pprof`?

[Brad Fitzpatrick]

Who is your target audience for this?

You seem to know how to do it (socat + go tool pprof), which suggests you
want end users to do this or something?


On Fri, Jul 29, 2016 at 3:43 PM, nathan.leclaire via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi all,
>
> I am interested in doing performance profiling on the Docker daemon using
> the existing pprof tools and/or code inside of the internal packages of
> commands, and I was hoping to get some guidance on the challenges I've
> encountered attempting this.
>
> The Docker daemon (a Go program) exposes the pprof endpoints at
> /debug/pprof.  However, by default the Docker daemon only listens on a
> Unix domain socket to expose its HTTP API, and exposing it over a
> non-encrypted TCP port is generally inadvisable due to privilege escalation
> concerns.
>
> The current most common method for accessing this pprof information seems
> to be to use socat to temporarily forward requests from the socket to a
> locally listening TCP port, and use go tool pprof to collect profile
> information and analyze it.  This works OK for local development, but I
> have a few questions about how we might be able to expand support for
> collecting these pprof dumps and analyzing them more easily:
>
> 1. Would a proposal be considered to add support for collecting this
> information directly through go tool pprof , e.g. go tool pprof
> unix:///var/run/docker.sock, or is it not an area of interest for the Go
> tools?  Some possible dilemmas include the unix:// protocol convention,
> which seems to be fairly Docker-unique to me and a little odd to conflate
> (transport layer vs. protocol) with http://.  I've looked extensively at
> the code and it doesn't seem to cover this today.
> 2. Is it possible to install and use go tool pprof in a minimal manner,
> i.e. without the rest of the Golang toolchain?  If so, how?
> 3. How inadvisable would it be to use the internal code for generating 
> *Profile
> and symbolizing the profiles in a 3rd party program?  Obviously due to the
> internal it's not meant to be exported but it would be very nice to be
> able to directly embed this type of code in a library-like fashion to be
> able to quickly generate dumps from running daemons that could later be
> loaded with rich semantic information into go tool pprof on another
> computer (without also needing the source binary).  Naturally it's
> *possible* to just cp and vendor the code from the stdlib and work around
> this restriction, but is it advisable?
> 4. Any other ideas for getting a easily importable stand-alone *.pb.gz
> pprof output from inside of an exiting Go program (separate from the one
> that is being profiled)?  I had an idea to make a minimal Go program (or
> embed in an existing one) which might be quite good at this, but getting
> richly annotated information (including symbols, etc.) via HTTP alone
> without any of the surrounding internal code to process it has proven a lot
> trickier than I naively assumed at first.
>
> Thanks all, and thanks of course for go tool pprof in the first place,
> it's a really excellent tool.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Controlling VMware ESXi from Go

[Brad Fitzpatrick]

If you have experience controlling VMware ESXi nodes from Go, could you
point me at recommended packages? Or API reference?

Note: no vCenter, no vSphere management console, no Windows. Only Linux (or
OS X), and only the basic level of ESXi.

I'm new to all this.

Thanks!

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

Re: [go-nuts] [ANN] goimports-update-ignore makes goimports faster, maintains .goimportsignore

[Brad Fitzpatrick]

Nice!

I got the honor of filing the first feature request:
https://github.com/pwaller/goimports-update-ignore/issues/1  :-)


On Sat, Jul 16, 2016 at 4:28 AM, Peter Waller  wrote:

> With , goimports now supports
> a mechanism for ignoring non-go-code directories. For cluttered source
> directories, this makes goimports quite a lot faster.
>
> The problem is, if you want to get the most benefit of this you may need
> to make and maintain a big ignore file.
>
> Enter goimports-update-ignore. See
> https://github.com/pwaller/goimports-update-ignore for more information.
>
> For me, goimports-update-ignore brings the CPU time down from 4200ms to
> 600ms and runtime from 800ms to 200ms.
>
>
> ---
>
> Here's what the result looks like.
>
> $ goimports-update-ignore -measure-only
> Ignored 0 directories. goimports considers 44367 directories in 877ms
> (cpu=4208ms).
>
> $ goimports-update-ignore -max-depth 1
> Ignored 34 directories. goimports considers 27794 directories in 486ms
> (cpu=2224ms).
>
> $ goimports-update-ignore -max-depth 2
> Ignored 118 directories. goimports considers 25461 directories in 406ms
> (cpu=1820ms).
>
> $ goimports-update-ignore -max-depth 3
> Ignored 304 directories. goimports considers 13238 directories in 267ms
> (cpu=1224ms).
>
> $ goimports-update-ignore -max-depth 4
> Ignored 572 directories. goimports considers 11194 directories in 234ms
> (cpu=684ms).
>
> $ goimports-update-ignore -max-depth 5
> Ignored 797 directories. goimports considers 9943 directories in 193ms
> (cpu=664ms).
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] goimports has been updated

[Brad Fitzpatrick]

On Fri, Jul 15, 2016 at 5:47 AM, Peter Waller  wrote:

> Awesome!
>
> For me it brings the CPU time from 6.5s to 3s. Wall from 2.9s to 2s. A
> noticable improvement.
>
> One thing that still makes it slow for me (2s instead of 500ms, I just
> tested), is that I have several of deep trees which aren't go code in my
> $GOPATH/src. To name a few: linux, clang, llvm.
>
> I feel silly for asking, but any chance of having a mechanism to ignore
> these non-go trees, or does anyone have any other clever ideas how to avoid
> this?
>

Done: https://go-review.googlesource.com/24971

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

[Brad Fitzpatrick]

goimports has been updated.

If you've been frustrated by its speed lately, run:

   $ go get -u golang.org/x/tools/cmd/goimports

... and things should be much nicer.

Details at https://golang.org/cl/24941

If I broke something, file a bug: https://golang.org/issues/new

The general speed tracking bug is https://golang.org/issue/16367 (don't use
for new bugs, only for speed)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] GoLang Https Client doesn't work - php curl does. HELP

[Brad Fitzpatrick]

You only need to set tls.Config.InsecureSkipVerify. Don't set Certificates
and ServerName.

Of course, you should not use InsecureSkipVerify for using a third-party
API at all. InsecureSkipVerify is really only meant for localhost testing.

You want to use https://golang.org/pkg/crypto/x509/#NewCertPool instead to
add the trusted certs, and then set tls.Config.RootCAs.


On Wed, Jul 6, 2016 at 5:01 AM,  wrote:

> Hi guys,
>
> I am currently working on integration of my system with 3rd party api.
> They provide us a test server and SSL certificates for it. When I try to
> use golang to connect it I am getting errror : *remote error: bad
> certificate *where code in php works with the same certificates. Can
> anyone tell me what am I doing wrong or what is the difference I cannot see?
>
> Here is my golang code:
>
> https://gist.github.com/Gobonoid/a3289f0665819bc04b03a6b0cfccdc2a
>
> And here is PHP curl:
>
> https://gist.github.com/Gobonoid/ab6c3ded4164e00a5c2e515bbb0959b2
>
> Thank You for any help.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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