From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) by hurricane.the-brannons.com (Postfix) with ESMTPS id A9F51791FB for ; Thu, 13 Jul 2017 15:02:45 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id VmCGd4UuimRfdVmCtdVz7l; Thu, 13 Jul 2017 22:03:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499983415; bh=Ribimfqu0/nF7gc6n/W1yK6Yar1cjTFDGihbS9zfy6I=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=YHDSh0/sASEb/ZDjzS4E0nwonG0sXcj4LuQQz0Ar3vYvFAbTagcDbgJ23yngOKtzR /cj/GjoetEIq3KKbMXhqMhLcjwV4ChfFuKJ8VApfT3MnBAvOY7x+jKWFjJDHitTr3w FzwNdpvVeUMqWgbsCYAi3SAhGjhUNt/Z9+Od1aI0HMAm9a/JUjWa1WM1iDQODvO+/v dN6DO7ZoNuB3GEPKn0J/4S9n8pvPmGxWytXj+QMVvCPsw9CukV7zuF9nW8q73Ff5kT +y/XgJ8PxF3bOxSzLmEeEwWQkfpG1+d/3MKwpszB07RWUVkK4NVor+PcKnYfwnDqg+ Ly5Xw2S1YrRbQ== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-09v.sys.comcast.net with SMTP id VmCtdouzWqjGuVmCtdkAEZ; Thu, 13 Jul 2017 22:03:35 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.6.3+ Date: Thu, 13 Jul 2017 18:03:34 -0400 Message-ID: <20170613180334.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-112904 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEK5/UZ8kA+0h51/n+TCXCSx/xGOjMglltNAeQ5xjlehio+EGmBuvagbVzKZzJuhUZhRJ0NdjkA8pdUFBOtCRlNu5rQrhnJm9ZQZdjUZ+I8RDhHJavAA Od5sYmtDO/Ee9CCNUAP2Qcx62XxeSf9z8EpZvyj0G00rp3rYdIs6g+7i Subject: [Edbrowse-dev] duktape and jsrt X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 22:02:45 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-112904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 --nextpart-eb-112904--