[Edbrowse-dev] Javascript support

[Edbrowse-dev] Javascript support

[Karl Dahlke]

Hi Adam and all.
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.

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.

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 <jsapi.h>

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.

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.
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.

So the first step might be to see if we canpt put

#include <jsapi.h>

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.
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 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?

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.
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.
Maybe it's time.
But if any of you know c++ better than me, which wouldn't be hard to do,
then you're a step ahead.

Karl Dahlke

Re: [Edbrowse-dev] Javascript support

[Adam Thompson]

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 <jsapi.h>
> 
> 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 <jsapi.h>
> 
> 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?

Re: [Edbrowse-dev] Javascript support

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> PS: what's the usual procedure for submitting patches?

How familiar are you with git?  If you aren't, I'll write up a
long-winded explanation.  Here's the short form.
Use git send-email to send your patches to this list.
You might want to run the following from the root of your edbrowse
repository:
git config --replace sendemail.to 'edbrowse-dev@lists.the-brannons.com'
If you don't know git, I'll do a walkthrough of submitting a patch.

Also, please insure that your code is formatted with tools/ebindent from
the edbrowse repo, just to be consistent with the rest of the codebase.

Re: [Edbrowse-dev] Javascript support

[Adam Thompson]

On Mon, Dec 23, 2013 at 06:26:49AM -0800, Chris Brannon wrote:
> How familiar are you with git?  If you aren't, I'll write up a
> long-winded explanation.  Here's the short form.
> Use git send-email to send your patches to this list.
> You might want to run the following from the root of your edbrowse
> repository:
> git config --replace sendemail.to 'edbrowse-dev@lists.the-brannons.com'

I'm not massively familiar with git,
but I do know distributed version control and how to commit changes to my local repository.
Thanks for the tip about git config though, that's a git thing which I was not aware of.
> Also, please insure that your code is formatted with tools/ebindent from
> the edbrowse repo, just to be consistent with the rest of the codebase.

I'll try. As long as there's not too much c++ weirdness in the code, indent
should cope relatively well I think.

Cheers,
Adam.

Re: [Edbrowse-dev] Javascript support

[Adam Thompson]

Hi,

On Sat, Dec 21, 2013 at 07:00:58PM +0100, MENGUAL Jean-Philippe wrote:
> Can you tell me if some plan exist to enable edbrowse to support
> Javascript from libmozjs version 26? So far, it seems the libmozjs
> on the base on which edbrowse builds has build failures and runtime
> issues. It is a safety problem. Do you have some guidelines in this
> matter?

I've been working on getting edbrowse built against a new libmozjs,
but couldn't find the 26 sources. I have, however,
got a version which builds against mozjs 24 (the latest version from the website).

Attempting to build against the experimental libmozjs26d package in Debian
yielded the problem that the jsapi.h under /usr/include/mozjs is a broken
symlink to something in /tmp (I don't know the exact path off the top of my
head, but can re-install the relevant dev package if this isn't already a reported bug).
This problem is present in both the i386 and amd64 packages.
In addition, although the altered version of edbrowse builds against a version
of mozjs 24 I compiled (using the --enable-optimize and --disable-debug
configure options), building against the debian supplied libmozjs24d package
causes the program to segfault. Could you please tell me what the correct
options are to compile a mozjs 24 as per the debian package so I can check if
this is an edbrowse issue or something in the Debian package?

Cheers,
Adam.

[Edbrowse-dev] Javascript support

[Karl Dahlke]

> Agreed, though I'd probably use cpp as the file suffix
> and provide a js.h to isolate datatypes etc,


Yes to both. I forgot about the cpp suffix.

URLs

This one is out of date, obviously,
but you may be able to back up a directory and find source
for the various versions of sm js.
I use to build from source, before it was routinely bundled
in linux distros.

ftp://ftp.mozilla.org/pub/mozilla.org/js/js-1.5.tar.gz

Documentation on the web here.

http://developer.mozilla.org/en/docs/Category:JSAPI_Reference

But that brings up another question ...
in the short run, just to keep things alive,
what if we built a static library libmoz185.a from its source,
put that binary in the edbrowse project,
and made a linked version of edbrowse with that.
That is not a long term solution, but it might keep debian going for a while.
I would have to ask Jean what he thought of this idea.
Course it would be better to go forward with jsdom.cpp and jsloc.cpp.

Those are new files so you could work on those locally,
and when they are ready for beta test we'll add them to the project.

Other patches that lay the foundation for this work,
such as js.h or changes to eb.h,
should be sent to me and Chris.
eklhad@comcast.net
chris@the-brannons.com
Chris is the maintainer of edbrowse at this time.

Thanks for all your hard work.

Karl Dahlke

Re: [Edbrowse-dev] Javascript support

[Adam Thompson]

On Sun, Dec 22, 2013 at 10:36:56AM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> 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.

Re: [Edbrowse-dev] Javascript support

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> 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."

Hi,
Thank you ever so much for doing the research.

Years ago, we batted around the idea of rewriting edbrowse in C++.
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 wonder
how difficult the adapter code will be?  I assume it'll just be tedious.

Happy Holidays,
-- Chris

Re: [Edbrowse-dev] Javascript support

[Adam Thompson]

Hi,
On Sun, Dec 22, 2013 at 07:42:27AM -0800, Chris Brannon wrote:
> MENGUAL Jean-Philippe <mengualjeanphi@free.fr> writes:
> >
> > Can you tell me if some plan exist to enable edbrowse to support
> > Javascript from libmozjs version 26?
> 
> Hi.  I don't know anything about libmozjs version 26, but I'll look into
> it.  It isn't even packaged for my distro though.  Any idea what is
> needed to build with it?

According to the mozilla website the most recent version is version 24 [1].
My initial investigations into building edbrowse against this yielded this
quote from the mozilla website [2]:
"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."

This, along with my initial attempts to build the current edbrowse with g++
indicate that this is probably not going to be a small change unless we
implement our own "adapter code" to interface with the engine and even then I
suspect there'll be quite a lot of work involved.

It's a good point about the old version of the engine used by edbrowse though,
on Debian it's built (I believe) against version 1.85 which is seriously old now.

For what it's worth my thoughts on this are:
- it's going to be a lot of work to switch to the new mozilla engine
- we probably should switch to something newer than the current SpiderMonkey version
for security reasons as well as supporting newer javascript language features
- I've yet to find a javascript engine which is both mature and provides a pure
C api (or anything which'd compile with a C compiler)
- we shouldn't go back to a hand-made javascript engine

I don't have a massive amount of time (due to university work)
but I may be able to help with development as I've done quite a bit of C and C++.

Cheers,
Adam.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey
[2] https://developer.mozilla.org/en-US/docs/SpiderMonkey/24

Re: [Edbrowse-dev] Javascript support

[Chris Brannon]

MENGUAL Jean-Philippe <mengualjeanphi@free.fr> writes:
>
> Can you tell me if some plan exist to enable edbrowse to support
> Javascript from libmozjs version 26?

Hi.  I don't know anything about libmozjs version 26, but I'll look into
it.  It isn't even packaged for my distro though.  Any idea what is
needed to build with it?

-- Chris

[Edbrowse-dev] Javascript support

[MENGUAL Jean-Philippe]

hi.


Can you tell me if some plan exist to enable edbrowse to support 
Javascript from libmozjs version 26? So far, it seems the libmozjs on 
the base on which edbrowse builds has build failures and runtime issues. 
It is a safety problem. Do you have some guidelines in this matter?

Regards,