Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39053 > unrolled thread

boolean while loops "how to stop" and "make room for textout to textarea"

Back to article view | Back to comp.lang.javascript

Contents

  boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 03:44 -0700
    Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 04:20 -0700
      Re: boolean while loops "how to stop" and  "make room for textout to textarea" Julio Di Egidio <julio@diegidio.name> - 2020-10-31 06:07 -0700
        Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 09:41 -0700
        Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 09:45 -0700
        Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 09:48 -0700
          Re: boolean while loops "how to stop" and  "make room for textout to textarea" Julio Di Egidio <julio@diegidio.name> - 2020-10-31 10:10 -0700
            Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 10:42 -0700
        Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 10:05 -0700
          Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-10-31 18:49 +0100
            Re: boolean while loops "how to stop" and "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 11:07 -0700
              Re: boolean while loops "how to stop" and "make room for textout to textarea" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-11-01 11:39 +0000
              Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-01 13:52 +0100
        Re: boolean while loops "how to stop" and  "make room for textout to textarea" Julio Di Egidio <julio@diegidio.name> - 2020-11-01 21:57 -0800
          Re: boolean while loops "how to stop" and  "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-11-01 23:44 -0800
    Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-10-31 18:24 +0100
      Re: boolean while loops "how to stop" and "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 10:44 -0700
        Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-10-31 18:52 +0100
          Re: boolean while loops "how to stop" and "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-10-31 11:14 -0700
            Re: boolean while loops "how to stop" and "make room for textout to textarea" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-11-01 11:45 +0000
              Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-01 14:02 +0100
                Re: boolean while loops "how to stop" and "make room for textout to textarea" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-11-01 17:38 +0000
                  Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-01 21:07 +0100
                    Re: boolean while loops "how to stop" and "make room for textout to textarea" John G Harris <niam@jghnorth.org.uk.invalid> - 2020-11-02 19:36 +0000
                      Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-03 18:34 +0100
                        Re: boolean while loops "how to stop" and "make room for textout to textarea" Julio Di Egidio <julio@diegidio.name> - 2020-11-03 11:48 -0800
                          Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-04 15:17 +0100
                            Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-04 15:18 +0100
                            Re: boolean while loops "how to stop" and "make room for textout to textarea" Julio Di Egidio <julio@diegidio.name> - 2020-11-04 12:52 -0800
                              Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-05 16:12 +0100
            Re: boolean while loops "how to stop" and "make room for textout to textarea" Arno Welzel <usenet@arnowelzel.de> - 2020-11-01 14:02 +0100
    Re: boolean while loops "how to stop" and "make room for textout to textarea" "sc...@sauyet.com" <scott@sauyet.com> - 2020-11-03 13:27 -0800
      Re: boolean while loops "how to stop" and "make room for textout to textarea" Jonas Thörnvall <jonas.thornvall@gmail.com> - 2020-11-03 14:08 -0800
        Re: boolean while loops "how to stop" and "make room for textout to textarea" Scott Sauyet <scott.sauyet@gmail.com> - 2020-11-03 17:28 -0800

Page 2 of 2 — ← Prev page 1 [2]

#39080 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

John G Harris:

> On Sat, 31 Oct 2020 11:14:46 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
>> That is basicly what i want to know, why aren't boolean while loops run in separate threads? 
> 
> So you want the HTML standard to be updated to say that the document
> MUST be displayed by a multi-core processor running an operating
> system that allows applications to demand more than one core.

Threads in software have nothing to do with CPU cores.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39086 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

On Sun, 1 Nov 2020 14:02:39 +0100, Arno Welzel <usenet@arnowelzel.de>
wrote:

>John G Harris:
>
>> On Sat, 31 Oct 2020 11:14:46 -0700 (PDT), Jonas Thörnvall
>> <jonas.thornvall@gmail.com> wrote:
>> 
>>   <snip>
>>> That is basicly what i want to know, why aren't boolean while loops run in separate threads? 
>> 
>> So you want the HTML standard to be updated to say that the document
>> MUST be displayed by a multi-core processor running an operating
>> system that allows applications to demand more than one core.
>
>Threads in software have nothing to do with CPU cores.

A software thread is not guaranteed to be activated immediately an
event appears in the Windows event queue. The thread needs to be using
separate hardware, whether part of the processor or all of it, for it
to be immediate. 

It was a short reply to Jonas so I decided that "core" would be good
enough. At least it's meaning is less likely to be fudged by marketing
hype.

  John

[toc] | [prev] | [next] | [standalone]

#39091 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

John G Harris:

> On Sun, 1 Nov 2020 14:02:39 +0100, Arno Welzel <usenet@arnowelzel.de>
> wrote:
> 
>> John G Harris:
>>
>>> On Sat, 31 Oct 2020 11:14:46 -0700 (PDT), Jonas Thörnvall
>>> <jonas.thornvall@gmail.com> wrote:
>>>
>>>   <snip>
>>>> That is basicly what i want to know, why aren't boolean while loops run in separate threads? 
>>>
>>> So you want the HTML standard to be updated to say that the document
>>> MUST be displayed by a multi-core processor running an operating
>>> system that allows applications to demand more than one core.
>>
>> Threads in software have nothing to do with CPU cores.
> 
> A software thread is not guaranteed to be activated immediately an
> event appears in the Windows event queue. The thread needs to be using
> separate hardware, whether part of the processor or all of it, for it
> to be immediate. 

Again: threads in software have nothing to do with CPU cores. Even a
single core single threaded CPU you run multithreaded software. The only
difference is the lower performance due to the context switches
neccessary for the CPU to handle different threads and the fact that
multiple cores can run more multiple threads at the same time.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39109 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

On Sun, 1 Nov 2020 21:07:57 +0100, Arno Welzel <usenet@arnowelzel.de>
wrote:

  <snip>
>Again: threads in software have nothing to do with CPU cores. Even a
>single core single threaded CPU you run multithreaded software. The only
>difference is the lower performance due to the context switches
>neccessary for the CPU to handle different threads and the fact that
>multiple cores can run more multiple threads at the same time.

Are you saying that every operating system that runs web browsers
guarantees to do time-slicing of threads if it can't do any better?
That is, a forever loop is guaranteed to be paused from time to time
without that being requested by the thread code.

If not, Jonas complains and wants the HTML standard to forbid it, one
way or another.

  John

[toc] | [prev] | [next] | [standalone]

#39110 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

John G Harris:

> On Sun, 1 Nov 2020 21:07:57 +0100, Arno Welzel <usenet@arnowelzel.de>
> wrote:
> 
>   <snip>
>> Again: threads in software have nothing to do with CPU cores. Even a
>> single core single threaded CPU you run multithreaded software. The only
>> difference is the lower performance due to the context switches
>> neccessary for the CPU to handle different threads and the fact that
>> multiple cores can run more multiple threads at the same time.
> 
> Are you saying that every operating system that runs web browsers
> guarantees to do time-slicing of threads if it can't do any better?

No, that is not what I am saying.

I said, that multiple cores are not a requirement to run multithreaded
software.

> That is, a forever loop is guaranteed to be paused from time to time
> without that being requested by the thread code.

No, a forever loop will block the current thread and a JavaScript
executes a script in the browser only in one single thread.

However other threads or processes may still run fine as long as the OS
uses preemptive multitasking. This already worked fine in the days of
the 68000 and Atari ST with MiNT or MagiC instead of TOS.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39111 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

On Tuesday, 3 November 2020 18:35:06 UTC+1, Arno Welzel  wrote:
> John G Harris fantasised:
<snip>
> > That is, a forever loop is guaranteed to be paused from time to time
> > without that being requested by the thread code.
> 
> No, a forever loop will block the current thread and a JavaScript
> executes a script in the browser only in one single thread.

JS executes in one thread everywhere (Node, JS.NET, etc.), not just
in the browser: event-driven is its very *runtime model*.

That said, an infinite loop without async calls or at last some sleep
is a CPU-choking nonsense in any language...

Julio

[toc] | [prev] | [next] | [standalone]

#39115 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Julio Di Egidio:

> On Tuesday, 3 November 2020 18:35:06 UTC+1, Arno Welzel  wrote:
>> John G Harris fantasised:
> <snip>
>>> That is, a forever loop is guaranteed to be paused from time to time
>>> without that being requested by the thread code.
>>
>> No, a forever loop will block the current thread and a JavaScript
>> executes a script in the browser only in one single thread.
> 
> JS executes in one thread everywhere (Node, JS.NET, etc.), not just
> in the browser: event-driven is its very *runtime model*.

So what? I did say that is is *only* in a browser this way.

> That said, an infinite loop without async calls or at last some sleep
> is a CPU-choking nonsense in any language...

Except when you need to get things done and CPU usage is less important
than the time needed to finish a job.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39116 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Arno Welzel:

> Julio Di Egidio:
> 
>> On Tuesday, 3 November 2020 18:35:06 UTC+1, Arno Welzel  wrote:
>>> John G Harris fantasised:
>> <snip>
>>>> That is, a forever loop is guaranteed to be paused from time to time
>>>> without that being requested by the thread code.
>>>
>>> No, a forever loop will block the current thread and a JavaScript
>>> executes a script in the browser only in one single thread.
>>
>> JS executes in one thread everywhere (Node, JS.NET, etc.), not just
>> in the browser: event-driven is its very *runtime model*.
> 
> So what? I did say that is is *only* in a browser this way.

Correction: I did *not* say that is is *only* in a browser this way.

(Wanted to write "Did I say... ?" but then forgot to correct the
sentence before sending the post).




-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39117 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

On Wednesday, 4 November 2020 15:17:37 UTC+1, Arno Welzel  wrote:
> Julio Di Egidio:
> 
> > On Tuesday, 3 November 2020 18:35:06 UTC+1, Arno Welzel  wrote:
> >> John G Harris fantasised:
> > <snip>
> >>> That is, a forever loop is guaranteed to be paused from time to time
> >>> without that being requested by the thread code.
> >>
> >> No, a forever loop will block the current thread and a JavaScript
> >> executes a script in the browser only in one single thread.
> > 
> > JS executes in one thread everywhere (Node, JS.NET, etc.), not just
> > in the browser: event-driven is its very *runtime model*.
> 
> So what? I did [not] say that is is *only* in a browser this way.

<<Just creating a loop which never exists as long as "run" is not false
does not work if this should be something useful in the browser.>>

<<JavaScript *is* able to do this. However you try to run a endless loop
in a *browser* and wonder why the browser does not handle input as long
as the loop runs. You just don't understand what "event driven"
programming means.>>

<<The language has nothing to do with it. I am talking about how a UI and
multithreading works in general. If there is only one thread there is no
way to handle UI events as long as the thread is inside a while() loop.>>

<<Finally you get it! Yes JavaScript in a browser *is* single threaded!>>

Sure, I know you didn't mean to say what you said, and I have
even refrained for several post before pointing out that mentioning
the UI or the browser here is *misleading* to say the least.  But
then I did because it was important, not to correct you, but to say
JAVASCRIPT's the very RUNTIME MODEL IS EVENT-DRIVEN, and even you
might learn something new for a change.

> > That said, an infinite loop without async calls or at last some sleep
> > is a CPU-choking nonsense in any language...
> 
> Except when you need to get things done and CPU usage is less important
> than the time needed to finish a job.

Or if it's your computer, as I don't give a damn about your computer.

You too, try and get your head out of your ass.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#39118 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Julio Di Egidio:

> On Wednesday, 4 November 2020 15:17:37 UTC+1, Arno Welzel  wrote:
[...]
> <<Finally you get it! Yes JavaScript in a browser *is* single threaded!>>
> 
> Sure, I know you didn't mean to say what you said, and I have

I did. I said, in a browser JavaScript is single threaded, because we
are talking about using JavaScript in a browser.

I did not say "JavaScript is only single threaded in a browser".

[...]
>> Except when you need to get things done and CPU usage is less important
>> than the time needed to finish a job.
> 
> Or if it's your computer, as I don't give a damn about your computer.
> 
> You too, try and get your head out of your ass.

And you try to learn how to communicate with human beings. Seems you
think we are all computers.

> 
> *Plonk*

Again a completely useles "*Plonk*" as usual. You will never understand
the meaning of that word ever.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39079 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Jonas Thörnvall:

> Den lördag 31 oktober 2020 kl. 18:53:09 UTC+1 skrev Arno Welzel:
>> Jonas Thörnvall:
>>
>> [...]
>>> Have no idea what you talk about answer why javascript do not stop
>>> loop when condition get false "boolean", and why it do not
>>> ***manage*** to print out to form while in loop, much more
>>> interesting question.
>>
>> JavaScript *is* able to do this. However you try to run a endless loop
>> in a *browser* and wonder why the browser does not handle input as long
>> as the loop runs. You just don't understand what "event driven"
>> programming means.
> 
> You are funny the event we talk about is pushing the button and it work perfectly, what does not work is javascript handling it, apparently it is occupied within a loop. So maybe it is just a case of javascript being single threaded.

Finally you get it! Yes JavaScript in a browser *is* single threaded!
And therefore you MUST NOT build code which constantly runs something in
a loop if you want to have user interaction as well.

> That is basicly what i want to know, why aren't boolean while loops run in separate threads? 

Because there are no separate threads.

If you want to run stuff in the background separate from the UI you
either have to "emulate" this by using setTimeout() or setInterval() and
let a background task only run one step every 1/100 second or you use
web workers to run a script separate from the UI in background:

<https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API>

Workers are also supported by literally all current browsers:

<https://caniuse.com/webworkers>


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#39112 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Jonas Thörnvall wrote:

> When creating a while loop like this. 
> while(run==true){ 
> 
> } 

Unless that block of code itself updates the value of `run`, this will
continue to run indefinitely, assuming `run` starts as `true`.

As others have pointed out, browsers run their code in a single thread
unless you've invoked WebWorkers or some such.

And this means that there is no external mechanism to interrupt this
infinite loop.


 
> 1. How can i stop it, i tried a button that call function that set 
> run=false but that do not work. 

The trouble is that there is no way for your code to stop and allow
the browser to handle your button press.  You've essentially told the
browser to continue this process until it's complete and then move on
to the next event in the event loop.  But since this one doesn't stop
the event loop never reaches that event.

What people are trying to tell you with `setTimeout`, `setInterval`,
or `requestAnimationFrame` is that you can keep your code processing,
but to do so you need to divide it into manageable chunks that will
be posted one-by-one to the event loop.  Here I discuss only 
`setTimeout`.  The others are similar.

The model is simply one of running

    const processChunk = (...args) => {
	  // Do some work with the arguments.
      // Decide whether there is more to do. (This might include
	  //   testing whether `run` has been set.)
      if (moreToDo) {
	    setTimeout (processChunk, 0, ...newArgs)
      }
	}

So, for your coin-flipping streak-checker, we would want to check
some number of flips -- let's say a million -- then in a `setTimeout`
call, call back to the current function with whatever state is
necessary to keep going.  Or you could keep this in some higher scope,
even global.  My solution below uses a combination of an outer 
function scope and paramters.

Between these calls, the JS engine can check if there is anything else
in the event queue and run that before coming back to the next chunk.
And this is what keeps the process running smoothly.

There is an art, not a science, to knowing how big a chunk to create.
If you created a new task for every coin flip, the overhead of the
function calls and the `setTimeout` mechanism itself will overwhelm
the time spent in actual work.  But if your chunks involved a billion
coin flips, the browser will start to lag because these chunks simply
take too long to process.

In the code below, I set `batchSize` to one million (`1e6`), and find
that for my simple console-based ui, this is fast enough, but ten 
million (`1e7`) starts to feel laggy.  It might be different if you
have serious DOM manipulations involved, but I can't imagine anything
below `1e5` would be necessary.



> 2. How can i write out values to textarea while still in loop, it 
> does not seem "to have time" want to do it until loop breaks?

There are various ways to achieve this.  The naive one is to just
incorporate the IO / DOM manipulation inside your loop.  A more
structured version of this would be to register a listener to your
system and call back to that listener when there are changes of note.
Because that call is happening in the same task, it will process
alongside your calculations.  This is what I do below.


----------

Here is an example of such a counter to track streaks of heads or 
tails, using `Math.random` to generate a sequence of pseudo-random
numbers.

I have a working version posted online at 

    <https://codepen.io/CrossEye/pen/ZEORrXo?editors=0012>
	

First, the code for the counter:


```
const flipCounter = () => {
  let batchSize = 1e6, running = false, total = 0, listeners = []
  
  const flip = () => Math.random() < .5 ? 'heads' : 'tails'
  
  const run = ({type, streaks = [], current = 0}) => {
    for (let i = 0; i < batchSize; i++) {
      if (flip() === type) {
        current += 1
      } else {
        if (current > (streaks[streaks.length - 1] || 0)) {
          streaks .push (current)
          listeners.forEach(fn => fn({streaks, flips: total + i}))
        }
        current = 0
      }
    }
    total += batchSize
    if (running) {setTimeout(run, 0, {type, streaks, current})}   
  }
  
  return {
    start: (type) => {running = true; total = 0; run ({type})},
    totalFlips: () => total,
    listen: (listener) => {listeners .push (listener); return true},
    stop: () => {running = false}
  }
}
```

And now the code that uses it:


```
const counter = flipCounter();
counter .listen (
  ({flips, streaks}) => 
    console.log(`After ${flips} flips, streaks are [${streaks}]`)
)
setTimeout(() => {
  counter .stop (); 
  console .log (`Total flips: ${counter.totalFlips()}`)
}, 10000)
counter.start('heads') 
```



You'll note that I don't try to build your user interface.  That's
not really relevant to the questions raised.  Instead we create a
counter with `counter = flipCounter()`.  We register a listener
that does nothing more than `console.log` the data supplied to it.  In
your UI, you would presumably update the controls with the new data.

We use `setTimeout` to simulate someone pressing the "stop" button ten
seconds from now, also logging the number of total flips tried in that
time.

And finally, we start the counter running with the choice of "heads".

Presumably there are paralells you could create with your UI.


A typical session might look something like this:


```
After 1 flips, streaks are [1]
After 10 flips, streaks are [1,3]
After 51 flips, streaks are [1,3,4]
After 131 flips, streaks are [1,3,4,5]
After 274 flips, streaks are [1,3,4,5,6]
After 515 flips, streaks are [1,3,4,5,6,9]
After 1660 flips, streaks are [1,3,4,5,6,9,10]
After 3761 flips, streaks are [1,3,4,5,6,9,10,23]
After 3743891 flips, streaks are [1,3,4,5,6,9,10,23,24]
After 55330189 flips, streaks are [1,3,4,5,6,9,10,23,24,31]
Total flips: 330000000
```

----------

Finally, could we stop with the attitude?  People here are interested
in discussing Javascript and other ES implementations.  They may love
it or hate it, but they are here because somehow or another JS is
useful to them.

There are no issues discussing the downsides of the language.
Certainly there are plenty of them.  But your incessant whining about
how poorly designed it is, and how it simply doesn't compare to 
language X doesn't add anything.  You often mention Basic.  I don't
know if you are talking about old line-number basic from 40+ years ago
or Visual Basic or VB.NET, but I have used the first two, and I have
to say this problem would be no simpler in either of those, which were
also single-threaded.

But the detailed explanation I just gave might have come your way
earlier if you asked polite questions rather than railed against the
language and against those trying to help you with it.

And, you've been told often, learn to make proper USENET posts.  A
proper newsreader is a help, but if you're stuck with Google Groups,
put in the effor to format your answer carefully, trim your quotations
properly, and make it more enjoyable to interact with you.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#39113 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Den tisdag 3 november 2020 kl. 22:28:02 UTC+1 skrev sc...@sauyet.com:
> Jonas Thörnvall wrote:
> 
> > When creating a while loop like this. 
> > while(run==true){ 
> > 
> > } 
> 
> Unless that block of code itself updates the value of `run`, this will
> continue to run indefinitely, assuming `run` starts as `true`.
> 
> As others have pointed out, browsers run their code in a single thread
> unless you've invoked WebWorkers or some such.
> 
> And this means that there is no external mechanism to interrupt this
> infinite loop.
> 
> 
>  
> > 1. How can i stop it, i tried a button that call function that set 
> > run=false but that do not work. 
> 
> The trouble is that there is no way for your code to stop and allow
> the browser to handle your button press.  You've essentially told the
> browser to continue this process until it's complete and then move on
> to the next event in the event loop.  But since this one doesn't stop
> the event loop never reaches that event.
> 
> What people are trying to tell you with `setTimeout`, `setInterval`,
> or `requestAnimationFrame` is that you can keep your code processing,
> but to do so you need to divide it into manageable chunks that will
> be posted one-by-one to the event loop.  Here I discuss only 
> `setTimeout`.  The others are similar.
> 
> The model is simply one of running
> 
>     const processChunk = (...args) => {
> 	  // Do some work with the arguments.
>       // Decide whether there is more to do. (This might include
> 	  //   testing whether `run` has been set.)
>       if (moreToDo) {
> 	    setTimeout (processChunk, 0, ...newArgs)
>       }
> 	}
> 
> So, for your coin-flipping streak-checker, we would want to check
> some number of flips -- let's say a million -- then in a `setTimeout`
> call, call back to the current function with whatever state is
> necessary to keep going.  Or you could keep this in some higher scope,
> even global.  My solution below uses a combination of an outer 
> function scope and paramters.
> 
> Between these calls, the JS engine can check if there is anything else
> in the event queue and run that before coming back to the next chunk.
> And this is what keeps the process running smoothly.
> 
> There is an art, not a science, to knowing how big a chunk to create.
> If you created a new task for every coin flip, the overhead of the
> function calls and the `setTimeout` mechanism itself will overwhelm
> the time spent in actual work.  But if your chunks involved a billion
> coin flips, the browser will start to lag because these chunks simply
> take too long to process.
> 
> In the code below, I set `batchSize` to one million (`1e6`), and find
> that for my simple console-based ui, this is fast enough, but ten 
> million (`1e7`) starts to feel laggy.  It might be different if you
> have serious DOM manipulations involved, but I can't imagine anything
> below `1e5` would be necessary.
> 
> 
> 
> > 2. How can i write out values to textarea while still in loop, it 
> > does not seem "to have time" want to do it until loop breaks?
> 
> There are various ways to achieve this.  The naive one is to just
> incorporate the IO / DOM manipulation inside your loop.  A more
> structured version of this would be to register a listener to your
> system and call back to that listener when there are changes of note.
> Because that call is happening in the same task, it will process
> alongside your calculations.  This is what I do below.
> 
> 
> ----------
> 
> Here is an example of such a counter to track streaks of heads or 
> tails, using `Math.random` to generate a sequence of pseudo-random
> numbers.
> 
> I have a working version posted online at 
> 
>     <https://codepen.io/CrossEye/pen/ZEORrXo?editors=0012>
> 	
> 
> First, the code for the counter:
> 
> 
> ```
> const flipCounter = () => {
>   let batchSize = 1e6, running = false, total = 0, listeners = []
>   
>   const flip = () => Math.random() < .5 ? 'heads' : 'tails'
>   
>   const run = ({type, streaks = [], current = 0}) => {
>     for (let i = 0; i < batchSize; i++) {
>       if (flip() === type) {
>         current += 1
>       } else {
>         if (current > (streaks[streaks.length - 1] || 0)) {
>           streaks .push (current)
>           listeners.forEach(fn => fn({streaks, flips: total + i}))
>         }
>         current = 0
>       }
>     }
>     total += batchSize
>     if (running) {setTimeout(run, 0, {type, streaks, current})}   
>   }
>   
>   return {
>     start: (type) => {running = true; total = 0; run ({type})},
>     totalFlips: () => total,
>     listen: (listener) => {listeners .push (listener); return true},
>     stop: () => {running = false}
>   }
> }
> ```
> 
> And now the code that uses it:
> 
> 
> ```
> const counter = flipCounter();
> counter .listen (
>   ({flips, streaks}) => 
>     console.log(`After ${flips} flips, streaks are [${streaks}]`)
> )
> setTimeout(() => {
>   counter .stop (); 
>   console .log (`Total flips: ${counter.totalFlips()}`)
> }, 10000)
> counter.start('heads') 
> ```
> 
> 
> 
> You'll note that I don't try to build your user interface.  That's
> not really relevant to the questions raised.  Instead we create a
> counter with `counter = flipCounter()`.  We register a listener
> that does nothing more than `console.log` the data supplied to it.  In
> your UI, you would presumably update the controls with the new data.
> 
> We use `setTimeout` to simulate someone pressing the "stop" button ten
> seconds from now, also logging the number of total flips tried in that
> time.
> 
> And finally, we start the counter running with the choice of "heads".
> 
> Presumably there are paralells you could create with your UI.
> 
> 
> A typical session might look something like this:
> 
> 
> ```
> After 1 flips, streaks are [1]
> After 10 flips, streaks are [1,3]
> After 51 flips, streaks are [1,3,4]
> After 131 flips, streaks are [1,3,4,5]
> After 274 flips, streaks are [1,3,4,5,6]
> After 515 flips, streaks are [1,3,4,5,6,9]
> After 1660 flips, streaks are [1,3,4,5,6,9,10]
> After 3761 flips, streaks are [1,3,4,5,6,9,10,23]
> After 3743891 flips, streaks are [1,3,4,5,6,9,10,23,24]
> After 55330189 flips, streaks are [1,3,4,5,6,9,10,23,24,31]
> Total flips: 330000000
> ```
> 
> ----------
> 
> Finally, could we stop with the attitude?  People here are interested
> in discussing Javascript and other ES implementations.  They may love
> it or hate it, but they are here because somehow or another JS is
> useful to them.
> 
> There are no issues discussing the downsides of the language.
> Certainly there are plenty of them.  But your incessant whining about
> how poorly designed it is, and how it simply doesn't compare to 
> language X doesn't add anything.  You often mention Basic.  I don't
> know if you are talking about old line-number basic from 40+ years ago
> or Visual Basic or VB.NET, but I have used the first two, and I have
> to say this problem would be no simpler in either of those, which were
> also single-threaded.
> 
> But the detailed explanation I just gave might have come your way
> earlier if you asked polite questions rather than railed against the
> language and against those trying to help you with it.
> 
> And, you've been told often, learn to make proper USENET posts.  A
> proper newsreader is a help, but if you're stuck with Google Groups,
> put in the effor to format your answer carefully, trim your quotations
> properly, and make it more enjoyable to interact with you.
> 
>   -- Scott

I was mor interested in something that did continous updates, for example every second.It is something backward with javascript you really want the pooling going out from loop. Not have a rendition "setTimeout setInterval" that call a coin flipping function every xth function.

But you are correct you could chunk it up, but i did not see the point when the calls to coinflipping anywhere near realtime.

Instead the interface set the length of loop, and all other grahical UI is done after loop exit.

https://jonasth.github.io/random.html

[toc] | [prev] | [next] | [standalone]

#39114 — Re: boolean while loops "how to stop" and "make room for textout to textarea"

Jonas Thörnvall wrote:
> Scott Sauyet wrote:

>> [... Discussion of code archived at 
>>    <https://codepen.io/CrossEye/pen/ZEORrXo?editors=0012>
>> ...]

> I was mor interested in something that did continous updates, for 
> example every second.

That could very easily be done with this technique.


> It is something backward with javascript you really want the pooling 
> going out from loop.

I'm sure others have pointed out that your English is often fairly 
unclear.  I can make a guess at what you mean here, but it's only a
guess.  Obviously, as usual, you're critiquing JS.  And I think
your concern is one of what code is calling other code, that, for
example in my code I have a listener that is called from inside the
code that's looping.  Is that correct?

If so, once again, the criticism is misplaced.  That was just the 
way I chose to implement this.  We could just as easily have an
external function calling methods on this object using some sort of
timer.

Your command of JS seems fairly weak.  You would be far better served
in your learning if you asked questions simply and cleanly and didn't
dress them up on criticism.


> Not have a rendition "setTimeout setInterval" that call a coin 
> flipping function every xth function.

I have no idea what this means.


> But you are correct you could chunk it up, but i did not see the point
> when the calls to coinflipping anywhere near realtime.

Or this.


> Instead the interface set the length of loop, and all other grahical 
> UI is done after loop exit.
> 
> https://jonasth.github.io/random.html

It certainly doesn't have to be this way.  It would not be hard to do
some timer-based updates.

  -- Scott

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web