Article: Linux’s Legal World After SCO

by Pamela Jones of Groklaw.net. Apparently Linux is ready for the business world. I particularly like the quotes on page six, including this gem:

No FOSS developer would ever pretend that a browser was part of an operating system, for example.

And this:

People Know Now that You Can Make Money with GPL Software

Now if only it was ready for the desktop… 😉 I wonder if Asa would like to update his opinion…

The Mac Mini pays off

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-processing

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.

Missing OSCON: No regrets

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.

XUL Widgets 0.4.0 released

So what’s new this time around?

  • There are now separate CVS tags for Gecko 1.8.0.x and Gecko 1.8.x. This means different XPI packages and XULRunner tarballs for each.
  • Flat XPI’s will update to flat XPI’s in the future, as opposed to jarred XPI’s.
  • One minor bug fix to textbox.xml for validation.

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!

Eureka

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.

Alex Vincent's ramblings about Mozilla technology, authoring, and whatever he feels like.