and so has our progressively increasing response time.
Sweet.
Thanks again!
Evan
On Monday, 12 December 2016 14:36:14 UTC-8, Evan Digby wrote:
>
> Hi Dave,
>
> Thanks for the insight. I'll look further into the heap creep. I'll also
> try to get together a log of a r
he
> span of the trace. GC sweep time is proportional to the size of the heap,
> so this is expected.
>
> On Tuesday, 13 December 2016 09:20:07 UTC+11, Evan Digby wrote:
>>
>> Hi Dave,
>>
>> Thanks for the reply. Attached is the full GCTRACE for ~8 hours
Hi all,
Under what circumstances could I expect the Go GC time per pause (right now
calculated using PauseTotalNS / NumGC using the runtime stats) creep up
slowly over time?
Assuming the number of allocations we do per second is consistent, could it
be that the GC is somehow not keeping up wit
y, 12 November 2016 12:57:07 UTC-8, Evan Digby wrote:
>
> I think I've eyeballed a bug in my code that *might* cause this but I
> won't be at a computer for a day or two to verify. I'll keep here posted!
--
You received this message because you are subscribed to the Google
I think I've eyeballed a bug in my code that *might* cause this but I won't be
at a computer for a day or two to verify. I'll keep here posted!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving ema
ace to paste:
https://play.golang.org/p/w9WYsNnkv6
On Thursday, 10 November 2016 17:34:08 UTC-8, Evan Digby wrote:
>
> I'm actually struggling to come up with a toy example that identically
> reproduces the results. I wonder if there are some compiler optimizations
> happening
day, 11 November 2016 12:06:21 UTC+11, Evan Digby wrote:
>>
>> Is it expected that if multiple sub-benchmarks are run in the same
>> benchmark, the cost of the setup will impact the results from the first
>> benchmark but not the second?
>>
>> func BenchmarkInt
Is it expected that if multiple sub-benchmarks are run in the same
benchmark, the cost of the setup will impact the results from the first
benchmark but not the second?
func BenchmarkIntersection(b *testing.B) {
// Long setup -- ~5.5 seconds
b.Run("basic 1", func(b *testing.B) {
for i :
me you put into this.
Evan
On Tuesday, 13 September 2016 22:41:44 UTC-7, Egon wrote:
>
> On Wednesday, 14 September 2016 00:58:39 UTC+3, Evan Digby wrote:
>>
>> Hi Egon,
>>
>> Thanks for that. It seems to implement the same requirements as
>> implemented in my
-apologies for miscommunication the
original question.
Evan
On Tue, 13 Sep 2016 at 14:48 Egon wrote:
>
>
> On Wednesday, 14 September 2016 00:18:26 UTC+3, Evan Digby wrote:
>>
>> Hi Egon,
>>
>> My requirements are more simple than a graceful http shutdown. I simply
n Tuesday, 13 September 2016 23:31:55 UTC+3, Evan Digby wrote:
>>
>> Hi John/Egon/Augusto,
>>
>> I should point out is that all we need to guarantee (barring abnormal
>> termination of course) is that once a task starts processing, it finishes.
>> Partially proces
for the h.closed channel.
>
>
>
> Back in a few. J
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* Evan Digby [mailto:evandi...@gmail.com]
> *Sent:* 2016 September 13, Tue 15:59
> *To:* John Souvestre; golang-nuts
>
>
>
gt;
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> *On Behalf Of *Evan Digby
> *Sent:* 2016 September 13, Tue 15:32
> *To:* golang-nuts
> *Cc:* aro...@gmail.com
> *Subject:
> at other libraries that do that? If you don't have a way to account for
> the time between Handle(..) is called and the goroutine starts, you always
> might miss a task that got called near the time Close() was called.
>
> - Augusto
>
>
> On Tuesday, Septemb
are trying to do graceful http shutdown. Have you looked
> at other libraries that do that? If you don't have a way to account for
> the time between Handle(..) is called and the goroutine starts, you always
> might miss a task that got called near the time Close() was called.
&g
n't have a way to account for
> the time between Handle(..) is called and the goroutine starts, you always
> might miss a task that got called near the time Close() was called.
>
> - Augusto
>
>
> On Tuesday, September 13, 2016 at 12:50:50 PM UTC-7, Evan Digby wrote:
>
n add a waitgroup Add or Rlock
before the goroutine is spawned (among other sync requirements to ensure no
new connections are accepted, etc).
Thanks again,
Evan
On Tuesday, 13 September 2016 13:11:17 UTC-7, Egon wrote:
>
> On Tuesday, 13 September 2016 22:52:27 UTC+3, Evan Digby
all it before the goroutine.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *Evan Digby
> *Sent:* 2016 September 13, Tue 14:59
> *To:* golang-nuts
> *Su
d do the job –
> one to show when all the tasks are running and one to show when all the
> tasks are done. No mutex and no blocking channels.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan
gt; earlier, there is no race.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *Evan Digby
> *Sent:* 2016 September 13, Tue 14:19
> *To:* golang-nuts
>
isecond) }
> // alternatively use runtime.Gosched() instead of Sleep
> }()
>
> h.Close()
>
> if atomic.LoadInt64(&counter) > 0 {
> // fail
> }
>
> It's not completely fool-proof, but should work well enough in practice.
>
> On Tuesday, 13 Septem
ch, since the lock approach
> could block an outstanding task. The key to using waitgroups is to call
> Add() outside of goroutines that might call done:
>
> https://play.golang.org/p/QVWoy8fCmI
>
> On Tuesday, September 13, 2016 at 12:19:16 PM UTC-7, Evan Digby wrote:
>>
vestre - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *Evan Digby
> *Sent:* 2016 September 13, Tue 13:56
> *To:* golang-nuts
> *Subject:* [go-nuts] Having difficulty testing this "cleanly"
>
&g
Has anyone come across a good way, non-racy way to ensure that N tasks are
guaranteed to be completed after a function is called? Essentially I have a
“Close” function that must be guaranteed to block until all tasks are
finished. Achieving this was pretty simple: wrap each task in an RLock, and
Sorry, I didn't see your longer high-level overview post--I see the vision
a bit more clearly now.
Have you used slack? It might be a good place to start discussion to hammer
out some details before moving onto a google doc. I find shared google docs
can be challenging without at least a founda
This is something I would be interested in working on/supporting. I have 14
month old twins so I have to limit my expectations for coding outside of
work these days, but this type of project I'd be keen on as an amateur
photographer/astrophotographer. I've often looked at contributing to
existi
BenchmarkCombine6-4 1000 145 ns/op
Since my full use case (wasn't included in the original post) requires
appending more than one thing in a loop, that exaggerates this issue
further.
Thanks!
Evan
On Sunday, 17 July 2016 16:31:33 UTC-7, kortschak wrote:
>
> On Su
Hi TL,
It's identical between the two runs as best as can be with a rebuild in between
two runs. The values used are the same.
I'm going to dig into the assembly a bit when I get the time.
For now the solution is to explicitly make copies, which was the desired result
in the first place.
The
Hi Nate,
Thanks for the suggestions. We've definitely backed off appending to a
separate value.
Our code ended up looking like this (the requirements were actually a bit
more complex than the core example):
func (n Namespace) Combine(with ...Namespace) Namespace {
// Benchmarks show it's worth
that
> share the same underlying array.
>
> On Friday, July 15, 2016 at 7:28:32 PM UTC+2, Evan Digby wrote:
>>
>> I can't reproduce this in go playground (yet), but under what
>> circumstances would/could/should:
>>
>> nss := []namespace
I can't reproduce this in go playground (yet), but under what circumstances
would/could/should:
nss := []namespace.Namespace{
append(ns, g2message.NamespaceWin...),
append(ns, g2message.NamespaceSpend...),
}
Act differently than:
ns1 := append(ns, g2message.NamespaceWin...)
ns2 := append(ns, g2
Hi All,
I'm looking for some advice on a pattern I've found myself trapped in. I
don't think I like it.
For all examples, assume I have to meet the following interface (enforced
externally):
type DoerCloser interface {
Do()
Close()
}
The code below is mostly snippets from:
https://play.gol
Filed issue: https://github.com/golang/go/issues/16156
Thanks all.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For
her than "that's what happens". Feel
> free to file an issue.
>
> -rob
>
>
> On Wed, Jun 22, 2016 at 1:29 PM, Evan Digby > wrote:
>
>> Hi Rob,
>>
>> Thanks! I'm using 1.6. I guess my question wasn't too clear now that I
>> read i
ing a template, which used to be an error but is not any
> more.
>
> -rob
>
>
> On Wed, Jun 22, 2016 at 1:13 PM, Evan Digby > wrote:
>
>> I'm noticing that if I accidentally create a second template with the
>> same name but no content there is no e
I'm noticing that if I accidentally create a second template with the same
name but no content there is no error reported when I "parse" it, but then
when I attempt to execute it I do see an error:
https://play.golang.org/p/Rj3433vvju
Is this expected behaviour? Why wouldn't it simply return an
To further this, if you do need your internal model to be a concrete struct
rather than interface this approach still fits:
https://play.golang.org/p/_wrgN1FltA
On Friday, 17 June 2016 15:02:43 UTC-7, Evan Digby wrote:
>
> One approach to deal with this would be to abstract your internal
One approach to deal with this would be to abstract your internal model as
an interface from the model you receive and mutate them to match. This also
gives you the power to truncate/round/mutate a float however best suites
your needs rather than hoping the library truncates/rounds/mutates in a
Currying is translating the evaluation of a function with multiple arguments
into evaluating a sequence of functions with one argument. Not sure how this
doesn't qualify, even if a closure was used to accomplish this.
As for the value, at the very least there is the same value as using closures
I played around tonight trying to come up with a better way, but instead I
came up with 2 decidedly worse ways (particularly considering
readability/maintenance is the primary concern of the question). I think
they're novel enough to share!
https://play.golang.org/p/w9YxsEFlF8
1) Original
2)
Unfortunately there's a reason why password managers still require a
passphrase. It's simply not secure to store the key anywhere near the
secure files.
I'm not saying password managers are perfect--they have their own security
issues--but it seems that you're attempting to closely mimic that
Apologies. I meant "as Axel" stated :)
On Monday, 13 June 2016 10:06:12 UTC-7, Evan Digby wrote:
>
> As Haddock stated, it is basically impossible to prevent it from being
> accessible to someone looking. Embedding as plaintext will be trivial to
> extract, and essentially
As Haddock stated, it is basically impossible to prevent it from being
accessible to someone looking. Embedding as plaintext will be trivial to
extract, and essentially any method you use to encrypt/obfuscate it
(encrypt the encryption??) will only be slightly less trivial to extract.
Typically
43 matches
Mail list logo
