Re: [go-nuts] module dependency & testing

There is an important distinction: - users of your project / library are interested in hard dependencies of it - developers / testers of your library will actually be using its test dependencies Go modules enforces the first group your test dependencies as hard dependencies, which is not right.

Re: [go-nuts] Channel Feature Suggestion

u can replace waitempty() and related with a simple atomic counter > variable and avoid channels for this. Far simpler. > > On Feb 22, 2019, at 6:38 AM, Serhat Sevki Dincer > wrote: > > A little imagination would help us all greatly. Select part would > obviously be in a fo

Re: [go-nuts] Channel Feature Suggestion

A little imagination would help us all greatly. Select part would obviously be in a for loop. Like this: func worker() { // do work, prepare whatever for some_condition{ // do stuff Select { ch <- true: go worker() // try to handover some jobs default: // max goroutine limit

Re: [go-nuts] Channel Feature Suggestion

Forgot to start it :P func main() { waiter() } 22 Şub 2019 Cum 09:56 tarihinde Kurtis Rader şunu yazdı: > I don't see where your `waiter()` function is used in your example. I have > been lurking till now but I concur with the other people who have told you > your proposal doesn't make any

Re: [go-nuts] Channel Feature Suggestion

21 Şub 2019 Per 17:12 tarihinde Burak Serdar şunu yazdı: > On Thu, Feb 21, 2019 at 6:51 AM Serhat Sevki Dincer > wrote: > > > > But observer goroutines are not supposed to push to or pull from the > channel. > > What is a use case for observing a channel like this?

Re: [go-nuts] Channel Feature Suggestion

meant has no guarantee 21 Şub 2019 Per 17:18 tarihinde Serhat Sevki Dincer şunu yazdı: > 21 Şub 2019 Per 17:12 tarihinde Burak Serdar şunu > yazdı: > >> On Thu, Feb 21, 2019 at 6:51 AM Serhat Sevki Dincer >> wrote: >> > >> > But observer goroutines a

Re: [go-nuts] Channel Feature Suggestion

But observer goroutines are not supposed to push to or pull from the channel. 21 Şub 2019 Per 16:46 tarihinde Jan Mercl <0xj...@gmail.com> şunu yazdı: > On Thu, Feb 21, 2019 at 2:38 PM Serhat Şevki Dinçer > wrote: > > > waitempty(ch) > > blocks caller until ch buffer is empty > > Not exactly

Re: [go-nuts] A Measure of Hash Function Collisions

wrote: > Good Morning Serhat, here it is: > > # time ./prime2x > prime2x xor: 0 collisions > > real355m51.484s > user12490m36.231s > sys 4079m42.192s > >>>> Am Mo., 18. Feb. 2019 um 08:47 Uhr schrieb Serhat Sevki Dincer >>>> : >&g

Re: [go-nuts] A Measure of Hash Function Collisions

14 Şub 2019 Per 01:58 tarihinde Michael Jones şunu yazdı: > Serhat, > > Some more ideas for you to consider: the expected number of collisions for > an ideal random hash, the option of "folding in" the high bits of the hash > rather than truncating, and finer control of operation. > >

Re: [go-nuts] A Measure of Hash Function Collisions

On Fri, Feb 8, 2019 at 7:42 PM Michael Jones wrote: > clustering: > https://www.cs.cornell.edu/courses/cs3110/2014fa/lectures/13/lec13.html > > careful hash functions often treat short inputs specially. > > iterated shift-xor alone is weak in expanding the "changed bits(s)" signal, > at least by

Re: [go-nuts] A Measure of Hash Function Collisions

8 Şub 2019 Cum 11:57 tarihinde Michael Jones şunu yazdı: > ...says that in one particular test condition (8 character strings, 1M > random strings, all possible shift values) > and under one particular metric of virtue... > > x = x<<15 ^ x>>33 > > ...gives the closest overall approximation to a

Re: [go-nuts] GC problem

repeat my self, use datastructure without huge continuous > allocation (ie slice of slices for your example). Then GC will have a > chance to trigger ealier and free some memory before it exhausted. > > 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" < > jfcga...@gm

Re: [go-nuts] GC problem

The allocation request (make) is made to the runtime which covers GC, right? GC percent is also set to 10%. After 1st call returns, my app has about 2gb ram allocated. When 2nd call requests allocation, runtime cannot: - first allocate another 2gb - free the 1st buffer later due to the definition

Re: [go-nuts] GC problem

yazdı: Your program completes without any trouble on my machine, but do note if we enter the following in an emacs scratch buffer and hit C-j to use it as a glorified calculator: (/ (* 3e8 8) (* 1024 1024 1024)) 2.2351741790771484 If each element in your array