[Edbrowse-dev] css in C

[Edbrowse-dev] css in C

[Karl Dahlke]

Well there you have it, 2000 lines of code.
It's so fast you can't even measure it, even for stackoverflow.com, 5000 selectors and 5000 nodes.
Course that may be because it isn't working properly.
It only makes 157 assignments, which seems awfully small.
Or maybe most of those selectors are for situations that don't come up,
i.e. a selector for every conceivable situation.
It will take a long time to actually debug this mess.
dbcss can help in this regard, dumps lots of information to /tmp/css
As a simple spotcheck,
ok(document.body.style) has all sorts of attributes, as one would expect.

Karl Dahlke

Re: [Edbrowse-dev] css in C

[Kevin Carhart]

This is great!

> dbcss can help in this regard, dumps lots of information to /tmp/css

If I make a list of all of the new debugging functionality, can you tell 
me if I'm missing any?

dber - you toggle this from the edbrowse command line
dbcss - is this a toggle also?
^> - the file redirect to your filesystem
showscripts - list all scripts
searchscripts - searches all scripts for a string
debugEvent - toggles diagnostic messages about events - to get this, you 
set the boolean variable to true and recompile
debugClone - you also enable this by recompiling 
startwindow
demin
aloop
jdb
db#

And on this subject, there's something else you implemented recently and I 
haven't taken advantage of it yet.  It's the hex prefixes that show when 
event handler code fails, usually near the end of the output after the 
regular .js files have finished. Such as,

error in f575d3.ontimer()

It seems like excellent information, so how would you go about cross 
referencing?  Can we go from this message, to a key where 
you can find out that f575d3 is a certain element?  And then from that 
point, maybe the element has an obscure string on it that you can look for 
with searchscripts(), or you can get your bearings based on f575d3 and its 
position in the tree.

It seems like a getElementsByEventListener("ontimer") would be useful. 
That would be another way of narrowing it down.  "I know from the error 
message that a timer fails, so now I have the result set of five elements 
that listen for this.  It must be one of these."  This could be either 
another getElements function or maybe there is something among the 
selector syntax to do it!

thanks
Kevin

[Edbrowse-dev] css in C

[Karl Dahlke]

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

As for debugging, I try to keep those commands in the quick reference guide under the debug section.
Though they don't include the js functions in startwindow that might help, maybe they should, maybe not, IDK,
at a philosophical level it's just the edbrowse commands.
So here is your list with some edits, the first few coming from the quick reference guide.
These work from edbrowse or within jdb.

db3 : set debug level, 0 through 9
db>/tmp/edbrowse.out : redirect debugging output to a file
jdb : javascript debugger, bye to exit
demin : deminimize javascript (toggle)
timers : disable javascript timers (toggle)
dbcn : enable cloneNode debugging (toggle)
dbev : enable event debugging (toggle)
dber : enable js error debugging (toggle)
dbcss : enable css debugging (toggle)

^> - the file redirect to your filesystem
showscripts - list all scripts
searchscripts - searches all scripts for a string
aloop

> error in f575d3.ontimer()

You have my head in a whirl with this one.
It comes from jseng-duk.c line 1790, from html.c line 2346.
So it's hex for the c pointer of the timer object that was created to run the timer,
but that object goes away once the timer has fired.
We would either have to make these timers not go away, whence they would accumulate, or perhaps print more helpful information before the timer runs.
The body attribute would be helpful, the source code for the timer,
but sometimes, perhaps most of the time, it isn't given source but rather a function.
setTimeout(f, 30000);
Hardly anything useful we can do with that.
I'll give this a little more thought.

Karl Dahlke

Re: [Edbrowse-dev] css in C

[Kevin Carhart]

On Tue, 27 Feb 2018, Karl Dahlke wrote:

> As for debugging, I try to keep those commands in the quick reference guide under the debug section.

Oops, thank you.  You had already documented it and I was not checking in 
the right section.

>> error in f575d3.ontimer()

> line 1790, from html.c line 2346. So it's hex for the c pointer of the

Ahhh, so that's what it is.  I don't know.  Maybe we can get something, 
maybe we can't.

[Edbrowse-dev] css in c

[Karl Dahlke]

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

Over the past month I've come to conclude that a lot of css stuff will have to run at document load time, maybe not all of it but enough,
and that says the stuff probably has to be rewritten in C.
I translated the css parser from javascript to c, thus the new file css.c.
This was about as much fun as cleaning the bathroom.

I pushed just because there are 900 new lines of code and I didn't want to lose all that work if my computer flaked out.

It isn't used yet, it just exists.
You can invoke it from jdb by cssCompile("css string")
or perhaps an existing source like
cssCompile(cssSource[0].data)
It parses the css and builds the tree of descriptors and rules internally
and prints it out for debugging purposes, in /tmp/css
All the old js machinery still does querySelectorAll and getComputedStyle etc.
This is the foundation.
I do expect it all to be very fast when done though.

I did find a few things while translating that I wasn't doing at all.
Like
@import url(blah)
which lets one css file import another.   Like #include
So that's working in the c version.
And a couple other small fixes too.
It's going to be a long road.

Karl Dahlke