About twelve hours ago, I was asked to expedite a patch for the Gecko 1.8 branch. Since I usually don't play around on the branch, this wasn't quite trivial. On my personal Windows box, I had uninstalled MSVC++ 6 several months ago, so that option was out. Ditto for my corporate Windows box (which never had it installed in the first place).
On my Linux operating system, I successfully compiled and ran a 1.8 branch build. Unfortunately, being rusty with gdb and ddd, this proved useless in terms of diagnosing the problem. If I knew how to debug in Linux properly, loading the right libraries and setting the breakpoints, I'd've had no problem.
So I switched to the Mac Mini I bought a couple weeks ago. Again, I successfully checked out, compiled, and ran the 1.8 branch build. I followed the instructions on using XCode at devmo, and got a little confused when they talked about Project Builder in the same sections (without giving me the rest of the details on XCode use). When I realized XCode and Project Builder were two different products entirely, it became relatively easy to set the breakpoints in running code and hit them - which led to me finding the cause of the problem I was looking for.
Ultimately, it turned out the problem I was researching wasn't really applicable to the 1.8 branch. But that's irrelevant. With relatively little trial and error, and the docs available on mozilla.org, I was able to debug the problem as I understood it at the time. I can truthfully say that this is the first time I was able to use the Mac Mini to hack something that would have been problematic to do on another operating system - without being an expert at every stinkin' little detail.
Now if only I could figure out the other little details, like why the "end" button doesn't take me to the end of a textbox line... or how to switch by keyboard from ChatZilla to another window in the parent application (SeaMonkey, Firefox)...
UPDATE: Wow, I really asked some dumb newbie questions in the previous paragraph, didn't I? I got so many responses just on that... :-)
IDL pre-processor Perl script and a text/plain version.
Following up on my previous post, here is evil, nefarious scheme number 692. Sample .mozconfig:
. /cygdrive/m/configs/sm-debug.mozconfig
ac_add_options --disable-mailnews
ac_add_options --disable-composer
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../nav-sm-debug
OBJDIR_CONFIG=${topsrcdir}/../nav-sm-debug/config
mkdir -p ${OBJDIR_CONFIG}
echo "
export:: idl-preprocess
idl-preprocess::
\$(PERL) /cygdrive/m/idl-preprocess.pl \$(XULPPFLAGS) \$(DEFINES) \$(ACDEFINES) --srcdir=\$(srcdir)
.PHONY: idl-preprocess
" > ${OBJDIR_CONFIG}/myconfig.mk
echo ${OBJDIR_CONFIG}/myconfig.mk
cat ${OBJDIR_CONFIG}/myconfig.mk
This allows me to take a foo.idl.in file and create a foo.idl file from it. Two known bugs in it: foo.idl must exist before you call it via the Makefile rule above, and you really can't risk compiling more than one build at a time over the directory foo.idl.in must live in (lest conflicting #ifdef macros take effect).
Why, you might ask, would anyone in their right mind want to preprocess IDL? One of the big goals of IDL is to make sure your interfaces are clearly defined, and preprocessing clutters it up.
I answer: because I want to preprocess C++ and chrome files using the same flags. But I want to do it locally only, in my development tree.
Basically, I'm combining a lot of ongoing work into a "supertrunk" tree (evil, nefarious scheme number 691), which I'll use to develop a lot of Web Forms 2 code concurrently. When I'm ready to create a patch, I'll make a complete copy of this tree and use preprocessing (of IDL, C++ and chrome) on the copy to get rid of the code that isn't relevant to that patch.
This also allows me to develop code which depends on other code which awaits reviews. In other words, I only create a new tree when I absolutely have to. Plus, conflicts when I update (after a checkin) become somewhat more manageable.
Note that I don't recommend this script be checked into mozilla.org's repository. One of the big reasons I wrote this IDL preprocessor was to avoid mixing up UUID's for each change to the interface. Consider:
#switchdef #casedef FOO [scriptable, uuid(e78e4889-d21d-442b-b89f-ab757f40458d)] #casebreak #default [scriptable, uuid(6438d086-68a4-4938-a781-b88f674f3eb1)] #casebreak #endswitchdef
There's no way in the world I'd want to see that in a patch for mozilla.org code. I use the switchdef structure so that when I go from one patch to another, I'll ultimately get a different UUID for each patch to the same IDL file - which is perfectly reasonable. But I don't see any reason to have code like this ifdef'd in mozilla.org's repository. This is just to help me out on my local tree.
This year I decided early on not to attend OSCON 2006. I enjoyed the last four OSCON's, and simply decided I didn't want to go to this one.
In hindsight, that was an excellent decision.
Don't get me wrong, OSCON is a blast. It is a pinnacle of the open-source community, and well worth the price of admission. I have no doubt I'd have enjoyed myself very thoroughly and learned a lot by going again. The main reason I didn't want to go was I needed a break.
So I'm taking a break from OSCON, away from tech heaven... and I'm having another blast working on another self-appointed Mozilla task: Web Forms 2.0.
My motivation is a bit narrow - a lot of the functionality in WF2 will also be useful for Verbosio. But by my beginning to implement it, Firefox trunk and SeaMonkey trunk will pick up a sizable boost in HTML form capabilities. Some of these I'll borrow from other XUL toolkit improvements (such as the date/time pickers Neil Deakin just blogged about), while other things XUL toolkit will itself inherit from my work.
I also just figured out an old trick (old enough to where CVS blame's log comment says "Free the lizard"), not well documented.
Here's a sample .mozconfig file:
# Include another .mozconfig, so we do everything incrementally
. /cygdrive/m/configs/nav-sm-debug.mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../ifdeftest
OBJDIR_CONFIG=${topsrcdir}/../ifdeftest/config
mkdir -p ${OBJDIR_CONFIG}
echo "MOZ_WEB_FORMS = 1
DEFINES += -DMOZ_WEB_FORMS " > ${OBJDIR_CONFIG}/myconfig.mk
echo ${OBJDIR_CONFIG}/myconfig.mk
cat ${OBJDIR_CONFIG}/myconfig.mk
What do these do? They turn on MOZ_WEB_FORMS for #ifdef'ing code in Makefiles, compiled code, and chrome.
In other words, through a simple .mozconfig file, I can selectively activate specific preprocessor flags. This can be very useful (if I don't abuse it, of course). I'm already dreaming up nefarious schemes for this new ability... muahahahaha...
UPDATE: Fixed a small bug in the .mozconfig above.
TortoiseSVN Menu Firefox Extension
I couldn't resist. You have to have TortoiseSVN installed as well (which means this is Windows-only), but for me being a big fan of Subversion and TortoiseSVN already, I just think this is great.
Now what I think would really be killer is a SVN client as an extension for Firefox directly. That would have potential to work cross-platform, and be very, very cool.
I defined a few more features here, mostly about passing arguments and return values in and out of components. Also a couple new sections on checking and setting null, and some highlighting (italics) to more clearly express which variables I'm talking about.
Pretty soon, I'll have to ask for someone to write the Python sections of this cheat sheet.
So what's new this time around?
Branch tags are listed under src/data/branches.inc in the XUL Widgets repository.
The purpose of this branching is to allow trunk-based and Gecko 1.8.x-based XUL Widgets extensions to line up more with their respective bases. For example, if trunk has implemented a XUL Widgets extension, there's no need to keep that extension on XUL Widgets's trunk. Also, new features which could not be supported on Gecko 1.8.0.x branch may now be included for trunk-based and possibly Gecko 1.8.x-based XUL Widgets packages.
The best part about this is that XUL Widgets now supports Gecko 1.8.x and trunk builds. I didn't fully realize it before, but the packages for XUL Widgets were previously restricted to only the Gecko 1.8.0.x series.
If you installed the flat chrome edition of XUL Widgets, please uninstall version 0.3.x before installing version 0.4.x. If you update directly, the update service will return a jarred chrome edition instead.
Your test results and feedback are most welcome!
A couple weeks ago, I ordered a Mac Mini for Mozilla development purposes. This was intended as a short-term replacement for my dysfunctional laptop, and to give me coverage on the Macintosh platform which I didn't have before.
I won't rant about FedEx here; suffice it to say they've got good company-to-customer communication, but their support for customer-to-company leaves a bit to be desired...
I was going to write up an entry detailing the two evenings it took me to set up the Mac for building (it's not quite a 45 minute process for a first-timer, but the docs were there). Suffice it to say that I successfully built a SeaMonkey 1.0.x build for verification, and executed it with general satisfaction.
Also last night, I caught the pilot of "Eureka" on Sci-Fi channel.
I thought the show was pretty good. There were a couple cliches, of course, but I really enjoyed it. I must say, as a techie and an amateur (but well-received) sci-fi writer, I'd very much like to write an episode of that show. It was really well done, a fair amount of comedy to go with the storyline. My imagination was cooking last night with three or four jokes and/or homages that I could pull as part of a story I also envisioned.
The beauty of open-source: when something can be improved, even in the slightest way, people inspire themselves to do it...
But who's going to offer me a decent contract? :-) My "JavaScript Developer's Dictionary" book won't carry that much weight.
I've changed the configuration on my weblog to require e-mail addresses from all commenters. Rest assured, I won't disclose them; I just want at least some idea of who's talking to me, so I can respond.
More to the point, I've been getting another new surge of blogspam lately, and so I did a few WHOIS searches on several of the domain names that keep popping up. One "Alex Santa" of Moscou, RU keeps coming up.
Mr. Santa, I am writing this to you now: either you or someone you are paying has been blogspamming me (and probably most of my feedhouse/planet companions) for a very long time now. However, I thought you might have caught on by now that it's not working over here: every one of these blogspam for over two years has not seen the light of day on my weblog.
Ultimately, since the source of funding for these blogspam is coming from you, you may find yourself the target of a lawsuit. Not from me alone (I don't have that much money), but sooner or later you're really going to tick someone off. We're spending too much time cleaning up after you and those you pay to advertise your worthless link sites.
I've been thinking the last few months about a change for XUL Widgets, and now that Firefox 2.0 Beta 1 is available, I need some advice from the community.
XUL Widgets, for those of you who haven't followed it, is a MozDev project to extend the standard mozilla.org toolkit of XBL-based widgets. Other projects are invited to adopt XUL Widgets as an extension and use the extended toolkit in their own applications. I've been updating it from time to time with new features (or fixing bugs in the update code), but now I have to decide which version of mozilla.org's toolkit XUL Widgets should support.
Currently, there are three versions I'm concerned about: 1.8.0.x branch (Firefox 1.5), 1.8.x branch (Firefox 2.0), and trunk (Firefox 3.0). A few of the changes I've made for XUL Widgets have landed in the 1.8.x branch, and a few more in the trunk. So my own unreviewed changes may conflict or degrade the expected results in these versions. On top of that, there are new capabilities in trunk (and to a lesser extent, 1.8.x branch) that weren't available in 1.8.0.x.
To my knowledge, I'm the only one actiovely using the XUL Widgets extension. If I am truly the only one interested in using it, then there's no reason for me not to switch its base to trunk. My usage of XUL Widgets is for Verbosio, and that cannot run on the 1.8.0.x or 1.8.x branches.
I'd like your feedback, especially if you use XUL Widgets. Which version of the toolkit should I base my extensions on?
UPDATE: Case in point: Trunk code just now received an active spinbuttons widget, which my integercontrol could easily depend on.
I decided to try my hand at a bit of artwork tonight. I'd been wondering what sort of logo I'd use for Verbosio, and this came to mind - another reference to XML, and to writing.
Opinions? Has this sort of logo been used by someone else before? I'd hate to infringe on someone's trademark...
UPDATE: The general consensus is that it is unique (yay!), but a bit basic. To me, that's okay for now. I'll gladly accept contributions of new SVG markup (preferred) or PNG graphics that do the logo in a better way. Just please don't hold any license on it; I'm not sure what licensing to hold the logo under for the project anyway, considering Verbosio is open-source, low-budget and likely to stay that way...
There's been a thought rattling around in my brain for a while, but when my hand started hurting a bit today, I thought a bit more.
Many of the Firefox extensions I use don't have keyboard shortcuts. Or, for that matter, menuitems inserted by overlay into the main toolbar.
I'm not intending to point fingers (I'm guilty of not considering a11y with tinderstatus), but there are some popular extensions out there that could really use some accessibility love. Including several that I use on a daily (and in one case, hourly or even more frequently ;-) ) basis.
On the other hand, there is the danger of two or more extensions picking the same key combination to do something. I am acutely aware of that problem; I face the same sort of issue at a higher level of magnitude with Verbosio. We might need some kind of functionality through Firefox's Extension Manager to override assigned alternate UI's to their core functions. (What to do for extensions missing UI I haven't figured out yet.)
Thoughts? I'd be willing to design & patch for this, but I want some community feedback (and if I do patch, a general assurance that it will get fast reviews). Is this worth doing? If so, how would you want it to work?
To quote Jamie Hyneman, "Whoops!"
In posting the 0.2.* series of XUL Widgets XPI's, I listed incorrect information in the install.rdf and update.rdf files. This mandates posting a new XUL Widgets 0.3.0 XPI & XULRunner series.
No new functionality, but you will find XULRunner 0.2 will not receive any future updates. So please uninstall it before installing version 0.3. XUL Widgets version 0.3 should be available in 24 hours or less.
UPDATE: Another well-formedness error bit me, install.rdf. 0.3.1 released now.
UPDATE 2 : Note to self: chrome.manifest is useful. 0.3.2 released.
There are so many things wrong with Verbosio in its current state that it's hard to keep the faith, and keep going. A number of large issues have been bubbling around, the biggest one being that I can't support WYSIWYG editing. But that's a discussion for another day.
Because Verbosio is intended as a complete application, involving a combination of chrome, content, and extensions, getting a proper development environment is notably a struggle. For example, I simply forget how to recompile IDL files after I've made a change to them. IDL's are actually pretty important in Verbosio, so that barrier alone to development is tough.
On top of that, I frequently make changes to Verbosio code, and forget to move it back to my Verbosio repository. I've probably got six or seven complete copies of Verbosio in various states of disrepair, and so by not using the advantages of CVS revision tracking (SVN would be better, but mozdev doesn't have that yet), I have allowed myself to lose pieces of code in development... which is even worse than outdated IDL's.
So on Friday evening, wanting to get myself organized, I grabbed Mozilla Sunbird 0.3a2 (I'm a developer - alphas only frighten me a little), and started writing down some of the unfinished business I have with regard to Verbosio and mozilla.org bugs. It turned out to be a big list... and the first thing on it was to simplify the development process between repository and objdir's. In other words, time to write some Perl and shell script code.
Now, I'm not all that great at Perl. But over the last year at ManyOne Networks, I've been exposed to more than a little of it. So with a handy Sams Teach Yourself Perl in 24 Hours guide, a few script subroutines borrowed from work, and an unhealthy bit of trial and error... I got a basic make-project.pl script written to handle exporting repo code into objdir code, and set up for the reverse.
I could have written it as a Makefile, I suppose... but Perl seemed to have more of the capability I needed. The Makefile will of course call on the Perl script... later.
Just to write this one script has literally taken me about 18 hours in pretty much one straight shot (one break for food, and another break for Saturday night anime). Along the way, I learned a few things:
I woke up Saturday morning about 8:30 AM. It's now 3:15 AM Sunday. Marathon coding sessions for me are relatively rare, but they do happen. Kinda like when I was writing my book for Sams Publishing - though I'm not planning on doing 40 hours without sleep like I did five years ago. I'm going to bed now.
Incidentally, I've been spending a bit of time lately writing patches for mozilla.org trunk code, just to support features that a editor like Verbosio should have. Patches that really make Verbosio moderately useful.
I'll take suggestions on CPAN modules for design-by-contract...
