On Saturday, October 15, 2016 at 6:37:08 PM UTC+8, Hotei wrote:
>
> re "meaningfullness" - I think he's saying that a finalizer for a function
> called in a goroutine might not run if main() quits first, intentionally or
> otherwise. You can of course check for this specific case by making
Thanks. Made the go code similar to python using CopyBuffer with a block
size of 65536.
buf := make([]byte, 65536)
if _, err := io.CopyBuffer(hash, file, buf); err != nil {
fmt.Println(err)
}
Didn't make too much of a difference, was slightly faster.
What got it to
On Sat, Oct 15, 2016 at 5:52 PM, Justin Israel wrote:
>
>
> On Sun, 16 Oct 2016, 8:17 AM Tong Sun wrote:
>
>> Hi,
>>
>> Need help again.
>>
>> I got everything tested out correctly, in https://github.com/suntong/
>> lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go, but when I tried
>> to
Too diagnose this issue, I tried some benchmarks with time tested tools:
On the same directory:
find DIR -type f -exec md5 {} \;
*5.36s user 2.93s system 50% cpu 16.552 total*
Adding a hashmap on top of that wouldn't significantly increase the time.
Making this multi-processed (32
On Sun, 16 Oct 2016, 8:17 AM Tong Sun wrote:
> Hi,
>
> Need help again.
>
> I got everything tested out correctly, in
> https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go,
> but when I tried to apply it to my real case (more complicated data
>
Thanks, worked.
Am Samstag, 15. Oktober 2016 22:16:14 UTC+2 schrieb Shawn Milochik:
>
> Escape the carat with the backslash.
>
> https://play.golang.org/p/SX_q0KuIvU
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
Escape the carat with the backslash.
https://play.golang.org/p/SX_q0KuIvU
--
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
Hello,
I have the problem, that I want to match expressions like:
bar_f00^42
, but "[[:alpha:]]+_[[:alnum:]]+^[[:digit:]]+" won't work because of the
'^'.
So what are my options?
Best,
Marvin
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
On Sat, Oct 15, 2016 at 3:17 PM, Tong Sun wrote:
> I've put my code at,
>
> http://gopkg.in/suntong/deduper.v1
> i.e., https://github.com/suntong/deduper/tree/v1.2
>
FTA, README updated, see https://github.com/suntong/deduper/tree/trim
--
You received this message because you are subscribed to
Sorry, I meant that calling Write on the hash type might be slower if it's
called more often.
(I'm on mobile right now. When I get back to a keyboard I'll try to come up
with an example)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
It also might be inefficient to call Sum multiple times with smaller slices
compared to calling it once with a larger slice. Try using io.CopyBuffer and
passing in larger buffer sizes to see if the CPU and memory usage start to
converge.
--
You received this message because you are subscribed
Hi,
Need help again.
I got everything tested out correctly,
in
https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go,
but when I tried to apply it to my real case (more complicated data
structure), it doesn't work any more. I've put my code at,
You shouldn't rely on finalisers for the correctness of your program, which is
another way of saying, you shouldn't rely on finalisers. Period.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
Does this happens on tip too? There was a recent CL that
modified the code of the nat pool; see
https://go-review.googlesource.com/#/c/30613/
exp. the "Eliminate allocation in divLarge nat pool" part.
Il giorno sabato 15 ottobre 2016 16:28:01 UTC+2, Raffaele Di Fazio ha
scritto:
>
> Hi,
> I
At first I didn't like this idea, but the README has converted me to the
possibilities. I have to admit I have a strong aversion to interface{}, and
a map as well, but a lot of the other features are very interesting. I
think, in a larger project, this may be just the thing for structured
On Sun, Feb 7, 2016 at 10:18 PM, Tong Sun wrote:
>
> On Sunday, February 7, 2016 at 8:29:29 PM UTC-5, Michael Jones wrote:
>>
>> ha ha! I was typing the same thing. Matt types faster. ;-)
>>
>
> Thank you both!
>
Just FTA, in case someone searches and finds this,
I've collected all three
Yeah, it's totally fine that way. It's doing reflect.New(CollectorTypeNeed)
instead
of reflect.New(CollectorTypeNeed).Elem(), so that the result has
type *CollectorGoogleAnalytics and can be cast to ICollector.
On Saturday, October 15, 2016 at 6:26:21 AM UTC+2, Paulo Coutinho wrote:
>
> Hi,
>
re "meaningfullness" - I think he's saying that a finalizer for a function
called in a goroutine might not run if main() quits first, intentionally or
otherwise. You can of course check for this specific case by making sure
all your goroutines are cleaned up before exiting main - but in some
On Saturday, October 15, 2016 at 8:18:04 AM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Oct 14, 2016 at 4:08 PM, 'Peter Lam' via golang-nuts
> wrote:
> > Is there someway to wait for all pending finalizers to be run?
>
> Not in general, no. Conceptually it doesn't
19 matches
Mail list logo