Re: [go-nuts] Slice reuse + GC
I see, thank you. RE reducing the capacity, I want to distinguish freeing the memory (1) used for the slice and (2) referred to by the slice elements. I can easily see that freeing (1) is hard and not so beneficial, but I can't see why (2) would be difficult, and the benefit seems potentially much larger. In our case, each slice element has a handle to a sizable []byte, so that's why I was interested to know if they would remain live. As an aside, (1) was addressed by Ian here: https://groups.google.com/d/msg/golang-nuts/sVhjhiYLXNg/YNZ_H-JsBAAJ -- You received this message because you are subscribed to the Google 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/ef48dc4d-ff17-4648-8fb9-4302f43ff5ae%40googlegroups.com.
[go-nuts] Slice reuse + GC
Reducing a slice's length makes the elements unreachable, but the GC appears to still treat them as live, based on this snippet: https://play.golang.org/p/SvsE-nXi-JA I would have expected the HeapInUse to go down in the second measurement. Why is that? I presume that the GC is traversing the slice's capacity rather than length, but I'm not sure why this is necessary. Is there a way (without using unsafe) to access slice elements past the length? -- You received this message because you are subscribed to the Google 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/c2bea525-0636-4365-b551-59d1fceb5959%40googlegroups.com.
[go-nuts] x/net/trace: a race to the Finish()
I use the x/net/trace package to trace requests, and I am running into a
panic caused by adding to a trace after it was Finished[1].
Here's the scenario:
- One incoming request leads to 2 parallel requests to backends.
- We return the fastest backend's response to the user and Finish the trace.
- Anything subsequently added to a trace by the slower backend results in a
panic, if that trace has already been recycled (a race condition).
Here are the options I can think of:
- Wrap the trace.Trace with an implementation that tracks whether Finish()
has been called and ignores subsequent calls.
- Check the context before adding information to a trace, under the
assumption that the context will be canceled if the trace is Finished.
Any others I'm missing?
Do you think it's worth opening an issue to have the library gracefully
ignore events on finished traces?
The rationale is that it seems efficient to implement, and this issue seems
like it would come up in any server that uses concurrent goroutines to
process a request. Although I noticed it because the happy path of my
server is unusual, I think this could arise in any server that uses
concurrent goroutines, if one of them returns early with an error while
others are still processing. Having a panic taking down your server due to
an unrelated error condition seems like something to avoid.
Thanks for your thoughts,
Rob
[1] To the authors: thank you for leaving this helpful note!
func (tr *trace) addEvent(x interface{}, recyclable, sensitive bool) {
/*
NOTE TO DEBUGGERS
If you are here because your program panicked in this code,
it is almost definitely the fault of code using this
package,
and very unlikely to be the fault of this code.
The most likely scenario is that some code elsewhere is
using
a trace.Trace after its Finish method is called.
You can temporarily set the DebugUseAfterFinish var
to help discover where that is; do not leave that var set,
since it makes this package much less efficient.
*/
--
You received this message because you are subscribed to the Google 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/0350993c-4835-4c37-a31c-23107eefd85c%40googlegroups.com.
Re: [go-nuts] Best way to buffer upstream responses in reverse proxy
You could use json iterator’s Stream type if you prefer to feel better by having it wrapped in a library. It does the same thing of course. As the name suggests it can be used to incrementally write the json to a writer if that’s what you’d like. https://godoc.org/github.com/json-iterator/go#Stream -- You received this message because you are subscribed to the Google 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/202ffb33-2f22-443b-9115-35d1fd93187d%40googlegroups.com.
[go-nuts] Does reducing capacity of a slice return memory?
I was curious if reducing the capacity of slice makes that memory available to be reclaimed? (1) Reducing capacity using a three-index: var s = make([]int64, 1e9) ... add data to s, keeping a count .. s = s[:n:n] // reduce length and capacity to number of items read (2) Reducing capacity by slicing off the front, as happens when using slice as a queue var s []int64 s = append(s, 1, 2, 3, 4, 5) s = s[5:] Should I be careful to allocate a new slice and copy over, if I want to avoid that memory being pinned until the original slice goes out of scope? Thank you, Rob -- You received this message because you are subscribed to the Google 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/555450b4-903b-4c65-80f5-64010d5fe0a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Modules - Issues releasing cron/v3
I maintain the github.com/robfig/cron package, and I have just released v3 using Modules via the branch mechanism (so it's on a v3 branch), but I'm having some issues. Here are things that would be ideal: - When people visit github.com/robfig/cron, I would like them to see the v3 version - Similarly, when people create pull requests, I would like them to be against the v3 branch by default. - I would like to have godoc available in the usual place. godoc.org does not seem to be module aware, so https://godoc.org/github.com/robfig/cron/v3 does not work. - "master" reflects ongoing development of v3, rather than being frozen in time as the v1 branch. (minor) I tried to accomplish this by changing the "default branch" from master to v3. However, that had the effect of breaking everyone who uses "go get" without version pinning, since they expected v1. I just reverted that settings change. Here's my next-best solution: - Update the README for v1 and v2 to have a big banner to direct folks to v3 - Link to godoc via gopkg.in: https://godoc.org/gopkg.in/robfig/cron.v3 That works, but it's problematic because (AFAIK) users can NOT actually import `gopkg.in/robfig/cron.v3`, they must import `github.com/robfig/cron/v3`, so the instruction that godoc.org adds at the top of every page to import this package will fail. Unless I'm missing something, not having godoc for module versions seems like a pretty major problem. Is there something I'm missing? How are other maintainers dealing with this? Thanks for your advice, -Rob -- You received this message because you are subscribed to the Google 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/67aeb1dd-579a-47b6-8f5a-d5dced5528a8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: How to parallelize text/template long running functions?
We do this exact thing except using closure templates https://blog.gopheracademy.com/advent-2014/soy-programmable-templates/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and 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
PSA: If anyone uses upx to shrink linux binaries, beware that it will now produce a binary that segfaults immediately. On Tuesday, August 16, 2016 at 7:50:22 AM UTC-4, bep wrote: > > Congrats! Good stuff! > > I wrote the benchmark below to compare two branches in Hugo, but ran a set > after 1.7 upgrade: > > 4 random but fairly big Hugo sites, each built 6 times, rendered to memory: > >- go1.6.2 0.17-DEV 24.479727984s - All OK >- go1.6.2 0.17-MULTILINGUAL 26.49965009s - All OK >- go1.7 0.17-DEV 21.830323612s - All OK >- go1.7 0.17-MULTILINGUAL 23.164846844s - All OK > > That should be a great 10%+ speedup, and that in an application I would > already consider pretty fast. > > > https://github.com/bep/hugo-benchmark > > > > > > > tirsdag 16. august 2016 02.04.08 UTC+2 skrev chai2010 følgende: >> >> go1.7.windows-amd64.zip missing. >> >> 2016-08-16 7:28 GMT+08:00 Chris Broadfoot : >> >>> Hello gophers, >>> >>> We just released Go 1.7. >>> >>> You can read the announcement blog post here: >>> https://blog.golang.org/go1.7 >>> >>> You can download binary and source distributions from our download page: >>> https://golang.org/dl/ >>> >>> To compile from source using a Git checkout, update to the release with >>> "git checkout go1.7" and build as usual. >>> >>> To find out what has changed, read the release notes: >>> https://golang.org/doc/go1.7 >>> >>> Thanks to everyone who contributed to the release. >>> >>> Chris >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> https://github.com/golang-china/gopl-zh >> https://github.com/golang-china >> https://github.com/chai2010 >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: upx / darwin support
Go 1.6
I haven't tried tip but according to a comment on a related issue
<https://github.com/golang/go/issues/6853#issuecomment-66088642>, it
doesn't sound like this is seen as Go's issue so I wouldn't expect any
changes
$ GOOS=darwin go build -o glock github.com/robfig/glock
$ upx glock
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2013
UPX 3.91Markus Oberhumer, Laszlo Molnar & John Reiser Sep 30th
2013
File size Ratio Format Name
-- --- ---
upx: glock: UnknownExecutableFormatException
Packed 0 files.
$ GOOS=linux go build -o glock github.com/robfig/glock
$ upx glock
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2013
UPX 3.91Markus Oberhumer, Laszlo Molnar & John Reiser Sep 30th
2013
File size Ratio Format Name
-- --- ---
10734192 -> 3110464 28.98% linux/ElfAMD glock
Packed 1 file.
Sounds like there is no such tool.
Thanks anyway!
On Thursday, June 23, 2016 at 4:32:34 AM UTC-4, Peter Waller wrote:
>
> On 23 June 2016 at 04:49, Miki Tebeka >
> wrote:
>
>> Which version of Go are you using? According to
>> https://github.com/pwaller/goupx upx should work well with go 1.6
>> (didn't check)
>>
>
> goupx only ever worked with Linux binaries, not OSX (darwin) binaries. I
> (author of goupx) don't know the state of play for upx and go darwin
> binaries.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and 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] upx / darwin support
Does anyone know a way to use upx (or comparable tool) to shrink Go darwin binaries? (It already works extremely well for linux binaries) I saw a link to mpress which claims to do the same thing (brew install mpress), but the source site appears to have gone offline and I can't find a copy of it. Thank you! Rob -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
