From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 14D3577AD7 for ; Sun, 22 Dec 2013 11:11:22 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so4343474wgg.16 for ; Sun, 22 Dec 2013 11:11:19 -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=ZDJseN+kyjpAvYIr0qqpxcK48kR4weTI0cCjgVdOtzA=; b=0xeJGXN9ey344IwdvCKqDXUs9/rZylAZ29Y2xp+oSO1FfX1LCj27tC6A/gEA+id4gG IQLv7DwpvGKG9mAJ4HAJP91ZZpE4ecmDDzKIkcsrrZtVNPF7X1MYIDPfhTl0CilZxIoW 4lMCcjYfEbB9kNspT9dYjNa2PQP1rNMuhWbd818bfZiJjbrxw9d93nWHc3TIge6cyCpD BXI87IYk/PIT2mk5bLm0BOEuKqIdR82kbtif1dy7usOr2KERpxjBl1oTi2KDu3DNjD2z F06DqYUxCjPQo7WmIFvwG1T/L6APB+03EC+k8PN1/Ef+wqyp/e49P8kFZphTeOPKg28n oDHQ== X-Received: by 10.194.63.228 with SMTP id j4mr15686744wjs.34.1387739479632; Sun, 22 Dec 2013 11:11:19 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id fh2sm29548877wib.3.2013.12.22.11.11.18 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 22 Dec 2013 11:11:18 -0800 (PST) Date: Sun, 22 Dec 2013 19:10:49 +0000 From: Adam Thompson To: Chris Brannon Message-ID: <20131222191049.GA16257@toaster.adamthompson.me.uk> References: <20131118134511.eklhad@comcast.net> <52B5D75A.8020804@free.fr> <87sitkdh98.fsf@mushroom.PK5001Z> <20131222164813.GA12841@toaster.adamthompson.me.uk> <87lhzcd96f.fsf@mushroom.PK5001Z> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhzcd96f.fsf@mushroom.PK5001Z> 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: Sun, 22 Dec 2013 19:11:23 -0000 On Sun, Dec 22, 2013 at 10:36:56AM -0800, Chris Brannon wrote: > Adam Thompson writes: > > > "SpiderMonkey now provides a fully C++ interface, > > so embedders relying on embeddability in C projects will have to convert to > > C++, or implement their own adapter code." > > Thank you ever so much for doing the research. That's ok, I've been thinking of looking at this for a while, though it's not until now that I've had the time. > Years ago, we batted around the idea of rewriting edbrowse in C++. Yeah, I noticed it in the todo. > Those string objects would sure be nice, and after all, edbrowse is very > string-intensive. We also use lists in some places, and we could use > STL's list container instead. But it never happened. C++ is a > complicated beast. The people who work on edbrowse are more comfortable > with C. I used to be decent with C++, but I've managed to forget most > of what I knew. So I'm not chomping at the bit to do this. I also prefer working in C, but have been forced to become fairly decent in c++ in order to use certain c++-only libraries. Honestly, although the string objects would be nice in terms of moving code out of edbrowse, and the same for stl lists, personally I've never really minded handling this kind of thing in C. Also as you said c++ brings its own set of complications. > I wonder how difficult the adapter code will be? I assume it'll just be tedious. I've got an idea how to do it whilst hopefully minimising the changes. I think the main files to alter are jsdom.c and jsloc.c. I'd then provide a jsdom.h and jsloc.h (or something) which is included in the rest of the program. This, with a few more changes, should *hopefully* allow the c++ code to be isolated to these 2 files. In the makefile, these would then be built with the c++ compiler, with the rest of the project still built using the c compiler. This assumes of course that there aren't additional functions in other files which require bits of the javascript library. If so, they'd have to be added to the adapter api. This approach'd also have the nice side-effect that, if in the future we decide to abandon SpiderMonkey altogether, we'd only have to change the implementation of the api exposed to edbrowse. At least that's the theory. Does this sound sensible? Anything I've missed? Cheers, Adam.