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
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
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
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.
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
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
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
