Mozilla 2 platform status
Jason Orendorff
means.
So far it's just Benjamin Smedberg, Taras Glek, and myself, as far as
I know.
Here are the changes we've made or are working on...
1. The Mozilla 2 source lives in Mercurial, not CVS.
So if you want to work in the Mozilla 2 codebase, feel free! We don't
want
gratuitous differences between the Mozilla 2 repository and CVS trunk,
because
it complicates merging. But with Mercurial, you can commit whatever
changes
you want in your very own copy of the Mozilla 2 repository.
* The Mercurial repository already exists and has a few changes,
mostly
build stuff. I routinely merge all changes from CVS trunk to
Mercurial,
about once a week.
* The build process is a bit different. See
http://developer.mozilla.org/en/docs/Mozilla_2_build_documentation
* Active development is happening in the actionmonkey branch:
http://wiki.mozilla.org/JavaScript:ActionMonkey
2. Mozilla 2 will include the Tamarin JavaScript engine. (If you'd
like me
to go over the reasoning behind this change, please let me know--my
impression
is it's been beaten to death already.)
Here are the relevant details of my life:
* We'll retain JSAPI compatibility, for SpiderMonkey embedders, with
as few
changes as possible.
* SpiderMonkey optimizations and features will be merged into
Tamarin as we
go.
* Tamarin's garbage collector isn't thread-safe. I'm working on a
patch to
add a build-time MMGC_THREADSAFE option. We'll see what the
performance
penalty is.
3. Benjamin Smedberg and Taras Glek are experimenting with making
all XPCOM objects garbage-collected:
http://wiki.mozilla.org/XPCOMGC
They are working on some patches so we can see what effect it
would have on memory footprint and speed. By the way, they're
using Taras's awesome patch-generating tools to automate the
changes, since it's a rather large change. Really cool stuff,
Benjamin's blog entry here is just the tip of the iceberg:
http://benjamin.smedbergs.us/blog/2007-10-11/dehydra-ftw/
Comments welcome. We often hang out in the #mmgc channel on
irc.mozilla.org.
Cheers,
-j
Jean-Marc Desperrier
> [...] they're
> using Taras's awesome patch-generating tools to automate the
> changes, since it's a rather large change. Really cool stuff,
> Benjamin's blog entry here is just the tip of the iceberg:
>
> http://benjamin.smedbergs.us/blog/2007-10-11/dehydra-ftw/
It really looks awesome. I'm sure lot of people are eager to play with
it, but the blog entry is indeed just the tip of the iceberg, and the
rest doesn't seem really accessible yet ? Don't start talking about
something like that if you're not ready to release :-) !!
I think the Eclipse CDT team should take a look at it, their product
really needs something like that to get up to par with Eclipse/java.
Jason Orendorff
> Jason Orendorff wrote:
> > http://benjamin.smedbergs.us/blog/2007-10-11/dehydra-ftw/
>
> It really looks awesome. I'm sure lot of people are eager to play with
> it, but the blog entry is indeed just the tip of the iceberg, and the
> rest doesn't seem really accessible yet ? Don't start talking about
> something like that if you're not ready to release :-) !!
I wouldn't say it's ready to release, but that doesn't mean it's
not accessible yet:
http://wiki.mozilla.org/Static_Analysis/Installing_the_Oink_Stack
Bring your own duct tape. If you aren't running Fedora Core Linux,
you'll have to figure out how to get libjs and its headers. It might
be easiest to build libjs from source:
http://developer.mozilla.org/en/docs/SpiderMonkey_Build_Documentation
This is where the duct tape comes in--you'll need to apply it to
one or more Makefiles to get stuff working. Good luck!
-j
rocal...@gmail.com
> I think the Eclipse CDT team should take a look at it, their product
> really needs something like that to get up to par with Eclipse/java.
The CDT people already have their own infrastructure, which is quite
good for their needs.
C++ tools will never catch up to Java tools; the Java context is much
easier to work in.
Rob