goroutines

[obtuse delta]

will this ensure than if a stop command is sent the goroutine will stop executing

[humble orchid]

Yeah, it looks so.
It would be more idiomatic if the for was directly on the read from the channel, and if the end of the stream was signaled by a closed channel, a la for _ = range cmd.

[obtuse delta]

for was directly on the read from the channel
wdym? i dont understand

[humble orchid]

a for with a range over the channel

[obtuse delta]

yc explained it, and i implemented it

func commandHandler(cmd chan struct{}, generated *[]string, nextWord func() string) {
    for range cmd {
        *generated = append(*generated, nextWord())
    }
}

is this right?

[humble orchid]

more idiomatic indeed, and you don't need the Command

[knotty quartz]

Why did you change the type from Command to struct{}?

And why do you have a channel that just says that a function should be called?

Why not send the words over the channel?

[humble orchid]

it looks a bit convoluted, given the number of words in the end is the number of messages you read form the channel

[obtuse delta]

coz now theres only 1 command left

ig i can change it to bool so its like pulsing

[obtuse delta]

func generateTimeTest(nextWord func() string, cmd chan struct{}) *[]string {
    var generated []string
    for range INIT_WORDS {
        generated = append(generated, nextWord())
    }

    go commandHandler(cmd, &generated, nextWord)
    return &generated
}

func commandHandler(cmd chan struct{}, generated *[]string, nextWord func() string) {
    for range cmd {
        *generated = append(*generated, nextWord())
    }
}

this is the full code

as the user types more words, more words get generated

i'll fix the naming a little

[obtuse delta]

coz ig then the reader will be blocking?

[humble orchid]

The goroutine running comamndHandler() is reading and writing the generated string array, and the main goroutine is gonna read that same variable, and there is no synchronization of any kind.

[obtuse delta]

ig its fine coz theres a buffer of 100 words

[humble orchid]

size does not matter

[knotty quartz]

What is command handler supposed to do?

Why is it run concurrently?

[obtuse delta]

add more words to the slice

when commanded to

[obtuse delta]

and there is no synchronization of any kind
y is it necessary

[humble orchid]

it is

[obtuse delta]

no im not challenging ur im asking y

[humble orchid]

I did not misunderstand, I'm answering, you need to fix the synchronization

[knotty quartz]

You must not read and write to the same memory without ensuring that the write happens in in isolation to reads.

[humble orchid]

if we knew how generated is going to be used, maybe we could give a possible way to synchronize it

[obtuse delta]

What problem will it cause?

[knotty quartz]

Corruption

Imagine you ready a piece of text just as someone is overwriting it. How much of the new and old text will you know?

You'll get some really weird bugs.

[obtuse delta]

https://github.com/Taz03/monkeytype-tui

[knotty quartz]

What is the project supposed to do?

[humble orchid]

oof, I don't have enough time to read through a whole project

[knotty quartz]

You should add a README.md that explains what the project is for and what it does.

[obtuse delta]

See the test folder

[obtuse delta]

It's in a pr

Soon

[obtuse delta]

Generator and test.go files

[knotty quartz]

Awful README. 😦

Can you explain what you're actually trying to do?

[obtuse delta]

Uhh so it's a typing test app

And the words are generated infinitely so it keeps going

After u type one word the slice reader sends command to add one more word

And it starts with 100 words

So there's a 100 words buffer in between

[knotty quartz]

What does nextWord() string do?

[obtuse delta]

Gives the next word to add

[knotty quartz]

What does it do though?

The name and return type explains what you just said.

What does the function actually do?

[obtuse delta]

The list of words are arranged in frequency order so it selects one randomly but giving the more frequent ones more frequently

Or if it's not arranged by frequency it just gives a random one

That's y the if else

[knotty quartz]

What does nextWord look like?

[obtuse delta]

Wdym

The result?

[knotty quartz]

The code

[obtuse delta]

U can see the code in GitHub repo?

[knotty quartz]

Is it a text generator?

[obtuse delta]

No it picks a word from predefined set of words

[knotty quartz]

I see

How do you know when to stop?

[obtuse delta]

I haven't implemented that yet but it should stop when timer runs out

[knotty quartz]

Send the words through a channel and the writer can close the channel when time's up

The reader of the channel will notice that there's no more words coming and can return.

[obtuse delta]

Well the reader will have to close and the writer will stop

[knotty quartz]

No, the write should close it

[obtuse delta]

Coz writer won't have access to timer

[knotty quartz]

It's much easier that way

Why not?

Can't you send a signal to the writer?

[obtuse delta]

Yes ig

[knotty quartz]

It would be much easier and less error prone that way

Reading from a closed channel yields a zero value. Writing to a closed channel causes a panic.

[obtuse delta]

Ohh

[knotty quartz]

So you want the writer be in control of that

You can use context.Context to tell the writing that it's time to stop.

The writer will check the context before writing. If the context is cancelled, it can close the channel.

The reader will notice that the channel is closed.

[obtuse delta]

But

for range chnl {
    // ...
}

Will automatically stop if the channel gets closed?

[knotty quartz]

Yes

for word := range ch { will loop until the channel is closed.

[obtuse delta]

So no extra writes an no panic?

[knotty quartz]

Exactly

When does the writer know that it's time to send the next word?

[obtuse delta]

So it's safe for reader to close in this case?

[knotty quartz]

No

The loop will read until it's closed.

[obtuse delta]

Reader signals it, after one word is typed

[knotty quartz]

Once the loop ends, the channel is closed already

So the reader asks for next word? 😐

[obtuse delta]

Yes

[knotty quartz]

Then the reader should just loop and call a function to get the next and then stop calling it when it's time to stop.

No channel

[obtuse delta]

But that'll block the main thread while all the operation is done

[knotty quartz]

The reader can run concurrently

[obtuse delta]

But then how will I sync the UI rendering

[knotty quartz]

What does the UI show?

[obtuse delta]

The words ?

[knotty quartz]

It's too much code for me to read now.

Yeah

Why can't the reader update the UI?

[obtuse delta]

I can't just update one single word in the UI I have to recalculate the entire UI and print it

[knotty quartz]

When do you want to update it then?