I am discussing with my friends about how map solve hash collision.
In my opinion, map uses separate chaining to solve hash collision.
but some of my friends think it is linear probing that solve the hash
collision.
--
You received this message because you are subscribed to the Google Groups
"
I recommend https://www.youtube.com/watch?v=Tl7mi9QmLns to learn about how
Go maps work. It's quite in-depth.
To your specific question: Go maps use separate chaining. Every bucket is a
linked list, where every list element stores 8 map entries.
On Sat, Sep 4, 2021 at 9:58 AM xie cui wrote:
> I
I don't think I'm going to be able to make any progress with this. I
chopped away enough code so that it compiles with TinyGo. It works but it's
even slower.
I was hoping to find a way of profiling the WASM code but I see DWARF
support for WASM binaries is still a work in progress.
https://git
Hi Stephen,
I haven't really looked at your code in detail but one obvious
difference between your version and the original is the rendering
code. Are you certain that the slowness is not confined to your
rendering code (I have no reason to believe it is btw)?
Here is a suggestion. I have had a
I was hoping it was the rendering code that was the problem but I'm almost
100% certain that it isn't. If I just allow the emulation to run without
drawing anything to the HTML canvas (and just writing a frame count to the
console) the performance is still the same.
Good tip about Ebiten though. I
I was hoping it was the rendering code that was the problem but I'm almost
100% certain that it isn't. If I just allow the emulation to run without
drawing anything to the HTML canvas (and just writing a frame count to the
console) the performance is still the same.
Good tip about Ebiten thoug
Dnia 2021-09-03, o godz. 17:45:27
Markus Heukelom napisał(a):
> > @Markus: I normally use browser's search function to get to the function
> > and it works well with pkg.go.dev too.
> If you vaguely remember a function name, for example "TrimPrefix" (note:
> it's actually "StripPrefix"), search
Hey Guys,
We know slices grow by doubling until size 1024, the capacity will grow at
25%. The question that I had was why after 1024 elements? Why didn't the
developers chose another number like 2048 or other numbers?
Thanks,
Milad
--
You received this message because you are subscribed to th
I'm wondering what the current state of GNU getopt-style Go packages is.
I've done some research and found the following:
DavidGamba / go-getoptions
alecthomas / kong
elegos / flags
jessevdk / go-flags
pborman / getopt
pborman / options
skeeto / optparse-go
spf13 / cobra
subchen / go-cli
tcler /
Thank you for your answer and opinion Briana Candler.
I ask about unset only because of the cryptic text, at least to me, in the
description of RE2 (https://github.com/google/re2/wiki/Syntax). From
practical point of view, your solutions look good.
I try to google about changes in examples in Go'
Ah, I missed the bit where it says "Flag syntax is xyz (set)
or -xyz (clear) or xy-z (set xy, clear z)." You're quite right, there's a
much simpler way:
https://play.golang.org/p/upupUQUcsR8
On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com wrote:
> Thank you for your answer a
What would you pick? You need to pick something.
It was just arbitrary, I'm sure. 1024 is a nice number, and it's larger
than the length of many slices.
Sometimes a number is just a number.
-rob
On Sun, Sep 5, 2021 at 3:14 AM Miraddo wrote:
> Hey Guys,
>
> We know slices grow by doubling unt
I encountered a deadlock when reading from a buffered channel.
The deadlock occurs when an attempt is made to read from the channel twice,
without an intermediate write to the channel.
The problematic code is as follows:
func main() {
myInt := 432
readerChan := make(chan int, 3)
for forI
On Sat, Sep 4, 2021 at 5:55 PM Michael Dwyer
wrote:
> I encountered a deadlock when reading from a buffered channel.
> The deadlock occurs when an attempt is made to read from the channel
> twice, without an intermediate write to the channel.
>
That is not a deadlock. Reading from a buffered cha
What would you expect to happen here? A chan that has had one item sent
and then one item received has no items on it, so a receive must wait
until another item is sent.
On Sat, 2021-09-04 at 17:55 -0700, Michael Dwyer wrote:
> I encountered a deadlock when reading from a buffered channel.
> The d
Kurtis, thank you for your explanation and for the links, providing more
detailed information on the subject matter.
This was what I was looking for, a reasoned explanation and documentation
that would explain why this condition occurred.
Always good when there are those willing to provide helpf
Quoth jlfo...@berkeley.edu :
> Some of these don't look active, and I'm sure I've missed some.
What kind of activity are you expecting? Are you
seeing unaddressed bugs?
Command line parsing isn't hard, and it's possible
the packages are just finished.
> Any comments on any of the above? What hav
Dese Jon
I have seen this one too
https://github.com/avelino/awesome-go#command-line
Searching like argsparse
Regards
Javier Ruano
El sáb., 4 sept. 2021 20:48, jlfo...@berkeley.edu
escribió:
> I'm wondering what the current state of GNU getopt-style Go packages is.
> I've done some research a
The problem of the current algorithm is it is not monotonically increasing:
x1 := make([]int, 897)
x2 := make([]int, 1024)
y := make([]int, 100)
println(cap(append(x1, y...))) // 2048
println(cap(append(x2, y...))) // 1280
And it is not symmetrical:
x := make([]int, 98)
On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com
wrote:
> The problem of the current algorithm is it is not monotonically increasing:
>
Please explain why that is a problem. Also, I think you are
misusing "monotonically increasing". The behavior up to length 1024 is not
"monotonically increasing
On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:
> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com
> wrote:
>
>> The problem of the current algorithm is it is not monotonically
>> increasing:
>>
>
> Please explain why that is a problem. Also, I think you are
> misusin
On Sat, Sep 4, 2021 at 8:57 PM tapi...@gmail.com
wrote:
> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:
>
>> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com
>> wrote:
>>
>>> The problem of the current algorithm is it is not monotonically
>>> increasing:
>>>
>>
>> Pleas
This is what you're describing, right?
https://play.golang.org/p/RJbEkmFsPKM
The code that does this is here
https://github.com/golang/go/blob/9133245be7365c23fcd60e3bb60ebb614970cdab/src/runtime/slice.go#L183-L242
. Note that there are cap adjustments to optimise block sizes and
alignments. This
On Sunday, September 5, 2021 at 12:16:48 AM UTC-4 kortschak wrote:
> This is what you're describing, right?
> https://play.golang.org/p/RJbEkmFsPKM
>
> The code that does this is here
>
> https://github.com/golang/go/blob/9133245be7365c23fcd60e3bb60ebb614970cdab/src/runtime/slice.go#L183-L242
On Sunday, September 5, 2021 at 12:12:46 AM UTC-4 Kurtis Rader wrote:
> On Sat, Sep 4, 2021 at 8:57 PM tapi...@gmail.com
> wrote:
>
>> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote:
>>
>>> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com
>>> wrote:
>>>
The probl
On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com
wrote:
> Why? That is an undocumented implementation detail. Furthermore, the
>> length of "x1" and "x2" at the time when they are appended to, in
>> combination with the value being appended, are reasonable predictors of the
>> capacity of the new
This is a known problem: https://github.com/golang/go/issues/8618
I looks the root cause is reflect.TypeOf and ValueOf make the values
referenced by the arguments escape, though often this is over-cautious.
On Sunday, August 29, 2021 at 3:02:42 PM UTC-4 nadashin wrote:
> fmt.Printf has a format
On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:
> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com
> wrote:
>
>> Why? That is an undocumented implementation detail. Furthermore, the
>>> length of "x1" and "x2" at the time when they are appended to, in
>>> combination wi
On Sat, Sep 4, 2021 at 7:15 PM Miraddo wrote:
> Hey Guys,
>
> We know slices grow by doubling until size 1024, the capacity will grow at
> 25%. The question that I had was why after 1024 elements? Why didn't the
> developers chose another number like 2048 or other numbers?
>
I suspect: No reason
On Sun, Sep 5, 2021 at 7:02 AM tapi...@gmail.com
wrote:
>
>
> On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote:
>
>> On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com
>> wrote:
>>
>>> Why? That is an undocumented implementation detail. Furthermore, the
length of "x1" and
30 matches
Mail list logo
