From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 9815377AC0 for ; Mon, 23 Dec 2013 01:26:58 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so4740369wes.27 for ; Mon, 23 Dec 2013 01:26:51 -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=fr73PlvICzm5FolTC6A7iaUiLNO4h0UamH+Eubw4Zic=; b=FIDI0gAVmBPDDvcaCDLbkR6o+uab/z3/vBhCdUBlX/MKNkbS5nigTwhBBO/RMUTgN+ PQ6rKHh34hctGp6i4f4v/G1FXYqvSNP2juhls2kibk07YDuyhxePo+CPbSd5j9SRfuUM HGBjcXOkk3hSYByC4ubxRtAVeCXkM3YwNEPaCYKBy9W5bu/OJArNwUaTtdSNOhEMIxoC wQrSIR+I0NTZfAojT9ZBP7lV3G0SsfbNEiorbzzN0uiqdu68nD4JIbiYVfGgTBImAPeU 974DAZbYyci2HN66/9TgVIFdmPEY10GAL76HNyWem/XvWLD3a7bg+80UQW5XVOmawBAD lYqQ== X-Received: by 10.194.78.141 with SMTP id b13mr17250642wjx.32.1387790810569; Mon, 23 Dec 2013 01:26:50 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id fj8sm32797073wib.1.2013.12.23.01.26.45 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Dec 2013 01:26:49 -0800 (PST) Date: Mon, 23 Dec 2013 09:26:33 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20131223092633.GB16257@toaster.adamthompson.me.uk> References: <20131122172649.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131122172649.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Javascript support 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: Mon, 23 Dec 2013 09:26:59 -0000 Hi Karl, On Sun, Dec 22, 2013 at 05:26:49PM -0500, Karl Dahlke wrote: > It seems to me you are spot on, > assumingf we want to take a few expedient steps, > rather than a complete rewrite. > When I think about string operations a complete rewrite is really tempting, > but I know that would take to long. > Our friend over at debian is tapping his foot. Also, nice as string objects look, I've got a feeling that starting a rewrite in this direction is going to be a lot more complicated to do right than we're currently thinking. > At this point I have to pat myself on the back, at least a little, > since my design is based on encapsulation. > I built jsdom.c and jsloc.c as a layer between edbrowse and the js engine, > so that only these files need be touched. > The rest of edbrowse knows nothing about javascript. > So that's a couple thousand lines of code, not prohibitive. That was how I thought things worked, well done for designing things this way. > In fact, my original eb.h did not reference jsapi.h or anything javascript at all. > I used void * for blind pointers to pass around js related structures. > So an edbrowse buffer or context structure would contain a member > void *js > for all its javascript stuff, without knowing or caring what it meant. > The semantics were all in js*.c. > But at some point, and I don't remember when or why, > > #include > > was moved out of js*.c and into eb.h, so everyone could see > and possibly muck with the javascript api. > But still I don't think they do, not for the most part. > It just means we can refer to jscontext * instead of void *, > and the code is more readable, > yet still I think it is all encapsulated in js*.c. Ah ok. > > The quick way, if there is such a thing, > is to > cp jsdom.c jsdom.C > cp jslod.c jsloc.C > Making the endings capital C instead of small c. > Then call the c++ functions instead of the original functions. > We can do this before the upgrade, since moz185 has the c++ interface. > The new calls will likely return a pointer to an object, not a structure, > but object structure it's all the same. > I can't pass that around amonst the other c functions in edbrowse. > In other words, go back to void * as it was before. Agreed, though I'd probably use cpp as the file suffix and provide a js.h to isolate datatypes etc, which could then be included in eb.h perhaps. Also, this'd allow us to have a js * instead of a void * which pointed to all the js machinary (runtime, context etc). > Keep all the js headers and classes in js*.C, as it was before. > Then when you can compile > cc -c js*.C (that's capital C) > switch the Makefile over to use those files > and not the original js*.c, which we'll keep around for a while > until we know what we're doing. I'm not sure if we can do this without the upgrade though as I've got a feeling that they've slightly changed datatypes etc between versions. > > So the first step might be to see if we canpt put > > #include > > back into jsdom.c and jsloc.c, and out of eb.h as it once was. > Then make files with capital C instead of small c. > gcc does the right thing based on the suffix. Agreed with the exception of the file suffix. > Then access the new api, which is probably not radically different > from the old just creates objects and calls object methods instead of functions. I don't think it's too different, it's still sort of a C api, but now uses c++ stuff in the headers and underlying interface. > I might be oversimplifying this terribly, I really don't know. > I have bookmarked the documentation for all the smjs functions, > is this updated to reflect the new c++ interface? What urls have you got for them? > And finally the question is who has time for all this? > I don't know but I hope someone does, > edbrowse is too valuable to die on the vine. Agreed. > I might, depending on how my life goes, > but the first thing I have to do is learn c++, > which I have religiously avoided for 30 years. > Truly, for 30 years. I can understand that. If it wasn't for the fact that I needed to learn c++ as part of my university course (we were exposed to it in my 1st and 2nd years and I need it as one of the libraries I need for my masters project only provides a c++ api) I'd also have avoided it. > Maybe it's time. Perhaps, but I'd rather not get into the object oriented programming discussion here. > But if any of you know c++ better than me, which wouldn't be hard to do, > then you're a step ahead. I can have a go at making some of this work, but as I said, I'm currently in my final year of a university course so there's a possibility that my time may become seriously limited. Cheers, Adam. PS: what's the usual procedure for submitting patches?