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.
2
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
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
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 si
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?
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 are n
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 the
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
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.
>
> https://pla
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
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 r
se 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...@gmail.com> нап
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 o
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 takes up 8 bytes, which is the cas
14 matches
Mail list logo
