Bloggy

I’m too tired to go too deep into the changes in the kdesrc-build 1.13 release, but the largest is that module data from projects.kde.org can now be used to build git modules.

Obviously kdesrc-build was already perfectly capable of finding git modules, so this isn’t very useful if you’re already building everything you want to be building. However, what the module database gives you is categorization and grouping (without git submodules, which kdesrc-build doesn’t support at all yet). e.g. if in theory you asked for extragear/graphics, which is not a real git module, kdesrc-build would figure out you wanted Digikam, kipi-plugins, Skanlite, and KGraphViewer.

The larger the groupings become, the more useful this feature becomes. There are many other minor fixes/changes/bugfixes to go with it (including the first release of a test suite, although it is still pitifully small). As always, please let me know if I’ve messed something up!

Posted by mpyne under KDE | No Comments »

I noticed someone encountered an issue with trying to find out what library is introducing dependencies into their program, and didn’t immediately think of a tool I’d written to do that, so obviously I am not “marketing” effectively. ;)

I wouldn’t bother trying to ride Robin’s coattails except that some of the issues he notes (repeated dependencies, search paths) should be implemented already in mine. Oh, and mine is GUI driven in case you’re of that persuasion (not that there’s anything wrong with CLI!)

Without further ado, ELF Library Viewer:

Please go easy on the screenshot, it’s been unchanged for a couple of years now. I’ve only just now confirmed that it even still builds.

Posted by mpyne under KDE & Useful Tricks | 2 Comments »

So, given the accelerating rate of KDE project migration to git.kde.org, I felt it was prudent to finally make a kdesrc-build release, for those who don’t follow kdesrc-build development in trunk.

So, kdesrc-build 1.12.1 is upon us (the link may be broken, I’ve just committed everything to svn, it should update within a few minutes of that). I probably shouldn’t have made it a mere +0.0.1 release, as it contains one notable large new feature, and several minor improvements besides the normal bugfixes.

The big deal is the module-set feature I discussed a couple of months ago. This allows for easy declaration of git-based modules in your .kdesrc-buildrc (which is good, as old Subversion modules are being migrated quickly now that 4.6 has been branched off of trunk).

However, it is not a long-term (or even a good medium-term) solution. To that end, the KDE sysadmins have been working hard on making a database of the projects available on git.kde.org, including what groups each repository falls under. Besides being needed to migrate some of the tools that we currently use with Subversion, it will be useful for allowing build scripts (such as kdesrc-build) to take a command to build e.g. “kdepim”, and figure out the full list of git repositories contained in the “kdepim” grouping.

The groups can themselves be contained within groups (in theory you’d be able to build all of extragear with a single command, although I’ll probably block groupings that large like kdesrc-build currently does to avoid users accidentally DoS-ing KDE resources).

That will be the next thing I start on. Hopefully finding good Perl libraries for parsing XML doesn’t take too long. ;)

The other thing I will be doing is migrating to git.kde.org myself. I’m not exactly sure when, but I already have the rules mostly written. Perhaps I’ll wrap everything up this weekend and move to git.kde.org myself.

Either way, let me know if there are issues with the new release (it’s been brewing for about a week so don’t say I didn’t give trunk users time to test! ;)

Happy building!

PS: Special side note, if you’ve been receiving messages about KSharedDataCache saying that “This cache is probably corrupt”, update kdelibs to either 4.6 branch or trunk, that bug should be fixed now…

Posted by mpyne under kdesvn-build & Programming | No Comments »

Except me that is… but only due to lack of rule-writing time.

But in the meantime, I’ve written some code to allow you to at least quickly declare KDE git modules to build. I’ve just committed it to trunk kdesrc-build (in kdesdk/scripts). This feature adds two options:

1. git-repository-base, which declares an alias name for a new git repository, and assigns it a URL. This is needed for a concept I’m calling “module-set” for now.
2. use-modules, which is used in a given module-set to name the git modules that you want to build at that point in the .kdesrc-buildrc, in order.

Simple example:

global
...
git-repository-base kde-git git://anongit.kde.org/
end global

# Need to set options for attica? Just declare it manually and set the options after the
# module-set. It still gets built before soprano though.
module attica
cmake-options ....
end module

Hopefully this makes managing the large numbers of individual git projects that are popping up much more reasonable. Another long-term measure is that some motivated git-transition types are working on a module-grouping XML format, which will be usable by kdesrc-build (among other software) to quickly group related git modules under a single name.

Posted by mpyne under KDE & kdesvn-build & Programming | No Comments »

I haven’t updated in awhile. This isn’t going to be much better, but it’s something.

Just got done with another long day at work. I will be leaving very soon to do my final class presentation (on a MySQL-backed Catalyst web site). After that I will be hitting the road tonight to drive 4-5 hours in order to see the Change of Command for one of my former Executive Officers, now taking command of my old ship (albeit the “other crew”…)

I hope to get more time for other things soon! :-/

Posted by mpyne under Navy & Personal | No Comments »

So this morning kde-core-devel was emailed to notify that a few projects that used to be hosted in kdesupport have moved to git.kde.org.

What this means for you if you use kdesrc-build is that you should probably update your ~/.kdesrc-buildrc to add the projects separately since they will no longer be built as part of kdesupport.

Affected are Akonadi (the underlying PIM layer, which might be required for kdelibs, I forget), Attica (“Implements the Open Collaboration Services API”, I assume this means it’s required as well) and Soprano (C++ RDF framework, used for Nepomuk. I believe Soprano is required even if Nepomuk is not being used, but that could also be wrong).

My recommendation is to add the following modules after your existing kdesupport module, before any other modules:

module soprano
    repository git://git.kde.org/soprano.git
end module

module attica
    repository git://git.kde.org/attica.git
end module

module akonadi
    repository git://git.kde.org/akonadi.git
end module

Naturally if you will be doing development on these repositories and not simply checking out a read-only copy for build purposes you should use the git@git.kde.org:foo.git form of the repository URL.

This migration to git has the potential to get annoying for end-users, especially as we modularize more and more. To that end, the KDE Sysadmin team is working on a specification for grouping related modules together, which kdesrc-build will support, that way you could just do something like:

kde-module-group kdeplatform
    # References known XML module grouping
end kde-module-group

and things would Automagically Work. Stay tuned…

Posted by mpyne under KDE & kdesvn-build | 3 Comments »

So it seems that Benoît Mandelbrot has died today.

If you’ve never heard about him, he was famous to many people for using computers to delve into mathematical studies about that had what he called “fractional dimension” instead of being simply 1-dimensional or 2-dimensional. These shapes would end up being called “fractals”.

Perhaps the most famous fractal is the one named after him, the Mandelbrot set:

Mandelbrot Set, from the Wikipedia article.

I bring all this up if only because it’s probably how I seriously got started in programming. My father had somehow acquired an old Compaq laptop which he let me use when he didn’t need it (which was often!)

For whatever crazy reason my high school actually offered a programming course, teaching Turbo Pascal 7.0. I ended up getting a version of that to use at home on the laptop, but since this was before the Internet was common I was kind of stuck as to what to do next.

I ended up reading about Mandelbrot fractals in the library, and they were very simple to make. I’m not sure where in the Turbo Pascal examples I found working code to do graphics-mode things, but I did, and eventually I had a program that could make fractals in full 320x200x8bit Mode 13h VGA glory.

Of course, I couldn’t for the life of me figure out how to save them to disk. I still had a lot to learn. ;) I think I had ended up getting a working PCX image writer before I was able to figure out Windows .BMP.

That gentle sloping introduction to programming was much better than teaching languages like Logo or more formal courses in my opinion. Results were almost instant, the problem setup was fairly easy, the output looked much better than plain old “Mad Libs” type of problems, and there were plenty of opportunities for improvement to explore when I got bored.

So even though I’d had an introduction to programming earlier with the Apple ][c+, it wasn’t until I came upon Mandelbrot’s magical fractal that I started seriously investigating how to program, or why I’d want to.

So here’s to you Dr. Mandelbrot. Thanks for always looking further into what happens when you zoom just a little bit closer…

Posted by mpyne under Personal | 4 Comments »

So. Matthias Fuchs of “Speeding up KGet with Callgrind” fame pointed out to me on IRC the other day that KIconLoader seemed to still be using a lot of time to load icon image data, even when the icon should have already been cached.

I managed to confirm the issue. Turns out that when I ported KIconLoader to use KSharedDataCache, I didn’t employ KIconLoader’s other cache (a pixmap cache [1]) in all the instances where it made sense. Specifically, the pixmap cache only had things added when an entry was also added to the KSharedDataCache.

But this doesn’t always make sense. The KSharedDataCache is shared across all KDE Platform-based processes, but there’s a different pixmap cache for every KIconLoader. So, it’s perfectly possible to have many processes never have to add an icon to the KSharedDataCache.

Now, new pixmaps that are read from a KSharedDataCache are added to a KIconLoader’s own personal pixmap cache to avoid trying to search the KSharedDataCache next time. This has the potential to significantly speedup icon-based operations, especially in situations where an application uses the same pixmaps over and over. This speedup is in trunk (future 4.6) and will also be released with KDE Platform 4.5.2.

Matthias (and Ingo Klöcker) provided another speedup, by converting some slow QString-based operations to use a QStringBuilder class introduced in Qt 4.6. This gave an 8% speedup on an icon microbenchmark, so not insignificant. This one will only be in KDE Platform 4.6 at this point, although I wouldn’t feel horrible if it were to be backported also.

Incidentally, this was the first I’d heard of regarding QStringBuilder, so it’s something I’d recommend brushing up on if you haven’t heard of it yet. The QStringBuilder documentation is part of the QString API reference (search for “More Efficient String Construction”).

[1] Every KIconLoader instance also has its own pixmap cache, which holds QPixmaps, while KIconLoader’s KSharedDataCache holds QImages.

Posted by mpyne under C++ & KDE & Programming & Useful Tricks | 2 Comments »

Unfortunately I haven’t made any blog updates in awhile. I’ve been very busy between work and school (and I will likely spend this weekend working on a 20 page project that I’ve written 0 pages for ;). That doesn’t mean I have nothing to report though…

First off, I have renamed kdesvn-build to kdesrc-build to reflect the fact that it builds from Git-based software repositories. In conjunction I released kdesrc-build 1.12 which has various minor improvements, including a few Git improvements.

I’ve complained about my car breaking down. It’s fixed, although I will be selling it now (my wife and I were debating the merits of getting an improved car for awhile before, this incident sealed the decision).

Just today I’ve committed a new feature to JuK, the sadly neglected KDE Software Compilation music manager. Now you can use the scroll wheel in the track announcement popup to quickly switch tracks without having to use the Next/Prev buttons. It’s probably already in every other media player with a playlist, but it’s at least in JuK now. Note that this is a 4.6 new feature, not 4.5.

I’ve also been “reviewing” a patch to further remove Qt3 support code from JuK, which I will try to clean up and get comitted this release cycle. The big thing I still need to do is to finally convert from K3ListView to a real Model/View architecture to finally be rid of Qt3Support. Help is always appreciated btw =D

Burkhard Lück, the documentation super-hero, has been improving JuK documentation for me, but I still need to make some changes that he’s requested to bring the docs closer to 2008-era (let alone 2010) :(

That’s another good “intro to KDE Platform” kind of job by the way, it’s how I got introducing into coding for JuK myself. ;)

Posted by mpyne under KDE & kdesvn-build & Programming | 4 Comments »

So… the engine on my Chevrolet Aveo abruptly stopped working today. Always a nice experience!

After getting it towed to a local mechanic who asked what happened, I related how the engine pretty much just stopped, all power-assist features went away, but the electrical gear still worked fine. I also told him that I was thinking it was probably a belt that broke or something.

• The good news: I was right! :( — Specifically, it was the timing belt.
• The bad news: The engine on the 2004 Aveo seems designed to self-destruct in this particular failure mode. Initial best-case estimates for damages are in the range of $1500.
• The worse news: This is a known problem for 2004 Aveos (my model year). For instance, try Google searching for aveo timing belt and be absolutely amazed at all the 2004-specific hits that pop up.

My car was at about 53,000 miles, the timing belt was supposed to be replaced at 60,000 miles (and had been inspected sat at around the 30,000 mile point). I even bothered having regular maintenance performed. Apparently Chevrolet knew about problems with the timing belts, as indicated by a Technical Service Bulletin 06-06-01-021 (the summary of which can be found at the National Highway Transportation Safety Administration 2004 Aveo TSB listings). I don’t have access to the full text but apparently GM would pay for the belt to be replaced (sans labor) before 55,000 miles, but that offer has since been rescinded.

So I called Chevrolet customer service, who essentially told me to go pay for the car to be towed to an authorized dealer, pay for an official inspection of the damage, and then they would decide whether they would show any responsibility for the damage caused. I’m OK with paying to have the car towed, and even to have them perform their inspection, but not without some measure of what I can expect to get in return besides “we might pay for part of the repairs”. Especially when the non-dealer shop is refusing to mention “best-case” prices below $1500! I don’t even want to think of what the “authorized dealer” would charge to fix their own shoddy parts sourcing. For that matter, I wonder how it is that GMAC Financing and seemingly every other GM-related subsidiary never had problems sending me junk mail, but receiving fairly serious technical bulletins describing engine-totaling casualties was left out of the mailing loop.

So this is my warning to you, if you have a Chevrolet Aveo, get that timing belt replaced probably every 40,000 miles or so (30,000 might not be bad either) until you can feasibly get rid of the car. One of my friends always made fun of me for buying a Chevy, and now I see exactly how right he is… Sayonara, General Motors.

Posted by mpyne under Personal | 5 Comments »