[Edbrowse-dev] js engine process, version 1

[Edbrowse-dev] js engine process, version 1

[Karl Dahlke]

I forgot about some of the handler functions.
Let me have a look and evaluate, and then I'll
bat it back into your court.

Karl Dahlke

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

[Adam Thompson]

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

On Tue, Dec 23, 2014 at 05:17:43PM -0500, Karl Dahlke wrote:
> I forgot about some of the handler functions.
> Let me have a look and evaluate, and then I'll
> bat it back into your court.

Thanks, sounds good.

Also, from a design perspective,
it'd be nicer if the alert, prompt etc functions were done as part of the
protocol, letting edbrowse handle user interaction I think.
At the moment it's going to make future enhancements a bit awkward with the
server occasionally needing user input,
plus I don't see why this can't be done via ipc messages.
Any thoughts?

Cheers,
Adam.

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

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

[Adam Thompson]

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

On Tue, Dec 23, 2014 at 05:50:47PM -0500, Karl Dahlke wrote:
> > it'd be nicer if the alert, prompt etc functions were done as part of the
> > protocol, letting edbrowse handle user interaction I think.
> 
> Yeah I think so too, I was saving that for a future increment.

Yeah, it may be worth doing sooner than later though, if only to make debugging easier.
> > I don't see why this can't be done via ipc messages.
> 
> I may not know enough, but I don't think ipc messages play nice with
> select, looking toward the day when we must monitor
> many input streams at the same time,
> many events coming in from many sources.
> You can select on many file descriptors, as I do in my adapter and
> other programs, but I don't think you can select on 4 file
> descriptors and an ipc message queue.
> If I'm wrong, we can switch from pipes to messages in the future,
> if it makes sense to do so.
> Probably not a big difference either way.

I don't massively mind, and as for the select thing,
it kind of depends on how portable we want to be.
If we really want to be portable then no, the two don't play nice,
but on linux, according to the documentation, they will actually work together.
I'm not sure how this'd be too much of a problem though,
since each edbrowse will have it's own edbrowse-js (with associated message queue),
and each window within edbrowse (assuming we go down the process per window
route) would share the message queue to the edbrowse-js process I suspect.
We could also look at using the mq_notify function to make async operation a bit easier and avoid the need to poll the message queue descriptors.
Anyway, just thoughts on a future increment. Let's get what we have functioning first.

Cheers,
Adam.

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

[Edbrowse-dev] js engine process, version 1

[Karl Dahlke]

> it'd be nicer if the alert, prompt etc functions were done as part of the
> protocol, letting edbrowse handle user interaction I think.

Yeah I think so too, I was saving that for a future increment.

> I don't see why this can't be done via ipc messages.

I may not know enough, but I don't think ipc messages play nice with
select, looking toward the day when we must monitor
many input streams at the same time,
many events coming in from many sources.
You can select on many file descriptors, as I do in my adapter and
other programs, but I don't think you can select on 4 file
descriptors and an ipc message queue.
If I'm wrong, we can switch from pipes to messages in the future,
if it makes sense to do so.
Probably not a big difference either way.

Karl Dahlke

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

[Adam Thompson]

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

On Tue, Dec 23, 2014 at 02:50:00PM -0500, Karl Dahlke wrote:
> Adam offers:
> > I may have a go at plugging in the new code at some stage.
> 
> Let me know if you want to take a whack at it. That would be great.
> If not I may try it next week. Either is fine with me.

Ok, I've pushed a couple of commits to start this process.
Unfortunately currently this means things don't compile due to a couple of
missing handler functions which I'm not sure how to implement.

> struct tagInfo and htmlTag move back into eb.h.
> In fact we won't need js.h at all.

As did the associated enums.

> Once the vital declarations move from js.h into eb.h,
> change makefile so it doesn't refer to js.h or jsdom.cpp or jsloc.cpp.
> Nor does it need the mozilla headers or libraries,
> except for the target edbrowse-js, which builds properly today.

It only built properly because everything c++ had these libraries,
I've fixed that now.

> And include edbrowse-js under all:
Done.

> struct htmlTag has the member jv, javascript variable,
> which links this tag to the corresponding object in the js world.
> currently HeapRootedObject jv; needs to be jsobjtype jv;

Done, as well as changing a bunch of those in html.cpp.
Also had to change ->jss to ->jcx (or remove where appropriate) in buffers.c.
Wow this code got tangled up with the js stuff very quickly.
> Rename createJavaContext1 to createJavaContext in ebjs.c
> and similarly for freeJavaContext1.

Done.

> Remove the block at the top of ebjs.c that is there just for stand alone
> compilation.

Done (I think).

> Generate the prototypes for ebjs.c, I can do it with my tool if you like,
> and put them into eb.p.
> We won't need ebjs.p any more.

Done, and ebjs.p is no more.

> Many of these functions are plug in replacements for the old functions.
> get_property_string(object, name)
> it does what it did before.
> So I'm hoping it is an easy process from here.
> Put it all together and build the new edbrowse.

Got stuck on this one, see above note about the handler functions.

Cheers,
Adam.

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

[Edbrowse-dev] js engine process, version 1

[Karl Dahlke]

Adam offers:
> I may have a go at plugging in the new code at some stage.

Let me know if you want to take a whack at it. That would be great.
If not I may try it next week. Either is fine with me.

This is a roadmap.

struct tagInfo and htmlTag move back into eb.h.
In fact we won't need js.h at all.

Once the vital declarations move from js.h into eb.h,
change makefile so it doesn't refer to js.h or jsdom.cpp or jsloc.cpp.
Nor does it need the mozilla headers or libraries,
except for the target edbrowse-js, which builds properly today.
And include edbrowse-js under all:

struct htmlTag has the member jv, javascript variable,
which links this tag to the corresponding object in the js world.
currently HeapRootedObject jv; needs to be jsobjtype jv;

Rename createJavaContext1 to createJavaContext in ebjs.c
and similarly for freeJavaContext1.

Remove the block at the top of ebjs.c that is there just for stand alone
compilation.

Generate the prototypes for ebjs.c, I can do it with my tool if you like,
and put them into eb.p.
We won't need ebjs.p any more.

Many of these functions are plug in replacements for the old functions.
get_property_string(object, name)
it does what it did before.
So I'm hoping it is an easy process from here.
Put it all together and build the new edbrowse.

Make sure edbrowse-js is linked into your path, or edbrowse won't
be able to exec edbrowse-js - although you may want to test
that condition as well.

Lots of testing, websites, javascript, and of course exercising jsrt.

Once we have some confidence in the new architecture, delete js.h ebjs.p
jsdom.cpp jsloc.cpp.

Convert html.cpp back to html.c.
Sadly, there were a few times I used c++ strings in here, for convenience,
and I think you told me not to, and now I see why.
Switch these back to strings using my dynamic string management routines
in stringfile.c, then the file can go back to html.c

Change makefile flags and libraries so edbrowse is a C program again.

Globally replace eb_bool eb_true eb_false with bool true false,
and appropriate #defines in eb.h, as it was before.

3.5.3

Then we can take the next step and the next and the next.

Karl Dahlke

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

[Adam Thompson]

[-- 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 --]

[Edbrowse-dev] js engine process, version 1

[Karl Dahlke]

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.

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

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!

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.

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.

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.

Karl Dahlke