This is the first thing I’m trying once I upgrade to GCC 3.4
July 13th 2004
Check out this GCC Symbol visibility patch. It can have quite an effect on code, especially code (*coughC++cough*) that generates very large symbol tables.
Archive for July, 2004
srcdir != builddir == good
July 13th 2004
I had a discussion on #kde-devel today with a developer who didn’t know about how to build programs with a different build and source directory. It came as quite a shock to me, as I had assumed that it was common knowledge.
It never hurts to spread the word, though, so here’s how it works:
- You need to have already unpacked the source, let’s call that directory srcdir.
- If you need to run make -f Makefile.cvs, run that in $srcdir, not $builddir.
- You need to make sure your build directory has been created, and change directory to the build directory.
- While in the build directory, run the configure script from the $srcdir. It will perform the configure process like normal, with the exception that all of the Makefiles and other generated files end up in $builddir, not $srcdir.
- Go ahead and use make like normal.
That’s nice, you’re thinking, but why would you want to use builddir != srcdir you ask. The answer is because it makes it easier to do a clean rebuild, so that you can be sure a package that builds for you also builds for someone else, or maybe you’ve b0rked a Makefile beyond repair. If you use KDE CVS, you can run make cvs-clean to get an equivalent effect, but that wastes bandwidth and server time, and doesn’t work when the network or server is down. Also, I’m not sure whether or not make cvs-clean will wipe out any changes you’ve made to the source code.
There are other ways of performing the same idea. XFree86 and X.Org include a tool called lndir (manpage), which is probably installed on your system, that creates a mirror image of a source directory by using symlinks. This has the advantage of ensuring the updates to the source are reflected in the symlinked files, but I have no clue how well it works or not, as I have not used it myself.
C++ Tips, Vol ?
July 13th 2004
I come across this every so often and still get surprised by it every time. So I figured I’d impart a bit of my hard-earned C++ knowledge so that more people would be familiar with the phenomenon.
Basically, in C++, you need to be sure that base classes don’t require anything from subclasses in their destructor activities. It sounds obvious, but it can pop up in surprising ways.
Say you have a subclass of KListView (we’ll just call it FooListView), and a corresponding subclass of KListViewItem, FooListViewItem. Also assume that you’ve not been praying to the OO gods, and the FooListViewItem is a friend of the FooListView, and accesses the FooListView in its constructor and destructor (like for debugging, or so the FooListView can easily hold data on its FooListViewItems no matter how they were created).
Normally this would work well enough, but during shutdown, as the FooListView is being destructed, it gets destructed starting at the subclasses, and working towards the base. In this case, the destructor would run in this order: ~FooListView() -> ~KListView() -> ~QListView() -> etc. Now, if the FooListView doesn’t delete its little FooListViewItems, what happens? They will still be present when the QListView destructor run, and QListView will happily delete them for you.
But wait! Remember how the FooListViewItems accessed their parent FooListView? The FooListView is now gone, only the QListView methods are valid. So you will get a crash on shutdown if you are not very careful, and remember to delete all FooListViewItems from within the FooListView destructor.
There are other ways that having Qt handle memory management for you can bite you, but they usually are typically due to “poor programming practices”. However, we all have to perform a few hacks in any program of more than minimal complexity, so it is something to keep in mind the next time you have two classes that are innately related to each other.
Getting ready to go for a trip
July 12th 2004
Haven’t blogged in a while, guess I’ve been pretty busy. Which is a pity, as I have always lamented the fact that there was no Planet KDE, until clee went and fixed that for me.
Scott’s been busy himself this past week, but slipped in enough time to ask me to commit some of my pending patches that I had asked him to review. I get the impression that he didn’t actually have time to review them, but I’ve been using them myself for about a two weeks now, and I haven’t received bug reports on them yet, so I guess they must have been OK. :-)
I somehow managed to work up enough energy today to close quite a few bugs in JuK, and also release a new version of my KDE build script. I sort of cringe when I see easy feature additions to JuK that I could work on, since I know they’ll have to wait for 4.0. :-( Of course, sometimes people file wishlist bugs that are actual bugs in their own right, such as Bug 84728, so that helps.
Back to the topic on hand, however, I’ll be leaving soon to visit my grandparents. They hold a family reunion every year, and I haven’t had a chance to attend for about 6 years now, so I guess I’m rather overdue. The only problem is that I hate vacations, as they do nothing but keep me from my coding. :-(
And before I forget, if you’re experiencing horrible layout problems with KHTML, try reducing your optimization settings in your CXXFLAGS to something sane (less than -O3 for starters). If you’re compiling for super-optimization, then it would perhaps behoove you to note that modern systems tend to perform better with -Os than with -O3 nowadays as processors outpace the memory systems on computers.
Web site coding
July 8th 2004
So I’d finally set up my grandma’s computer the other day, and configured
it to run Fluxbox and Mozilla Firefox to conserve memory. Unfortunately,
Fluxbox isn’t included with Gentoo’s GRP package, and after a few hours of
compiling it was looking like my grandma’s computer would never be able to
install it either. So what I did was setup a chroot environment on my home
system which is very similar to my Grandma’s system, down to the last USE
flag. I was then able to compile binary packages on my fast home system and
then have them downloaded from my Grandma’s slow computer. It’s up at http://grammarian.homelinux.net/cgi-bin/x86-packages
right now. Feel free to browse around, but please don’t actually download
anything, my upload bandwidth is bad enough as it is. ;-)
It’s easy enough just to add the list of packages to an HTML file as I
build them, but I figured this would be a great way to learn the CGI.pm module
that comes with Perl. So I made a simple script that allows you to browse the
built packages, search for one by name, and download it. Luckily, it was
nothing too difficult, although I did notice that the File::Copy module just
doesn’t seem to work in conjunction with CGI scripting, at least with Apache
2.
Now I just have to parlay this knowledge into improving my site, or just be
happy that I know something about CGI scripting now and install some other
software to improve my site. :-D
Well, off to bed, I have to get up in about 5 1/2 hours. :-(
Lotsa stuff
July 6th 2004
I’m just blogging this random collection of thoughts.
- QTorrent is splendid. Saves me from having to write my own BitTorrent client. I especially like the option to cap the upload rate, because otherwise I can’t browse the Internet anymore.
- They Might Be Giants is selling high-quality MP3, non-DRM versions of some of their songs. I don’t really recognize any of the songs, but the price is right. Great move, guys.
- Are you feeling evil? Are you trying to set records on number of kicks received on IRC? If so, you may be interested in the following shell script code, which takes advantage of the DCOP features of Konversation:
#!/bin/bash # Do whatever you want with this code. By Michael Pyne # First paramater is the server Konversation has connected to, # the second paramater is the channel to torment. Don't forget # to escape the # at the beginning of the channel name. ref=`dcopfind -a 'konversation-*'` if [ "x$ref" == "x" ] then echo "Konversation isn't running!" exit 1 fi server=$1 channel=$2 if [ "x$channel" == "x" ]; then echo "You must specify the channel!" exit 1 fi if [ "x$server" == "x" ]; then echo "You must specify the server!" exit 1 fi while true do dcop $ref Konversation say $server $channel "This is the song that doesn't end..." sleep 5 dcop $ref Konversation say $server $channel "Yes it goes on and on my friend..." sleep 5 dcop $ref Konversation say $server $channel "Some people, started singing it, not knowing what it was..." sleep 5 dcop $ref Konversation say $server $channel "And they'll continue singing it forever just because..." sleep 5 done
More tackiness
July 4th 2004
annma has kindly tested the last release of Tacky. I feel sort of bad for even releasing it, as it wouldn’t even start up if you hadn’t configured the directory already! But anyways, I’m putting v0.6.1 out, which fixes that problem, and makes it possible to build using the normal automake framework again thanks to an /admin directory update (again thanks to annma).
I was unclear about this last time I blogged on it. Not only do you have to have a pyblosxom blog, but you have to be hosting it since all the program does is write the blog to disk. I will release a KIO-ified version later so that you’ll be able to use it wherever you can use KIO, but until then, you might want to bug clee about adding XML-RPC support (or whatever) to Tack.
Anyways, regarding the mission to install Linux on my Grandma’s old POS, I finally got it installed, including a small 2.6.7 kernel and bootloader and junk. Still very slow, and I wish the packages CD actually had packages for the basics like GRUB, but at least it won’t take forever to install KDE tomorrow.
My new blogging tool.
July 3rd 2004
Well I’ve been working a little on a pyblosxom blogging tool for me to use while in KDE. I’ve named it Tacky, although it has no relation to clee‘s Tack blogger.
Click for a screenie.
It’s not real advanced or anything, and probably never will be. I just wanted to be able to quickly post blogs while in KDE, but with more features than tack.
Notes:
- Hitting the Post button will quit the application if it succeeds.
- You need to configure the program and give it the path to pyblosxom’s data directory first.
- It has syntax highlighting using a hand-coded (read: sucks) munger to keep the footprint small.
- Don’t ask about the logo, it’s supposed to be a pyblosxom flower with a push-pin or something.
- The program uses kconfig_compiler, which means KDE 3.2 or above. It compiles while using unsermake, but using automake doesn’t generate the correct files for me for some reason. I think this may be the first time I’ve ever used a program that worked for unsermake and didn’t work for automake. Patches are accepted for that problem. ;-)
You can download it from my University of North Florida webspace.
BWAHAHAHA
July 3rd 2004
I was reading JWZ’s blog, and came across him posting about his experiences reporting a GIMP bug.
------- Additional Comment #1 From sven@gimp.org 2004-07-02 11:08 ------- Use a stable version then or at least use the latest development version. Submitting bug reports for outdated development versions is rather rude behaviour.------- Additional Comment #2 From Jamie Zawinski 2004-07-02 14:02 ------- Outdated? I downloaded it *two weeks ago*! It was the latest released development version as of June 13.------- Additional Comment #3 From Michael Schumacher 2004-07-02 14:39 ------- Well, development releases are outdated when the next commit to CVS happens...
It must suck to be Jamie. I would have at least asked him to run valgrind on it or said, “Yeah, we know” or “It’s fixed” as appropriate.
Maybe KDE development is slower paced, but I can’t think of too many times when 2 weeks made a program useless for debugging.
-
Recent Comments
mpyne on The future of kdesrc-build
afiestas on The future of kdesrc-build- mpyne on Oh fun
mandarin on Oh fun- mandarin on Oh fun
