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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#39945

onsdag 14 april 2021 kl. 14:22:07 UTC+2 skrev sc...@sauyet.com:
> Jonas Thörnvall <jonas.t...@gmail.com> wrote:
> > Scott Sauyet <sc...@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
Feel free to assume that all variables are local and initiated to zero, except the time and note array.
I doubt that help you though.

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

#39946

torsdag 15 april 2021 kl. 20:52:15 UTC+2 skrev Jonas Thörnvall:
> onsdag 14 april 2021 kl. 14:22:07 UTC+2 skrev sc...@sauyet.com: 
> > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > Scott Sauyet <sc...@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
> Feel free to assume that all variables are local and initiated to zero, except the time and note array. 
> I doubt that help you though.
Just to play nice.

var keepgoing=true; var playPos=0;var shedTime=0; var oldPassedTime=0;
 function STARTPLAY(noteMessage,copyEv){
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]

#39947

torsdag 15 april 2021 kl. 20:57:37 UTC+2 skrev Jonas Thörnvall:
> torsdag 15 april 2021 kl. 20:52:15 UTC+2 skrev Jonas Thörnvall: 
> > onsdag 14 april 2021 kl. 14:22:07 UTC+2 skrev sc...@sauyet.com: 
> > > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > Scott Sauyet <sc...@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 
> > Feel free to assume that all variables are local and initiated to zero, except the time and note array. 
> > I doubt that help you though.
> Just to play nice. 
> 
> var keepgoing=true; var playPos=0;var shedTime=0; var oldPassedTime=0; 
> function STARTPLAY(noteMessage,copyEv){
> 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++; 
> } 
> }
I can see some anal nitpicking coming so...
var keepgoing=true; var playPos=0;var shedTime=0; 
 function STARTPLAY(noteMessage,copyEv){
 if (keepGoing) { 
 setTimeout(STARTPLAY,copyEv[playPos]); 
var  REALTIME=performance.now()-browserLoadTIME; 
var  LATENCY=REALTIME-oldPassedTime; 
var  oldPassedTime=schedTime; 
 schedTime=copyEv[playPos]+schedTime; 
 copyEv[playPos]=Math.max(0,copyEv[playPos]-LATENCY); 
 outportarr[outportindex].send(noteMessage[playPos]); 
 playPos++; 
 } 
}

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

#39948

> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
>> Scott Sauyet <sc...@sauyet.com> wrote: 
>>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 

>>> And i did post a more comprehensive example. 
>>> [ ... code elided -- I've seen it too often ...]

>> 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. 

> Feel free to assume that all variables are local and initiated to 
> zero, except the time and note array. I doubt that help you though.

Feel free to spend the effort necessary to understand the criticism 
you've been given and to attempt to create an actual helpful example of 
the problem you're having.

My guess is that it would help you solve the issue on your own.  But
if not, then we'd have something easily digestible to chew on.  Either
way should help make progress.

  -- Scott

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

#39995

fredag 16 april 2021 kl. 04:29:29 UTC+2 skrev Scott Sauyet:
> > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> >> Scott Sauyet <sc...@sauyet.com> wrote: 
> >>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> 
> >>> And i did post a more comprehensive example.
> >>> [ ... code elided -- I've seen it too often ...]
> >> 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.
> > Feel free to assume that all variables are local and initiated to 
> > zero, except the time and note array. I doubt that help you though.
> Feel free to spend the effort necessary to understand the criticism 
> you've been given and to attempt to create an actual helpful example of 
> the problem you're having. 
> 
> My guess is that it would help you solve the issue on your own. But 
> if not, then we'd have something easily digestible to chew on. Either 
> way should help make progress. 
> 
> -- Scott
Well i just fiddled around and solved the latentcy, but the order in which i do the things don't seem correct.
I don't think i will fully solve it without drawing. But the playtime is now correct.
https://jonasth.github.io/

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

#39996

tisdag 20 april 2021 kl. 23:12:25 UTC+2 skrev Jonas Thörnvall:
> fredag 16 april 2021 kl. 04:29:29 UTC+2 skrev Scott Sauyet: 
> > > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > >> Scott Sauyet <sc...@sauyet.com> wrote: 
> > >>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > 
> > >>> And i did post a more comprehensive example. 
> > >>> [ ... code elided -- I've seen it too often ...] 
> > >> 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. 
> > > Feel free to assume that all variables are local and initiated to 
> > > zero, except the time and note array. I doubt that help you though. 
> > Feel free to spend the effort necessary to understand the criticism 
> > you've been given and to attempt to create an actual helpful example of 
> > the problem you're having. 
> > 
> > My guess is that it would help you solve the issue on your own. But 
> > if not, then we'd have something easily digestible to chew on. Either 
> > way should help make progress. 
> > 
> > -- Scott
> Well i just fiddled around and solved the latentcy, but the order in which i do the things don't seem correct. 
> I don't think i will fully solve it without drawing. But the playtime is now correct. 
> https://jonasth.github.io/
It could be i have todo the greasemonkey solution sending dumb messages every 5th millisecond because Javascript seems no way differ by 5 ms at setTimeout it can go well above 100 ms.

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

#39997

tisdag 20 april 2021 kl. 23:47:06 UTC+2 skrev Jonas Thörnvall:
> tisdag 20 april 2021 kl. 23:12:25 UTC+2 skrev Jonas Thörnvall: 
> > fredag 16 april 2021 kl. 04:29:29 UTC+2 skrev Scott Sauyet: 
> > > > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > >> Scott Sauyet <sc...@sauyet.com> wrote: 
> > > >>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > 
> > > >>> And i did post a more comprehensive example. 
> > > >>> [ ... code elided -- I've seen it too often ...] 
> > > >> 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. 
> > > > Feel free to assume that all variables are local and initiated to 
> > > > zero, except the time and note array. I doubt that help you though. 
> > > Feel free to spend the effort necessary to understand the criticism 
> > > you've been given and to attempt to create an actual helpful example of 
> > > the problem you're having. 
> > > 
> > > My guess is that it would help you solve the issue on your own. But 
> > > if not, then we'd have something easily digestible to chew on. Either 
> > > way should help make progress. 
> > > 
> > > -- Scott 
> > Well i just fiddled around and solved the latentcy, but the order in which i do the things don't seem correct. 
> > I don't think i will fully solve it without drawing. But the playtime is now correct. 
> > https://jonasth.github.io/
> It could be i have todo the greasemonkey solution sending dumb messages every 5th millisecond because Javascript seems no way differ by 5 ms at setTimeout it can go well above 100 ms.

I simply do not like recursions especially if they come with timers set into the future.
Although producing a timelike coherent result, something seem awfully wrong with the logic of function

function STARTPLAY(){
	if (keepGoing) {
		if (playPos<copyEv.length) {
			outportarr[outportindex].send(noteMessage[playPos]);
			stopRec=setTimeout(STARTPLAY,copyEv[playPos]);
			REALTIME=performance.now()-browserLoadTIME;
			LATENCY=REALTIME-oldPassedTime;			
			oldPassedTime=schedTime;
			schedTime=copyEv[playPos+1]+schedTime; 
			copyEv[playPos+1]=copyEv[playPos+1]-LATENCY;
			playPos++;	
		} else { stop();}
	}
}

To me the above seem to say the note is sent two times? First directly at call, later same note scheduled again, should it not be playPos+1?????
Is it just that i do not understand recursions, the above seem to work and it baffels me?

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

#39998

onsdag 21 april 2021 kl. 08:35:52 UTC+2 skrev Jonas Thörnvall:
> tisdag 20 april 2021 kl. 23:47:06 UTC+2 skrev Jonas Thörnvall: 
> > tisdag 20 april 2021 kl. 23:12:25 UTC+2 skrev Jonas Thörnvall: 
> > > fredag 16 april 2021 kl. 04:29:29 UTC+2 skrev Scott Sauyet: 
> > > > > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > >> Scott Sauyet <sc...@sauyet.com> wrote: 
> > > > >>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > 
> > > > >>> And i did post a more comprehensive example. 
> > > > >>> [ ... code elided -- I've seen it too often ...] 
> > > > >> 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. 
> > > > > Feel free to assume that all variables are local and initiated to 
> > > > > zero, except the time and note array. I doubt that help you though. 
> > > > Feel free to spend the effort necessary to understand the criticism 
> > > > you've been given and to attempt to create an actual helpful example of 
> > > > the problem you're having. 
> > > > 
> > > > My guess is that it would help you solve the issue on your own. But 
> > > > if not, then we'd have something easily digestible to chew on. Either 
> > > > way should help make progress. 
> > > > 
> > > > -- Scott 
> > > Well i just fiddled around and solved the latentcy, but the order in which i do the things don't seem correct. 
> > > I don't think i will fully solve it without drawing. But the playtime is now correct. 
> > > https://jonasth.github.io/ 
> > It could be i have todo the greasemonkey solution sending dumb messages every 5th millisecond because Javascript seems no way differ by 5 ms at setTimeout it can go well above 100 ms.
> I simply do not like recursions especially if they come with timers set into the future. 
> Although producing a timelike coherent result, something seem awfully wrong with the logic of function 
> 
> function STARTPLAY(){ 
> if (keepGoing) { 
> if (playPos<copyEv.length) {
> outportarr[outportindex].send(noteMessage[playPos]);
> stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> REALTIME=performance.now()-browserLoadTIME; 
> LATENCY=REALTIME-oldPassedTime; 
> oldPassedTime=schedTime; 
> schedTime=copyEv[playPos+1]+schedTime; 
> copyEv[playPos+1]=copyEv[playPos+1]-LATENCY; 
> playPos++; 
> } else { stop();} 
> } 
> } 
> 
> To me the above seem to say the note is sent two times? First directly at call, later same note scheduled again, should it not be playPos+1????? 
> Is it just that i do not understand recursions, the above seem to work and it baffels me?
Isn't this the logic that should apply, i find the whole thing utterly confusing?
function STARTRECPLAY(){
	if (keepGoing) {
		//While still notes
		if (playPos<copyEv.length-1) {
			outportarr[outportindex].send(noteMessage[playPos]);
			REALTIME=performance.now()-browserLoadTIME;
			LATENCY=REALTIME-oldPassedTime;			
			oldPassedTime=schedTime;
			schedTime=copyEv[playPos+1]+schedTime; 
			copyEv[playPos+1]=copyEv[playPos+1]-LATENCY;
			playPos++;	
			stopRec=setTimeout(STARTPLAY,copyEv[playPos]);
		} else { stop();}
	}
}

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

#39999

onsdag 21 april 2021 kl. 10:08:30 UTC+2 skrev Jonas Thörnvall:
> onsdag 21 april 2021 kl. 08:35:52 UTC+2 skrev Jonas Thörnvall: 
> > tisdag 20 april 2021 kl. 23:47:06 UTC+2 skrev Jonas Thörnvall: 
> > > tisdag 20 april 2021 kl. 23:12:25 UTC+2 skrev Jonas Thörnvall: 
> > > > fredag 16 april 2021 kl. 04:29:29 UTC+2 skrev Scott Sauyet: 
> > > > > > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > > >> Scott Sauyet <sc...@sauyet.com> wrote: 
> > > > > >>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > > 
> > > > > >>> And i did post a more comprehensive example. 
> > > > > >>> [ ... code elided -- I've seen it too often ...] 
> > > > > >> 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. 
> > > > > > Feel free to assume that all variables are local and initiated to 
> > > > > > zero, except the time and note array. I doubt that help you though. 
> > > > > Feel free to spend the effort necessary to understand the criticism 
> > > > > you've been given and to attempt to create an actual helpful example of 
> > > > > the problem you're having. 
> > > > > 
> > > > > My guess is that it would help you solve the issue on your own. But 
> > > > > if not, then we'd have something easily digestible to chew on. Either 
> > > > > way should help make progress. 
> > > > > 
> > > > > -- Scott 
> > > > Well i just fiddled around and solved the latentcy, but the order in which i do the things don't seem correct. 
> > > > I don't think i will fully solve it without drawing. But the playtime is now correct. 
> > > > https://jonasth.github.io/ 
> > > It could be i have todo the greasemonkey solution sending dumb messages every 5th millisecond because Javascript seems no way differ by 5 ms at setTimeout it can go well above 100 ms. 
> > I simply do not like recursions especially if they come with timers set into the future. 
> > Although producing a timelike coherent result, something seem awfully wrong with the logic of function 
> > 
> > function STARTPLAY(){ 
> > if (keepGoing) { 
> > if (playPos<copyEv.length) { 
> > outportarr[outportindex].send(noteMessage[playPos]); 
> > stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> > REALTIME=performance.now()-browserLoadTIME; 
> > LATENCY=REALTIME-oldPassedTime; 
> > oldPassedTime=schedTime; 
> > schedTime=copyEv[playPos+1]+schedTime; 
> > copyEv[playPos+1]=copyEv[playPos+1]-LATENCY; 
> > playPos++; 
> > } else { stop();} 
> > } 
> > } 
> > 
> > To me the above seem to say the note is sent two times? First directly at call, later same note scheduled again, should it not be playPos+1????? 
> > Is it just that i do not understand recursions, the above seem to work and it baffels me?
> Isn't this the logic that should apply, i find the whole thing utterly confusing? 
> function STARTRECPLAY(){ 
> if (keepGoing) { 
> //While still notes 
> if (playPos<copyEv.length-1) {
> outportarr[outportindex].send(noteMessage[playPos]);
> REALTIME=performance.now()-browserLoadTIME; 
> LATENCY=REALTIME-oldPassedTime; 
> oldPassedTime=schedTime; 
> schedTime=copyEv[playPos+1]+schedTime; 
> copyEv[playPos+1]=copyEv[playPos+1]-LATENCY; 
> playPos++;
> stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> } else { stop();} 
> } 
> }
Or if you prefer
function STARTRECPLAY(){
if (keepGoing) {
//While still notes
if (playPos<copyEv.length-1) {
outportarr[outportindex].send(noteMessage[playPos]);
REALTIME=performance.now()-browserLoadTIME;
oldPassedTime=schedTime;
schedTime=copyEv[playPos+1]+schedTime;
LATENCY=REALTIME-oldPassedTime;
copyEv[playPos+1]=copyEv[playPos+1]-LATENCY;
stopRec=setTimeout(STARTPLAY,copyEv[playPos+1]);
playPos++;
} else { stop();}
}
}

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

#40000

onsdag 21 april 2021 kl. 10:24:33 UTC+2 skrev Jonas Thörnvall:
> onsdag 21 april 2021 kl. 10:08:30 UTC+2 skrev Jonas Thörnvall: 
> > onsdag 21 april 2021 kl. 08:35:52 UTC+2 skrev Jonas Thörnvall: 
> > > tisdag 20 april 2021 kl. 23:47:06 UTC+2 skrev Jonas Thörnvall: 
> > > > tisdag 20 april 2021 kl. 23:12:25 UTC+2 skrev Jonas Thörnvall: 
> > > > > fredag 16 april 2021 kl. 04:29:29 UTC+2 skrev Scott Sauyet: 
> > > > > > > Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > > > >> Scott Sauyet <sc...@sauyet.com> wrote: 
> > > > > > >>> Jonas Thörnvall <jonas.t...@gmail.com> wrote: 
> > > > > > 
> > > > > > >>> And i did post a more comprehensive example. 
> > > > > > >>> [ ... code elided -- I've seen it too often ...] 
> > > > > > >> 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. 
> > > > > > > Feel free to assume that all variables are local and initiated to 
> > > > > > > zero, except the time and note array. I doubt that help you though. 
> > > > > > Feel free to spend the effort necessary to understand the criticism 
> > > > > > you've been given and to attempt to create an actual helpful example of 
> > > > > > the problem you're having. 
> > > > > > 
> > > > > > My guess is that it would help you solve the issue on your own. But 
> > > > > > if not, then we'd have something easily digestible to chew on. Either 
> > > > > > way should help make progress. 
> > > > > > 
> > > > > > -- Scott 
> > > > > Well i just fiddled around and solved the latentcy, but the order in which i do the things don't seem correct. 
> > > > > I don't think i will fully solve it without drawing. But the playtime is now correct. 
> > > > > https://jonasth.github.io/ 
> > > > It could be i have todo the greasemonkey solution sending dumb messages every 5th millisecond because Javascript seems no way differ by 5 ms at setTimeout it can go well above 100 ms. 
> > > I simply do not like recursions especially if they come with timers set into the future. 
> > > Although producing a timelike coherent result, something seem awfully wrong with the logic of function 
> > > 
> > > function STARTPLAY(){ 
> > > if (keepGoing) { 
> > > if (playPos<copyEv.length) { 
> > > outportarr[outportindex].send(noteMessage[playPos]); 
> > > stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> > > REALTIME=performance.now()-browserLoadTIME; 
> > > LATENCY=REALTIME-oldPassedTime; 
> > > oldPassedTime=schedTime; 
> > > schedTime=copyEv[playPos+1]+schedTime; 
> > > copyEv[playPos+1]=copyEv[playPos+1]-LATENCY; 
> > > playPos++; 
> > > } else { stop();} 
> > > } 
> > > } 
> > > 
> > > To me the above seem to say the note is sent two times? First directly at call, later same note scheduled again, should it not be playPos+1????? 
> > > Is it just that i do not understand recursions, the above seem to work and it baffels me? 
> > Isn't this the logic that should apply, i find the whole thing utterly confusing? 
> > function STARTRECPLAY(){ 
> > if (keepGoing) { 
> > //While still notes 
> > if (playPos<copyEv.length-1) { 
> > outportarr[outportindex].send(noteMessage[playPos]); 
> > REALTIME=performance.now()-browserLoadTIME; 
> > LATENCY=REALTIME-oldPassedTime; 
> > oldPassedTime=schedTime; 
> > schedTime=copyEv[playPos+1]+schedTime; 
> > copyEv[playPos+1]=copyEv[playPos+1]-LATENCY; 
> > playPos++; 
> > stopRec=setTimeout(STARTPLAY,copyEv[playPos]); 
> > } else { stop();} 
> > } 
> > }
> Or if you prefer
> function STARTRECPLAY(){ 
> if (keepGoing) { 
> //While still notes 
> if (playPos<copyEv.length-1) { 
> outportarr[outportindex].send(noteMessage[playPos]); 
> REALTIME=performance.now()-browserLoadTIME;
> oldPassedTime=schedTime; 
> schedTime=copyEv[playPos+1]+schedTime; 
> LATENCY=REALTIME-oldPassedTime;
> copyEv[playPos+1]=copyEv[playPos+1]-LATENCY;
> stopRec=setTimeout(STARTPLAY,copyEv[playPos+1]); 
> playPos++; 
> } else { stop();} 
> } 
> }
Anyway something is wrong although the melody "seem" to play okay, the metronome track sounds totally fucked up when recording.
It is something about the order of things done.

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

#39922

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.
That said i do not think javascript act as expected, or as intended in this case, or i missunderstood setTimout and recursive calls severly.
What i say is should not my code subtract timings "from the sent out notes via setTimeout", because i am pretty sure it does not.
But then again i really can not tell if Javascript do what it is supposed todo, but you probably can.

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

#39926

On 13/04/2021 14:58, Ben Bacarisse wrote:
>    The function is doing  exactly what you wrote.

Not for at least two decades, and certainly not in JavaScript.

The function is doing what the compiler and/or interpreter decided you 
*meant* by what you wrote.

Which is why you now have new keywords like 'volatile' to try and force 
it not to be clever with loop optimisations and Number() to ensure it 
actually does cast an unknown variable type to a number...

Years ago I could look at a bit of C code and translate it into the 
actual assembler that the compiler would spit out. Today it produces 
nothing like that at all.

So far I have always been impressed at how good it was at optimisation, 
but as I have said elsewhere, sometimes it gets it wrong.

And there are holes in the spec - areas that are 'indeterminate' and up 
to the whim of the compiler/interpreter and of course things like 
uninitialised memory.

Then when you get to concurrent threads...

-- 
“But what a weak barrier is truth when it stands in the way of an 
hypothesis!”

Mary Wollstonecraft

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

#39929

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

> On 13/04/2021 14:58, Ben Bacarisse wrote:
>>    The function is doing  exactly what you wrote.
>
> Not for at least two decades, and certainly not in JavaScript.
>
> The function is doing what the compiler and/or interpreter decided you
> *meant* by what you wrote.

It's a common mistake to think of code as implying more than it does.
This is particularly true of high-level languages like ECMAScript, but
it's also true of languages like C.  Assuming more than the language
guarantees has been the source of many bugs in C programs.

> Which is why you now have new keywords like 'volatile' to try and
> force it not to be clever with loop optimisations and Number() to
> ensure it actually does cast an unknown variable type to a number...

Hmm...  Your recent Number() example seems to be simply a case of your
not knowing what the language guarantees.

> Years ago I could look at a bit of C code and translate it into the
> actual assembler that the compiler would spit out. Today it produces
> nothing like that at all.
>
> So far I have always been impressed at how good it was at
> optimisation, but as I have said elsewhere, sometimes it gets it
> wrong.

I agree that all of this is contingent on the specification being clear
and there being no bugs in the language implementation.  But in JT's
case, I would be very surprised if the problem where a bug in the
implementation.  All beginners think they have found a compiler bug!

> And there are holes in the spec - areas that are 'indeterminate' and
> up to the whim of the compiler/interpreter and of course things like
> uninitialised memory.
>
> Then when you get to concurrent threads...

-- 
Ben.

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

#39930

On 14/04/2021 01:32, Ben Bacarisse wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
> 
>> On 13/04/2021 14:58, Ben Bacarisse wrote:
>>>     The function is doing  exactly what you wrote.
>>
>> Not for at least two decades, and certainly not in JavaScript.
>>
>> The function is doing what the compiler and/or interpreter decided you
>> *meant* by what you wrote.
> 
> It's a common mistake to think of code as implying more than it does.
> This is particularly true of high-level languages like ECMAScript, but
> it's also true of languages like C.  Assuming more than the language
> guarantees has been the source of many bugs in C programs.
> 
>> Which is why you now have new keywords like 'volatile' to try and
>> force it not to be clever with loop optimisations and Number() to
>> ensure it actually does cast an unknown variable type to a number...
> 
> Hmm...  Your recent Number() example seems to be simply a case of your
> not knowing what the language guarantees. 

Indeed. In the end that was exactly what it was, which proves that 
particular point. The spec didn't cover the case. And yet it should 
have. I had no reason to suppose that having got it working in Firefox 
it would utterly fail to work in IE4...

> 
>> Years ago I could look at a bit of C code and translate it into the
>> actual assembler that the compiler would spit out. Today it produces
>> nothing like that at all.
>>
>> So far I have always been impressed at how good it was at
>> optimisation, but as I have said elsewhere, sometimes it gets it
>> wrong.
> 
> I agree that all of this is contingent on the specification being clear
> and there being no bugs in the language implementation.  But in JT's
> case, I would be very surprised if the problem where a bug in the
> implementation.  All beginners think they have found a compiler bug!

Again its less bugs, than inability to handle edge cases.
> 
>> And there are holes in the spec - areas that are 'indeterminate' and
>> up to the whim of the compiler/interpreter and of course things like
>> uninitialised memory.
>>
>> Then when you get to concurrent threads...
> 


-- 
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

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

#39932

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

> On 14/04/2021 01:32, Ben Bacarisse wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 13/04/2021 14:58, Ben Bacarisse wrote:
>>>>     The function is doing  exactly what you wrote.
>>>
>>> Not for at least two decades, and certainly not in JavaScript.
>>>
>>> The function is doing what the compiler and/or interpreter decided you
>>> *meant* by what you wrote.
>>
>> It's a common mistake to think of code as implying more than it does.
>> This is particularly true of high-level languages like ECMAScript, but
>> it's also true of languages like C.  Assuming more than the language
>> guarantees has been the source of many bugs in C programs.
>>
>>> Which is why you now have new keywords like 'volatile' to try and
>>> force it not to be clever with loop optimisations and Number() to
>>> ensure it actually does cast an unknown variable type to a number...
>>
>> Hmm...  Your recent Number() example seems to be simply a case of your
>> not knowing what the language guarantees. 
>
> Indeed. In the end that was exactly what it was, which proves that
> particular point. The spec didn't cover the case.

You are mistaken.  Did you check the sections I cited?  You seem to
have a fixation with spreading FUD about the specification.

> And yet it should have. I had no reason to suppose that having got it
> working in Firefox it would utterly fail to work in IE4...

I hope that 4 is a typo.  The code you originally posted works as per
the spec in IE6 (contrary to your previous claims).  If is was broken in
one, it had to be in Mozilla.  Whilst I doubt that, I can't easily test
old versions of it.  You appear to be immune to these facts.

The code you most recently posted shows nothing since if you want to
compare two string numerically it makes sense to convert both explicitly
to numbers.  There's no relation to the previous point about implicit
conversions as far as I can see since, given that you were unaware of
what the language requires, you would not have converted only one.
Anyway, you don't post the code that you say caused problems, only the
"corrected" code which is exactly as I would expect it to look.

-- 
Ben.

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

#39933

On 14/04/2021 10:06, Ben Bacarisse wrote:
> Anyway, you don't post the code that you say caused problems, only the
> "corrected" code which is exactly as I would expect it to look.

Have you, excuse me asking, ever written a single line of production 
code under a deadline, to solve a real world problem , in your life, or 
are you in fact just another 'Computer Scientist'?

I really don't remember whether it was IE4 or 6. It was whatever XP 
started out with.

And no, I am not going to keep the unfixed code merely to prove to some 
armchair theorist 14 years later than I am in fact not lying.




-- 
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

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

#39935

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

> On 14/04/2021 10:06, Ben Bacarisse wrote:
>> Anyway, you don't post the code that you say caused problems, only the
>> "corrected" code which is exactly as I would expect it to look.
>
> Have you, excuse me asking, ever written a single line of production
> code under a deadline, to solve a real world problem , in your life,
> or are you in fact just another 'Computer Scientist'?

No need to excuse the question.  It's a reasonable one.  The answer is
yes.

> I really don't remember whether it was IE4 or 6. It was whatever XP
> started out with.

It's a shame you didn't say that that up front.  Given that you did say
you couldn't find what the specification says, coming clean about not
knowing what browser you where using would probably have prevented
anyone commenting!  It was the confidently stated incorrect remarks that
got people answering.

> And no, I am not going to keep the unfixed code merely to prove to
> some armchair theorist 14 years later than I am in fact not lying.

No one wants to see the old code.  Its the incorrect remarks you made
about a code fragment posted here that got people commenting.  In
particular, your remark that the language spec did not say what the
correct behaviour should be when in fact it does (and it did at the time
you specified).

-- 
Ben.

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

#39938

On 14/04/2021 14:05, Ben Bacarisse wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
> 
>> On 14/04/2021 10:06, Ben Bacarisse wrote:
>>> Anyway, you don't post the code that you say caused problems, only the
>>> "corrected" code which is exactly as I would expect it to look.
>>
>> Have you, excuse me asking, ever written a single line of production
>> code under a deadline, to solve a real world problem , in your life,
>> or are you in fact just another 'Computer Scientist'?
> 
> No need to excuse the question.  It's a reasonable one.  The answer is
> yes.
> 
>> I really don't remember whether it was IE4 or 6. It was whatever XP
>> started out with.
> 
> It's a shame you didn't say that that up front.  Given that you did say
> you couldn't find what the specification says, coming clean about not
> knowing what browser you where using would probably have prevented
> anyone commenting!  It was the confidently stated incorrect remarks that
> got people answering.
> 
>> And no, I am not going to keep the unfixed code merely to prove to
>> some armchair theorist 14 years later than I am in fact not lying.
> 
> No one wants to see the old code.  Its the incorrect remarks you made
> about a code fragment posted here that got people commenting.  In
> particular, your remark that the language spec did not say what the
> correct behaviour should be when in fact it does (and it did at the time
> you specified).
> 
No. Again you are lying and accusing me of lying.
What I said was that the two browsers behaved differently. And the 
specification at that time as far as I could see did not cover the case .

The fact is that the same code behaved completely differently in two 
browsers. I have shown you what the fixed code looked like.

My recollection is that I cursorily investigated the spec. to see if 
there was a reportable bug, but decided that in this particular case the 
code specification was sufficiently poor that either side could claim 
they had implemented JavaScipt *not in contradiction* to the spec.

Why you cant accept that and have to insist that I am lying, is beyond 
me. Perhaps you need to get laid or something.

I have absolutely no reason to make it up.

-- 
Gun Control: The law that ensures that only criminals have guns.

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

#39943

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

> On 14/04/2021 14:05, Ben Bacarisse wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 14/04/2021 10:06, Ben Bacarisse wrote:
>>>> Anyway, you don't post the code that you say caused problems, only the
>>>> "corrected" code which is exactly as I would expect it to look.
>>>
>>> Have you, excuse me asking, ever written a single line of production
>>> code under a deadline, to solve a real world problem , in your life,
>>> or are you in fact just another 'Computer Scientist'?
>>
>> No need to excuse the question.  It's a reasonable one.  The answer is
>> yes.
>>
>>> I really don't remember whether it was IE4 or 6. It was whatever XP
>>> started out with.
>>
>> It's a shame you didn't say that that up front.  Given that you did say
>> you couldn't find what the specification says, coming clean about not
>> knowing what browser you where using would probably have prevented
>> anyone commenting!  It was the confidently stated incorrect remarks that
>> got people answering.
>>
>>> And no, I am not going to keep the unfixed code merely to prove to
>>> some armchair theorist 14 years later than I am in fact not lying.
>>
>> No one wants to see the old code.  Its the incorrect remarks you made
>> about a code fragment posted here that got people commenting.  In
>> particular, your remark that the language spec did not say what the
>> correct behaviour should be when in fact it does (and it did at the time
>> you specified).
>>
> No. Again you are lying and accusing me of lying.

I don't think anything useful can come from continuing this exchange.

-- 
Ben.

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

#39944

On 14/04/2021 23:53, Ben Bacarisse wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
> 
>> On 14/04/2021 14:05, Ben Bacarisse wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>
>>>> On 14/04/2021 10:06, Ben Bacarisse wrote:
>>>>> Anyway, you don't post the code that you say caused problems, only the
>>>>> "corrected" code which is exactly as I would expect it to look.
>>>>
>>>> Have you, excuse me asking, ever written a single line of production
>>>> code under a deadline, to solve a real world problem , in your life,
>>>> or are you in fact just another 'Computer Scientist'?
>>>
>>> No need to excuse the question.  It's a reasonable one.  The answer is
>>> yes.
>>>
>>>> I really don't remember whether it was IE4 or 6. It was whatever XP
>>>> started out with.
>>>
>>> It's a shame you didn't say that that up front.  Given that you did say
>>> you couldn't find what the specification says, coming clean about not
>>> knowing what browser you where using would probably have prevented
>>> anyone commenting!  It was the confidently stated incorrect remarks that
>>> got people answering.
>>>
>>>> And no, I am not going to keep the unfixed code merely to prove to
>>>> some armchair theorist 14 years later than I am in fact not lying.
>>>
>>> No one wants to see the old code.  Its the incorrect remarks you made
>>> about a code fragment posted here that got people commenting.  In
>>> particular, your remark that the language spec did not say what the
>>> correct behaviour should be when in fact it does (and it did at the time
>>> you specified).
>>>
>> No. Again you are lying and accusing me of lying.
> 
> I don't think anything useful can come from continuing this exchange.
> 
for you certainly not. you have been caught. stop digging

-- 
"The great thing about Glasgow is that if there's a nuclear attack it'll 
look exactly the same afterwards."

Billy Connolly

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

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

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

csiph-web