The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht am 04.06.2007 an. Zurück zu allen aktuellen Beiträgen | |||||||||||||||||||||||||||||||||||||||||||
4. Juni 2007
The F-Word - or: Code is not Country Music
Some of you might know a song called "The F-Word", recorded by Hank Williams, Jr. and Kid Rock, which explains in all length that "in Country Music, you don't use the f-word", and yes, it's fun - esp. given how Kid Rock lyrics usually read 
A bit more recently, there Jack Ingram's "Love You" that takes this cursing down a completely different path: "Love this mother-lovin' truck that keeps breakin' lovin' down / There's only one four-letter word that'll do: / Love you"
Nicely said
Still, that's music, that's lyrical art - and software source code is different.
When I read preed's article on Planet today and read this recent bug report, I couldn't help but burst out into a big "WTF?" myself. There are lots of hacks in our code, we sometimes suck, and can't get it to fuckin' work as it should - and this guy wants to put censorship on us instead of admitting in comments what's really happening in the code. This sounds plainly wrong to me.
When I looked into an older article about Netscape/Mozilla "censorship", I had a few good laughs though. See for example this one, from Netscape 3 (but apparently still present in 4.x):
lib/libmime/mimestub.c: Life kinda sucks, but oh well.
Given this is in libmime, and I heard enough talk about the suckiness of that lib, it's real fun to see this in a version of it - even though I don't know what it relates to.
Seeing "hack" used various times in security/ might make some people uncomfortable though... and // fucking idiot! in the same subdir might also not increase trust in this...
I guess it depends where you can use what words
A bit more recently, there Jack Ingram's "Love You" that takes this cursing down a completely different path: "Love this mother-lovin' truck that keeps breakin' lovin' down / There's only one four-letter word that'll do: / Love you"
Nicely said
Still, that's music, that's lyrical art - and software source code is different.
When I read preed's article on Planet today and read this recent bug report, I couldn't help but burst out into a big "WTF?" myself. There are lots of hacks in our code, we sometimes suck, and can't get it to fuckin' work as it should - and this guy wants to put censorship on us instead of admitting in comments what's really happening in the code. This sounds plainly wrong to me.
When I looked into an older article about Netscape/Mozilla "censorship", I had a few good laughs though. See for example this one, from Netscape 3 (but apparently still present in 4.x):
lib/libmime/mimestub.c: Life kinda sucks, but oh well.
Given this is in libmime, and I heard enough talk about the suckiness of that lib, it's real fun to see this in a version of it - even though I don't know what it relates to.
Seeing "hack" used various times in security/ might make some people uncomfortable though... and // fucking idiot! in the same subdir might also not increase trust in this...
I guess it depends where you can use what words
Von KaiRo, um 20:55 | Tags: Country Music, Mozilla | keine Kommentare | TrackBack: 0
Build system defaults to MOZ_XUL_APP now!
The SeaMonkey confvars.sh did only set MOZ_XUL_APP=1 for a very short time, as I just removed it again
As a matter of fact, after my checkin for bug 383112 that I just did, the configure script makes all applications built from mozilla.org trunk default to MOZ_XUL_APP=1, so they don't need to explicitely set this variable any more - just Camino does unset it (until that last user of xpfe gets converted).
Actually, we might near a world where this variable isn't needed at all any more, as everyone uses the same toolkit anyways. But for now, configure turns it on for everybody - once Camino doesn't have to unset it, we might be able to just kill all its appearances from the code step by step.
As a matter of fact, after my checkin for bug 383112 that I just did, the configure script makes all applications built from mozilla.org trunk default to MOZ_XUL_APP=1, so they don't need to explicitely set this variable any more - just Camino does unset it (until that last user of xpfe gets converted).
Actually, we might near a world where this variable isn't needed at all any more, as everyone uses the same toolkit anyways. But for now, configure turns it on for everybody - once Camino doesn't have to unset it, we might be able to just kill all its appearances from the code step by step.
Von KaiRo, um 17:19 | Tags: Mozilla, Mozpad | keine Kommentare | TrackBack: 0
Weekly Status Report, W22/2007
After a quite busy week (both work- and non-work-related) here's the report on my SeaMonkey work in week 22/2007 (May 28 - June 3):
As we have entered the brave new world of the new toolkit now, there's a real lot to do to improve how well SeaMonkey works on it, clean up what we left behind, switch over to the parts of it we're not using yet - and add features that will make SeaMonkey 2 an even better Internet suite. We'd be happy about anyone who can help us in any of those areas.
Oh, and if you can't, test nightlies and report bugs - that's the first step to being a contributor and improving your favorite software!
- SeaMonkey releases:
Those went online on May 30, once more in sync with Firefox/Gecko releases - and I'm proud we could push out new localized packages in 7 languages additional to US English right at the same time as the official release. For our old process with L10n teams creating and contributing the packages themselves, this is quite a nice number. Along with the still usable language packs from 1.1(.1), we now have SeaMonkey 1.1.2 in 15 languages total - for the first time also in Brazilian Portugese. - suiterunner switch:
It is done!
I checked in the patch for the real switch on Tuesday, after Frank had added the NSIS installer on Monday. Also fixed tinderbox configs to build the nightlies correctly. Mark and Frank have fixed a number of problems in migration and installer since, and are still working on newly reported ones.
If you run into problem with the new "2.0a1pre" builds, look for filed bugs and report new ones if your problem isn't know there.
Now Camino is the only xpfe-based app left, I hope we get them off that toolkit soon as well so we can clean up the source and finally kill that old code. - Killing wallet:
Did look again into the wallet -> satchel change, but I'm now at an interesting point where my (opt) build crashes when I focus any form field, which is not too helpful for working on that. - places history:
Last Sunday evening, I was contacted by Mano in IRC about what history implementation we're using in suiterunner, and I had to confess we're still using the xpfe one after looking into the code. He told me it would probably be easy to skip the toolkit version of it and go directly to places history. I
filed bug 382187 for that and with help from him and biesi, I got the backend to build and work within 3-4 hours (where most of the time was spent tweaking build vars and recompiling). It even automatically imports data from the old mork file into places.sqlite, so visited sites still stay displayed as visited after switching.
Unfortunately, getting the UI to work with this is harder, as our UI for history stuff is mostly RDF-based and mozstorage data doesn't get presented as RDF. And, which is probably worse, I have much too little coding experience in those areas.
I did manage to get a Firefox places history panel mostly working in my experimental build, but though the search and sort is nice there, I think I like our old one better functionality-wise (or even better a crossover of them). Unfortunately, it needs a ridiculously big number of files from browser/ to work properly, and one bug caused my error console to fill with one repeated line over and over. - Themes:
I again put some work into porting over my EarlyBlue theme to suiterunner, adding support for the (new) help viewer. When I realized this might be a good place to start using PNG files and -moz-image-region, I asked on IRC what the coordinates there exactly meant and ended up writing a layout reftest and improving its documentation for that instead of doing actual theme work for a while. Even though such things are distracting, more people than just me end up profiting from that, I hope. - Mozpad:
Took part in the second IRC meeting - I think this project is heading into a good direction, even if some hopes of participants might be set a bit too high for now. Cooperating for a better platform and more docs is a quite important mission though, and everyone should profit from that. - Various discussions:
A huge list of suiterunner post-landing discussions around regressions, cleanups and further improvements; continued Firefox3 UI discussions, SeaMonkey icon set and others.
As we have entered the brave new world of the new toolkit now, there's a real lot to do to improve how well SeaMonkey works on it, clean up what we left behind, switch over to the parts of it we're not using yet - and add features that will make SeaMonkey 2 an even better Internet suite. We'd be happy about anyone who can help us in any of those areas.
Oh, and if you can't, test nightlies and report bugs - that's the first step to being a contributor and improving your favorite software!
Von KaiRo, um 00:22 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 0
