Re: [Edbrowse-dev] js engine process, version 1

[Adam Thompson <arthompson1990@gmail.com>]

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

On Mon, Dec 22, 2014 at 03:23:30PM -0500, Karl Dahlke wrote:
> Just in time for Christmas - but don't get too excited,
> because it is entirely untested. All I know is it compiles.
> git pull
> and read through jseng-moz.cpp
> It corresponds to ebjs.c.
> They send messages to each other in a coordinated fashion.

Ok, I'll have a look at that, sounds good.

> make edbrowse-js
> Then run edbrowse-js to get the usage.
> That's as far as I got.

Yep, that works on my system.
> I was almost ready to commit this file yesterday,
> having worked on it for a week solid,
> and then I deleted it. No shit!
> I typed rm instead of mv or cp or whatever the hell I was trying to do,
> and the file was gone, with absolutely no backups.
> So I had to start over.
> Fortunately most of it was still in my head,
> and there was lots of copying and modifying from the existing files,
> and I remembered how I did it, so stayed up all night
> while it was fresh in my mind and banged it out again,
> then sent it to github in a hurry!

Yeah, I've done that before, the worst part is when you know what you've done
and know it's too late to do anything about it.

> The first thing you see is several small functions copied from
> stringfile.c and url.c.
> These are functions that I just need everywhere.
> This is duplication, and that concerns me,
> but I didn't want to drag in eb.h, and from there all of edbrowse,
> so for now I copied the routines I needed.
> Some day we might want to put these into common.c or some such.

Yep, common.c for the code and common.h for the prototypes probably.

> Finally the real code begins at line 546.
> Message management, much like that in ebjs.c, and the dom classes
> and setters and side effects and all that.
> If you like statistics, the new code is 3408 lines,
> and the old code is 3100 lines.
> Since the new has all sorts of messaging and message parsing,
> that wasn't there before, it's fair to say I was able to optimize
> much of the old code along the way.
> One example is making use of the C preprocessor.
> Look at the definitions for generic_class and generic_ctor
> Now the classes and constructors are basically a list,
> whereas they use to be pages of essentially the same C code
> over and over and over again.
> I feared this trick might derail indent,
> but it seems to have indented the code properly,
> except it keeps getting rid of the blank line after the list of classes,
> not sure why.
> Maybe I should put a semicolon in just to get it back on track.

No please don't. The lack of a blank is potentially annoying (though tbh I've
never been too good at code style),
but I'd rather that than an empty statement for no good reason.
> 
> As I say this is all untested.
> I wanted to do some stand-alone tests,
> but I'd have to write some nontrivial programs to do that.
> It's probably about the same work to just take the plunge
> and modify edbrowse to use the new interface,
> and test it in battle.
> I'm not going to attempt any of this until after christmas.
> That gives you time to find some bugs in the code just by reading it.

Yeah, I've got some time now (not back at work till 5th Jan) so if it's ok,
I may have a go at plugging in the new code at some stage.

It'll be a bunch of work, but it'll hopefully be useful.

I'm also investigating if there's anything we can use to parse html into a DOM
rather than our own hand-rolled parser or something which is too bound up with
an existing browser. So far I've not had much luck finding something in c which
does html, is fairly lightweight and produces the kind of DOM you can actually use.

Cheers,
Adam.

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