4:30 a.m.
On Wed, 04 Jul 2012 01:23:04 +0200, Ole wrote:
The JS_FS_ etc. macros were already in my patch. I guess they
didn't
made it into the repository
because there wasn't an additional #ifdef JS_VERSION <= 170
So, it's maybe worth a second try.
I'll let you handle that :)
So, finally I want to suggest that you also try to compile 1.7, it
would be better if we both
use the same "old" version. 1.7 should be easy to port. At least as
easy as 1.5. Then
we don't have to figure out difference between 1.5 and 1.7...
I'll give it a try when I get time - might not be for a couple of
weeks though. Unfortunately it wasn't me who ported 1.5 so I'm not
exactly wure what was changed to get it to work.
Is there anyone with big-endian and working spidermonkey 1.8
jsconsole?
I do not have problems when running
scripts directly, just when starting up the interactive jsconsole. It
happens during JS_NewObjectWithPrototype.
I get a crash with my Spidermonkey 1.8.5 library, but I didn't build
the console so I haven't tried that. A newer version is included with
Timberwolf (I'm trying to get hold of the includes, but it has a lot
of dependencies so I'm not sure whether it is a good idea anyway),
that doesn't have the standalone console either, but the library
works.
I think my 1.8.5 problem is because it's trying to use JIT even though
I (tried to) disable it.
Chris
6:36 p.m.
New subject: JavaScript
<snip>
> So, finally I want to suggest that you also try to compile 1.7,
it
> would be better if we both
> use the same "old" version. 1.7 should be easy to port. At least as
> easy as 1.5. Then
> we don't have to figure out difference between 1.5 and 1.7...
I'll give it a try when I get time - might not be for a couple of
weeks though. Unfortunately it wasn't me who ported 1.5 so I'm not
exactly wure what was changed to get it to work.
From a recent commit looks like you moved up to 1.7. Just a quick
query, does 1.7 not include jsversion.h when you pull in mozjs/js.h
because you seem to be overriding JS_VERSION and if teh library sets
it for you that would seem counterproductive.
I have not yet merged any of the pre 1.8.0 version jsapi.h macro
changes as I beleive as I continue to add functionality I will be
breaking them :-/ As an observation I do not have easy development
acess to library version other than 1.8.0 and 1.8.5
And just in case you had not twigged what the mozilla guys were up to,
basically the method calls have been altered 1.7 -> 1.8.0 -> 1.8.5 to
make them consistant in signature with the property callbacks.
To do this they introduced the JS_* macros but certianly in 1.8.0
these appear to not work properly for native calls which is why i
introduced our own JSAPI wrappers which attempt to use macro magic to
make the netsurf jsapi code version agnoisic.
Hope some of this helps.
--
Regards Vincent
http://www.kyllikki.org/
10:42 p.m.
New subject: JavaScript
On Sat, 7 Jul 2012 10:36:06 +0100, Vincent Sanders wrote:
From a recent commit looks like you moved up to 1.7.
I had a bit of time and it didn't take anywhere near as long as I was
expecting. This should make things easier with me and Ole using the
same version.
Just a quick
query, does 1.7 not include jsversion.h when you pull in mozjs/js.h
because you seem to be overriding JS_VERSION and if teh library sets
it for you that would seem counterproductive.
It's there, but when I was using 1.5 I found that it was ignoring the
JS_VERSION <= 180 #ifdefs unless I also put it in manually. I haven't
actually checked whether this is still necessary.
I have not yet merged any of the pre 1.8.0 version jsapi.h macro
changes as I beleive as I continue to add functionality I will be
breaking them :-/
Probably sensible!
The following will need fixing:
JS_THIS_OBJECT calls JS_ComputeThis() which doesn't exist in 1.7. Not
sure what the solution to this is, it might involve passing our
JSObject pointer around in JAPI_NATIVE.
In the same revision, hubbub/libdom/NetSurf (not sure which - hubbub
is the last point on the stack trace, but before I started trying to
fix it I was getting an extra libdom call after it) is running
off into NULL pointer territory if Javascript is enabled (with my
homepage as http://www.google.co.uk). It might just be I've missed
something when updating the libraries and recompiling them (I'm having
to update them manually as I don't have a native Git client - which is
an utter PITA - and cross-compiling the libraries didn't work when I
tried it) or it might be something the script on www.google.co.uk is
doing. I'll try a different start page, forgot to do that before.
As an observation I do not have easy development
acess to library version other than 1.8.0 and 1.8.5
Ole seems to be on top of fixing it up to work on 1.7 (and clearly
knows much more about Spidermonkey than me - which isn't hard tbh).
We can both test it so it's not a major problem if you can't.
Hope some of this helps.
Yes, thanks.
Chris
1:17 a.m.
New subject: JavaScript
> I have not yet merged any of the pre 1.8.0 version jsapi.h macro
> changes as I beleive as I continue to add functionality I will be
> breaking them :-/
I have no problems with version 1.7 - no crashes or such.
Are you using my spidermonkey-1.7 branch? It's not in sync with
the master so you need pull in commits of the master.
AFAIK JS_VERSION isn't defined by any of the jsapi <= 1.7 includes.
spidermonkey >= 1.8 defines JSVERSION_LATEST, which is probably
used to define JS_VERSION.
With spidermonkey <= 1.7 you have to define JS_VERSION in the
OS_CONFIG file. I don't know if these flags are saved in some header
file. I pass JS_VERSION manually to programs that get linked against
libsjs and need the macro.
About the missing merges:
personally I would vote for merging the changes as soon as possible
into master.
This will ease the "maintainers" of the spidermonkey-1.7-support
tree to track new commits. Otherwise the diffs will get
larger and larger...
If there is really now way to integrate the branch "soon",
then it looks like we have (the need for) an fork,
and I don't know if I want to care about such fork,
because it means to pull in master commits into the fork within time.
Personally I don't think it's a good idea that the branches will drift
away from each other....
Greets,
Ole
1:27 a.m.
New subject: JavaScript
On Sat, Jul 07, 2012 at 06:17:12PM +0200, m0n0 wrote:
This will ease the "maintainers" of the
spidermonkey-1.7-support
tree to track new commits. Otherwise the diffs will get
larger and larger...
If there is really now way to integrate the branch "soon",
then it looks like we have (the need for) an fork,
and I don't know if I want to care about such fork,
because it means to pull in master commits into the fork within time.
Criss-Cross merging in git is cheap and easy and I'd suggest you try it. If I
were the spidermonkey-1.7 branch maintainer I would be regularly merging master
into my branch (or rebasing my branch on top of new master) so that I could
test against changes made in master and ensure that my patches apply cleanly.
Otherwise when it comes to merging to master, the maintainer of that section
(Vincent) will find it hard to merge the code and thus will be less likely to
take it.
It is the job of the branch owner to make sure their branch is mergeable with
master if they actively expect it to be merged.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
4097
days inactive
4100
days old
netsurf-dev@netsurf-browser.org
4 comments
4 participants
participants (4)
-
Chris Young -
Daniel Silverstone -
m0n0 -
Vincent Sanders