[Edbrowse-dev] Churning Timers

[Edbrowse-dev] Churning Timers

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Ok,here is the problem of the day.
If you don't apply my latest push / fix, and go to this site, it locks you out in what seems like an infinite loop.
You can type and type and nothing happens.
Hit control c and get the usual "type qt to quit" message, but still you have no access.
You have to kill the process. At least that's what happens over here.

http://www.huffingtonpost.com/entry/the-inevitability-of-impeachment_us_588e8d52e4b0b065cbbcd09f

I thought my code was traversing a broken tree forever, again, or some such, but no.
I fixed those problems.
This site has a half doesn't timers, actually intervals, that fire every 50ms.
My implementation is sufficiently slow, or perhaps I have the wrong priorities on select() channels, or some such, that I am locked out.
As a bandaid, I now wait at least 230ms before running timers.
That is the latest push.
It's just a couple lines of code.
I actually don't think this is a bad idea.
Timers firing every 50ms almost surely exist to render fast visual effects, which are lost on us.
If it takes a couple minutes to read a message on the screen, or understand what part of the screen has changed,
then there's just no reason to change the screen 20 times a second.
Slowing down the process fixes the problem.
I can enter commands and edbrowse responds.
Type db4 and oh yes you can see the timers firing, and the screen rerendering, even though nothing on the screen changes.
Type db1 to go back to quiet.
It works, though even at this level it consumes 10% of my processor.
If I happen to have 10 such web pages open, either in parallel or pushed up onto the stack, the whole processor is churning.
So we don't have a clear solution yet.
Obviously the real browsers fire these timers 20 times a second without making a dent in cpu usage and without blocking user input.
No idea how they do it.

Anyways, the web page works now, and as for its contents, I can only hope he's right.

Karl Dahlke

[Edbrowse-dev] Churning timers / I'd like to submit 3 things today

[Kevin Carhart]

Wooo, this is great lately!

> Ok I think I fixed the node tree problem. It was a silly silly silly 
> mistake.

So the thing with "can't create tag blah" is done with?  That's awesome. 
I suspected it wasn't ideal to add things to tagInfo one by one. 
Something seemed awry about adding canvas, video, bootstrap and on and on.

> You can type and type and nothing happens.
> Hit control c and get the usual "type qt to quit" message, but still you have no access.
> You have to kill the process. At least that's what happens over here.

I have definitely hit these before.

Other things bubbling up that I need to submit and haven't yet.  These 
four are four reasons why nasa.gov isn't working, maybe among other 
problems too.

- document.querySelectorAll is going to come up.  It's like the selections 
made by getElementsByTagName, etc, except that it uses a language within 
a language, for selection by CSS.  I suggest maybe plugging in outside code 
to take care of it.  I predict we are going to want to have a discussion 
about what to do about this thing.
- domLink TAGACT_META so that metas are part of document.head.childNodes 
and JS can use their contents
- TidyDropEmptyElems no and TidyDropEmptyParas no in html-tidy.c
- I think there needs to be an Option.prototype block along with our 
sets of element types in startwindow.  It's asking for the 
attribute-related methods, like Option.get

Could I do 2,3 and 4 today to get them out of our hair, and do they sound 
acceptable?  querySelectorAll is going to be more of a pain in the butt.

thanks
Kevin

Re: [Edbrowse-dev] Churning timers / I'd like to submit 3 things today

[Kevin Carhart]

Sorry, I wrote sloppy and left something off of the item about Option:

> Other things bubbling up that I need to submit and haven't yet.  These four 
> are four reasons why nasa.gov isn't working, maybe among other problems too.
>
> - document.querySelectorAll is going to come up.  It's like the selections 
> made by getElementsByTagName, etc, except that it uses a language within a 
> language, for selection by CSS.  I suggest maybe plugging in outside code to 
> take care of it.  I predict we are going to want to have a discussion about 
> what to do about this thing.
> - domLink TAGACT_META so that metas are part of document.head.childNodes and 
> JS can use their contents
> - TidyDropEmptyElems no and TidyDropEmptyParas no in html-tidy.c
> - I think there needs to be an Option.prototype block along with our sets of 
> element types in startwindow.  It's asking for the attribute-related methods, 
> like Option.getAttribute

To be specific, deep in the bowels of nasa.gov it wants to say this:
var testEl = document.createElement('div');
testEl.innerHTML = "<select><option></option></select>";
return testEl.childNodes[0].childNodes[0].getAttribute('selected') === 'selected';

[Edbrowse-dev] Churning timers / I'd like to submit 3 things...

[Karl Dahlke]

Sure that sounds fine and straightforward.
You can pop on the channel if you want to talk about #1 interactively.

Karl Dahlke

Re: [Edbrowse-dev] Churning timers / I'd like to submit 3 things...

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

On Mon, Jan 30, 2017 at 09:31:46PM -0500, Karl Dahlke wrote:
> Sure that sounds fine and straightforward.

Agreed.

> You can pop on the channel if you want to talk about #1 interactively.

I'll also be on as soon as I work out how to get my irc client to correctly
identify my nic on reconnect (I'm registered as adth on freenode).

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Edbrowse-dev] Churning Timers

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]

Thanks for fixing this, along with the attributes stuff.
As an interesting note, if you use the latest version on:
http://acid3.acidtests.org

It's fairly clear that the page loads, gets rendered, then blanked by some js
breakage.  I've yet to see an error in the output but I've not had time to do
much checking with this new code.

On Mon, Jan 30, 2017 at 06:00:40AM -0500, Karl Dahlke wrote:
> Ok,here is the problem of the day.
> If you don't apply my latest push / fix, and go to this site, it locks you out in what seems like an infinite loop.
> You can type and type and nothing happens.
> Hit control c and get the usual "type qt to quit" message, but still you have no access.
> You have to kill the process. At least that's what happens over here.
> 
> http://www.huffingtonpost.com/entry/the-inevitability-of-impeachment_us_588e8d52e4b0b065cbbcd09f
> 
> I thought my code was traversing a broken tree forever, again, or some such, but no.
> I fixed those problems.
> This site has a half doesn't timers, actually intervals, that fire every 50ms.
> My implementation is sufficiently slow, or perhaps I have the wrong priorities on select() channels, or some such, that I am locked out.
> As a bandaid, I now wait at least 230ms before running timers.
> That is the latest push.
> It's just a couple lines of code.
> I actually don't think this is a bad idea.
> Timers firing every 50ms almost surely exist to render fast visual effects, which are lost on us.
> If it takes a couple minutes to read a message on the screen, or understand what part of the screen has changed,
> then there's just no reason to change the screen 20 times a second.
> Slowing down the process fixes the problem.
> I can enter commands and edbrowse responds.
> Type db4 and oh yes you can see the timers firing, and the screen rerendering, even though nothing on the screen changes.
> Type db1 to go back to quiet.
> It works, though even at this level it consumes 10% of my processor.
> If I happen to have 10 such web pages open, either in parallel or pushed up onto the stack, the whole processor is churning.
> So we don't have a clear solution yet.
> Obviously the real browsers fire these timers 20 times a second without making a dent in cpu usage and without blocking user input.
> No idea how they do it.
> 
> Anyways, the web page works now, and as for its contents, I can only hope he's right.
> 
> Karl Dahlke

> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev


[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Edbrowse-dev] Churning Timers

[Kevin Carhart]

Those three things are in.  Thanks, I will get on the channel.

> http://acid3.acidtests.org
I better get with it, and switch to working off of acidtests.  This is 
exciting.

Fascinating - acidtests.org blanks, but on db5 it completes!
Maybe this is a good sign.

Kevin




On Tue, 31 Jan 2017, Adam Thompson wrote:

> Thanks for fixing this, along with the attributes stuff.
> As an interesting note, if you use the latest version on:
> http://acid3.acidtests.org
>
> It's fairly clear that the page loads, gets rendered, then blanked by some js
> breakage.  I've yet to see an error in the output but I've not had time to do
> much checking with this new code.
>
> On Mon, Jan 30, 2017 at 06:00:40AM -0500, Karl Dahlke wrote:
>> Ok,here is the problem of the day.
>> If you don't apply my latest push / fix, and go to this site, it locks you out in what seems like an infinite loop.
>> You can type and type and nothing happens.
>> Hit control c and get the usual "type qt to quit" message, but still you have no access.
>> You have to kill the process. At least that's what happens over here.
>>
>> http://www.huffingtonpost.com/entry/the-inevitability-of-impeachment_us_588e8d52e4b0b065cbbcd09f
>>
>> I thought my code was traversing a broken tree forever, again, or some such, but no.
>> I fixed those problems.
>> This site has a half doesn't timers, actually intervals, that fire every 50ms.
>> My implementation is sufficiently slow, or perhaps I have the wrong priorities on select() channels, or some such, that I am locked out.
>> As a bandaid, I now wait at least 230ms before running timers.
>> That is the latest push.
>> It's just a couple lines of code.
>> I actually don't think this is a bad idea.
>> Timers firing every 50ms almost surely exist to render fast visual effects, which are lost on us.
>> If it takes a couple minutes to read a message on the screen, or understand what part of the screen has changed,
>> then there's just no reason to change the screen 20 times a second.
>> Slowing down the process fixes the problem.
>> I can enter commands and edbrowse responds.
>> Type db4 and oh yes you can see the timers firing, and the screen rerendering, even though nothing on the screen changes.
>> Type db1 to go back to quiet.
>> It works, though even at this level it consumes 10% of my processor.
>> If I happen to have 10 such web pages open, either in parallel or pushed up onto the stack, the whole processor is churning.
>> So we don't have a clear solution yet.
>> Obviously the real browsers fire these timers 20 times a second without making a dent in cpu usage and without blocking user input.
>> No idea how they do it.
>>
>> Anyways, the web page works now, and as for its contents, I can only hope he's right.
>>
>> Karl Dahlke
>
>> _______________________________________________
>> Edbrowse-dev mailing list
>> Edbrowse-dev@lists.the-brannons.com
>> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] acidtests script 8

[Kevin Carhart]

Apparently almost all the action is in script eight, numbering from zero. 
It's 172k characters.. I wonder where to begin.

document.scripts.length
10

ds0 = document.scripts[0].data
ds1 = document.scripts[1].data
ds2 = document.scripts[2].data
ds3 = document.scripts[3].data
ds4 = document.scripts[4].data
ds5 = document.scripts[5].data
ds6 = document.scripts[6].data
ds7 = document.scripts[7].data
ds8 = document.scripts[8].data
ds9 = document.scripts[9].data

ds8.length
172980

It's nice to know we are dealing with developers who have a sense of 
humor:

   var kungFuDeathGrip = null; // used to hold things from test to test
   var tests = [
.
.
.

[Edbrowse-dev] acidtests.org

[Kevin Carhart]

This is great.  This is going to be a big deal.  The javascript in 
acidtests.org contains a tests[100] array.  Each of the 100 elements is 
the code for one of the 100 tests.  The code actually appears to be 
handmade and intended to be read and comprehended.  So if I go to jdb and 
paste something in that runs a handful, or all 100, I get coherent 
feedback on what's wrong!  And unlike the usual endless chutes and 
ladders and a million meandering, nested calls, the tests are bitesized 
and not out of the question to actually understand.

So I got stuff like this:

tests[1]()
jdb line 188: TypeError: doc is undefined
tests[2]()
jdb line 188: TypeError: doc is undefined
tests[3]()
jdb line 188: TypeError: doc is undefined
tests[4]()
jdb line 376: TypeError: document.createNodeIterator is not a function
tests[5]()
jdb line 471: TypeError: document.createTreeWalker is not a function
tests[6]()
jdb line 188: TypeError: doc is undefined
tests[7]()
jdb line 522: TypeError: document.createRange is not a function
tests[8]()
jdb line 554: TypeError: document.implementation.createDocument is not a 
function
tests[9]()
jdb line 188: TypeError: doc is undefined
tests[10]()
1



And you can get your score out of 100 by echoing score

score
22

So we pass around a quarter of the tests apparently.  This is 
really good to know about, thanks for concentrating on 
acid3, Adam!

Kevin








On Tue, 31 Jan 2017, Kevin Carhart wrote:

>
> Apparently almost all the action is in script eight, numbering from zero. 
> It's 172k characters.. I wonder where to begin.
>
> document.scripts.length
> 10
>
> ds0 = document.scripts[0].data
> ds1 = document.scripts[1].data
> ds2 = document.scripts[2].data
> ds3 = document.scripts[3].data
> ds4 = document.scripts[4].data
> ds5 = document.scripts[5].data
> ds6 = document.scripts[6].data
> ds7 = document.scripts[7].data
> ds8 = document.scripts[8].data
> ds9 = document.scripts[9].data
>
> ds8.length
> 172980
>
> It's nice to know we are dealing with developers who have a sense of humor:
>
>  var kungFuDeathGrip = null; // used to hold things from test to test
>  var tests = [
> .
> .
> .
>
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists