About Lectures Research Software Blog
Musical Site

Moods Blog

Dojo Shin Kaï

RSS Feed
Thank you!

XHTML 1.0 conformant
CSS 2.0 conformant
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff.


Entries feed - Comments feed

Monday, October 6 2008

Ucopia vs. Utopia

Il y a des captures d’écran qui parlent d’elles mêmes... :-)

Wednesday, September 3 2008

The hell with MuckPorts !

That's it. I'm done with MacPorts. Fink is the Way To Go (tm).

One year ago or so, I had come to the conclusion that I needed both of them on my machine: Fink was not very up-to-date, but at least it could provide binary packages ready for my Mac. On the other hand, the MacPorts had some bleeding-edge techno that I needed from time to time, but I had to compile everything on my machine which is absolutely ridiculous (have you tried compiling ghc recently ?).

But let's face it. MacPorts maintenance is a nightmare. I think that in one year, I could never reach a fully functional MacPorts installation. Let alone the regular buggy ports which can't even compile, I'm talking about the variant/dependency mess: impossible to upgrade the whole thing because there's always one package that depends on something that conflicts with something else; impossible to remove anything, including obsolete package versions and worse, including inactive ports, because there's always one package that depends on what you want to remove, even if you just want to remove an inactive variant.

For me, the result was an ever-growing installation with duplicate packages everywhere (sometimes, 3 or 4 different and unremovable versions with only one active). Yesterday, I eventually blew my last MacPort fuze when it hanged while deactivating whatever version of aalib, effectively freezing my installation: impossible to upgrade, remove, activate or deactivate anything. I then ended up orgasmatically typing "rm -fr /opt/local/", and you know what ? It felt good !!

Maybe I've missed something from the start. Maybe it goes smoothly for everybody else but me. But this boils down to the same conclusion. If I have to read 3 tons of documentation, semi-obsolete obscure wiki, FAQ, or web forums (oh boy do I hate them) to have the MacPorts behave, the hell with them. I want something that just works.

So here's the thing: Fink is the way to go. As of June 2008, Fink is ready for Leopard and Fink "just works". Yes, you still have to compile things at home, but it's starting to provide binary packages for Leopard already. And what's more, you get the apt/dpkg machinery (for an old Debian user like me, this is cool) because the guys are clever, you know, like, they didn't reinvent the wheel and decided on a package management system that "just works".

Here's my little advice if you want recent free software from the Unix world on your Mac 10.5:
  • download the Fink 0.9.0 binary installer and run it.
  • run "fink configure" and be sure to tell it to use binary packages if available, and to activate the unstable branch as well.
  • run "fink selfupdate" to get the latest point release. That will also let you use the rsync updating method afterwards.
  • run "fink selfupdate-rsync" to get bleeding edge stuff. This will also let you switch to the rsync upgrading method by default.

That's it ! Watch it populate your /sw/ directory... If you have Apple's X11 installed, Fink even provides system-xfree86 packages automatically. These are virtual packages for satisfying applications that depend on X11. You don't have anything to do; you can go "fink install gimp" right away.

Ah yes, one last piece of advice: the binary distribution is far from complete, so when you're looking for something, you'd better get used to use fink instead of apt, because you'll get much more information on what's available that way.

Fink about it man, fink about it !

Wednesday, March 19 2008

Domain Registry of America (for idiots)

I'm quoting this letter from DRoA that I've been receiving each year for some time now. It's called "Domain Name Expiration Notice", but would be more appropriately entitled "Domain Name Extortion Notice", you'll see why:

As a courtesy to domain name holders, we are sending you this notification of the domain name registration that is due to expire in the next few months [...]

This guys are soooo kind with us, domain name owners, that they even care to propose to switch the domain name to their company, for 26 euros a year, whereas I'm currently paying 5 euros for the same service. What else could we ask for !

I guess these guys were put to trial before. I remember the first letter I received from them; it was much more agressive and ambiguous; like "***WARNING*** if you don't renew your domain name RIGHT NOW by filling this form (theirs ;-)), your domain name will be lost". Now, instead of that, the warning says "This is not a bill"...

On the other hand, if they really send this spam by postal mail to every domain name owners in the world, no wonder they need to charge 26 euros a year !

Il y a un vers dans mon Orange

Le logiciel de messagerie d’Orange doit au moins être écrit en Visual Basic sous Windows Vista... voici mon dernier message:

"888" messagerie Orange: le / / à : ce correspondant
a appelé 0 fois sans laisser de message.

Moi je dis qu’il aurait quand même pu laisser son numéro, pour que je puisse le rappeler 0 fois. Il y a des gens qui ne sont pas polis.

Tuesday, October 23 2007

FP & DL: the future of OO (OOPSLA'07 again)

Some cool surprises at the "Celebrating 40 years of language evolution" panel this morning...

Under the general assumption that the next challenge to come in computer science is distribution / concurrency, I was quite puzzled to notice a general agreement from the panelers that the future in programming languages is going to be more functionnal than ever. I was not puzzled because I don't believe that will be the case (of course I believe so); I was puzzled to hear that coming out loud in a conference on Object Orientation.

Of course, it's not so surprising once you realize that there are people like Guy Steele among the panelers, but still, you know, it's comforting. It's good to hear. I'm also thankful to Guy for mentionning Lisp twice during the panel, once when talking about the Yahoo Store originally written in Common Lisp, and the next time, to compare Lisp to a black hole: once a language begins to look like Lisp, it is irrevocably sucked into it. Sure thing. Nobody blinked. Like if the whole crowd knew Lisp was the answer, and had nothing to reply. Strange feeling :-)

And the same guys, right in the open, complaining because the problem with OOPSLA is that there are too many papers on how to add XXX to Java. How cool to hear that! I wish they would go to ECOOP and say "the problem with ECOOP is that there are too many papers on how to add YYY to Eclipse"...

And then there was this guy from Microsoft, declaring that he was amazed at what the dynamic languages folks were doing, like meta-programming and stuff, and he believed that what we do in dynamic languages today is what will be done in static languages in the future.

Well, you know, after a panel like that, life suddenly seems beautiful.:-)

OOPSLA ! But no cigar...

So, you know, OOPSLA is a nice conference (it's nicer than ECOOP, by the way). Apart from one thing. Today I was deeply shocked when I discovered that lunch is not included in the conference fee (only people attending tutorials get to eat something).

This is the first time ever that I attend a conference, especially of that size, which doesn't provide sustentation for the attendees. A true scandal, if you ask me.

On the other hand, if the food is what I believe it is, seing the guys coming out of the lunch room, I think I'll consider myself lucky to have to get food by myself...


Wednesday, August 22 2007

WMSCI 2007

Again. The Nagib Callaos mafia hit me again :-) If you don't know WMSCI (the World Multi-Conference on Stupiditics, Catastrophics and Idiotics) yet, you should. That's the one and only conference where randomly generated papers are accepted.

So I just received this email again:

From: Reviewers Conference <wmsci2007.reviewers@iiis-info-cyber.org>
Subject: Thank you for your commitment to support us as a WMSCI 2007's
Date: 16 Aug 2007 15:09:36 -0400

Dear Didier Verna:

On behalf of the Organizing Committee of The 11th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2007), I would like to thank you very much for your commitment to support us as a WMSCI 2007's reviewer.

You are one of our few cases who did not receive from us a notice for their possible support in the conference reviewing process. The causes were the lack of submissions in your area and/or a bug we found in the program by means of which a random selection of the reviewers were made in the last conference. We are fixing this bug so it will not happen again in the future.

We would like to inform you that we maintained your name among the reviewers of the WMSCI 2008 conference. If for any reason you will not be able to support us, as a reviewer of the next conference, we will highly appreciate your information about it by means of a reply to this email.

We really appreciate your co-operation, and we hope we will have your support again for WMSCI 2008.

Best Regards

Prof. Nagib Callaos
WMSCI 2007 General Chair

So you know, the bug must be damn hard to fix because I'm receiving this email every year since at least 2003... But yeah, I'm gonna support them again, by not reporting this as spam, as I should.

Tuesday, February 15 2005

Why configure scripts should go in repositories

With the spreading of revision control systems (CVS, PRCS, Subversion etc) and the benefits of using the autotools for project management and portability, there has been some debate on whether to put automatically generated files in project repositories.

Personally, I've had this argument several times, with different projects leaders (most notably with the BBDB maintainer at the time I upgraded BBDB to autoconf 2.5*). In this article, I'll try to explain why (certain) generated files should go in the repository.

If you're wondering whether such or such generated file should go in your repository, there is a simple rule of thumb:

"what goes in the distribution goes in the repository"

This applies consequently to files generated by the autotools, like the configure script, but not only to them. In the discussion below, I might be speaking of configure in particular, but you should keep in mind that my points apply to many other files.

Some people think that no generated file should go in repositories. They are wrong. If you're not convinced (by my simple rule of thumb), read further, I hope to have you change your mind. I'll give some personal arguments below, and I'll also show how irrelevant arguments that have been thrown at my face are.

Personal arguments

Different kinds of "generated files"

Makefile's are generated at build time, and depend on the user environment. They're very likely to be different from build to build so it is obvious to exclude them from the archive. configure, on the contrary, is the same file for everybody so it makes a lot of sense to have it in the archive. Put it another way, why would you require every single person using the repository to rebuild the same file locally?

Building configure requires autoconf

And this might be a problem in several ways. There is an undeniable fact these days: more and more people give up tarballs and use repositories directly, either to stay on the bleeding edge, or just to simplify the process of getting the latest patchlevel for their stable version of the software. It's easy to realize: just look at sourceforge and other similar hosting services to see how common and popular public repository access has become. And this is normal: if you upgrade frequently, you save a lot of bandwith by downloading only the parts that have changed.

So the current trend is to actually use repositories not only as development facilities, but as a distribution mean as well. In other words, not only developers but also end-users make use of repositories. Given this fact, it becomes obvious that you need to put in the repository exactly what goes in the distribution. The whole point of configure is precisely that once generated, it becomes independant from autoconf. So you don't want to require a working installation of autoconf from each of your users.

Building configure requires the right version of autoconf

The situation is even worse than that: having a working autoconf installation is not sufficient in general. You have to use preferably the same version as the one configure.[in|ac] was written for. For example, upgrading from the 2.14 to the 2.5* series is a major backward incompatible process. Of course, autoconf attempts to maintain compatibility on surface. But remember that it's just a macro package. This means that, almost by nature (the same applies to TeX or LaTeX development BTW), it is nearly impossible to use just the surface of autoconf without having the need to hack something on top of the internals, thus bypassing the standard API. And the internals evolve constantly. That's why in actuality, you often need to follow very closely the version number.

Not distributing configure in the repository thus means that you actually force your users to upgrade their installation of autoconf before upgrading the software they're interested in. And what if they also follow another piece of software that makes use of another version ? How many versions will they be obliged to maintain at the same time?

What I've been retorted

"configure is hudge. It's silly to keep generable files that big in a repository."

OK. The biggest configure script I know of is probably XEmacs's. It's about 500Ko. Most other scripts will probably be smaller. Now, given that we're speaking of a machine large enough to run a revision control system service such as CVS or Subversion, what is exactly the point in trying to save 500Ko?

"configure is hudge. It's silly to download generable files that big at each checkout."

First of all, configure scripts do not change very often compared for example to changes made to the project's sources. And the point of downloading from a revision control system is precisely to download only the things that have changed. So you actually don't download configure at each checkout.

Second, remember that running the complete autotools suite (most of the time, autoconf is not enough. You also need to run automake, aclocal, libtool or whatever through a bootstrap script) takes time. I wouldn't be surprised if on most boxes, the time to download already generated files is actually smaller than the time required to regenerate them.

"I don't want to see those generated files appear in diff outputs"

Abso-fraggin-lutely. And this is not very difficult to achieve: first, it happens only when you do a plain diff, without specifying the involved files. Otherwise, there are plenty of wrappers around diff commands that filter out unwanted files, plus other bells and whistles, and even options for ignoring files in many revision control systems. So this is not a problem in practice.

"Having configure in the repository generates a lot of conflicts."

That's the most frequent argument that I've heard, and it is as irrelevant as the others. If you're just an end-user, you won't ever have to touch configure. Hence, an update of your working copy will just download the delta and apply it. No conflict.

Still, if for some obscure reason, you're getting conflicts, these are not conflicts you want to edit by hand anyway, since the file is generated! So assuming the developers have done their job correctly (meaning: checking in the new configure script as well as configure.[in|ac], actually "fixing" the conflict is as painful as typing rm configure && cvs update. Not much of a burden, is it?

Now, if you are a developer, you might actually get conflicts because of parallel development. But the point is you don't care because this file is generated. What you're interested in is conflicts on configure.[in|ac]. And if you do your job correctly, each tweaking of the source file should lead to regeneration of configure and friends. So the previous paragraph applies here too.

Well, I think that's about it. I hope that you're convinced now. And remember: what goes in the distribution goes in the repository.. It is as simple as that.

page 2 of 2 -

French Flag English Flag
Copyright (C) 2008 -- 2018 Didier Verna didier@lrde.epita.fr