[Edbrowse-dev] duktape and jsrt

[Edbrowse-dev] duktape and jsrt

[Karl Dahlke]

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

1. As I've been working with duktape I'm feeling free, free from the nightmare of rooted strings and rooted objects and mutable handles in moz js, and if you don't get all of that right all of the time it could seg fault one time in 100, in a manner that is almost impossible to track down and fix.
I love duktape.
But ... if you're using pointers to objects in your c program and you want those pointers to be valid forever more,
(that's how we connect html tags to their javascript objects), you do have to realize a couple things.
The manual guarantees these pointers are valid if each object is always "connected", as far as garbage collection is concerned.
Connected can mean accessible from the window object in the usual way, or, on the duktape stack.
So here's something you can't do.
A native method f1 in C calls duktape to create a new object,
passes the pointer to this object back to a calling function f2,
and then f2, or some other function f3, links it into the tree under document.
When f1 returns, its piece of the duktape stack goes away,
and for a short moment you have a pointer to a disconnected object, an object that could move or go away.
I learned all this while chasing a bug, which was actually caused by something else, but it's still good to understand.
As it happens, we did everything right, at least I think we did.
Look at the functions in ebprot.h.
Example:  instantiate(parent, name, classname);
This function creates a new object from the class classname, and links it in under parent.name, all in one fell swoop.
The new object sits happily on the duktape stack, then is linked int the window tree, then the function returns.
Other functions are the same way.
instantiate_array_element(a, idx, classname);
Create the new object and linke it into a[idx] all as part of that one function, before we give up the duktape stack.
So maybe by sheer good fortune the API is right,
and that made the conversion way easier.
I don't think I changed the API at all. Sure didn't want to!!

2. There are some differences between the engines, and I'm dealing with them one by one.
See the last push for an example, if you're interested.

3. As the subject says, jsrt now passes with duktape.
No errors, and I interacted with the form, select, reset, submit, etc, and it seems to work properly.
But ... a lot of web pages in the wild still cause duktape to seg fault.
It's more fragile than mozilla, either that or I have to do more checking as we go, and use more protected calls.
I use the protected eval and the protected compile, for example.
More work to do here.

4. Maybe it's time for others to play with it and provide feedback, but just remember that js will fail on you.
You know I want to merge branches as soon as possible, so we're all working on the same beast again, but I don't want to recklessly merge too early.
In other words, we want to be pretty confident that duktape is our future.
After the merge it will be awfully difficult to go back to mozilla.
I don't know about v8 and others, but I'm hoping never to do this kind of conversion again.

5. Interwindow communication seems possible, based on just a few sentences from the programmers guide.
I currently create a heap for each edbrowse window, then a js context in that heap.
We should create one heap for all of edbrowse, then a context for each window, and then the manual says these contexts can talk to each other.
This is all for another day of course, but I like the warm fuzzy feeling that it's at least doable.

Cheers,

Karl Dahlke

Re: [Edbrowse-dev] duktape and jsrt

[Kevin Carhart]

Among these many interesting points number five caught my ear:

> 5. Interwindow communication seems possible, based on just a few sentences from the programmers guide.

Gee!  Are you referencing what I think you're referencing, namely 
communication between window.document and an iframe's 
contentWindow.contentDocument?  In other words, we have this pivotal 
utility function that is relied on by a lot of the tests in 
acid3.acidtests.org:

   function getTestDocument() {
     var iframe = document.getElementById("selectors");
     var doc = iframe.contentDocument;
     for (var i = doc.documentElement.childNodes.length-1; i >= 0; i -= 1)
       doc.documentElement.removeChild(doc.documentElement.childNodes[i]);
     doc.documentElement.appendChild(doc.createElement('head'));
     doc.documentElement.firstChild.appendChild(doc.createElement('title'));
     doc.documentElement.appendChild(doc.createElement('body'));
     return doc;
   }

And we had set it aside, so is this back on the table thanks to duktape?
If so, that's great.  If not, it sounds like duktape is great anyhow, and 
thank you for doing all of this work on porting.

Kevin

[Edbrowse-dev] duktape and jsrt

[Karl Dahlke]

> communication between window.document and an iframe's

Yes. But our duktape edbrowse marriage has to be pretty stable before we take that step.
Meantime you can still procede with your problem pages, dom improvements, etc,
but please do so on the duktape branch, as startwindow.js has been radically changed,
and you want to be working with the latest.

Karl Dahlke