Abacus 0.1.1 is broken in recent Mozilla builds. Sometime in the last six months, there was an upgrade to Mozilla's XML parsing. The upgrade, thanks to some not-quite-sane sanity checking I did for 0.1.1, caused Abacus to hang Mozilla in an endless JavaScript loop.
Oops.
I've fixed that in my local Abacus, and with another fix to JSLib I've posted a patch for, Abacus 0.1.2 should be available soon. No new features, just making it work again. (Really, it's ready now, but I want to upload it directly to mozdev, not here.)
Then I'll start work on Abacus 0.1.3, which will be a bit streamlined and support much more MathML.
(1) http://jslib.mozdev.org/source.html for getting source code (2) set MOZ_DIST=(path_to_mozilla_build)/dist/bin (3) cd jslib (4) sh configure (5) make
That's it. If you've built Mozilla, you can build JSLib.
Interestingly, the build process doesn't install JSLib into Mozilla. I think that's generally wise, but I can see some people expecting it automatically installing in chrome.
It's the easiest build I've ever done of anything. Now, if I can get some decent tests for the various modules of JSLib, I can start putting together a "stable" JSLib. jslib/tests seems to have only a few tests of the io module...
Would anyone care to write some? I'll be more than happy to provide a basic test harness, including code that can expect exceptions. So, if you want to write a test that you know should throw a particular exception, go for it. (Just please don't use Venkman at the same time.)
If I do get a stable JSLib, I'll offer it to MozDevGroup. If they post it, great. If not, I'll offer it here.
For the record, I'm willing to volunteer as a MozDev Bugzilla admin, just to shut down incidents like this one. I'm on at all sorts of odd hours anyway.
A lot of people tonight have received bugspam thanks to a gracious QA person who decided to mark a bunch of bugs fixed without consulting the people who make these extensions, and without consulting the people who actually report these bugs honestly and wisely.
I know the Mozilla b.m.o QA's struggle to keep up with the deluge, and on the whole they do a good job. I anticipate (expect would be too strong a word, as it sounds like "demand") at least one member of the MozDev staff will be apologizing for this happening and no one catching it.
I'm personally not mad at MozDev. They're being gracious by offering to host our projects, including a fair amount of stagnating code I have to offer. This is just growing pains. MozDev people have lives too, and as far as I know, they're a lot smaller group, financially and physically, than even the Mozilla Foundation. They have been for years.
I think MozDev is more important than most of us realize. Including some of the people in MozDev Group. My only real beef with them is that they're a bit insular, that it's hard to get a response that leads to better code, faster, or even a "Yeah, that's a great idea, go ahead and submit something and we'll put it up." I griped a few days ago about JSLib holding me back, and that didn't go anywhere serious.
Oh, well. Like I said, this is just growing pains.
But I sure would like to have some sharp words for whoever's doing this wonderful QA work.
UPDATE: And for the people who decided to be oh, so helpful in telling people how to back out these changes, and the same people who decided to give me and the other contributors a second tsunami of bugspam. Thank you for using your common sense, although you're doing something that's almost as bad.
I know you have the best intentions at heart, and this is going to make you a little mad. Sorry.
MozillaZine is running a story about K-Meleon 0.9 being released. It didn't take people very long to compare it to Mozilla Firefox 1.0.
That said, I'd really like some in-depth reviews of each product against the other. Maybe one of them has features that the other could implement.
Please, no "they suck, use this" comments. :) I'm actually not biased either way. I've had good and bad experiences from both Firefox and K-Meleon in the past.
UPDATE: I just spotted an article on PCMag about what essentially adds up to overclocking Mozilla Firefox. Note I don't necessarily approve of this idea (I don't care for overclocking anything I have), but I hadn't seen it on planet yet. So I wanted to get some feedback from the mozilla.org community on it.
Use at your own risk! If you file a bug at Bugzilla that can't be reproduced from a normally-configured Firefox, but is reproducible from an overclocked one, don't be surprised if someone (not me) marks it INVALID.
I have no idea if it works on K-Meleon, and I'm not that enthusiastic to find out.
From the head honcho's mouth, so to speak. Thanks to Slashdot for the link. The big revelations for us are at the bottom of page 2 and the start of page 3.
So things weren't quite as sinister at the time as we thought.
I'd really like to do some Abacus development. I just picked up Mozilla 1.8a6 (thank you, Asa & crew), went to install the prerequisite jslib library, then Abacus 0.1.1 so I could go back and fix some bugs. I then restarted Mozilla, and ran through the steps to start Abacus.
It didn't work.
jslib_current_static.xpi is what I usually use. I figure that seems a bit more stable than the cutting-edge jslib-current.xpi. As of a couple weeks ago, it wouldn't install. Now, it installed and couldn't find its own chrome directory.
jslib_current.xpi I then tried out, only to discover that was broken too. MozDev bug 8698 details the problem. (This bug may have been fixed, but the fix wouldn't have propagated yet. They usually make weekly releases, and the last one as of this writing was six days ago.)
The lite version, unsurprisingly, had the same problem.
So, JSLib is currently a little bit broken, in the part that I really need.
I figured, "okay, I'll see if we can get a stable jslib known to work." Specifically, I wanted to see if we could get monthly drops which people could consider stable. (Akin to using 1.7 instead of 1.8a6 as your baseline milestone.) Pete Collins responded (with a cc to the jslib mailing list),
There are too many updated builds posted to keep a running history of past builds. Keeping a history of snaps may be a good idea, but because of the way xpinstall works, it is easy for another app author to blow out the older version of jsLib.
I hope Pete & his team will forgive me for coming up with a solution and mentioning it here. chrome://jslib/content is taken, but what about chrome://jslib-stable/content? (I just sent this suggestion to the jslib list.) Bugs with patches I post to jslib receive a lukewarm reception, too, probably because MozDevGroup has too much on their plate as-is.
By the way, jslib isn't the only application I'm shaking my head in amusement at. Movable Type 3.14 came out just before the new year, essentially fixing the blogspam issue. Which version of MT is MozillaZine running, three or four weeks after the release of MT3.14?
:-) It seems all the people we developers love to have in our court just have other issues to pay attention to until somebody like me opens his mouth. You can't really blame them or get mad at them yet, because I'm just one guy with a blog. Nor are these things show-stoppers for Mozilla development. Just annoyances that I figured I'd write about, that's all.
No flames in the comments, please, for anyone.
Well, I'm just about stumped now. I can crash in Mozilla courtesy of bug 265736, but apparently when I do, I get a stack with no symbols. This means I have no information loaded on what lines of code the stack points to.
I've tried six different ways to get gdb to grab these symbols, and without success. I've even tried getting a couple IDE's, and am just on a wild goose chase.
Anyone have suggestions? Has anyone else ever debugged a crash in a MinGW-built Mozilla?
My build completed successfully! (I forgot to credit gemal.dk's website with some very good instructions. One piece of advice: read the problems he lists and implement the solutions he suggests before attempting a build. I have no doubt this saved me some heartache.) I'm writing this comment from it.
That said, I am already getting extremely sick of these NS_ASSERTION alerts. Abort, Retry, Ignore options appear every time I hit one. It's from here.
Fortunately, dmose already answered my question here.
Rule of thumb for MinGW builders of Mozilla: read both the Windows and the Linux FAQs. They will both apply (and surprisingly enough, don't directly contradict each other that much).
Anytime I build Mozilla for my purposes, I'm going to insist on doing a debug build. There's no particular reason why, I just think being able to track down where a crash is happening is useful. That said, I feel somewhat dumb for having my machine dedicated to a long, lumbering build without first ensuring that I actually had a debugger on my system.
Oops. 8-)
Fortunately, I do have cygwin, which can get gdb if necessary, I believe. I'm also, very painfully and slowly under timeless's wing, starting to learn a little about IDE's.
This inadvertent discovery of mine, however, leads me to ask a few questions:
* Why is there no mention of a debugger for MinGW builds of Mozilla anywhere I can find? (As MinGW builds are "tier 3", mozilla.org is excused from any responsibility in answering this one.) I am assuming, prematurely, that gdb from cygwin will work.
* If --enable-debug is set, why do we not have some sort of basic checks in ./configure that the user has a debugger? :) I honestly don't know. Maybe --enable-debug is used for something else as well.
* What happens when you run "mozilla -g" and you don't have a debugger?
* What good, free IDE's exist for MinGW / CygWin? I spotted Visual MinGW in a brief hunt earlier...
* Coincidentally, what good, inexpensive IDE tutorials or books exist? Those things are even more intimidating than C++ to this JSer.
Feedback welcomed. Just be gentle, please.
*crunch*
I'd been stuck on gklayout.dll (linking layout is so fun) for at least twenty minutes, and then suddenly I start hearing my hard drive spin. I'm thinking, "okay, it's borrowing swap file."
There was only so much in the bank, though:
d:\MINGW\BIN\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: BFD 2.15.9
1 20040904 internal error, aborting at ../../src/bfd/cache.c line 495 in bfd_cache_lookup_worker
d:\MINGW\BIN\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: Please report this bug.
collect2: ld returned 1 exit status
make[4]: *** [gklayout.dll] Error 1
...
Those familiar with building Mozilla know the rest of the story.
I'm about to attempt it again, moving my swap file to the D drive I'm building on, and setting it up to 1800 MB. I hope it works...
Basically, I'm wondering how it's done, besides on-the-fly translations like those provided by babelfish.altavista.com or Google's language tools. No automated tool is as good as a human expert in the languages involved.
I'm not asking so much for an actual tool as an idea of how a UI for a manual translation tool might be designed. Basically, I'd want to have some (preferably XUL) UI that would guide the developer using it through a translation process.
This relates to my Abacus project, so my personal interest in this is in translating presentation MathML.