Older blog entries for pfremy (starting at number 15)

diff is unintuitive

diff is a tool you use without even thinking about it. Given its age, you assume it to be robust and to use the best algorithm. However, reading the documentation about python diff library, I discover that it produces unintuitive set of changes.

Let me show you.

This is a1.c :

if (a) {
	// x
} else {
	// y

This is b1.c:

if (a) {
	// z

if (a) { // x } else { // y }

How would you intuitively go from a1.c to b1.c ? Obviously, one has added a new statement "if (a) { // z }" in before the existing one.

However, if you pass it through diff, you will get:

--- a1.c 2003-04-29 13:28:15.000000000 +0200 +++ b1.c 2003-04-29 13:28:30.000000000 +0200 @@ -1,5 +1,9 @@

if (a) { + // z +} + +if (a) { // x } else { // y

According to diff, you have modified the inside of the then statement of the test by adding some content, which contains half of the new then statement, an end of statement and a new test.

Both results are correct. But one is more intuitive to the programmer than the other.

The diff library of python would produce the intuitive result. How come ?. The algorithm of the diff python library is to find repeatedly the Longest Common Subsequence (LCS) of both files, until all the common parts have been found. When there is no LCS left, everything remaining are differences. The common code "if (a) { // x } else { // y }" gets identified as common and the rest gets identified properly as difference.

The algorithm of diff is different. Basically, it scans the file as a stream for common lines. When it encounters a difference, it looks forward to find the next common lines. Everything in the middle is a difference. This is why diff has hooked the first "if (a) {" as common to both file and had included in its difference everything until the next common line.

So, don't trust your tools blindly. Although they may be old and respected and robust, someone can still do better. Anyone wants to rewrite to diff so that it produces the most intuitive result ? Given the importance of diffing in producing software, producing more intuitive diff is an issue.

Philippe Fremy

Qt and murrayc
I read your flame/debate with Guillaume.

You are at least obviously wrong about one thing. You stated multiple time that Trolltech would prevent you from porting Qt to windows or MacOs X.

Qt is released under GPL so there is no way Trolltech can prevent you from doing anything with it. You can twist the code the way you want as long as you stay GPL. And in fact, Qt is being ported on windows and Trolltech is aware of it. See: kde-cygwin.sf.net

Right now, the project require cygwin and X11 server. But there are plans to port Qt to native win32. I remember a project one year ago where a Mac hacker said he had the GPL Qt running on MacOs X in one day, and was planning to port it on MacOs 9 since it was so easy. Seems like he did not do it.

So you could prefectely wrap Qt using libsig++ instead of their signal/slot system :-)

Another thing that many people seem to miss is that Qt is GPL but if Trolltech does not release a new version in two years, it becomes BSD-licensed (see the FreeQt foundation) so you can use it in any kind of commercial close-source product . You get the same protection against 'what happens if the company goes bankrupt' as for any open source project.

A final point: I agree that you have no true development list for Qt as for other project. But their direct support is very good and they even provided it to me although I had no license (at that time). Some of my feature-requests have been taken into account and many of KDE's requests/problems are dealt with by Qt.

So the development is not as open as you could with but it does not prevent you from benefitting of the result. In fact, I would be ready to trade some openness of many open source projects for more stability/quality (with the source still fully available and modifiable of course).

Random thought
One thing cool with C code (and probably an advantage of native Gtk over Qt) is that compiles fast. Damn fast in comparison of C++ code. Add ccache power to that, you it compiles at the speed of printf.

You should really have a look at KPart and its internals. All the problems you describe have been faced and solved by KDE.

I understand the component activation is quite tricky, espcially if you plan to have two components displayed in a widget. Get in contact with David Faure and Simon Haussman (or simply kde-core-devel) to see if they can provide you some insights.

Slashdot interview
Scott Tape said in the Slashdot Interview:

In my experience, programmers like to write code. Period. They don't like to write documentation, they don't like to write system tests, and they don't like to write unit tests. Programmers are also optimists--how else could they tackle building these enormously complex systems and think they had any chance of working? Programmers like instant gratification (who doesn't?). They enjoy coming up with a solution to a problem and seeing that solution implemented immediately.

Because programmers are optimists, that is reflected in their unit tests. Time and time again I've seen developer-written tests that demonstrate the feature works -- because the tests reflect the thinking of the developer about how the feature will be used. They rarely do a good job of testing corner cases, limits, or "unusual" situations (like running out of memory or other finite resources). </blockquote>

While all the remarks are good, the conclusion that programmers will not enjoy test first methodology is wrong. To my surprise, I have enjoyed it a lot. Here are some arguments :

  • Programmers like to write code : programmers write even more code with test first methodology
  • Programmers enjoy solving technical challenges : building a system so that it can be fully tested is a technical challenge wich makes the test system as interesting to write as the code for the sytem.
  • Programmers enjoy instant gratification : having one's test run successfully is instant gratification and programmers enjoy it a lot. It may sound silly but I enjoy seeing my
     Result 37 / 37 successful test, 100% test pass
    . And I like seeing the number of test (== feature) moving forward. Means I am actually doing some measurable progress in my application
  • writing tests is boring : it is boring if you write them once the application is ready. If you write them before your code, it gets interesting because it is equivalent to writing code. At some point, writing the test gets more interesting than the code, because the code "just runs the test, you know, not very exciting".
  • corner case are not tested : in test first, it is recommended to test the corner case before the normal case. That way, they are a lot easier to deal with, and you are not tempted to skip them. Having plenty of tests already working also helps in building tests for corner cases. When it is just about calling 3 tests in a row and adding 10 lines of code, corner case testing is a lot more common.
  • Geeks like to achieve good work : Having the system running many tests successfully is rewarding. You know that your system is fully working and tested. It will be easy to maintain and extend. If you modify it, just runs the tests to check that it is still working. This is really reassuring.
One week ago, I have submitted an article for posting. Since then, I have no news. I don't know if my article is waiting in a long queue for moderation approval. But that seems improbable given the sheer number of articles that get posted these days.

I can suppose that it has been rejected but I have no mail to confirm this. And if it has been rejected, I would like to know why. I have invested my time to write a reasonably good article. I find it certainly more interesting than the latest Advogato users are lame.

For a site about open-source, I would expect the processing to be more ... open.

There is a lot of FUD going on about Qt these days. Four years ago, people would complain that Qt was not free. Now, they complain that it is too free and it forces you to write free program. How evil!

I would like to remind a few points:

  • RMS recommands GPL for library the implement something that is available already in a non-free form. Clearly, Qt stands there. So it should have RMS's blessing now.
  • Qt is GPL. There is no license issue around it anymore.
  • Many free software bigots like to brag about how free software gives you more freedom and more choice. In this specific case, the GPL version of Qt does not let you choose the license for your application, which could be seen as a restriction of freedom as a user. However, if you pay, you can have all the freedom you want.
  • Some people would like you to believe that Qt is not suitable for commercial appliation because either it is too expensive, or it requires to develop a GPL application.

    Well, some business model can work very well with a GPL application. So in that case, Qt is free (if you use the unix version) and the argument does not apply.

    For the other point, if your business can not afford a version of Qt or a version of PyQt (a lot cheaper, see the PyQt website), then your business has a serious problem.

    If your business makes real money, then giving back to Trolltech to help make Qt better is a good idea. I don't see why we should support people that make money off the hard work of others without giving back. When you use Qt in a non free environement, you are forced to give back. And Trolltech gives you back too, every version of Qt has new wonders.

For the record, I have built with friends a small business based on Qt and it was successful (see www.yalbi.com). It is perfectely possible to use Qt in a commercial environment. In fact, if it wasn't, I wonder how Trolltech would have survived all these years. Trolltech does not have any VC money, it is self-funded. So it is profitable thank to all the business that use it.

I have even used Qt to do windows-only program. It is a lot better than MFC, .NET or VB and in the end, it is a lot less expensive. What you pay for the license, you spare it on your development time, feature richness, maintenability and royalties (many windows libraries have royalties scheme).

My first time configuring procmail. I really wonder what the author was smoking when he designed the syntax. I understand better the old saying : LSD and Unix both come from Berkeley. This is no coincidence.

How can someone make such a braindead syntax ? ':0:' means use a lock file when delivering. ! means forward to an address. My God.

Anyway, the good part of it is that it is very standard, fetchmail can deliver directly to procmail. And once you have set-up the basic rules, you won't touch it often. So it is more or less ok.

Now my spam is all filtered out. MMh, what a delight. Thousand thanks to bogofilter and Paul Graham.

I am using and patching CppUnit. This is such a beast!

CppUnit was developed after JavaUnit, which was developed from SmallTalkUnit, which was written by the author of Extrem Programming. I think something has been lost somewhere on the way from SmallTalk unit to Cpp Unit.

Some core principles in Extrem Programming are:

  • use the simplest design that work
  • you are not going to need it
  • refactor mercilessly
  • do things only once in your code

    I look at CppUnit and I see exactly the opposite of this. Ironically, CppUnit is used to develop test suites in the Extrem Programming spirit. Briefly, CppUnit has:

    • a very complicated architecture. There are so many classes that delegates anything to another one that you don't get a clue about who does what.
    • lot of empty classes. This comes from historical reasons I think. They changed the internal but kept the classes around.
    • lot of duplicated interfaces, probably for the same reason
    • despite so many classes, it does not have extensiblity where I need it.

    It looks to me as the typical example of over-engineering. People have read Design Pattern and they want to apply it desperatly. And they also read about templates and want a maximum number of them.

    CppUnit should fit in 3 or 4 classes. No more. I'll rewrite it one day.

  • Free Software Happiness

    Yesterday, I looked around at Free Software and I was happy.

    Three years ago, if you had asked me about the state of Free Software, I would have given a reluctant answer. Yes, there were good developments on the server side. But the desktop was really poor compared with Windows or Mac.

    But yesterday, I looked back at what has been achieved and I was happy. Most of the problems are either addressed or under active development. The things that pleases me (non exhaustive and in no particular order):

    • X: the old beast was seen as a major stopper for further development of graphical software: no hardware accelerated drivers, very old and big codebase, no anti-aliasing, no fancy cursors. But time has proven that the beast can be improved and bring high quality desktop environment. We even have promises for better quality desktops than in other OS.

    • supermount: you can now insert your floppy, type ls /mnt/floppy, change your floppy and type ls /mnt/floppy again. What a delight. Manual mounting of removable devices is has not been jutified since ages.

    • USB hotplug: ok, I heard it does not work perfectely but we are not far from that. What a world between today and three years ago.

    • journaling FS: you can boot quickly, you can turn off your computer, no more five minutes of waiting in front of a fsck.

    • KDE/Gnome: we now have a good deal of graphical software, with (and this is the most important) a consistent look'n feel. No need to relearn GUI when switching from XFig to xv.

    • good distro installers: all major distro are now at the point where it is easier to install linux than windows. Dynamic resizing of partition was heartily welcome.

    • Cups: we can manage printer in a modern way. This is the kind of services improvement I expect from technology.

    • Evolution: we have a clone of Outlook, so people can have a very smooth transition from windows to unix

    • Samba: really mature stable integration into windows environement

    • OpenOffice: we can finally have a reasonable alternative to Microsoft Office, on windows or Unix.

    • France: I see with joy Free Software making a way through the educational system. The governement has some recommendations for Free Software. Almost all major IT magazines have had a special edition for Free Software.

    • Germany: some companies have had a public contract to improve KDE the way the governement wanted it. I couldn't dream for more.

    • Other countries: many good stories with Free Software in other governements, like Peru, Spain, ...

    • mplayer, xine: we can play DVD with almost the same facility than in other OS.

    • IBM is comitting to Free Software with strong support. They do help a lot in ways that no individual or project could. That is great.

    • Virii: windows has seen many virulent virii those last year. There are more and more spyware and unwanted software on anybody's windows. People are starting to realise the interest of controlling his computer.

    • Gnome/KDE integration: common dock application, common description of application, this is the present. The future looks bright. I am eagerly waiting for common themes, common mimetype databases and things like that. It will arrive one year of the other. It is unavoidable and needed.

    • Sourceforge: you may critisize certain aspects of it, but sourceforge is a great repository and incentive for free software. It is very easy to now get the necessary infrastructure for any project.

    There are progress for which you must really be a geek to appreciate:

    • Mozilla: certainly the most powerful browser for geeks. If you want a browser feature, you certainly have it in Mozilla. And it works on windows!

    • bogofilter: this made my day. The final weapon against spam has been found. I can't wait to see it in action on my mail account.

    • ssh, ssl, https, gpg: we are using advanced crypto tools. We are the future.

    • gentoo: the coolest distribution ever. Distro self-compiling and bleeding-edge packages are great. For me, it cumulates the advantages slackware, debian and mandrake, with none of the problems I had with these three.

    • linux: some really interesting stuff in the future stable kernel. We are on the way to kernels superior to major competitors.

    • Konqueror: the best integrated ever. You can rip a CD, browse a ftp site, browse the web, browse your shares, preview many types of files, manage CVS, ...

    • CVS and co: despite a few problems, CVS rocks. Very lightweight and stable client, ssh connections, mail with diff of commits, web browsing of repository, concurrent modification of the same file, CVS is years ahead of what my company is using for managing its software.

    • ccache, distcc, ValGrind and CacheGrind: those are very powerful developers tools that have no equivalent elsewhere.

    • cool tools: this is not new but perl, python, cron, ssh, cvs, grep, bash, find are really good tools that can be used for plenty of things.

    • Linus uses bitkeeper: some see it a failure for Free Software, but I am just so happy to see Linus finally using a revision system. Makes it much easier to follow Linus developments, to patch, to fork, and so on. I am sure this improves the kernel quality.
    We are going to take over the world. I did not doubt it, because you can not stop Free Software. But now I am seeing it happening and I fill the chill.

    There are still progresses to be made in development tools. IDE with tight integration of every development tool (gcc, make, gdb, CVS, ...) are seeing the light, but plenty of progresses can be made. I am also waiting for a good C++ refactoring tool.

    I wonder why everything I post is interpreted as an agressive move. Too sensible subjects ? My bad grasp of english ? I thought I had written this last diary entry with a clearer intent. I question Eazel's contribution to Free Software, not Nautilus's capabilities. And yet I am attacked on Nautilus.

    Thomasvs Here are a few points : You specifically mention Nautilus 1.0 without mentioning that this is the OLD Nautilus developed by Eazel. All your points are ONLY valid about the OLD Nautilus, and even then they're skewed at best.

    I thought it was obvious that I am referring to the old Nautilus developed by Eazel. I was referring specifically to an interview where all the modifications that have gone into Nautilus 2.0 are explained.

    Why don't we compare KDE1 or KDE2 Konqueror with the Nautilus you bash ?

    The thing I was willing to compare was specifically the development made by Eazel, not the features of Nautilus 2.0 . Something equivalent to compare would be for example the developments made by the Kompany. They have the same problem, they usually do not use KDE's technologies. They do not integrate much with KDE. TheKompany now develops everything using Qt only, so KDE integration is even more limited. Just like for Eazel.

    One big difference between TheKompany's contribution to KDE and Eazel's contriubtion to Gnome is that none of TheKompany's applications are named "core KDE applications". The fact that they are not under a free licence certainly helps. :-)

    Yes, you are right that the original Nautilus 1.0 developers didn't put integration with the rest of GNOME high on their priority list. That is because Eazel was foremost a COMPANY trying to make MONEY on Eazel services served by Nautilus.

    Which was exactly my point. I was not willing to discuss further than that. Now another question is, should Gnome accept this ? Given that Eazel did not care about Gnome's goal, should have Nautilus been in Gnome ? My personal answer is no. I have no problem with any company making money building an application that does not integrage with Gnome, but then it should not be distributed as part of the Gnome desktop. This is contrary to the goal of the dekstop thing.

    Now, the maintainers are spending effort to integrate Nautilus properly. Had the eazel guys done Nautilus the right way, this effort could be spared.

    You say "it is not possible to reuse parts of it". Well, ha ha ;) All code that is reusable has been abstracted out into other libraries which now are used throughout Gnome.

    Are you speaking about Nautilus 2.0 or Nautilus 1.0 ? I was referring specifically to Nautilus 1.0 . I understand from the interview that most of the problems of Eazel's Nautilus are being addressed. That's good news.

    Anyway, I made my conclusions based on the interview I read. This is not the result of a five month research on Nautilus, but a diary entry reflecting what I understand from an interview. The interview makes it clear it is not possible to reuse the icon view of Nautilus. I find this surprising because Gnome has all the technologies to make this possible. Does Nautilus (1 or 2) use bonobo in any way ? I thought this was exactly the thing bonobo was created for.

    You should have picked another application to try to bash on integration issues, because Nautilus is a really good example on how to do integration nicely.

    I am still under the impression that Nautilus integration into Gnome could be far stronger than what it is.

    You do both KDE and Gnome a disservice by trying to instigate some sort of fight based on very skewed assumptions and giving a lot of reasons that are easily disproved. Code talks, and my code disproved your point.

    Sorry but I was talking neither about Gnome, nor about KDE but about the way Eazel contributed to the Free Software. I think they have missed the culture and people like the current Nautilus maintainers have to come after them to clean things up. That's a pity.

    I think Ximian did a far better work with Evolution. Not only do I find evolution more useful than Nautilus, it also integrates properly with Gnome.

    6 older entries...

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!