Open GoogleCodeExporter opened 9 years ago
JavaScript 1.8.0.x porting has begun for 9.0.4. If this is successful, we'll
advance
incrementally.
Original comment by classi...@floodgap.com
on 18 Jul 2009 at 3:27
Holding further progress on this (we're actually selecting from *Mozilla* 1.8,
which
is actually JavaScript 1.6) as it seems some of the bugs that were allegedly to
be
fixed are actually DOM issues. However, we will increase the memory runtime for
9.0.4
to see if things like JQuery can work (I get out of memory errors for those).
Original comment by classi...@floodgap.com
on 8 Aug 2009 at 5:20
Increasing runtime did NOT help. This is an interpreter issue. Officially
pushing
JavaScript interpreter change to 9.0.5 series with target for 9.1. DOM changes
will
still land in 9.0.4.
Original comment by classi...@floodgap.com
on 12 Aug 2009 at 5:25
For 9.0.4, some of the syntactic changes in Mozilla 1.7/1.8's parser were
backported
to JS1.5 pending the full upgrade sequence. This gets a lot more sites parsing.
The
missing functionality for these sites is probably still DOM gaps.
Original comment by classi...@floodgap.com
on 23 Aug 2009 at 8:03
Several things we cannot solve with merely parser updates:
- JS_markGCthing crashes in multiple and inexplicably complicated ways (twitpic)
- recursion overload (aolmail comes to mind)
- regex object methods (gmail)
When 9.0.4 ships, we should immediately do a pullup to the highest available Moz
1.8.x for 9.0.5. 1.9 might be 9.0.6.
Original comment by classi...@floodgap.com
on 15 Sep 2009 at 5:19
Summary change
Original comment by classi...@floodgap.com
on 25 Feb 2010 at 6:13
Using as a tracker for the new JavaScript for 9.2. This is a must.
The target is Fx 3.6 (Moz 1.9.2). Getting the JSON methods would be a win too.
If
not, Camino 1.6.11 (Moz 1.8.1.23), which at least gets us to JavaScript 1.7.
Original comment by classi...@floodgap.com
on 7 Apr 2010 at 1:16
The first step is porting all the Metrowerks and classic Mac-specific changes.
These
touch:
% cd mozilla/js
% grep -lr XP_MAC * | grep '\.[ch]'
jsd/jsd_java.c
jsd/jsdstubs.c
src/fdlibm/k_standard.c
src/js.c
src/jsbool.c
src/jscpucfg.c
src/jscpucfg.h
src/jsfile.c
src/jsinterp.c
src/jsmath.c
src/jsobj.c
src/jsosdep.h
src/jsotypes.h
src/jsregexp.c
src/jstypes.h
src/jsutil.c
src/liveconnect/jsj.c
src/liveconnect/jsj_convert.c
src/liveconnect/jsj_hash.c
src/liveconnect/jsj_JSObject.c
src/liveconnect/jsj_private.h
src/liveconnect/jsj_simpleapi.c
src/prmjtime.c
src/xpconnect/loader/mozJSComponentLoader.cpp
src/xpconnect/shell/xpcshell.cpp
% grep -lr MWERKS * | grep '\.[ch]'
src/jscpucfg.c
src/jsdate.c
src/jslibmath.h
src/jsnum.c
src/jstypes.h
Original comment by classi...@floodgap.com
on 11 Apr 2010 at 11:23
Initial survey complete. In addition to the diffs that will be needed,
##################################
### FILES THAT ARE BEING ADDED ###
##################################
jsdtracef.c and jsdtracef.h
no obvious problems. this IS called by jsinterp.c so we must use them
jsinvoke.c
I'm not sure what this is; it just #includes jsinterp.c.
Skip it?
jsiter.c and jsiter.h
we do NOT need jskwgen.c
jsxml.c and jsxml.h
############################################
### FILES TO MOVE INTO THE LEGACY FOLDER ###
############################################
jsosdep.h (may merge into jscpucfg.h)
Also,
general notes:
use jsconfig.h to control what features we import if some don't work.
make sure to get all *.tbl and *.msg files; they are usually included. There
are several.
Changes in the API:
JS_Init(mem) should be changed to JS_NewRuntime(mem)
The API recommendation is 0x400000L for the init, but it seems like Firefox
goes even
bigger.
When shutting down, change JS_Finish(rt) to:
JS_DestroyRuntime(rt)
followed by JS_ShutDown() // Finish did both roles
We also need to largely port back prjmtime.c -- most of that is very custom
code for
classic Mac. I am not going to update js.c if I can possibly avoid it.
Original comment by classi...@floodgap.com
on 22 Apr 2010 at 4:05
This at least gets us to the default SpiderMonkey implementation without
TraceMonkey.
It might be worth doing that first to find any glitches there, make a save
point, and
then try to jump to TraceMonkey. I have some concerns about whether the PPC
nanojit
will compile, let alone operate, so it will be best to stick with the pure C
implementation first.
diff to http://mxr.mozilla.org/mozilla1.9.2/source/js/src/
after.
Original comment by classi...@floodgap.com
on 22 Apr 2010 at 1:28
... and make sure we obey
https://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide
Original comment by classi...@floodgap.com
on 22 Apr 2010 at 1:31
Flipped the switch on SpiderMonkey tonight. Still have a lot of problems with
jQuery
sites, including jquery.org itself (need to get the uncompressed version and do
some
testing in Venkman). However, SunSpider runtime is already under 16000ms, and
eBay
and NYT now work! I think we'll do some serious study of TraceMonkey at this
point
and then determine our next move.
Original comment by classi...@floodgap.com
on 25 Apr 2010 at 4:30
The key problems to overcome will be namespaces, which it appears CW 7.1 *does*
support, and code generation, which is currently written only for GCC in the PPC
nanojit. Also, the entire codebase must be converted to C++, although much of
that is
still the same code.
On the other hand, we also get native JSON and some other nice things, so this
is
definitely worth trying. If we get nowhere, we revert and simply use regular
SpiderMonkey.
Original comment by classi...@floodgap.com
on 26 Apr 2010 at 2:04
TraceMonkey is already a failure. The rdtsc emulation code uses mftb/mftbu, and
I
don't think mfrtcl/mfrtcu is going to be an adequate substitute for 601.
More to the point, the code generator heavily relies on the gcc assembler
syntax and
I could not translate it. As written I don't think it's arbitrarily
translatable to
CodeWarrior in any manner -- it would need a full rewrite and I don't think I'm
up to
that challenge.
We will stick with SpiderMonkey for 9.2 though I would sure love native JSON. I
might
see if I can add that.
Original comment by classi...@floodgap.com
on 26 Apr 2010 at 3:53
Comparison with MXR shows that we are now running the same engine as Firefox
3.0.19.
This is a huge leap forward.
Original comment by classi...@floodgap.com
on 17 May 2010 at 6:48
No new problems have been found; they are all DOM. I am holding this bug over
for the
TraceMonkey conversion which I want to do around 9.4.
Original comment by classi...@floodgap.com
on 17 May 2010 at 11:28
Original issue reported on code.google.com by
classi...@floodgap.com
on 27 May 2009 at 1:15