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

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

I don't get it

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

Contents

  I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-08 03:32 -0700
    Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-08 03:37 -0700
      Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-08 04:26 -0700
        Re: I don't get it JJ <jj4public@gmail.com> - 2021-04-08 19:39 +0700
          Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-08 05:53 -0700
            Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-08 13:55 -0700
              Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-09 00:46 -0700
                Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-09 10:03 +0100
                  Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-09 04:09 -0700
                  Re: I don't get it "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-09 11:07 -0700
                    Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-10 03:23 +0100
                      Re: I don't get it "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-10 22:02 -0700
                        Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-11 01:05 -0700
                          Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-11 01:07 -0700
                        Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:42 +0100
                  Re: I don't get it John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-09 20:01 +0100
                    Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-09 13:31 -0700
                    Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-10 03:37 +0100
                      Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-09 23:53 -0700
                      Re: I don't get it John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-10 12:05 +0100
                        Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-10 15:59 +0100
                      Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-10 15:47 +0100
                        Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-10 18:25 +0100
                          Re: I don't get it Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-04-10 17:29 +0000
                          Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-10 19:08 +0100
                            Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:41 +0100
                              Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-11 14:33 +0100
                                Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-12 02:39 -0700
                                  Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-12 11:21 +0100
                                    Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-12 10:19 -0700
                                      Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-12 21:20 +0100
                                      Re: I don't get it "sc...@sauyet.com" <scott@sauyet.com> - 2021-04-12 14:32 -0700
                                        Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-13 04:11 -0700
                                          Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-13 14:58 +0100
                                            Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-13 09:20 -0700
                                              Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-13 09:29 -0700
                                              Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-13 20:06 +0100
                                              Re: I don't get it "sc...@sauyet.com" <scott@sauyet.com> - 2021-04-13 15:09 -0700
                                                Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-14 01:15 -0700
                                                  Re: I don't get it "sc...@sauyet.com" <scott@sauyet.com> - 2021-04-14 05:22 -0700
                                                    Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-15 11:52 -0700
                                                      Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-15 11:57 -0700
                                                        Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-15 12:04 -0700
                                                      Re: I don't get it Scott Sauyet <scott.sauyet@gmail.com> - 2021-04-15 19:29 -0700
                                                        Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-20 14:12 -0700
                                                          Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-20 14:47 -0700
                                                            Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-20 23:35 -0700
                                                              Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-21 01:08 -0700
                                                                Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-21 01:24 -0700
                                                                  Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-21 01:29 -0700
                                            Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-13 09:32 -0700
                                            Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-13 21:59 +0100
                                              Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-14 01:32 +0100
                                                Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-14 09:08 +0100
                                                  Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-14 10:06 +0100
                                                    Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-14 10:59 +0100
                                                      Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-14 14:05 +0100
                                                        Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-14 16:32 +0100
                                                          Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-14 23:53 +0100
                                                            Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-15 13:56 +0100
                                Re: I don't get it The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 11:20 +0100
          Re: I don't get it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-08 15:21 +0100
            Re: I don't get it Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-09 16:50 +0200
    Re: I don't get it Man From a city with name Viljandi <he12457@hotmail.com> - 2021-04-08 10:44 -0700
    Re: I don't get it Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-10 00:01 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#39884

John G Harris <niam@jghnorth.org.uk.invalid> writes:
<cut>
> What would it do with the Malaysian whose complete full name is A ?
>
> And Readers Digest said that someone in the USA named his daughter 5/8
> Smith, just to be different.

And let's not forget little Bobby Tables: https://xkcd.com/327/

-- 
Ben.

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

#39883

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 09/04/2021 20:01, John G Harris wrote:
>> On Fri, 9 Apr 2021 10:03:13 +0100, The Natural Philosopher
>> <tnp@invalid.invalid> wrote:
>>
>>    <snip>
>>> After spending two days some years ago I discovered that IE and Firefox
>>> differed in their handling of comparisons of numerical and string data,
>>> and that something like
>>>
>>> if('1'== 1)
>>>
>>> was handled differently in each browser.
>>>
>>> As with all loosely typed languages, bugs in your code are trumped by
>>> bugs in the language itself.
>>
>> Was that before or after they claimed to conform to ECMA 262? If
>> after, one or both browsers had a bug, not the language. If before,
>> that's what you get with USPs.
>
> It was around 2007 give or take. IE6 and XP was current. I coded for
> firefox, it broke in IE6.
>
> I actually checked the language spec. As far as I cam remember the
> spec was explicit, that you converted to whatever the target of an
> assignement was in a mixed type operation, but in a conditional there
> was no assignment type...

So you looked in the wrong place.  I don't think that adds much useful
information.  ECMA 262, 3rd edition (2000) is very clear about the
conversions required by the == operator (section 11.9.1 and 11.9.3).
For the record, the string should be converted to a number (and the
algorithm for doing that is given in great detail too).

So it's not an issue with the specification.  Testing in IE6 running on
XP I find that the conversion is done correctly.  Did Mozilla really
have such a crude bug, and if so, did you really code for that despite
the specification being clear?

-- 
Ben.

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

#39885

On 10/04/2021 15:47, Ben Bacarisse wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
> 
>> On 09/04/2021 20:01, John G Harris wrote:
>>> On Fri, 9 Apr 2021 10:03:13 +0100, The Natural Philosopher
>>> <tnp@invalid.invalid> wrote:
>>>
>>>     <snip>
>>>> After spending two days some years ago I discovered that IE and Firefox
>>>> differed in their handling of comparisons of numerical and string data,
>>>> and that something like
>>>>
>>>> if('1'== 1)
>>>>
>>>> was handled differently in each browser.
>>>>
>>>> As with all loosely typed languages, bugs in your code are trumped by
>>>> bugs in the language itself.
>>>
>>> Was that before or after they claimed to conform to ECMA 262? If
>>> after, one or both browsers had a bug, not the language. If before,
>>> that's what you get with USPs.
>>
>> It was around 2007 give or take. IE6 and XP was current. I coded for
>> firefox, it broke in IE6.
>>
>> I actually checked the language spec. As far as I cam remember the
>> spec was explicit, that you converted to whatever the target of an
>> assignement was in a mixed type operation, but in a conditional there
>> was no assignment type...
> 
> So you looked in the wrong place.  I don't think that adds much useful
> information.  ECMA 262, 3rd edition (2000) is very clear about the
> conversions required by the == operator (section 11.9.1 and 11.9.3).
> For the record, the string should be converted to a number (and the
> algorithm for doing that is given in great detail too).
> 
> So it's not an issue with the specification.  Testing in IE6 running on
> XP I find that the conversion is done correctly.  Did Mozilla really
> have such a crude bug, and if so, did you really code for that despite
> the specification being clear?
> 
All I know is that IE6 and firefox gave different results and it was 
down to an implicit cast in a conditional statement. The code I have now 
- dated 2008, after fixing -  simply turns everything explicitly into a 
Number()....so I assume that firefox was doing that implicitly and IE6 
was not.

You can defend the language all you like - I was past caring. I had a 
job to do and IE6 and firefox produced completely different results on 
the same web page, because of casting. Forcing everything to a number 
whether it needed it or not fixed the issue.



-- 
Climate is what you expect but weather is what you get.
Mark Twain

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

#39886

On 2021-04-10, The Natural Philosopher <tnp@invalid.invalid> wrote:
> You can defend the language all you like - I was past caring. I had a 
> job to do and IE6 and firefox produced completely different results on 
> the same web page, because of casting.

Your villains in this piece are a browser created by a team in a large
company with an unlimited budget and acres of time, and a programming
language created by one guy in a week. It's remarkable really that the
browser is by *far* the greater villain...

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

#39888

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 10/04/2021 15:47, Ben Bacarisse wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 09/04/2021 20:01, John G Harris wrote:
>>>> On Fri, 9 Apr 2021 10:03:13 +0100, The Natural Philosopher
>>>> <tnp@invalid.invalid> wrote:
>>>>
>>>>     <snip>
>>>>> After spending two days some years ago I discovered that IE and Firefox
>>>>> differed in their handling of comparisons of numerical and string data,
>>>>> and that something like
>>>>>
>>>>> if('1'== 1)
>>>>>
>>>>> was handled differently in each browser.
>>>>>
>>>>> As with all loosely typed languages, bugs in your code are trumped by
>>>>> bugs in the language itself.
>>>>
>>>> Was that before or after they claimed to conform to ECMA 262? If
>>>> after, one or both browsers had a bug, not the language. If before,
>>>> that's what you get with USPs.
>>>
>>> It was around 2007 give or take. IE6 and XP was current. I coded for
>>> firefox, it broke in IE6.
>>>
>>> I actually checked the language spec. As far as I cam remember the
>>> spec was explicit, that you converted to whatever the target of an
>>> assignement was in a mixed type operation, but in a conditional there
>>> was no assignment type...
>>
>> So you looked in the wrong place.  I don't think that adds much useful
>> information.  ECMA 262, 3rd edition (2000) is very clear about the
>> conversions required by the == operator (section 11.9.1 and 11.9.3).
>> For the record, the string should be converted to a number (and the
>> algorithm for doing that is given in great detail too).
>>
>> So it's not an issue with the specification.  Testing in IE6 running on
>> XP I find that the conversion is done correctly.  Did Mozilla really
>> have such a crude bug, and if so, did you really code for that despite
>> the specification being clear?
>>
> All I know is that IE6 and firefox gave different results and it was
> down to an implicit cast in a conditional statement. The code I have
> now - dated 2008, after fixing -  simply turns everything explicitly
> into a Number()....so I assume that firefox was doing that implicitly
> and IE6 was not.

I've tested it on IE6.  Unless IE6 is a Heisenberg browser, it does the
conversion correctly. 

> You can defend the language all you like - I was past caring.

I'm not defending the language.

> I had a job to do and IE6 and firefox produced completely different
> results on the same web page, because of casting. Forcing everything
> to a number whether it needed it or not fixed the issue.

Maybe is was Mozilla that got it wrong, or maybe you are
mis-remembering?

-- 
Ben.

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

#39898

On 10/04/2021 19:08, Ben Bacarisse wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
> 
>> On 10/04/2021 15:47, Ben Bacarisse wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>
>>>> On 09/04/2021 20:01, John G Harris wrote:
>>>>> On Fri, 9 Apr 2021 10:03:13 +0100, The Natural Philosopher
>>>>> <tnp@invalid.invalid> wrote:
>>>>>
>>>>>      <snip>
>>>>>> After spending two days some years ago I discovered that IE and Firefox
>>>>>> differed in their handling of comparisons of numerical and string data,
>>>>>> and that something like
>>>>>>
>>>>>> if('1'== 1)
>>>>>>
>>>>>> was handled differently in each browser.
>>>>>>
>>>>>> As with all loosely typed languages, bugs in your code are trumped by
>>>>>> bugs in the language itself.
>>>>>
>>>>> Was that before or after they claimed to conform to ECMA 262? If
>>>>> after, one or both browsers had a bug, not the language. If before,
>>>>> that's what you get with USPs.
>>>>
>>>> It was around 2007 give or take. IE6 and XP was current. I coded for
>>>> firefox, it broke in IE6.
>>>>
>>>> I actually checked the language spec. As far as I cam remember the
>>>> spec was explicit, that you converted to whatever the target of an
>>>> assignement was in a mixed type operation, but in a conditional there
>>>> was no assignment type...
>>>
>>> So you looked in the wrong place.  I don't think that adds much useful
>>> information.  ECMA 262, 3rd edition (2000) is very clear about the
>>> conversions required by the == operator (section 11.9.1 and 11.9.3).
>>> For the record, the string should be converted to a number (and the
>>> algorithm for doing that is given in great detail too).
>>>
>>> So it's not an issue with the specification.  Testing in IE6 running on
>>> XP I find that the conversion is done correctly.  Did Mozilla really
>>> have such a crude bug, and if so, did you really code for that despite
>>> the specification being clear?
>>>
>> All I know is that IE6 and firefox gave different results and it was
>> down to an implicit cast in a conditional statement. The code I have
>> now - dated 2008, after fixing -  simply turns everything explicitly
>> into a Number()....so I assume that firefox was doing that implicitly
>> and IE6 was not.
> 
> I've tested it on IE6.  Unless IE6 is a Heisenberg browser, it does the
> conversion correctly.
> 
>> You can defend the language all you like - I was past caring.
> 
> I'm not defending the language.
> 
>> I had a job to do and IE6 and firefox produced completely different
>> results on the same web page, because of casting. Forcing everything
>> to a number whether it needed it or not fixed the issue.
> 
> Maybe is was Mozilla that got it wrong, or maybe you are
> mis-remembering?
> 
There was no right or wrong as I recall. Two browsers interpreted the 
spec differently because the correct interpretation was not clear.

I coded for Mozilla. It worked, Others tried IE6, it didn't work. I 
scattered explicit Number() casts throughout my code, it worked for 
everyone.

At some level mozilla was casting to a number, but IE6 wasn't.

I spent a little time trying to work out what SHOULD happen, but the 
spec didn't cover the exact case.

-- 
If I had all the money I've spent on drink...
..I'd spend it on drink.

Sir Henry (at Rawlinson's End)

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

#39900

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 10/04/2021 19:08, Ben Bacarisse wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 10/04/2021 15:47, Ben Bacarisse wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>
>>>>> On 09/04/2021 20:01, John G Harris wrote:
>>>>>> On Fri, 9 Apr 2021 10:03:13 +0100, The Natural Philosopher
>>>>>> <tnp@invalid.invalid> wrote:
>>>>>>
>>>>>>      <snip>
>>>>>>> After spending two days some years ago I discovered that IE and Firefox
>>>>>>> differed in their handling of comparisons of numerical and string data,
>>>>>>> and that something like
>>>>>>>
>>>>>>> if('1'== 1)
>>>>>>>
>>>>>>> was handled differently in each browser.
>>>>>>>
>>>>>>> As with all loosely typed languages, bugs in your code are trumped by
>>>>>>> bugs in the language itself.
>>>>>>
>>>>>> Was that before or after they claimed to conform to ECMA 262? If
>>>>>> after, one or both browsers had a bug, not the language. If before,
>>>>>> that's what you get with USPs.
>>>>>
>>>>> It was around 2007 give or take. IE6 and XP was current. I coded for
>>>>> firefox, it broke in IE6.
>>>>>
>>>>> I actually checked the language spec. As far as I cam remember the
>>>>> spec was explicit, that you converted to whatever the target of an
>>>>> assignement was in a mixed type operation, but in a conditional there
>>>>> was no assignment type...
>>>>
>>>> So you looked in the wrong place.  I don't think that adds much useful
>>>> information.  ECMA 262, 3rd edition (2000) is very clear about the
>>>> conversions required by the == operator (section 11.9.1 and 11.9.3).
>>>> For the record, the string should be converted to a number (and the
>>>> algorithm for doing that is given in great detail too).
>>>>
>>>> So it's not an issue with the specification.  Testing in IE6 running on
>>>> XP I find that the conversion is done correctly.  Did Mozilla really
>>>> have such a crude bug, and if so, did you really code for that despite
>>>> the specification being clear?
>>>>
>>> All I know is that IE6 and firefox gave different results and it was
>>> down to an implicit cast in a conditional statement. The code I have
>>> now - dated 2008, after fixing -  simply turns everything explicitly
>>> into a Number()....so I assume that firefox was doing that implicitly
>>> and IE6 was not.
>>
>> I've tested it on IE6.  Unless IE6 is a Heisenberg browser, it does the
>> conversion correctly.
>>
>>> You can defend the language all you like - I was past caring.
>>
>> I'm not defending the language.
>>
>>> I had a job to do and IE6 and firefox produced completely different
>>> results on the same web page, because of casting. Forcing everything
>>> to a number whether it needed it or not fixed the issue.
>>
>> Maybe is was Mozilla that got it wrong, or maybe you are
>> mis-remembering?
>>
> There was no right or wrong as I recall. Two browsers interpreted the
> spec differently because the correct interpretation was not clear.

I don't think you have read the specification.  I can't see any room for
misinterpretation in this case.  You made it clear that you had
originally read the wrong part of the specification so you can hardly
claim to be a reliable source for what the specification says.

> I coded for Mozilla. It worked, Others tried IE6, it didn't work. I
> scattered explicit Number() casts throughout my code, it worked for
> everyone.

Then you mislead people with your example, because IE6 does not get that
conversion wrong.  I can't be sure that Mozilla did not (but I would be
very surprised) but IE6 is readily available for testing.

> At some level mozilla was casting to a number,

In the case you cited, that is correct (and very clearly required by the
specification).

> but IE6 wasn't.

I tested it on IE6 and it correctly converted the string to a number in
the comparison.  I think you are spreading confusion.

> I spent a little time trying to work out what SHOULD happen, but the
> spec didn't cover the exact case.

That is not true.  I gave you the section numbers that explain the
required conversions in an equality comparison (the case you cited).

-- 
Ben.

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

#39905

söndag 11 april 2021 kl. 15:34:03 UTC+2 skrev Ben Bacarisse:
> The Natural Philosopher <t...@invalid.invalid> writes: 
> 
> > On 10/04/2021 19:08, Ben Bacarisse wrote: 
> >> The Natural Philosopher <t...@invalid.invalid> writes: 
> >> 
> >>> On 10/04/2021 15:47, Ben Bacarisse wrote: 
> >>>> The Natural Philosopher <t...@invalid.invalid> writes: 
> >>>> 
> >>>>> On 09/04/2021 20:01, John G Harris wrote: 
> >>>>>> On Fri, 9 Apr 2021 10:03:13 +0100, The Natural Philosopher 
> >>>>>> <t...@invalid.invalid> wrote: 
> >>>>>> 
> >>>>>> <snip> 
> >>>>>>> After spending two days some years ago I discovered that IE and Firefox 
> >>>>>>> differed in their handling of comparisons of numerical and string data, 
> >>>>>>> and that something like 
> >>>>>>> 
> >>>>>>> if('1'== 1) 
> >>>>>>> 
> >>>>>>> was handled differently in each browser. 
> >>>>>>> 
> >>>>>>> As with all loosely typed languages, bugs in your code are trumped by 
> >>>>>>> bugs in the language itself. 
> >>>>>> 
> >>>>>> Was that before or after they claimed to conform to ECMA 262? If 
> >>>>>> after, one or both browsers had a bug, not the language. If before, 
> >>>>>> that's what you get with USPs. 
> >>>>> 
> >>>>> It was around 2007 give or take. IE6 and XP was current. I coded for 
> >>>>> firefox, it broke in IE6. 
> >>>>> 
> >>>>> I actually checked the language spec. As far as I cam remember the 
> >>>>> spec was explicit, that you converted to whatever the target of an 
> >>>>> assignement was in a mixed type operation, but in a conditional there 
> >>>>> was no assignment type... 
> >>>> 
> >>>> So you looked in the wrong place. I don't think that adds much useful 
> >>>> information. ECMA 262, 3rd edition (2000) is very clear about the 
> >>>> conversions required by the == operator (section 11.9.1 and 11.9.3). 
> >>>> For the record, the string should be converted to a number (and the 
> >>>> algorithm for doing that is given in great detail too). 
> >>>> 
> >>>> So it's not an issue with the specification. Testing in IE6 running on 
> >>>> XP I find that the conversion is done correctly. Did Mozilla really 
> >>>> have such a crude bug, and if so, did you really code for that despite 
> >>>> the specification being clear? 
> >>>> 
> >>> All I know is that IE6 and firefox gave different results and it was 
> >>> down to an implicit cast in a conditional statement. The code I have 
> >>> now - dated 2008, after fixing - simply turns everything explicitly 
> >>> into a Number()....so I assume that firefox was doing that implicitly 
> >>> and IE6 was not. 
> >> 
> >> I've tested it on IE6. Unless IE6 is a Heisenberg browser, it does the 
> >> conversion correctly. 
> >> 
> >>> You can defend the language all you like - I was past caring. 
> >> 
> >> I'm not defending the language. 
> >> 
> >>> I had a job to do and IE6 and firefox produced completely different 
> >>> results on the same web page, because of casting. Forcing everything 
> >>> to a number whether it needed it or not fixed the issue. 
> >> 
> >> Maybe is was Mozilla that got it wrong, or maybe you are 
> >> mis-remembering? 
> >> 
> > There was no right or wrong as I recall. Two browsers interpreted the 
> > spec differently because the correct interpretation was not clear.
> I don't think you have read the specification. I can't see any room for 
> misinterpretation in this case. You made it clear that you had 
> originally read the wrong part of the specification so you can hardly 
> claim to be a reliable source for what the specification says.
> > I coded for Mozilla. It worked, Others tried IE6, it didn't work. I 
> > scattered explicit Number() casts throughout my code, it worked for 
> > everyone.
> Then you mislead people with your example, because IE6 does not get that 
> conversion wrong. I can't be sure that Mozilla did not (but I would be 
> very surprised) but IE6 is readily available for testing.
> > At some level mozilla was casting to a number,
> In the case you cited, that is correct (and very clearly required by the 
> specification). 
> 
> > but IE6 wasn't. 
> 
> I tested it on IE6 and it correctly converted the string to a number in 
> the comparison. I think you are spreading confusion.
> > I spent a little time trying to work out what SHOULD happen, but the 
> > spec didn't cover the exact case.
> That is not true. I gave you the section numbers that explain the 
> required conversions in an equality comparison (the case you cited). 
> 
> -- 
> Ben.
I still do not get it, so could someone comment on what goes wrong with my approach "AND WHY LATENCY BUILDS UP" although i try to correct it before each note played?
Just give me a qualified guess.

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

#39907

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:

> I still do not get it, so could someone comment on what goes wrong
> with my approach "AND WHY LATENCY BUILDS UP" although i try to correct
> it before each note played?  Just give me a qualified guess.

Your code is unmanagable.  Almost any part of it can alter the behaviour
of any other part.  You might be sure what parts do what (though your
repeated requests for help suggest you probably no longer know what the
code is doing) but other people will find it almost impossible.

Your best bet is to re-write it step by step making sure that functions
are genuinely self-contained actions.  Not only will the result be
easier to modify, you will probably find the problem on your own.

-- 
Ben.

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

#39910

måndag 12 april 2021 kl. 12:21:45 UTC+2 skrev Ben Bacarisse:
> Jonas Thörnvall <jonas.t...@gmail.com> writes: 
> 
> > I still do not get it, so could someone comment on what goes wrong 
> > with my approach "AND WHY LATENCY BUILDS UP" although i try to correct 
> > it before each note played? Just give me a qualified guess.
> Your code is unmanagable. Almost any part of it can alter the behaviour 
> of any other part. You might be sure what parts do what (though your 
> repeated requests for help suggest you probably no longer know what the 
> code is doing) but other people will find it almost impossible. 
> 
> Your best bet is to re-write it step by step making sure that functions 
> are genuinely self-contained actions. Not only will the result be 
> easier to modify, you will probably find the problem on your own. 
> 
> -- 
> Ben.
You are dreaming Ben it is a single function with ten lines of code and just two global arrays.

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

#39911

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:

> måndag 12 april 2021 kl. 12:21:45 UTC+2 skrev Ben Bacarisse:
>> Jonas Thörnvall <jonas.t...@gmail.com> writes: 
>> 
>> > I still do not get it, so could someone comment on what goes wrong 
>> > with my approach "AND WHY LATENCY BUILDS UP" although i try to correct 
>> > it before each note played? Just give me a qualified guess.
>> Your code is unmanagable. Almost any part of it can alter the behaviour 
>> of any other part. You might be sure what parts do what (though your 
>> repeated requests for help suggest you probably no longer know what the 
>> code is doing) but other people will find it almost impossible. 
>> 
>> Your best bet is to re-write it step by step making sure that functions 
>> are genuinely self-contained actions. Not only will the result be 
>> easier to modify, you will probably find the problem on your own. 

> You are dreaming Ben it is a single function with ten lines of code
> and just two global arrays.

The only code I've see here (it's in a direct ancestor post and is the
code I was referring to) is at least twice that long and littered with
references to non-local variables and arrays.  In fact, there is not a
single local reference in the twenty or more lines.  You many know which
of these are not used elsewhere, but I don't.  That's simply not the
sort of code I am going to spend time on anymore.  I did that for pay in
the late 1970s.  Never again.  We now know how to write proper code.

You appear to keep hitting behaviour you don't understand in code you've
written.  That is the number one symptom of unmaintainable spaghetti
code.  My advice was not frivolous or intended to palm you off.  There
very best thing you can do is to re-write it all taking care to use
proper, modern, programming practice.  By doing that, you will almost
certainly find and fix all the problems by yourself.

-- 
Ben.

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

#39912

Jonas Thörnvall wrote:
> Ben Bacarisse wrote: 

>> Your code is unmanagable. Almost any part of it can alter the behaviour 
>> of any other part. You might be sure what parts do what (though your 
>> repeated requests for help suggest you probably no longer know what the 
>> code is doing) but other people will find it almost impossible. 
>> 
>> Your best bet is to re-write it step by step making sure that functions 
>> are genuinely self-contained actions. Not only will the result be 
>> easier to modify, you will probably find the problem on your own. 

> You are dreaming Ben it is a single function with ten lines of code
> and just two global arrays.

The first three lines of this single "function" are 

|  function STARTPLAY(){
|    if (keepGoing) {
|      stopRec=setTimeout(STARTPLAY,copyEv[playPos]);

We have four free variables used here: `keepGoing`, `stopRec`, `copyEv`,
and `playPos`.  There are at least ten more in the remainder of the
snippet you passed.  

This is horrible.

Ben was, if anything, too kind.

  -- Scott

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

#39915

måndag 12 april 2021 kl. 23:32:18 UTC+2 skrev sc...@sauyet.com:
> Jonas Thörnvall wrote:
> > Ben Bacarisse wrote: 
> 
> >> Your code is unmanagable. Almost any part of it can alter the behaviour 
> >> of any other part. You might be sure what parts do what (though your 
> >> repeated requests for help suggest you probably no longer know what the 
> >> code is doing) but other people will find it almost impossible. 
> >> 
> >> Your best bet is to re-write it step by step making sure that functions 
> >> are genuinely self-contained actions. Not only will the result be 
> >> easier to modify, you will probably find the problem on your own.
> > You are dreaming Ben it is a single function with ten lines of code 
> > and just two global arrays.
> The first three lines of this single "function" are
> | function STARTPLAY(){ 
> | if (keepGoing) { 
> | stopRec=setTimeout(STARTPLAY,copyEv[playPos]);
> We have four free variables used here: `keepGoing`, `stopRec`, `copyEv`, 
> and `playPos`. There are at least ten more in the remainder of the 
> snippet you passed. 
> 
> This is horrible. 
> 
> Ben was, if anything, too kind. 
> 
> -- Scott
Well those can't possibly effect anything going on in recursion of function, not even the understaning of it.
keepGoing is obviously refer to some boolean mouseclick event.
the same goes for stopRec. 
Playposition is just the element to play.
The only thing to understand is that copyEv is an array of timings between call of function.
The other array noteMessage is just holding the note.
outportarr[outportindex].send(noteMessage[playPos]);

function STARTPLAY(){
if (keepGoing) {
setTimeout(STARTPLAY,copyEv[playPos]);
REALTIME=performance.now()-browserLoadTIME;
LATENCY=REALTIME-oldPassedTime;
oldPassedTime=schedTime;
schedTime=copyEv[playPos]+schedTime;
copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY);
outportarr[outportindex].send(noteMessage[playPos]);
playPos++;
} 
}
https://jonasth.github.io/
What is so hard to understand about function nothing, the hard thing is to understand why it does not work.


 

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

#39918

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:

> måndag 12 april 2021 kl. 23:32:18 UTC+2 skrev sc...@sauyet.com:
>> Jonas Thörnvall wrote:
>> > Ben Bacarisse wrote: 
>> 
>> >> Your code is unmanagable. Almost any part of it can alter the behaviour 
>> >> of any other part. You might be sure what parts do what (though your 
>> >> repeated requests for help suggest you probably no longer know what the 
>> >> code is doing) but other people will find it almost impossible. 
>> >> 
>> >> Your best bet is to re-write it step by step making sure that functions 
>> >> are genuinely self-contained actions. Not only will the result be 
>> >> easier to modify, you will probably find the problem on your own.
>> > You are dreaming Ben it is a single function with ten lines of code 
>> > and just two global arrays.
>> The first three lines of this single "function" are
>> | function STARTPLAY(){ 
>> | if (keepGoing) { 
>> | stopRec=setTimeout(STARTPLAY,copyEv[playPos]);
>> We have four free variables used here: `keepGoing`, `stopRec`, `copyEv`, 
>> and `playPos`. There are at least ten more in the remainder of the 
>> snippet you passed. 
>> 
>> This is horrible. 
>> 
>> Ben was, if anything, too kind. 
>> 
> Well those can't possibly effect anything going on in recursion of
> function, not even the understaning of it.

Even you can't understand it.

You are arguing with people who have, I suspect, many decades more
experience than you do in debugging horrid code.  The advice to write it
properly is not given flippantly.  It is by far the best course of
action.

> function STARTPLAY(){
> if (keepGoing) {
> setTimeout(STARTPLAY,copyEv[playPos]);
> REALTIME=performance.now()-browserLoadTIME;
> LATENCY=REALTIME-oldPassedTime;
> oldPassedTime=schedTime;
> schedTime=copyEv[playPos]+schedTime;
> copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY);
> outportarr[outportindex].send(noteMessage[playPos]);
> playPos++;
> } 
> }
> https://jonasth.github.io/

> What is so hard to understand about function nothing, the hard thing
> is to understand why it does not work.

If it's easy to understand, why don't you know what it's doing?

You need to ditch this distinction between understanding it and
understanding why it does not work because they are the same thing.
This is about the first step every programming student has to take.  You
must stop thinking you know what you wrote.  The function is doing
exactly what you wrote.  If that's not what you want or need, then you
need to understand it better.  Other people may be able to help, but I,
for one, am not going to try unless you put some effort into writing it
properly.

You are, I think, doing this for fun, yes?  If it remains fun to be
puzzling out what's going on, then you really don't need any help.  Just
keep going as you are.  But if the fun comes from getting things to
work, then learning how to program will be a huge benefit.  There is,
usually, much more fun to be had from productive coding than poking
about in a mess you don't quite follow.

-- 
Ben.

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

#39920

tisdag 13 april 2021 kl. 15:58:19 UTC+2 skrev Ben Bacarisse:
> Jonas Thörnvall <jonas.t...@gmail.com> writes: 
> 
> > måndag 12 april 2021 kl. 23:32:18 UTC+2 skrev sc...@sauyet.com: 
> >> Jonas Thörnvall wrote: 
> >> > Ben Bacarisse wrote: 
> >> 
> >> >> Your code is unmanagable. Almost any part of it can alter the behaviour 
> >> >> of any other part. You might be sure what parts do what (though your 
> >> >> repeated requests for help suggest you probably no longer know what the 
> >> >> code is doing) but other people will find it almost impossible. 
> >> >> 
> >> >> Your best bet is to re-write it step by step making sure that functions 
> >> >> are genuinely self-contained actions. Not only will the result be 
> >> >> easier to modify, you will probably find the problem on your own. 
> >> > You are dreaming Ben it is a single function with ten lines of code 
> >> > and just two global arrays. 
> >> The first three lines of this single "function" are 
> >> | function STARTPLAY(){ 
> >> | if (keepGoing) { 
> >> | stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> >> We have four free variables used here: `keepGoing`, `stopRec`, `copyEv`, 
> >> and `playPos`. There are at least ten more in the remainder of the 
> >> snippet you passed. 
> >> 
> >> This is horrible. 
> >> 
> >> Ben was, if anything, too kind. 
> >>
> > Well those can't possibly effect anything going on in recursion of 
> > function, not even the understaning of it.
> Even you can't understand it. 
> 
> You are arguing with people who have, I suspect, many decades more 
> experience than you do in debugging horrid code. The advice to write it 
> properly is not given flippantly. It is by far the best course of 
> action.
> > function STARTPLAY(){ 
> > if (keepGoing) { 
> > setTimeout(STARTPLAY,copyEv[playPos]); 
> > REALTIME=performance.now()-browserLoadTIME; 
> > LATENCY=REALTIME-oldPassedTime; 
> > oldPassedTime=schedTime; 
> > schedTime=copyEv[playPos]+schedTime; 
> > copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY); 
> > outportarr[outportindex].send(noteMessage[playPos]); 
> > playPos++; 
> > } 
> > } 
> > https://jonasth.github.io/ 
> 
> > What is so hard to understand about function nothing, the hard thing 
> > is to understand why it does not work.
> If it's easy to understand, why don't you know what it's doing? 
> 
> You need to ditch this distinction between understanding it and 
> understanding why it does not work because they are the same thing. 
> This is about the first step every programming student has to take. You 
> must stop thinking you know what you wrote. The function is doing 
> exactly what you wrote. If that's not what you want or need, then you 
> need to understand it better. Other people may be able to help, but I, 
> for one, am not going to try unless you put some effort into writing it 
> properly. 
> 
> You are, I think, doing this for fun, yes? If it remains fun to be 
> puzzling out what's going on, then you really don't need any help. Just 
> keep going as you are. But if the fun comes from getting things to 
> work, then learning how to program will be a huge benefit. There is, 
> usually, much more fun to be had from productive coding than poking 
> about in a mess you don't quite follow. 
> 
> -- 
> Ben.
I understand the code, not how the recursion effect it...
You see one cannot look into a blackbox, you can learn how it behave and that is why i ask you people, what is going on?
Because i am clueless about what the recursion do to it. I probably could and should do an iterative solution, but i want to know what is going on.

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

#39921

tisdag 13 april 2021 kl. 18:20:39 UTC+2 skrev Jonas Thörnvall:
> tisdag 13 april 2021 kl. 15:58:19 UTC+2 skrev Ben Bacarisse: 
> > Jonas Thörnvall <jonas.t...@gmail.com> writes: 
> > 
> > > måndag 12 april 2021 kl. 23:32:18 UTC+2 skrev sc...@sauyet.com: 
> > >> Jonas Thörnvall wrote: 
> > >> > Ben Bacarisse wrote: 
> > >> 
> > >> >> Your code is unmanagable. Almost any part of it can alter the behaviour 
> > >> >> of any other part. You might be sure what parts do what (though your 
> > >> >> repeated requests for help suggest you probably no longer know what the 
> > >> >> code is doing) but other people will find it almost impossible. 
> > >> >> 
> > >> >> Your best bet is to re-write it step by step making sure that functions 
> > >> >> are genuinely self-contained actions. Not only will the result be 
> > >> >> easier to modify, you will probably find the problem on your own. 
> > >> > You are dreaming Ben it is a single function with ten lines of code 
> > >> > and just two global arrays. 
> > >> The first three lines of this single "function" are 
> > >> | function STARTPLAY(){ 
> > >> | if (keepGoing) { 
> > >> | stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> > >> We have four free variables used here: `keepGoing`, `stopRec`, `copyEv`, 
> > >> and `playPos`. There are at least ten more in the remainder of the 
> > >> snippet you passed. 
> > >> 
> > >> This is horrible. 
> > >> 
> > >> Ben was, if anything, too kind. 
> > >> 
> > > Well those can't possibly effect anything going on in recursion of 
> > > function, not even the understaning of it. 
> > Even you can't understand it. 
> > 
> > You are arguing with people who have, I suspect, many decades more 
> > experience than you do in debugging horrid code. The advice to write it 
> > properly is not given flippantly. It is by far the best course of 
> > action. 
> > > function STARTPLAY(){ 
> > > if (keepGoing) { 
> > > setTimeout(STARTPLAY,copyEv[playPos]); 
> > > REALTIME=performance.now()-browserLoadTIME; 
> > > LATENCY=REALTIME-oldPassedTime; 
> > > oldPassedTime=schedTime; 
> > > schedTime=copyEv[playPos]+schedTime; 
> > > copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY); 
> > > outportarr[outportindex].send(noteMessage[playPos]); 
> > > playPos++; 
> > > } 
> > > } 
> > > https://jonasth.github.io/ 
> > 
> > > What is so hard to understand about function nothing, the hard thing 
> > > is to understand why it does not work. 
> > If it's easy to understand, why don't you know what it's doing? 
> > 
> > You need to ditch this distinction between understanding it and 
> > understanding why it does not work because they are the same thing. 
> > This is about the first step every programming student has to take. You 
> > must stop thinking you know what you wrote. The function is doing 
> > exactly what you wrote. If that's not what you want or need, then you 
> > need to understand it better. Other people may be able to help, but I, 
> > for one, am not going to try unless you put some effort into writing it 
> > properly. 
> > 
> > You are, I think, doing this for fun, yes? If it remains fun to be 
> > puzzling out what's going on, then you really don't need any help. Just 
> > keep going as you are. But if the fun comes from getting things to 
> > work, then learning how to program will be a huge benefit. There is, 
> > usually, much more fun to be had from productive coding than poking 
> > about in a mess you don't quite follow. 
> > 
> > -- 
> > Ben.
> I understand the code, not how the recursion effect it... 
> You see one cannot look into a blackbox, you can learn how it behave and that is why i ask you people, what is going on? 
> Because i am clueless about what the recursion do to it. I probably could and should do an iterative solution, but i want to know what is going on.
I have no problem to follow my code, it is simple beyond metacode. What i do not understand is how the recurisve function affect setTimeout or vice versa.
Both those are blackboxes, a hidden layer to the programmer, but i suspect that some of you are knowledgeable about the innerwork "blackbox" of javascript, and can tell why my approach fail.
And it is not because of global variables, i can tell you that....

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

#39923

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:

> tisdag 13 april 2021 kl. 15:58:19 UTC+2 skrev Ben Bacarisse:
>> Jonas Thörnvall <jonas.t...@gmail.com> writes: 
>> 
>> > måndag 12 april 2021 kl. 23:32:18 UTC+2 skrev sc...@sauyet.com: 
>> >> Jonas Thörnvall wrote: 
>> >> > Ben Bacarisse wrote: 
>> >> 
>> >> >> Your code is unmanagable. Almost any part of it can alter the behaviour 
>> >> >> of any other part. You might be sure what parts do what (though your 
>> >> >> repeated requests for help suggest you probably no longer know what the 
>> >> >> code is doing) but other people will find it almost impossible. 
>> >> >> 
>> >> >> Your best bet is to re-write it step by step making sure that functions 
>> >> >> are genuinely self-contained actions. Not only will the result be 
>> >> >> easier to modify, you will probably find the problem on your own. 
>> >> > You are dreaming Ben it is a single function with ten lines of code 
>> >> > and just two global arrays. 
>> >> The first three lines of this single "function" are 
>> >> | function STARTPLAY(){ 
>> >> | if (keepGoing) { 
>> >> | stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
>> >> We have four free variables used here: `keepGoing`, `stopRec`, `copyEv`, 
>> >> and `playPos`. There are at least ten more in the remainder of the 
>> >> snippet you passed. 
>> >> 
>> >> This is horrible. 
>> >> 
>> >> Ben was, if anything, too kind. 
>> >>
>> > Well those can't possibly effect anything going on in recursion of 
>> > function, not even the understaning of it.
>> Even you can't understand it. 
>> 
>> You are arguing with people who have, I suspect, many decades more 
>> experience than you do in debugging horrid code. The advice to write it 
>> properly is not given flippantly. It is by far the best course of 
>> action.
>> > function STARTPLAY(){ 
>> > if (keepGoing) { 
>> > setTimeout(STARTPLAY,copyEv[playPos]); 
>> > REALTIME=performance.now()-browserLoadTIME; 
>> > LATENCY=REALTIME-oldPassedTime; 
>> > oldPassedTime=schedTime; 
>> > schedTime=copyEv[playPos]+schedTime; 
>> > copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY); 
>> > outportarr[outportindex].send(noteMessage[playPos]); 
>> > playPos++; 
>> > } 
>> > } 
>> > https://jonasth.github.io/ 
>> 
>> > What is so hard to understand about function nothing, the hard thing 
>> > is to understand why it does not work.
>> If it's easy to understand, why don't you know what it's doing? 
>> 
>> You need to ditch this distinction between understanding it and 
>> understanding why it does not work because they are the same thing. 
>> This is about the first step every programming student has to take. You 
>> must stop thinking you know what you wrote. The function is doing 
>> exactly what you wrote. If that's not what you want or need, then you 
>> need to understand it better. Other people may be able to help, but I, 
>> for one, am not going to try unless you put some effort into writing it 
>> properly. 
>> 
>> You are, I think, doing this for fun, yes? If it remains fun to be 
>> puzzling out what's going on, then you really don't need any help. Just 
>> keep going as you are. But if the fun comes from getting things to 
>> work, then learning how to program will be a huge benefit. There is, 
>> usually, much more fun to be had from productive coding than poking 
>> about in a mess you don't quite follow. 
>> 
> I understand the code, not how the recursion effect it...

Recursion and non-local variables don't mix well.  You know what my
advice would be.

> You see one cannot look into a blackbox, you can learn how it behave
> and that is why i ask you people, what is going on?  Because i am
> clueless about what the recursion do to it. I probably could and
> should do an iterative solution, but i want to know what is going on.

I wish you well.

-- 
Ben.

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

#39927

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote: 

> I understand the code, not how the recursion effect it... 

Recursion is actually a quite simple, but as Ben said,

| Recursion and non-local variables don't mix well.

You are simultaneously claiming these facts:

  - My code is so simple anyone can understand it

  - My code is broken in a way I don't understand
  
At that point, before seeking help, you need to figure out which
of those statements is true.

> You see one cannot look into a blackbox, you can learn how it behave 
> and that is why i ask you people, what is going on? 

You're asking a lot from volunteers.  You say your code is simple, but
it doesn't appear that way from the outside.  I didn't dig into it 
because there seems to be nothing of interest, and it's not simple 
enough to understand at a glance.


> Because i am clueless about what the recursion do to it. I probably 
> could and should do an iterative solution, but i want to know what 
> is going on.

From my perspective as a mostly functional-programming coder, *any*
code that accesses or mutates data outside its local scope is suspect.
Recursive code that does that is downright evil.

I'm sure it's been recommended to you before, but it would really 
help here if you read this and took its lessons to heart:

    <http://www.catb.org/~esr/faqs/smart-questions.html>
	
And if you could create a minimal complete example, it would make
a huge difference.  Does the problem still occur if you remove the
line `ctm.font = "26px Arial";`?  What about other similar lines?
You can either continue removing lines until your example is trivial, 
or you can rebuild from scratch only those parts you suspect might 
be at fault.  If doing this exercise does not help you find the 
problem on your own, then it should give you something others
can analyze without digging through your cruft.

  -- Scott

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

#39931

onsdag 14 april 2021 kl. 00:09:41 UTC+2 skrev sc...@sauyet.com:
> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> 
> > I understand the code, not how the recursion effect it...
> Recursion is actually a quite simple, but as Ben said,
> | Recursion and non-local variables don't mix well.
> You are simultaneously claiming these facts: 
> 
> - My code is so simple anyone can understand it 
> 
> - My code is broken in a way I don't understand 
> 
> At that point, before seeking help, you need to figure out which 
> of those statements is true.
> > You see one cannot look into a blackbox, you can learn how it behave 
> > and that is why i ask you people, what is going on?
> You're asking a lot from volunteers. You say your code is simple, but 
> it doesn't appear that way from the outside. I didn't dig into it 
> because there seems to be nothing of interest, and it's not simple 
> enough to understand at a glance.
> > Because i am clueless about what the recursion do to it. I probably 
> > could and should do an iterative solution, but i want to know what 
> > is going on.
> From my perspective as a mostly functional-programming coder, *any* 
> code that accesses or mutates data outside its local scope is suspect. 
> Recursive code that does that is downright evil. 
> 
> I'm sure it's been recommended to you before, but it would really 
> help here if you read this and took its lessons to heart: 
> 
> <http://www.catb.org/~esr/faqs/smart-questions.html> 
> 
> And if you could create a minimal complete example, it would make 
> a huge difference. Does the problem still occur if you remove the 
> line `ctm.font = "26px Arial";`? What about other similar lines? 
> You can either continue removing lines until your example is trivial, 
> or you can rebuild from scratch only those parts you suspect might 
> be at fault. If doing this exercise does not help you find the 
> problem on your own, then it should give you something others 
> can analyze without digging through your cruft. 
> 
> -- Scott
No there is a third alternative Scott the blackbox is broken.
And i did post a more comprehensive example.
function STARTPLAY(){
if (keepGoing) {
setTimeout(STARTPLAY,copyEv[playPos]);
REALTIME=performance.now()-browserLoadTIME;
LATENCY=REALTIME-oldPassedTime;
oldPassedTime=schedTime;
schedTime=copyEv[playPos]+schedTime;
copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY);
outportarr[outportindex].send(noteMessage[playPos]);
playPos++;
}
}

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

#39934

Jonas Thörnvall <jonas.thornvall@gmail.com> wrote: 
> Scott Sauyet <scott@sauyet.com> wrote:
>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
 
>>> I understand the code, not how the recursion effect it... 

>> You are simultaneously claiming these facts: 
>> 
>> - My code is so simple anyone can understand it 
>> - My code is broken in a way I don't understand 
>> 
>> At that point, before seeking help, you need to figure out which 
>> of those statements is true. 

> No there is a third alternative Scott the blackbox is broken. 

If you really think there's a bug in the JS implementation you use, then 
by all means point to the implementation and the section of the 
specification it fails.  Post a bug in their tracker.  And feel free to 
tell us about it.  Remember what they're going to want: a small self-
contained example.

But 99+% of the time, when someone without a great deal of experience
suggests a bug in a language implementation, it's a sign of their lack
of understanding.  Maybe you're the exception.  I can't tell because you
cannot share with us a simple example of how it fails.


> And i did post a more comprehensive example.

> function STARTPLAY(){ 
> if (keepGoing) { 
> setTimeout(STARTPLAY,copyEv[playPos]); 
> REALTIME=performance.now()-browserLoadTIME; 
> LATENCY=REALTIME-oldPassedTime; 
> oldPassedTime=schedTime; 
> schedTime=copyEv[playPos]+schedTime; 
> copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY); 
> outportarr[outportindex].send(noteMessage[playPos]); 
> playPos++; 
> } 
> }

This has all the issues described above.  It's full of non-local 
variables, and while it might be clear to you what it is supposed
to do, I don't understand it.  The idea of a minimal complete
example is that it's something I can deploy and test and -- most
importantly -- understand myself.

This isn't close.

  -- Scott

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web