From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by hurricane.the-brannons.com (Postfix) with ESMTPS id C176B77AAF for ; Sun, 5 Jan 2014 09:01:41 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bz8so2028463wib.17 for ; Sun, 05 Jan 2014 09:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=q7EpWyQH6zmCz7Y7+f/8QOodt9GXNbLEmDko5Fo+4tA=; b=u3mvYK15igeuGZBGeX3zD4uJ+wkihcgWxlV58eF62cimafS65ijkjFFVC80fPElJEG dvfSQKMoafbOZJRzR2CUwMtT9iMJ141VVXI5cCEC4KzD7UZwnfLuNnqQs2454LcWSegC GaYwCztKeUkDFN+TrNVday9blO24iq3aLmvGdxDTAAMZb8qjE1vYS13/q0x8DnmyHh+R nRSWgPiFYgI34LTFM/iSVb7qjtnn0E/oxCj0ZgBJeMh9sQTtcDW2Bri+8UntrOULr/Mn Cs/QieRtyzyIYUgHWvveJ0GmlM231ru2U8+32UYB0plGCHz5WA73iSmCwXbc3zEGHPMv WuCQ== X-Received: by 10.194.241.228 with SMTP id wl4mr69262273wjc.2.1388941288804; Sun, 05 Jan 2014 09:01:28 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id bc5sm13484293wib.4.2014.01.05.09.01.27 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 05 Jan 2014 09:01:27 -0800 (PST) Date: Sun, 5 Jan 2014 17:01:25 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140105170125.GE11201@toaster.adamthompson.me.uk> References: <20140005103426.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140005103426.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Maybe do more with strings, maybe do everything with strings X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2014 17:01:42 -0000 On Sun, Jan 05, 2014 at 10:34:26AM -0500, Karl Dahlke wrote: > When I first create the js runtime context, > and when I first create a window to go with the html page, > there are quite a few variables and functions that I set up within js itself, > only because it was easier to do it that way. > Look for the word initScript in jsdom.c. > And I likely could have put more stuff in there. Yeah I noticed that. > This raises some questions. > > Are all the variables and functions that I made in that manner > protected from gc? Yes as they're all attached to some sort of variable thus there's a reference to them within the js world. > Is that a method that works? Yes, in fact I think (haven't looked through the smjs source too closely) that SpiderMonkey does something similar in places. > > Could it be used more often, and would that be easier and safer, > mostly safer, than what we are doing now? > > Example: the function establish_property_string, which puts a string beneath > an object. > This is in jsloc.c. > What if it looked like this instead. > > establish_property_string(const char *this_obj, const char *name, const char *value) > > this_obj is the full name of the object, > "document.forms.foo.bar" > name and value are as they are today. > The function is then a silly wrapper. > > { > char delim = '"'; // string delimiter > // you may need to switch delim to '\'' if value contains quotes. > // If value contains both quotes and apostrophes I'm not sure what to do. > string smallScript =this_obj + "." + name + " = " + > delim + valu + delim; > JS_EvaluateScript(jcx, jwin, smallScript, > "establish_property_string", 1, &rval); > } > > That last line being replaced with whatever the new call is to > run the js engine on a string. > > Looks easy; easier than what we're doing - > except we would have to maintain string pointers instead of object pointers, > even outside of js*.c, > possibly changing stuff in other files. > Might be worth stepping back a bit and see if this is a better approach. > It would almost surely be safer once complete, > since everything is done in their world, playing by their rules. Maybe but there'll be some things we couldn't do, and as long as we correctly use the GC api everything *should* be fine. It's just going to take a bit more rewriting to use the GC correctly. Basicly I'd try and keep things in native code as otherwise we end up with many c -> javascript -> c switches which is going to become a real pain. It's just a case of working out how to properly encapsulate this c++ stuff from the C code whilst playing nicely with the GC. Also, do you know why the javascript context creation code is ran even when js is disabled? I only noticed this when testing my version of edbrowse as I wanted to check if I'd inadvertantly broken something somewhere else in all the git fun we were having so I tried browsing a page I know contains no javascript with javascript disabled and it still segfaulted in the javaCreatesContext function. Surely, if javascript is disabled it shouldn't need to create the context at all? Cheers, Adam.