François Pinard's site |
||||||||||||||||||||||||||||||||||||||||||||||
Pseudo-blogA transient storing device for personal mumblings and miscellaneous thoughtsWhy do I call this a pseudo-blog? In a real blog, entries are permanent, and visitors may freely add their own comments. While here, entries are transient, likely to be modified, reattached elsewhere in my Web site, or plainly deleted. Comments may be emailed directly to me. A table of contents appears at the end of this page. The blog entries are themselves selected from my published notes, for which there is also a table showing the most recently modified entries. In reverse chronological order as well, you may find some recent Twitter tweets, and a diary of my humble explorations about images and sounds (in French mainly). The blog entry sources, previously held in reStructuredText format, have been translated as Tomboy notes. Little glitches from this conversion will be polished out over time.
Notes, sites, methodsEquilibrium is difficult between functionality and simplicity. I always put some effort at automating various own elementary work methods, especially around management of my schedule, taking and handling personal notes on a flurry of subjects, and the maintenance of many Web sites. Seen at a distance, over the years, my methods in these area widely changed. More locally, the transition has been rather smooth and progressive — drastic changes may be accomplished through a sequence of careful changes! The time has come to renew a snapshot of my work methods.
1 From email to notesFor a very long time, my work methods revolved around email and Usenet news articles, which have almost the same format, and may be handled with similar tools. Taking notes was akin to saving email or articles into a rather big hierarchy of email folders, creating them on the fly as needed. Agenda items were essentially postponed email reminders. Emacs was used to drive this all, linking all parts together, with efficient completion to folders, and a lot of indexing and searching machinery. Lars' Gnus had been an extraordinary good reader for me. Yet my overall Emacs customization progressively grew in complexity and became daunting. Then, from Emacs, Gnus and Lisp, I switched to Vim, Mutt and Python (see Thoughts on editors), and successfully rebuilt in there a powerful, comparable setup. This has been a big change overall, which produced easier paths to the honest exploration of a wider set of working avenues. In particular, this is how I ended replacing Mutt by Thunderbird, and tamed myself to many simplifications. My note taking habits started to grow significantly with Thinktanker type tools, like with standard Emacs Allout and, later, my Vim Allout, While I used Allout for many things, some being big (like writing books), email stayed predominent in my habits. However, Tomboy progressively took over Allout for me (see Passage à Tomboy), and is interesting enough that I really started to shift importance from email to note taking. While almost all of my Allout has been converted to Tomboy by now, I still have a great deal of saved email and articles which I'm slowly, progressively summarizing into Tomboy notes. Whenever possible or easy, I now prefer saving information into Tomboy notes rather than email folders,. Thunderbird is quite useful for managing such email archive folders. For day-to-day email duties, I'm still a bit torn between Thunderbird and Gmail, yet I guess Gmail is advantageous overall. 2 Origin of information
3 My web sites
4 Synchronization issues
5 Daily organization
BONJOURThe old BONJOUR project has been a free-source initiative within the once isolated world of Université de Montréal. (Later, one introduced the GNU project to me by stating it was a planetary BONJOUR!) Despite BONJOUR has long been lost in the dust, it is fun to remember! I found bits and pieces of BONJOUR files and history in my computer files, which I'm now making public to amuse some friends and old participants. This is almost all French, however. In these old files, I found a fairly good description of the project. There is an overall presentation of Bonjour which I found and saved from an old curriculum vitæ. There is also a non-null intersection between Bonjour participants and the Solange group. As all this code is meant for defunct CDC mainframes, operating systems and tools (see Control Data times for some anecdotes), there is no point in exactly retaining the old project structure, so I shuffled things around a bit to increase legibility. I made one HTML page for each project name, and a terse table of contents with pointers for all these names. Each project page has sections hinting at the real origin for the contents of this section. For anyone wanting to scrutinize the sources, the following information might have some use: Compil comes from the COMPIL part of SYSF, Docum0 to Docum9 come from SYSD, Include comes from SYSI, and Source comes from either SYSF or SYSS. (The few SYSF sources are maintenance-related, these are: FAIREB, INS, LAZB, LAZBDIR, LAZI, NPSTAT, PACK, SB, SUBMIT, SUPSYSR, and TX.) File names were limited to seven letters or digits, with no case distinction. Some source management, like conditional code or included files, was achieved through the UPDATE program, using directives like *deck, *incl or *if in the source. Lines were usually limited to 72 characters because of punched cards. We were
experimenting with French support, using
bang-bang code, on a system which was hostile even to
mere ASCII. In the BONJOUR sources now published, all the
bang-bang has been converted to UTF-8. Line sequence
prefixes (each source line beginning with something like
14560=) for Telum EDIT have been eliminated.
SolangeDans les années 1980, le Centre de Calcul de l'Université de Montréal a développé (audacieuse nouveauté pour l'époque!) un système de messagerie nommé MU, qui permettait la création de groupes de discussion. Solange a été l'un d'eux, où les participants laissent joyeusement tomber la pression, sous le couvert d'un pseudonyme. 1 Historique1.1 OrigineLe nom Solange provient de Solange Harvey, qui tenait alors un Courrier du cœur dans un quotidien de l'époque. Au départ, quiconque faisant partie de ce petit groupe pouvait envoyer un message commençant par "Solange, j'ai un problème!", suivi de la description d'une difficulté personnelle, réelle ou inventée. Chaque participant en recevait copie et pouvait fabriquer une réponse. L'originateur était alors gratifié en retour d'une collection de conseils, plus ineptes, farfelus et drôles les uns que les autres. Les pseudonymes n'ont pas protégé l'anonymat des participants bien longtemps. Une sympathie, puis une amitié s'est progressivement développée entre les membres du groupe Solange, et nos missives se sont souvent éloignées du schéma initial, pour couvrir une grande variété de sujets et d'intérêts, avec la gentillesse et l'humour comme trame de fond. Encore aujourd'hui, plusieurs membres de Solange gardent contact, et se connaissent par leur surnom. 1.2 Membres de SolangeIl faudrait bien que j'essaie d'établir la liste complète des membres, mais je n'ai pas beaucoup de mémoire pour les noms. Oh, quelques contributeurs de BONJOUR s'y sont retrouvés, mais on y discutait plutôt d'autre chose. Évidemment, jamais je n'oublierai:
Il y en a quelques autres que ma mémoire ne réussit malheureusement pas à retenir correctement. Ceux qui savent, aidez-moi à compléter cette liste! Solange (je veux dire, les membres de Solange!) doit en théorie se rencontrer avec régularité, à tel jour et telle heure précises à chaque dix ans, an Wendy's sur Décarie ou, si ce Wendy's n'existe plus, à l'hamburgererie la plus proche. Je dois pourtant avoir l'information plus précise quelque part… Mais où?! 2 Citations de SolangeEn classant de très vieux listings imprimés chez moi, j'ai retrouvé quelques citations que les gens de Solange s'étaient partagées, et que je répète ici. Les citations viennent d'ailleurs, bien sûr, mais ce sont de beaux souvenirs pour moi. 2.1 VignaultJamais les fleurs
du temps d'aimer Gilles Vignault, La navette, nov. 81 2.2 Lurette
Voici une vieille
lettre que l'Icule "En ce moment, Belle Lurette apportait elle-même à 4@ une tasse de thé. C'était plus qu'une distinction, c'était une faveur. Il y a, dans la manière dont une femme s'acquitte de cette fonction, tout un langage; mais les femmes le savent bien; aussi est-ce une étude curieuse à faire que celle de leurs mouvements, de leurgs gestes, de leurs regards, de leur ton, de leur accent, quand elles accomplissent cet acte de politesse en apparence si simple. Depuis la demande: Prenez-vous du thé? — Voulez-vous du thé? — Une tasse de thé? — froidement formulée, et l'ordre d'en apporter donné à la nymphe qui tient l'urne, jusqu'à l'énorme poème de l'Odalisque venant de la table à thé, la tasse à la main, jusqu'àu pacha du coeur et la lui présentant d'un air soumis, l'offrant d'une voix caressante, avec un regard plein de promesses voluptueuses, un physiologiste peut observer tous les sentiments féminins, depuis l'aversion, depuis l'indifférence, jusqu'à la déclaration de Phèdre à Hippolyte. Les femmes peuvent là se faire, à volonté, méprisantes jusqu'à l'insulte, humbles jusqu'à l'esclavage de l'Orient. Belle Lurette fut plus qu'une femme, elle fut le serpent fait femme, elle acheva son oeuvre diabolique en marchant jusqu'à 4@, une tasse de thé à la main." Cigit, 1984-03-21 2.3 Rostand"Atome dérisoire, predu dans le cosmos inerte et démesuré, il sait que sa fiévreuse activité n'est qu'un petit phénomène local, éphémère, sans signification et sans but. Il sait que ses valeurs ne valent que pour lui, et que, du point de vue sidéral, la chute d'une empire, ou mème la ruine d'un idéal, ne compte pas plus que l'effondrement d'une fourmilière sous le pied d'un passant distrait. Aussi n'aura-t-il d'autre ressource que de s'appliquer à oublier l'immensité brute, qui l'écrase et qui l'ignore. Repoussant le stérile vertige de l'infini, sourd au silence effrayant des espaces, il s'efforcera de devenir aussi incosmique que l'univers est inhumain; farouchement replié sur lui-même, il se consacrera humblement, terrestrement, humaintement, à la réalisation de ses desseins chétifs, où il feindra de prêter le même sérieux que s'ils visaient à des fins éternelles." Rostand (J.), L'homme. Collections Idées, Gallimard Gigit, 1984-12-04 2.4 Raissa MaritainLe lac Le lac plein de
maisons de verre Depuis si
longtemps en silence Raïssa Maritin, Au creux du Rocher
Twitter thoughtsTwitter is an interesting communication media, overwhelming and terse at the same time. I merely want to summarize bits of my experience using it. 1 On reciprocating1.1 IntroductionTwitter is a strange animal. It is easy to get in and out. There is a wide variety of people, interests and opinions in there. I cannot easily dismiss the value of that diversity, and am tempted to follow many for the only sake of better opening my human horizon and spirit. But I quickly saw that I need efficient means so it does not consume much of the little free time I still have. One may not really appreciate or enjoy the benefits of Twitter without inversting some time in it, so the equilibrium that would best fit who I am is a bit uneasy. So, after legitimate enthusiasm, I got a bit carried under too much pollution of uninteresting tweets, and I was torn between the desire of keeping links, and not spending too much time at evaluating and managing my Following list. Twitter is assymetrical. We do not have to follow back each other. Nevertheless, I quite value the richness of experience that comes out of relations which are not fully volatile, and by following back, I want to increase the probability that it all happens. To some extent, I expect the same from those I follow. Now, there are exceptions. Some tweets are produced by research centers or news publishers; and some people are more of an institution than an individual — I would not expect that such entities reciprocate, I then have the feeling of subscribing in some more traditional way. 1.2 Initial clean outAs a newcomer to Twitter, I've been surprised at first by the high number of followers I got in the first few days and weeks of presence, after only a very modest announcement on my Web site. I followed back everyone, soon shuddering that I would be just unable to give everyboy the attention he (or she) deserves. And indeed, I had not enough free time to keep up with the stream. So, even if uncomfortable, I let the experience mature for a while, long enough to develop some sounded criteria that could drive a revision of who I was following back, so breaking the symmetry. Here there are:
1.3 My following policyFor now, I may describe my current policy for following back by the following points:
Moreover, I may often be slow to reply, as I do not have much free time to do so. 2 Choosing a Twitter clientThe few Twitter tools I initially tried left me on my appetite, really, as they did not give what I needed to handle my initial flow of Twitter users and tweets. So I decided to look around for many clients of different type (browser plugins, as well as applications based on curses, GTK, AIR, and others). Twitter is a nice idea, but I'm not so satisfied with the available readers. For example, Pidgin has two readers for it, taking opposite directions (one chat per user, one chat for all users), none of them is really usable in my opinion. I stuck with TweetDeck for a while, and despite it is fairly popular, I do not understand how people suffer its quirks. I knew what I
would like to have, but hade no time to write it. So, I
perused some Twitter API libraries, merely to see what
could be done. This is how I sketched the fairly vaporous
TweeTabs project, just to put in writing what I'm
looking for, (not so) secretely hoping that someone would
pick on the idea and write it. To my own suprise, I found
bits of free time, enough to get a (barely) usable
TweeTabs tool, which replaced TweetDeck in my habits. But
more time was required for developing and completing that
project. So I welcomed a solution on which I stumbled in
the meantime, that is Seesmic, which I much like,
and am using since then.
Letter to NtEd-usersThis is a letter to Jörg Anders, and the nted-users mailing list. This morning, I felt like creating a draft of a musical score, and boil it in various ways. Direct Lilypond, which I sometimes do, would have been a bit heavy for this exploratory work, so I looked around for helping tools, and found NtEd, which looked both usable and useful. There is a great deal of work captured into that package, and I'm quite grateful, Jörg, that you created it, and made it available to all of us. Thanks a lot for this. Ubuntu Karmic offers version 1.5.1, which I used most of the day. Yet this afternoon, already hooked, I fetched sources for 1.9.18, recompiled and installed them. This was surprisingly easy and smooth, and given the complexity of the thing, I admire a job well done! Moreover, a few little bugs or irritations from 1.5.1 merely vanished, so it was worth reinstalling. This version also implements some fairly interesting new features. In particular, I enjoyed the MIDI input features, and the quality of the writing style in the generated Lilypond source. Finally, I peeked at all archives from the nted-users mailing list, which happily enough, were not too voluminous. Notable is your apparent hate of the idea of a Windows port — not that I need any, of course, but even if I do not much praise Microsoft, I feel much more neutral, by comparison! ☺ Another astonishing remark is this sentence you wrote on 2010-02-02: Actually I want the perfect music notation and playing tool. Which is quite a challenge and undertaking! So, I dare a few comments, hoping you'll forgive me. I do not have much experience with NtEd yet, so many things surely escape me. My main struggle today was about cutting and pasting between voices and staves, or restricting some operations to be per-voice (or maybe a few chosen voices). Currently, there does not seem to be a way to extract a single voice to a (maybe temporary) stave, or two combine all voices from two staves into a single stave (presuming that there is no more than four voices in both). Or to paste into a voice without erasing the other voices in the same staves. Or to switch a selection from one voice to another. It might even be useful to insert within a voice (the voice equivalent of insert block) without changing the others. Even if this was not my case today, let's presume one is working at a fugue, or any kind of ricarcere. The various themes and counter-subjects have to be repeated and mixed from a voice to another, and before the harmony gets perfect, the musician would like to try in various ways. An score editor like NtEd should ideally ease such works. Moreover, the themes have to be transposed (one voice at a time), and even, in some more complex but not so unusual cases, reversed (symmetry around an horizontal axe), elongated (doubling the time of each note) or squeezed (halving the time of each note). I quote this merely to illustrate possible usages. (For the record, someone else presented a similar request on the mailing list, a while ago.) What is the purpose of asking the paper size, once some MIDI has been collected? Could not it be deduced from the preferences, the same as it is done already for the main NtEd edit page? When two voices collide (are in unison) on one beat and then diverge on the following beat, while the lower note (say) stay the same, I did not find a way to create a tie between the two lower notes. It works, however, if the initial beat has no unison: a tie is then obeyed. I append a .ntd file to this message for illustrating my attempt. Of course, one may simulate a tie with a slur (I did not try). While it would be acceptable visually, the MIDI rendering would differ. Thanks for listening and, of course, for giving me such a nice tool!
Recode and thread-safetySomeone just asked me about thread-safety of the Recode library. This exchange might interest other Recode users, so I save it here. At least until I revise and integrate this information elsewhere! ☺
For me, a good answer is an honest one! The truth is that I never checked through actual testing that it is thread-safe. On the other hand, I designed the library so it should be. Long ago, when Ulrich Drepper, who maintains GNU libc, wanted to add various character set support in libc, he asked me if we could manage to use Recode for it, and asked me to produce a reentrant library out of Recode, because threading considerations were getting hot everywhere in libc. At the same time, Richard Stallman accepted that I change the license of Recode from GPL to LGPL, so it could later be recycled into libc. So did I: the extraction of a library out of the code, and the change of license. I did not want to dive deep into the intricacies of thread control and exclusion, because there were too many implementations to consider at the time, all different, and with the reputation of having each its own flurry of bugs. I rather tried to design the library so to clearly minimize the danger of threading problems, as far as possible, but completely avoided thread related library calls. A bit later, Ulrich shared a design he had in head for implementing the iconv specs in libc, and suggested that I rewrite the Recode library to support it. This would have implied that I significantly restrict or weaken Recode specs. My opinion was that we should not make ourselves miserable for the only sake of following questionable new standards. We did not reach an agreement, and so, the Recode library did not get used in GNU libc.
This is exactly how I meant it to be used in threading contexts. I'm not so sure, by now, that this is the best approach, because producing a RECODE_OUTER per thread currently implies a non-negligible CPU overhead, as well as duplication of in-memory descriptions. On the other hand, this is indeed the safe way to proceed.
Before everything, I assumed that thread-safety is to be already guaranteed in malloc and free, and common I/O operations. If these are not thread-safe, the Recode library is surely not. Moreover, no thread exclusion is explicitly taken, nowhere in the Recode library itself. There should not be any problem, by design, because requests are derived out of outers. But once again, I never tried it myself, and I've nothing to substantiate an assertion that there is no bug in that area. If I myself had the problem for my own needs, I would probably not fear using the Recode library, but that is surely no guarantee for others. Writing this reply helps at shaking my memory, and something comes to my mind. I'm not even sure I'm right, as I thought about this quite a while ago. There are a few places in the code where pre-conditioning is computed on the fly at execution time. There are slight time windows in which the same pre-conditioning might be simultaneously computed by different threads. Both threads would then compute the exact same tables, so it is not important about which thread will finally write the pointer to the structure last, obliterating the same pointer from other threads. This might cause some memory to be spoiled. This might also induce a problem at cleanup time if there is any cleanup in such area, as I think there is no cleanup for preconditioning. To make this fully clean would require threading exclusions (or locks). If you happen to know gettext machinery, which Recode uses here and there, but not in the library part, so far that I remember, there are similar problems. For each place where the gettext macro is expanded, the expansion contains a cache; gettext saves the translation on the first call, and uses the cached copy on subsequent calls. If two threads were using gettext simultaneously, two translations would occur, both yielding the same result, both caching them in the same cache, and one of the translation would be spoiled. (I may be wrong!) In any case, if
someone was reporting a lack of re-entrance somewhere, I
would undoubtedly consider it as a bug, that I would
happily correct. However, if a threading bug was building
over some obscure area (I should rather say: one that I'm
not aware of! ☺), requiring a deeper knowledge of
internals for a few likely incompatible libraries, and
asking for complex auto-configuration machinery, it would
likely fall outside my competence to solve it.
Harpes et orguesCette histoire avait été racontée, il y a bien des années maintenant, du vivant d'Antoine Reboulot, lors d'une conférence musicale qu'il illustrait dans la chapelle Saint-Louis de l'église Saint-Jean-Baptiste. Je me souviens encore de ce rire bonenfant, intense et profondément amusé, très sympathique, de l'aveugle qui n'a pas l'habitude du regard de l'autre. Marcel Dupré, dans son temps, était un organiste de renom, et populaire dans sa cathédrale. Les dames de la haute, qui ne connaissaient que bien peu de choses à la musique, se bousculaient pour s'assoir près de sa tribune durant les offices religieux qu'il accompagnait, et pouvoir parler à l'homme ensuite, ce qu'il endurait de bonne grâce, mais sans grand enthousiasme. Un jour, l'une de ces dames demande: « Maître, dites-moi, nous voudrions savoir, à quoi servent les pédales de l'orgue? Pas celles sur lesquelles vous jouez, nous comprenons bien sûr qu'elles servent à faire de la musique, mais les grosses qui se trouvent au dessus? ». Elle faisait référence aux quelques pédales d'expression qui ouvrent ou ferment des cages qui enferment les tuyaux, et aussi la pédale de crescendo, qui enclenche tous les jeux de l'orgue de manière progressive, en une cinquantaine de crans prévus par l'organier. N'ayant pas le goût d'entrer dans toutes ces explications techniques, Marcel Dupré s'est contenté de dire: « Ces pédales, mesdames, servent à accorder l'orgue! ». Plus tard, ailleurs, dans quelque salon galant, ces bonnes dames s'empressent de répéter l'explication reçue, et quelqu'un de leur dire: « Ces pédales ne servent pas du tout à l'accord de l'orgue, j'ai bien peur qu'on se soit simplement foutu de votre gueule, mesdames! ». Un temps passe,
et ces mêmes dames se retrouvent assises aux premiers
rangs d'un concert de harpe. Comme il faut s'y attendre,
avec un grand sourire intéressé, l'une d'elles demande: «
Dites-moi, à quoi servent ces pédales, à la base de la
harpe? ». Et le musicien de répondre, le plus honnêtement
du monde: « Ces pédales servent à accorder l'instrument!
». Les dames se lèvent alors et après un vibrant «
Celle-là, on nous l'a déjà faite… », s'empressent de
quitter les lieux, offusquées, outrées…
Chrome et DeliciousMe voilà avec Google Chrome depuis quelques jours. Je voulais tenter l'expérience d'en faire mon fureteur préférentiel pendant quelque temps, délogeant ainsi Firefox dans ce rôle. Je prends goût à sa vitesse de démarrage, au point que j'ai déjà moins tendance à protéger sa permanence sur un bureau. D'ailleurs, Chrome disparaît lorsqu'on élimine le seul onglet restant. Cela me rappelle un peu Vim, que l'on démarre et quitte plus allègrement que Emacs. Dans ce sens-là, j'oserais dire que Chrome est à Firefox ce que Vim est à Emacs. Chrome offre une bonne foison de greffons, mais comme je n'en utilisais pas plus d'une demi-douzaine dans Firefox, j'ai fait l'hypothèse que je pourrais tenter d'être parsimonieux pour Chrome aussi. Quelques greffons dans Firefox sont moins nécessaires dans Chrome, qui offre d'embrée des fonctionnalités équivalentes. Pour les autres, j'utilise souvent Delicious bookmarks (by Yahoo), et Dafizilla ViewSourceWith. Je n'ai pas essayé tous les greffons pour Delicious que Chrome offre, mais un rapide regard m'a donné l'impression qu'ils sont moins intéressants que celui de Yahoo pour Firefox. Bonne chose, dans le fond, puisque quelque chose me chatouille depuis un bon bout de temps déjà dans Delicious, et cela m'a permis d'y réfléchir. Le service offert par Delicious est indubitablement précieux, mais avec plus de 5000 signets et autour de 800 tags, la gestion en est progressivement devenu balourde, lente et même ardue. Il est difficile de garder une nomenclature consistante dans le temps pour un grand nombre de tags. Puisque plusieurs tags s'évanouissent de la mémoire, les signets associés deviennent indisponibles à toute fin pratique. Je me rends compte que j'ai besoin de garder une vision plus globale et plus synthétique de l'ensemble, et de structurer tous ces signets bien au-delà de ce que peut offrir des collections de tags. À la recherche d'une solution qui me soit confortable, j'ai décidé d'explorer l'idée suivante: carrément intégrer mes signets Delicious à mes notes Tomboy. J'hésite un peu. D'une part, Delicious procède d'une mise-en-commun des signets, ce qui en permet l'évaluation collaborative, et je m'éloigne de ce partage. D'autre part, s'il est facile de passer de Tomboy à Chrome en cliquant sur un URL, je n'ai pas encore d'outil qui me permette de rapidement alimenter une note Tomboy d'une référence provenant d'une page Web affichée dans Chrome, ou d'éliminer cette référence. Avec un peu de chance, je trouverai bien quelque chose. Pour l'instant, j'accepte le risque et je plonge! (P.S. — 2009-12-21 Je me suis finalement fait une extension Chrome qui copie, dans la sélection, l'insertion Tomboy à faire pour la page courramment affichée.) Alors voilà. En utilisant l'exportation massive offerte par Delicious, doublée d'un script Python qui transforme cette exportation en un fichier textuel dans un format très semblable à celui de mes conventions d'usage dans Tomboy, plusieurs heures d'édition m'ont permis de transporter tous mes signets. Bon, c'est peut-être un peu rude, ici et là; ce premier jet a été rapide et massif. Je raffinerai sûrement avec le temps, et bien plus facilement que ce que Delicious me le permet. Pour éviter toute
confusion, j'ai aussi résolu d'éliminer l'essentiel de
mes signets se trouvant sur Delicious. J'imagine que la
plupart des utilisateurs auraient simplement laissé
traîner, mais j'ai ce petit côté anal qui cherche
toujours à nettoyer. L'interface Web fourni par Delicious
offre une élimination en vrac, mais chacun de ces
vracs est limité à 10 signets. Avec plus de 5000 signets,
cela me fait des vracs qui me semblent minuscules. Je me
suis rabattu sur le greffon iMacros for Chrome,
qui m'a bien servi ici, en particulier par la possibilité
qu'il offre de boucler sur l'exécution d'un macro. C'est
un peu lent au niveau des mises-à-jour chez Delicious, et
on gagne en vitesse en réduisant l'affichage au minimum
(par exemple en évitant l'affichage de listes explicites
de tags). Au pur clavier et à la souris, ce travail de
nettoyage s'annonçait mortellement fastidieux, et
iMacros a sauvé la donne!
PureData musingsAvez-vous déjà joué avec le logiciel PureData? Je suis tombé là-dessus en fin de semaine. C'est un logiciel de création, d'analyse ou de transformation de musique. Il traite à la fois MIDI et onde, les logiciels . Il a été étendu depuis aussi pour le vidéo et le graphisme, mais je n'ai pas regardé ces aspects là. C'est aussi un logiciel de programmation graphique : vous interconnectez des boîtes pour représenter des algorithmes plutôt que d'écrire du code source; et celui-là est très instructuré, dans ce sens que toutes horreurs y sont permises. Il est du niveau de CSound, ou de la circuiterie électronique. Vous pouvez visiter, mais sans vous fier aux images affichées. L'interface graphique actuel de pd est basé sur Tk, dont l'aspect est très vieillot (regardez le menu sous pd webring à gauche, qui donne une idée beaucoup plus proche de la réalité). Si l'on passe outre la pauvre qualité graphique de l'interface, l'outil demeure intéressant à connaître. Chez moi, il s'interface bien à OSS, Alsa et Jack pour l'audio, et prend automatiquement en charge toutes les entrées et sorties MIDI configurées dans mon ordinateur, aussi bien l'équipement externe que les instruments complètement logiciels. Alors j'ai rapidement pu y jeter un coup d'oreille ☺, si j'ose dire.
Sound of 64 feet pipesQuite interesting, I presume, for the sound technician in each of us! I stumbled on this recording of 64 feet opened pipes from the oversized organ in Atlantic City. More precisely, we hear the two lower scales (only the white notes), and the 15 notes are played descending, one at a time. I insist on opened pipes because it is quite usual, in organs, to close the top of pipes as a way to force the belly of the sound wave at the end of the pipe, while in an opened pipe, the belly is located at the middle of the pipe. So, a closed pipe has its effective wave length multiplied by two, compared to an opened pipe of the same length, and consequently, the sound frequency is divided by two. For the lowest notes, which require the biggest pipes, closing them is a way to be economical in space, weight and money. However, odd harmonics have more amplitude in a closed pipe than even harmonics, and this gives the sound a particular colour. The overall sound is also a bit weaker. But in the recorded sound as above, the longest pipes really use 64 feet, there is no trickery on 32 feet pipes. Could we really speak about sounds here? Frequencies are below the sonic threshold, we can even hear the separate wave peeks one by one for the lowest notes. These pipes are like enormous whistles, where sound happens in very slow motion. Yet, imagine the blow it would take for sounding such gigantic whistles! It is especially
amusing, for me at least, that we can recognize the notes
even if the pipes play subsonic waves. This is a
consequence that many harmonics of the fundamental are in
the sonic range, and these are what we hear briefly
beyond each separate vibration of the fundamental.
Défense de l'orgue Saint-LouisJan Walgrave m'a signalé, hier, l'existence d'un groupe sur Facebook dédié à la Défense de l'orgue de Saint-Louis . Je viens de m'inscrire à cette liste, et j'ai regardé avec plaisir les quelques vidéos qu'on y trouve. Ils mettent bien en valeur l'acoustique très généreuse de l'église Saint-Louis-de-France, et les riches sonorités d'un orgue que j'ai eu beaucoup de plaisir à toucher, vraiment. Un peu à la course, je n'ai pas encore pris le temps de tout lire. Mais je suis étonné par ce que Jan a récemment écrit: "j'attendrai dans le détour certains pontifes qui voudraient me faire taire aussi". Étonnant! Connais-tu vraiment des gens qui veulent te faire taire? Ou s'agit-il plutôt de craintes? Les gens n'ont pas toujours les mêmes opinions, et c'est même souvent fertile. Mais de là à vouloir museler, il y a une marge. Jan, si tu me lis, à quoi fais-tu référence, ici? Chose certaine, il y a une question de sous derrière tout ça. J'ai survolé dans les archives de ce groupe des suggestions pour la création de lois protectrices et l'établissement de moratoires, mais pour que tout cela ait un sens, il faut en même temps trouver l'argent qui entretient les orgues et qui chauffe les églises l'hiver. J'ai été témoin un peu de ce qui s'est passé à Saint-Louis-de-France, et suis même surpris que cette paroisse ait pu survivre aussi longtemps, compte tenu de ses très faibles revenus. Personne n'a pu proposer de solution viable pour sauver l'église, et l'orgue. Mais je n'ai pas du tout la fibre de la finance, remarquez, alors mon imagination ne va pas très loin dans ce domaine. La très faible évaluation de l'orgue, par son constructeur même, m'a décontenancé. L'orgue ne vaut pas beaucoup plus, semble-t-il, que le coût de sa complète réparation. Ou peut-être, plus probablement, que la loi de l'offre et de la demande est telle que le cours de l'orgue, si j'ose dire, n'est pas très élevé de ce temps-ci. C'est un coup dur, mais il faut accuser le coup. En bref, à mon avis, pour Saint-Louis-de-France, c'est vraiment trop peu, et beaucoup trop tard. Nous allons nous épuiser à vouloir sauver précisément celui-là, et nous fabriquer en cours de route beaucoup plus d'ennemis qu'il nous en faut. Peut-être vaudrait-il mieux identifier plusieurs orgues méritoires qui survivent encore, et trouver maintenant comment les protéger pour plus tard. Les orgues sont tous uniques et originaux, chacun à leur manière, c'est dans l'essence même de l'art et de la facture. Ils ont tous, forcément, une valeur patrimoniale. Quel que soit l'attachement qu'on leur porte, on ne pourra les sauver tous. Il faut s'y faire. Utiliser une rhétorique remplie de révolte ou de scandale n'aidera pas beaucoup la cause. La pire chose à faire serait de cultiver notre frustration, puis critiquer le gouvernement, l'évêché, la population civile, la population catholique, et tout ce qui bouge ou ne bouge pas. Il faut plutôt
examiner, froidement, calmement, les actions à prendre,
sans fanatisme, en examinant tous les aspects de la
question, pour au moins prouver à nos interlocuteurs que
l'on a les pieds sur terre, et pour mériter aux yeux de
tous une certaine crédibilité. Et si des actions
raisonnables sont possibles, alors vraiment,
vraiment faire plus qu'en parler, ou exiger que
d'autres les fassent.
Tomboy, Web and mathsSeeing the tomboy-LaTeX add-in for Tomboy, I decided to give it a try. Here are my first impressions. More it goes, more I use Tomboy for taking notes and organising my work in various ways. Many pages on my Web sites are now Tomboy notes, converted to HTML using my tboy and site.mk machinery. The Tomboy page holds, near its beginning, a few links yielding to other Tomboy-related comments of mine. Popping an existing Tomboy note, either through the menu of recently edited notes, by following a link from another note, or though the search facility, is easier to me than traditionally looking for a file and calling an editor on it. Slight or moderate edition is immediate and simple within Tomboy. So I converted many of my previous reST or HTML notes to Tomboy, knowing they are going to be easier to manage, while being converted back to HTML of quality comparable to what it was before. Granted that reST is far more expressive, yet I found out that I do not need all of reST power on the average. I have a few notes, not so many, which are a bit more mathematically oriented, and for which I used a kind of character art for representing the formulas. So, when I recently stumbled on the tomboy-LaTeX page, I felt it might be worth a try. I'm not really setup to compile C# code, and did not succeed at compiling Tomboy from sources the last time I tried, so I feared tomboy-LaTeX might be difficult to install. But to my pleasure, it went rather well: the add-in compiles simply and quickly, independantly of Tomboy itself. The activation of the add-in is also a simple matter. I initially found tomboy-LaTeX suprisingly speedy. I was expecting worse, given that for each mathematical snippet in a Tomboy note, processing or external programs are needed for generating a LaTeX source, and for turning it successively into DVI, then PostScript, then PNG. But that speed impression vanished when I started using LaTex within real, actual notes. The conversion appears fast enough indeed, but the overall edition crawls to the point of irritation: the cursor often disappears out of sight for many seconds, and inserting or deleting a single character often take a long time. I presume this is related to the number of formulas in a single Tomboy note, but am not sure. However, when there is no or little math involved, like in this very note I'm writing, everything is speedy as normal. Using LaTeX in my case in only acceptable if it can be extended to automatic HTML conversion, so this was the natural next step. There does not seem to be a universally supported way to embedd images within an HTML page, we can only include references to external images. This means that we need ways for naming each mathematical snippet extracted from Tomboy notes, turning these into images, caching the work already done so to avoid useless regeneration, recovering the cache if it existed already, and cleanup of images which are not needed anymore. Everything being fully automatic, of course. I'm not overly satisfied with the result, even if is acceptable to a certain extent. See the page choose(n, k) is an integer! for an example, which I criticize at least on these two points:
Within Tomboy itself, tomboy-LaTeX uses bottom alignment, which is not ideal, and even a bit ugly at times. Nevertheless, previewing the rendered mathematical formulas within Tomboy notes, almost in real-time, is a comfortable capability.
Gitification of Tomboy notesI was previously using Dropbox to spread Tomboy synchronisation directories between the machines I access, yet I sometimes forget to Tomboy synchronize before leaving home or work, feeling a bit miserable afterwards — as I now depend on Tomboy for many aspects of my duties. However, as I never forget Git synchronisation, the idea came to me that I should use Git to synchronize Tomboy notes, just like for most of my other things. Tomboy is a wonderful and very useful tool. Yet, its internal file and directory formats are under-documented, and some guess work is needed here and there, when I want to handle my Tomboy notes through various scripts. There is a D-Bus interface that I could use, and this is how I originally started my tboy tool. But I found out I do not master that interface so well; so tboy was sometimes using D-Bus, and other times avoiding it. As tboy was progressively growing to accomodate my various needs, I finally decided it was easier to uniformize it towards direct reading of directories and files, with the practical result I almost never use D-Bus by now. Another tiny advantage is that tboy may work even when Tomboy is not running. The guess work may have strange consequences. I got the persistent impression that the Tomboy synchronisation directories were designed in such a way to preserve the evolution history of successive synchronisation calls — each being called a revision in Tomboy terminology — yet I had some difficulty in deciphering every detail of this. Sandy Armstrong, the actual maintainer of Tomboy, is especially friendly and talkable, so I dared asking him for some help. He explained to me that maintaining the synchronisation history has never been an intent in Tomboy, and that if I ever find two versions of the same note, than I'm uncovering a Tomboy bug. Surprised by this statement, I made a more thorough examination of my whole Tomboy synchronisation directory, and found a lot of duplication. So there is a bug in Tomboy sync in which the cleanup does not work properly — I'm not fully sure, but the cleanup apparently works only in a few cases, for notes being handled in adjacent revisions. All the clutter which results holds a lot of recoverable history. So that particular bug was quite productive in my case ☺. Each revision has an associated number, counting chronologically from zero. The synchronisation directory has one subdirectory per revision, named after the revision number. To be precise, a revision directory is two-level down from the top synchronisation directory, as directories are grouped one hundred at a time (the grouping directory merely uses the hundred digit of the revision number). Each revision directory holds a manifest.xml file explaining which notes were still existing at that revision level, and for each note, at which revision it was last modified. The revision directory also holds the full note contents for notes which were introduced or modified at that revision level. The gitification works in two passes. The first pass establishes, for each note, all revision numbers for which the revision holds a full note contents for that note. It also attributes a timestamp to the revision (the manifest.xml modification time seems a good estimator). The second pass checks, for each revision and referenced note, if we still have its contents at the last modified revision. Most of the times, because of the cleanup bug, we do. If we do not, than we pick a copy at the closest higher revision where the full text of the note exists. If there is no such higher revision, then most likely, the note has been deleted for good, but still exists in the ~/.tomboy/Backup/ directory, so we pick that backed up note instead. Now that we have a set of existing notes at each revision level, it becomes a trivial matter to restore a previous state one revision at a time, and to generate Git commands for staging and commiting that state. After the execution of the transformation script, I manually copied back the few other administrative directories from the original ~/.tomboy/, that is: addins/, addin-db-001/, sync_temp/ and Backup/. With Tomboy stopped, the final step has been to replace ~/.tomboy/ by the new one. When I gitified my Tomboy notes as described above, 375 notes existed after the 187'th revision, and I was ideally expecting 187 Git commits. Whenever the Tomboy sync cleanup code worked correctly, some historical information was lost, to the point that some commits were discarded as being empty. I ended up with 176 commits, which is rather satisfying result. The space savings are interesting as well. The Tomboy synchronisation directory was taking 22M; the resulting Git pack uses 1,5M, while the checkout itself uses 1,8 Meg. While Tomboy built-in synchronisation works live, proper care is needed to stop Tomboy before Git synchronisation, and start it afterwards. If one plays straight and never takes chances about this, there is no reason to have a synchronisation problem ever. As I use many scripts and tools for moving files between machines, as I wander between home and work, it seems easy to slip a few more commands in the scripts ot make sure Tomboy does not run when it should not be running. As the cleanup bug will likely be corrected in Tomboy some day, the whole trickery above, however fun it may be, might not work for long ☺. However, I'll continue using Git to store history, do synchronisation, and even knowingly let conflicts get in, knowing the powerful machinery I now have to resolve them.
Away from os.path.walkQuite a number of times in all these years, I needed to explore directory hierarchies in my programming. When I switched to Python (it was version 1.5.2 then), os.path.walk was the documented way to do it, and I surely used it a lot. Yet, the functional argument was sometimes awkward for fitting the exact processing functionality I needed for each particular directory walking. The impedance mismatch between the functional argument and os.path.walk has been painful more than once (the From Cfengine to Python case comes to my memory as I write, I do not know why this one in particular). Walking big directory trees has never been inordinately slow in Python, as it is I/O bound overall. This I/O may well be dominated by stat calls, checking if a particular directory entry is a sub-directory or another type of file. In Unix, each directory is pointed to by its father directory, has a . entry pointing at itself, and is pointed to by all .. entries from its immediate sub-directories, and these all contribute to the link count for that directory entry (the root directory has no father, however). GNU find uses this fact for optimizing out stat calls: it saves the link count and monitors the number of sub-directories seen so far, as soon as enough sub-directories has been seen to explain the link count, it safely assumes that the remaining entries have no further directories, without any need to stat them out. Of course, stat may be needed for lot of other checks within find, in which case the above optimization is useless. But in the most frequent use, by far, the optimization well applies. I discussed the thing with Guido and implemented it for os.path.walk, but finally never officially submitted the patch, as for some reason I never figured out, the patch did not yield the spectacular improvement I expected ☺. The later
os.walk, despite undoubtedly nicer than
os.path.walk, was still a bit
insufficient for my needs. It offers more control over
some aspects of the walking, while loosing others. I
rather see os.walk as part of the initial effort
for pushing iterators in the Python library and in all
Python programmers' mind. So I finally gave up completely
on using the provided wrappers, and instead started
rewriting the walking part explicitly within each
application. This is only a few lines of code along: (Note: the check for a symbolic link avoids a looping bug, when the link points to a directory which is higher in the hierarchy. Thanks to Al Danial for pointing out this potential problem.) These may be torn and bent at will, depending of the particular need — pre-order, post-order, anything in between or elsewhere, name it — much more easily that if implicit recursion was used: the recursion stack is explicit, here. The advantage is especially bold when writing generators: if the file processing part contains any yield statement, implicit recursion gets cumbersome and expensive, having to chain imbricated yield loops just for delivering results at the outer level. Now, let's presume the file processing part delivers diagnostic of some sort, prefixed by the directory name. Humans like output to be sorted, because the eyes are usually the search tool. And besides, output is more entertaining when sorted, one has a better feeling of a progression, than with a jumble of all-mixed up directory names that psychologically appears like if it will never finish. One solution is to accumulate all output first, sort it, and only then display it. While being conceptually simple, this is not perfect. This is not a real problem usually that it spoils the memory savings from using a generator, but it surely defeats the elegance of using one. We lose the entertainment resulting of more progressive and parallel output. There is only one
way to keep the advantages, and this is to directly walk
directories in sorted order. This means that appending
names at the end of a stack, and popping from the end of
the stack, is too naive. On the other hand, since the
above loop is often rewritten, it should nevertheless
stay simple. Here is one easy way to do so: There is only two modifications: we pop from the start of the stack instead of from its end, and we sort the bases separately for each directory. Doing so, we append in a kind of sorted order. But it still has a few disadvantages: the stack will be shifted whole at each removal, the sorted function produces copies, and the sort is not exactly what one wants: it will be a bit like restarted at each directory level, exploring width-first. I attempted several remedies to these drawbacks over the years. To give only one example, I once saved directories in an intermediate list, reverse-sorting it before appending it to the stack, so I could still pop from the end of the stack, do smaller sorts, sometimes sparing sorts depending on the precise output I knew I was to get, and God knows what. But deep down, this is all annoying optimization complexity. Here is the last
trick I recently found in this series, and yet another
application of priority
queues — the documentation of which amusingly
recycles another article of mine! ☺ As I still feel it
now, it is surprinsingly elegant. Enough at least so I
share it with my readers: After thoughts(These come from a recent conversation with Guido on the above.) I did not time the above loops, but I'm pretty sure the improvement is more on the side of conceptual elegance. sort() is very fast, to the point one may easily abuse of it without having to pay the penalty. Unless we have a big list, and as I perceive it, sorted() is not so different than list() efficiency-wise. Unless sort is used in the bottleneck of a computation, there is no compelling reason not to liberally use it. I would have a hard time advocating that, for mere efficiency considerations, heapq is really the best approach. In practice, if we keep a stack of unprocessed directories, that stack will be rather small on average, so popping the first element is likely faster that heap-popping it, even if it implies N operations rather than log(N). When N is small, log(N) is not very different from N, and mere shifting does not involve comparisons. I said that there is a single heap sort over all directories, rather than one sort per directory, as an argument that we save processing. This is debatable. Each per-directory sort handles a small number of entries, and calling sort K times on N / K entries each time is roughly the same effort as calling sort once on N entries. However, the heap sort only sees directories, while the per-directory sorts handles both files and directories. For this discussion, I was interested in sorting directories, not files. The precise case I had when I wrote this, was to produce one .gitignore file per project out of all .cvsignore files within that project, for many projects held in a single big directory hierarchy. So, there was not much to diagnose about non-directories. If files ought to be sorted as well, per-directory sorts are still required, and then, the elegance benefits of heapq fade out a bit.
Tomboy report 582696Trackers and robots were not kind with me in the past, they each have their own flurry of bugs, drawbacks and limitations, some even loose submissions at times. Some maintainers just go overboard with their tracker toys, they should play all their soul themselves, and give some rest to their users. The truth is that I learned to hate robots, I've been avoiding them for years (life is too short! ☺). Yet, Sandy insisted that I make an effort at using the Tomboy one, and since Sandy has been so nice to me, I'll comply and try again, once more. But I'll keep a copy of the submission on my side, at least for a good while, just in case! Hi, Sandy. You see, I'm trying your robot! ☺ The Lier and Texte buttons (likely Link and Text in English) are fairly close to one another, and when doing massive editing, or being tired, or various other reasons, it may happen that I click on the wrong one: I highlight a word and then want to change font size or feature, but accidentally ask for a link instead. Now, if this happens to be a common word, I might have created many, many dead links (because I will end-up deleting the wrongly created note). Undoubtedly, this is my error. Yet, a friendly tool should help me at not hurting myself too badly. So here is my suggestion, hoping it is affordable to do. If Tomboy could estimate, when I create a new note, how many links would be created from everywhere else in other notes to this new note, it could request prior user confirmation, whenever that number exceeds some threshold (five seems a reasonable value). As a consequence, creating a legitimate new link is likely to require no confirmation in practice, and creating a link over a common word is likely to request for a confirmation. If the link is wrong with fewer than five induced links, it would then be reasonably fast to use the Find links on this note from the newly created note to spot the links that will die, once the newly created note gets deleted. The same confirmation might also be available whenever a dead link is resurrected. It is an easy error, clicking next to a dead link with the intent of erasing it and typing it again (non-dead this time), to accidentally click it instead, and to instantly destroy some patient prior work meant exactly to un-dead-ify multiple occurrences of that dead link at many other places. Maybe that five would be too high a number for some users, and too low a number for others. It could be set from the Preferences window. Zero would imply unconditional confirmation, a high value would correspond to the actual behavior. I presume that
this suggestion would cover the main absolute source of
spoiled time, in my experience of Tomboy so far. Hoping
that you would look at it with a favorable eye!
Dia criticism
A little while ago (a month maybe?), I needed to produce a few diagrams, and looked around for some tool of the right availability and size. I wanted it bundled for the few systems I use at work or at home, or if not, at least very easy to install. I refused to go overboard with UML, some tools being rich and complex, but not so usable outside UML — I was more attracted to eclectic tools. At the other hand, I did not want to go too simple, expecting a minimum of flexibility and rendering quality. Dia seemed to fit the bill pretty well. I vaguely remember I tried it, years ago, and was not satisfied. Revisiting the documentation, it still looks attractive. Maybe I was too stubborn at the time to understand all benefits? Maybe the package evolved over the years, and I would see it differently now? So, I gave Dia a good and honest second try, studying it afresh with the most opened mind possible. I used it quite seriously, for many days and a few types of projects. Reluctantly, I had to give up. It did not pass the reality test for me and did not work well. I realized my quest was not over, and that I had to seek for something else. In the end, I finally opted for Inkscape, which is surely less featured than Dia in its speciality: if one moves objects aroud, best still is to revise all arrows manually. Yet, Inkscape is more usable overall, so the pros and the cons counterbalance in practice. Also, I have the rather strong feeling that it is a good investment in the long run, so the learning effort is more productive. The main problem with Dia, for me, has been stability. I can of course suffer a few bugs here and there and work around them, but in the Dia case, their pace of arrival or severity was too high for me. Many years ago, I would have fearlessly contacted maintainers and users groups to report all the problems, but experience taught me that this might be pretty time-consuming, and I'm not available enough to do all the research and tries which usually accompanies or follows such discussions. I saved a few points which annoyed me with Dia. Time going by, these progressively fade in my memory. Yet, I'll list them here merely to remember a bit, and not be tempted to return there a third time ☺. I'm surely not seeking a systematic rebuttal or discussion. So if you are a Dia proponent, please do not take it too personnal: your comments are welcome, just do not push to convert me back…
P.S. - @burakbayramli says: Francois: What is your alternative to Dia? I am a user myself, and would love to hear about what's out there. (I had a hard time reaching him, should try later) I also had good comments from Sergio, should resume this all here.
Passage à Tomboy
Les pannes du
réseau électrique, dans notre province, peuvent durer
parfois plusieurs longs et pénibles jours. Les gens
veulent comprendre. Bon, la tempête de verglas d'il y a
quelques années était crédible. Mais le nombre de taches
sombres à la surface du soleil pour expliquer les pannes,
ça, ça passe moins bien. Finalement, après bien des
années, le chat sort du sac! Échappée des documents
secrets d'Hydro-Québec, voici la véritable raison pour
laquelle tout dure parfois si longtemps. ☺ De plus, ça pousse bien dans une direction que Richard Nault m'avait déjà décrite comme un idéal, lors d'une longue discussion que nous avions eu au SRAM, l'un de ces soirs où il était particulièrement enthousiasme et inspiré. Il espérait alors, et ardemment, un outil qui lui permettrait de facilement sauver et éditer ses idées sous la forme d'un réseau de notes fortement inter-reliées (et non pas dans une nécessaire hiérarchie d'idées). À l'usage, encore récent, je me rends compte que l'outil est fourbi de détails d'opération intelligemment pensés, et c'est encore un plaisir et une découverte pour moi. Je l'utilise avec Gnome sur Linux, avec lequel il est bien intégré, c'est certain. La documentation dit, quelque part: Tomboy is a desktop note taking application for Linux and Unix. Mais j'ai vu dans les notes du site plusieurs références à une implantation sur Windows, alors j'imagine qu'elle existe, mais sans l'avoir expérimentée. Comme Tomboy est écrit en C# (un langage privilégié par .NET), j'imagine, mais sans le savoir vraiment, qu'il doit aussi être orienté vers les usages sur Microsoft. Il m'est venu à l'esprit qu'un autre outil Python, qui s'occupe déjà de convertir une partie de mes notes Tomboy vers le Web pourrait être adapté pour rattraper toutes les notes Tomboy se terminant par " blog entry", les ordonner chronologiquement, et les ajouter à mon pseudo-blog. Finalement, j'ai fait mieux que ça et me suis libéré du besoin de suffixer le titre spécialement. Je place une date comme première ligne d'une note Tomboy si je veux qu'elle se retrouve au pseudo-blog. Lors de la transformation de toutes mes notes Tomboy vers HTML, le convertisseur note la présence des dates et sauve la référence. Le blogue est ensuite produit, en ordre de date descendante, durant les phases finales de la conversion. J'ai transformé toutes les entrées existantes de mon pseudo-blog en notes Tomboy de telle manière que les sources véritables s'y retrouvent en entier Je voulais aussi trouver moyen de garder l'idée d'une photo avec un court commentaire pour chaque entrée, cet aspect me semble agréable. C'est fait aussi, et même pas particulier pour mon pseudo-blogue. Je peux maintenant attacher à toute note Tomboy une ou plusieurs photos, chacune possiblement cliquable vers un autre lien. Ces photos sont attachées pendant la transformation vers HTML. Chose certaine,
je devrais nourrir mon pseudo-blogue plus souvent. Je ne
manque pas de matériel pour le faire, mais il faut que le
temps pris par l'édition et les transformations soit
vraiment réduit au minimum. Je sens qu'il y a une avenue,
dans ce que je viens de rapidement décrire. Ça devrait
dorénavant m'être un peu plus facile. On verra bien si
j'en profite!
From CherryPy to Yaws
1 How it wentHere are a few comments, after three months of Yaws experience (this started 2008-05-30). See the following sections for the full story. A sure thing, Yaws required just no maintenance at all. Not that CherryPy required so much either. The worst was the need of regularly processing the logs, which were filling up the disks every few months. I do not save Yaws logs. After the move, I've been fully overwhelmed with other duties, both in my personal life and in my computer life. So, the no-maintenance of Yaws has been really welcome! Once again, I might soon find some more free time, as I'm progressively un-burying myself and digging up towards the surface… Another thing is that Yaws is a bit less demanding on memory resources. CherryPy was using 120M (21M resident) of virtual storage, Yaws asks for 26M (23M resident). But this comparison is not completely fair, as I got foreign Python code imported in CherryPy to do dynamic generation of many Web pages. These pages did not really need to be dynamically generated, so for Yaws, all these pages are pre-generated. One might say that it is more inviting for a long-time Python user to abuse of CherryPy's facilities than Yaws' ones ☺. 2 IntroductionI'm rather satisfied with CherryPy as a way to support most of my Web sites. My configuration progressively grew over the years, it is still fairly tractable, and I do not have to touch it often. On the other hand, while CherryPy is fairly elegant in its way to trigger various processors, exploring URL path elements from left to right, I lost part of that elegance for addressing the various needs I had. There is some complexity in the class hierarchy representing all my Web sites, and in the various redefinitions of methods, sometimes for fundamental CherryPy operations. So, the whole thing would suffer some cleanup, nothing extraordinary, just for getting back the original elegance designed into CherryPy. In that respect, an overall switch from CherryPy to Yaws is total overkill, but as I'm interested in getting acquainted more deeply with Erlang in practical contexts, this switch is a kind of good exercise for me. The difficulties to foresee is that Python is processing most of my Web pages at delivery-time (through a templating language of my own). This processing falls within these categories:
3 ImplementationFor now I'll accumulate thoughts and remarks here as I go! ☺
With some luck,
I'll find some free time to play in these areas. But free
time, I get only a few drops here and there in these
days.
Brève biographie
François a
fait quelques études en informatique à l'Université de
Montréal, avant de travailler comme administrateur
système à divers endroits, dont le Centre de Calcul de
l'Université, la Société de Mathématiques Appliquées, le
Centre Informatique de Dorval. Il a enseigné aux petits
et aux grands, ici ou aux États-Unis, et depuis toujours,
il réalise divers travaux en informatique. Quelques-uns
le perçoivent un peu comme le fantôme de l'Opéra. En, fait, cette brève biographie apparaissait comme une rubrique du menu de mon site Web personnel principal, qui contient une version plus complète de ma biographie. Ce blogue pourra m'aider, j'espère, à rendre mon site principal un peu moins lourd: il m'offre un moyen de placer l'information hors du chemin, sans toutefois la perdre!
Souvenirs du DIRO
Malgré que je ne sois pas académicien de profession, j'ai toujours eu une relation un peu bizarre avec l'Université de Montréal, et réciproquement. C'est là que j'ai eu mon tout premier emploi, dans ce qui s'appelait alors le Centre de Calcul (et qui évolué de diverses manières depuis pour devenir la DGTIC d'aujourd'hui). Plusieurs années après que j'aie quitté cet emploi, l'Université a longtemps continué à m'attribuer un bureau, et ainsi, facilité mes fréquentes visites et diverses collaborations par la suite. (Il faudrait bien que je complète quelques détails à ce sujet, l'un de ces jours.) Sur les CDC-6000 du Centre de Calcul, j'étais l'usager no 6. Claude Goutier a repris ce numéro lorsqu'il m'a remplacé dans le poste que j'occupais, et je suis devenu l'usager no 16 pour toute la durée du projet BONJOUR, et bien au-delà. Au DIRO (Département d'informatique et de recherche opérationnelle), mon code pinard existe depuis mes études, et dure encore. Je m'en sers parfois pour faire des tests, généralement juste pour avoir une autre vision sur le réseau, mais rarement pour les ressources de calcul qui y sont associées. Par contre, l'adresse de courriel (ainsi que la paramétrisation du compte qui sous-tend cette adresse) sert vraiment beaucoup, puisque pinard@iro.umontreal.ca a toujours été la seule adresse de courriel que je publie officiellement! Je l'ai toujours gardée comme référence, malgré qu'au fur et à mesure de mes emplois, contrats ou activités et collaborations dans divers projets ou laboratoires, j'ai bénéficié d'un bon nombre d'autres adresses, que j'ai tenues discrètes la plupart du temps. Mon courriel au DIRO, c'est mon adresse rémanente ☺. Bernard Derval me
demandait un jour jusqu'à quand,
approximativement, je prévois utiliser pinard au DIRO, ce à quoi je lui avais
alors répondu: Jusqu'à mon irrécupérable sénilité.
Mais il m'est difficile de prédire, même de manière
approximative, à quel moment cela se produira. Remarque
que mes amis proches, peut-être, ont des opinions plus
précises que moi à ce sujet, que leur politesse empêche
de me partager? ☺
Java old commentsJean-Philippe, a friend but also my nephew, asked me how I felt about Java. Here is my reply. Si je suis familier avec Java? Oui et non. Je le connais pour l'avoir étudié au début, mais il ne m'a jamais vraiment servi. Il était horriblement truffés d'erreurs au début (les SDK en particulier), et nous dépendions totalement de Sun pour les corrections, ça m'a laissé un arrière-goût assez tenace, même si je sais que tout s'est correctement stabilisé depuis. Le souvenir de Java s'est émoussé depuis, mais j'imagine que ça reviendrait vite. En fait, les langages, j'en ai étudié beaucoup (je les étudiais tous au début), mais maintenant, j'ai plutôt tendance à apprendre au besoin, parce que dans un certain sens, j'en ai trop appris pour rien. Maintenant, je les apprends selon les projets à réaliser. Java est dans la lignée des langages fortement typés de manière statique (comme Pascal, Ada, et un grand nombre d'autres). Comme tous les langages de sa catégorie, il est plutôt verbeux. Mais il pourrait être bien pire, s'il n'offrait pas cette originalité de libérer le programmeur du besoin de penser au détail de l'allocation mémoire. Oh, plusieurs autres langages le font aussi, mais généralement, ils offrent en même temps un typage fort dynamique plutôt que statique — le type est porté par l'objet à l'exécution, plutôt que par la position lexicale de l'objet dans le source (Lisp, Python, Scheme, et plusieurs langages fonctionnels utilisent le typage dynamique — à ne pas confondre avec la portée dynamique — Lisp est à portée dynamique, Scheme à portée lexicale). L'avantage de ces langages sur Java, c'est qu'ils sont excellents pour le prototypage (développement rapide). En pratique, une fois que le prototype fonctionne, il est en général satisfaisant, et on laisse les choses comme ça. Un moment donné, on apprend à directement viser des prototypes utilisables sans les voir comme intermédiaires, et les langages de protypages supplantent carrément PL/I, C++ ou Java. D'ailleurs, certains développeurs Java utilisent Jython pour travailler plus vite et beaucoup réduire la dimension de leurs sources. Il y a des langages à typage statique faible (il y en a beaucoup, mais parmi les langages populaires, Perl est typique de cette catégorie). Ils sont un peu à l'opposé de Java, et pourtant, plusieurs programmeurs parlent à la fois Java et Perl. Question de mode probablement. Java est encore très populaire, même si parmi les spécialistes des langages, il est plutôt mal vu. On voit pour Java une incroyable panoplie de bibliothèques disponibles, où chaque chose est offerte des douzaines ou des centaines de fois de manières différentes, et tout n'est pas également bon. L'embarras du choix est submergeant. Le modèle de développement de gros projets Java apporte son lot de difficultés, avec ses définitions d'interfaces, ses compilations séparées admettant des mélanges ouverts / fermés, public / privé, et la foison de classes induites par la nature même de ses orientations de base. Mais ces problèmes particuliers ont suscité le développement de réponses originales, comme Eclipse, que l'on dit remarquable et brillant dans ce contexte, malgré sa lourdeur informatique intrinsèque. Des amis compétents m'en ont dit tellement de bien que j'ai le goût de l'examiner mieux. Il faudrait que j'imagine un projet, pour m'amuser, qui rendrait Java justifiable. Il y a pratiquement toujours mieux, comme langage, pour à peu près n'importe quel problème (quoique beaucoup de gens se sentent sécurisés, en quelque sorte, par le typage statique). Alors, il faut trouver un environnement où les concurrents de Java ne peuvent exister. J'ai récemment acquis un téléphone mobile (cellulaire) que je pourrais programmer en Java, et probablement rien d'autre — ça me servira peut-être de jouet et d'excuse pour rafraîchir le souvenir que j'en ai. ☺
BarCamp
1 AvantLe courriel m'a rejoint le 27 octobre, mais comme j'en reçois beaucoup, je fais un premier tri et y reviens un peu plus tard. Pour un évènement prévu le 3 novembre, de 9:00 à 18:00, je n'ai vraiment lu le courriel que le soir du 30 octobre. (Il y a d'ailleurs conflit, je dois être à l'orgue de 16:30 environ à 18:00, le même jour.) Cette annonce d'un BarCamp (je ne connaissais alors pas le concept) m'a d'abord semblé être une continuation improvisée de la rencontre du MSLUG qui avait récemment eu lieu pendant le OOPSLA, j'ai même pensé qu'elle était spécialisée au langage Scheme. Mais en fait, on peut aborder des sujets variés, comme le montre déjà la page donnant la liste des présentations (c'est un Wiki, les présentateurs s'y inscrivent eux-mêmes, ils peuvent d'ailleurs le faire jusqu'au dernier moment). Si j'avais tout-de-suite compris, lors de ma première lecture, que tous les gens présents doivent participer, j'aurais tout-de-suite prévenu les amis, et me serait donné trois jours de plus pour préparer ma propre contribution, du moins en sentant moins de pression! ☺ De toute façon, il y a plusieurs façons de contribuer, et je serais heureux de simplement aider quelqu'un d'autre (il suffit qu'on m'en parle)! D'un autre côté, l'idée me sourit de présenter quelque chose en propre, qui m'appartienne un peu en quelque sorte. Au début, je ne voyais pas du tout que je puisse organiser quelque chose en deux courtes journées. Mais en y réfléchissant un peu, je me rends compte que j'ai plusieurs d'idées de sujets qui pourraient intéresser les confrères, et qu'il me suffit dans le fond de rester humble et simple. Pour l'orgue, je n'aurai qu'à m'éclipser du BarCamp plus tôt, c'est tout! ☺ 2 AprèsUn confrère, à qui j'avais transmis l'invitation et qui semblait pourtant bien intéressé, a douté de pouvoir convenablement participer, et s'est abstenu. Il m'a demandé quelques nouvelles par la suite, et voici un extrait de courriels que je lui ai envoyés. Je ne savais pas trop à quoi m'attendre, mais après avoir vu, je crois bien que tu aurais pu facilement y être, même sans avoir de présentation technologique. Il y avait des présentations de quinze minutes, généralement entrecoupées de présentations de cinq minutes, dont certaines étaient parfois très amusantes, pas vraiment techniques. Par exemple, un bonhomme est venu nous inviter à reprendre conscience de l'importance de la recherche du bonheur. Un autre a préparé des diapositives invraisemblables, et invité quelques volontaires de l'assistance à venir totalement improviser cette présentation sans connaître le sujet, ni savoir à quoi ressemble la diapositive suivante (il paraît que bien des patrons savent faire ça, qui font préparer leurs présentations par d'autres). Il y avait aussi des présentations de une minute, les seules d'ailleurs où il est permis de faire de la promotion ou de la publicité. Je m'attendais à ce que l'assistance soit à peu près égale au nombre de présentateurs (autour de deux douzaines peut-être), mais à ma surprise, il y avait vraiment beaucoup plus de gens présents, et les organisateurs originaux semblent l'avoir prévu, parce que l'espace était plutôt vaste. Il y avait des gens à l'accueil, à la surveillance du vestiaire, aux breuvages, à l'affichage de l'horaire (concocté sur place durant la première heure, et complété au vol ensuite pour les petits groupes qui voulaient s'improviser des tables de discussion), au chronométrage des conférenciers, pour aider la connexion du matériel des présentateurs, et certainement bien d'autres choses aussi. Moi qui m'attendais à un petit groupe genre familial ou très amical, autour d'une grande table peut-être, j'ai trouvé tout cet ensemble plus intimidant que je ne l'avais imaginé. Mais en fait, l'assemblée était sympathique, et je ne regrette pas l'expérience. Mon sujet était Scripting for speed (lighting a LAMP). J'ai voulu y décrire les principes sur lesquels je me suis appuyé pour accélérer de grosses applications sans recourir à des langages compilés traditionnels. En fait, j'y décrivais, bien partiellement, l'effort derrière la ré-écriture du projet Classer.
Thonnard
C'est lors de mes études collégiales, à l'Assomption, que l'on m'a fait acquérir, puis connaître les deux opus magnum de Thonnard en philosophie. Le Précis de philosophie fournit avec beaucoup d'autorité une synthèse très structurée de la vision thomiste scolastique. D'ailleurs, l'abbé Gaston Corriveau nous présentait ce contenu non pas comme une approche philosophique parmi d'autres, mais plutôt comme l'expression directe d'une vérité objective et indiscutable. L'évolutionnisme (et le darwinisme) était alors populaire dans nos jeunes esprits, ce qui était à l'origine de plusieurs objections et mêmes de quelques affrontements avec notre professeur, qui nous gratifiait alors de théâtrales et convaincantes colères. À mon grand étonnement, l'abbé Corriveau m'a un jour démontré en aparté que ces éclats étaient tout-à-fait prévus, et planifiés par écrit, dans sa préparation personnelle de cours. Quoiqu'il en soit et quoique l'on puisse penser de Thonnard, je me souviens avoir été séduit, presque conquis, par la grande extension de l'ouvrage, la consistance de ses constructions et l'élégance de ses structures (élégance qui se reflétait souvent par de jolies symétries dans le langage utilisé pour les décrire). Peu importe si j'interprétais le contenu comme une théorie ou comme la vérité, c'était pour moi un livre précieux, et j'ai été attristé de le perdre accidentellement un jour (dans l'incendie de la maison des Quintal, à Charlemagne — je l'avais en fait prêté à Marie-Andrée). Et lorsque j'ai voulu le remplacer, il y a fort longtemps, le livre était déjà introuvable, et j'en avais définitivement fait mon deuil. Alors, on peut imaginer ma surprise lorsque tout récemment, presque par hasard, j'ai trébuché sur une copie de ce livre, patiemment numérisée par Stefan Jetchick. Stefan me donne un truc pour fouiller le livre, en me fournissant la bonne clé de fouille. Stefan me fait cette mise en garde: Mais faites attention! Je n'ai pas numérisé Thonnard pour des fins d'édition critique, mais bien pour avoir un bon Manuel de philo. Alors parfois j'ai tripoté un peu le texte (presque toujours en l'indiquant dans les notes de bas de page). Le hasard veut aussi que j'aie connu, un peu, Karine Thonnard, la nièce de l'auteur, qui a oeuvré dans le domaine de l'éducation à Sherbrooke et dans le bas St-Laurent. Lors de conversations téléphoniques, Karine m'avait parlé un peu du caractère de l'homme et du souvenir qu'elle en avait gardé à travers les réunions de famille. Je me souviens de mon étonnement de recueillir ainsi des souvenirs projetant une image bien différente de celle que je m'étais faite. (Karine m'avait rejoint téléphoniquement lorsque je travaillais à la GRICS, pour obtenir de l'aide technique sur quelques points précis, et de communication en communication, sur un fond courant de sympathie, nous avons fini par nous tutoyer, et jaser de plusieurs choses en périphérie de nos missions respectives. Lorsque j'ai quitté la GRICS, les occasions de nous parler ont disparu, et nous nous sommes alors perdus de vue — si j'ose dire, puisque nous ne nous sommes jamais rencontré de visu. Mais j'ai le souvenir d'une personne dynamique et bien sympathique, ainsi que d'une travailleuse impliquée et sérieuse.) En passant, en
discutant de Thonnard et de ses livres avec Stefan
Jetchick, mes cours de philosophie du collège me sont un
peu remontés à la mémoire. Et parmi ces souvenirs, un
détail relatif à un travail sur la notion liberté, qui
exigeait quelques recherches en bibliothèque. En faisant
cette recherche, j'ai trouvé un livre, relativement
récent (qui ne date pas du Moyen-Âge ou d'avant)
affirmant sans détour que Les femmes, les animaux et
les épileptiques n'ont pas d'âme. Peut-être aurais-je
dû conserver la référence pour la citer correctement.
Dire que j'ai lu ça de mon vivant! ☺
Cahier à colorier
Employé à ce moment par le Centre Météorologique Canadien (à Dorval, sur la Transcanadienne près du boulevard des Sources), il m'était venu à l'idée d'attribuer un dessin de ce cahier à chacun de mes confrères ou consoeurs de l'endroit, et d'afficher chaque dessin bien en évidence sur la porte ou à l'entrée de leur bureau respectif. Tout le monde avait été amusé par l'idée, et les dessins sont sûrement restés là un grand bout de temps. 
Par exemple, l'un de mes supérieurs était connu pour sa combativité tenace à l'occasion de longues querelles avec plusieurs autres fonctionnaires de l'endroit. Bizarrement, je n'ai jamais eu de problème avec lui. Lorsque j'ai appris que, à la suite d'un miracle qui m'échappe, il avait nommé ombudsman de la place, je l'avais taquiné: Allons-donc, Zavie, ça n'est pas sérieux! Si quelqu'un devait se plaindre à l'ombudsman qu'il a problème avec quelqu'un, c'est probablement qu'il a un problème avec toi!. Ce à quoi, avec un large sourire, il m'avait répondu: Lorsque quelqu'un a un problème avec moi, il a vraiment un problème!. Alors, j'avais choisi d'afficher sur sa porte ce dessin illustrant la fable de La Fontaine. Et Zavie en était d'ailleurs assez fier, disant à tout le monde qu'il se reconnaissait tout-à-fait dans le personnage de droite! 
Dans d'autres cas, je laissais la personne choisir parmi les dessins restants. La secrétaire du groupe, très gentille par ailleurs, avait été séduite par le gentil sourire de cette image représentant un escargot, et l'avait collée à l'avant de son bureau. Mais, devant toutes les taquineries que cela lui a amenées, et qu'elle n'avait pas prévues, elle est rapidement venue me voir pour savoir si elle pouvait changer de dessin!
Les Aiguilleurs
Dans ces années-là, je suivais avec intérêt plusieurs des activités culturelles que m'offrait la ville de Montréal, dont entre autres, celles du Théâtre du Nouveau Monde (TNM), qui logeait alors sur la rue Ste-Catherine, tout près de Bleury. En fait, étant un habitué du TNM depuis plusieurs années, j'avais acquis avec le temps le droit à d'excellents fauteuils dans la place. Par les discussions d'après-théâtre, et à d'autres occasions aussi, la secrétaire administrative du TNM et moi avions développé une sorte de sympathie. Devant mon intérêt et mon enthousiasme, elle m'a présenté à Jean-Louis Roux, alors directeur artistique, qui m'a rapidement invité, si je le désirais, à suivre toutes les étapes de la mise-en-scène d'une nouvelle pièce. C'est ainsi que je me suis retrouvé, invité comme observateur, dès la première lecture du texte de la pièce Les Aiguilleurs, de Brian Phelan, avec les illustres Guy Provost et Jacques Godin, et aussi Christian St-Denis, dont le métier commençait alors. Et Jean-Louis Roux, bien sûr, qui allait assurer la mise en scène. J'avais reçu, comme les acteurs de la pièce, une copie du texte, traduit de l'anglais et adapté au québécois par Jean-Louis Roux (qui faisait à l'époque ce travail de traduction et d'adaptation pour plusieurs de pièces de théâtre). C'était dactylographié sur environ deux cent pages, d'une manière très aérée pour permettre annotations et corrections, à large interligne et d'un seul côté des pages en format papier ministre. (De nos jours, on utiliserait sûrement des traitements de texte.) Je me souviens encore de la sobriété de ce cahier, non identifié, non daté, et boudiné entre deux pièces de gros carton noir. Ce petit groupe de cinq personnes se rencontrait régulièrement, parfois plusieurs fois par semaine, dans une école désaffectée quelque part dans Saint-Henri (si je me souviens bien), que le TNM utilisait pour les répétitions, l'entreposage, la construction des décors, etc. J'ai vu le professionnalisme, le travail d'équipe, le développement et l'affermissement des personnages chez les acteurs, et les petits mais multiples changements au texte pour augmenter la crédibilité de l'ensemble. Et les discussions relatives aux décors et artifices techniques exigés par la pièce. Par exemple, à un moment donné de la pièce, une maquette ferroviaire, savamment construite par Alfred, est démolie par Edward. Mais s'il avait fallu construire autant de maquettes que la pièce allait avoir de représentations, les coûts de décor auraient été exorbitants. La solution retenue a été de construire une "maquette démolie" et de la coller en-dessous du plan de la maquette originale, donc invisible du public. Par une astuce d'éclairage au moment approprié, le plan est basculé à l'insu des spectateurs, la maquette démolie apparaît, et la maquette originale se retrouve à son tour en-dessous, et invisible. Les jours de
répétitions, sur l'heure du midi, Christian et moi avions
pris l'habitude de partager nos repas dans un restaurant
plus modeste, ce qui m'a permis non seulement de le
connaître un peu mieux, mais aussi de saisir le sens des
aspirations et des ambitions des gens du milieu. Certains
souvenirs relatifs à cette expérience seraient longs à
expliquer, et surprendraient peut-être quelques-unes des
personnes impliquées — le monde est vraiment plus petit
qu'on ne le croit ☺. Quoiqu'il en soit, je me trouve très
chanceux que l'on m'ait offert cette opportunité
d'observer et de mieux comprendre.
Brassage
Il y a eu pas mal de brassage dans tous mes fichiers depuis quelques temps, question de déconnecter la synchronisation que je maintenais entre quelques sites. Suite à des changements administratifs, l'un d'entre eux a ralenti sa progression informatique, au point d'entraver la mienne. J'apprécie maintenant l'indépendance retrouvée! Durant ce branle-bas, j'ai entreposé quelques documents en vrac, que je ressors progressivement lorsque je trouve un peu de temps libre. J'en profite pour réorganiser la section Plaisirs du menu de mon site Web personnel, pour regrouper sous Musique les pages qui en parlent, renommer Animations en Dessins, puis y rapatrier l'animation du logo de Recode, qui se trouvait auparavant dans ce blogue. Toujours au chapitre de l'animation, la documentation de mon paquetage NRart contenait quelques liens devenus invalides, que j'ai corrigés pour la circonstance dans une version 0.1. Une nouvelle sous-section Mathématiques contient maintenant mon aide-mémoire pour le langage R, qui se trouvait auparavant dans la section Opinions. Cet aide-mémoire, trop massif, a été découpé en une dizaine de sous-pages. Puis j'ai ajouté mon aide-mémoire pour Maxima, tout embryonnaire et monolithique qu'il soit. Durant le remue-ménage, j'ai égaré l'original reST de la documentation de mon vieux programme gantt, qui me sert encore quotidiennement. J'ai dû le reconstituer à partir de sa dérivation HTML. Un peu fastidieux, mais pas difficile: w3m -dump gantt.html > gantt.txt a accompli le gros du travail. Je n'ai eu qu'à le compléter ensuite par une bonne séance dans Vim, pour ajouter le balisage typographique. Afin de vérifier si j'ai bien récupéré tout ce balisage, j'ai fait un peu comme les astronomes qui comparent deux photos à la recherche d'une planète qui bouge. Dans Firefox, j'ai fait en sorte qu'un onglet contienne le document avant, et un autre le document après. En basculant d'un onglet à l'autre (identiquement positionnés, bien sûr), l'oeil attrape efficacement les différences les plus subtiles.
Les réformes scolaires! ☺
Les deux derniers mois ont été passablement lourds, et m'ont laissé peu de temps pour ce blogue. Comme manière de reprendre contact, voici une galéjade reçue de mon frère Gilles sur l'évolution de notre système d'éducation! 1 Les réformes scolaires1.1 Enseignement 1960Un paysan vend un sac de pommes de terre pour $100. Ses frais de production s'élèvent aux 4/5 du prix de vente. Quel est son bénéfice? 1.2 Enseignement 1970Un paysan vend un sac de pommes de terre pour $100. Ses frais de production s'élèvent aux 4/5 du prix de vente, c'est-à-dire $80. Quel est son bénéfice? Enseignement moderne 1970 (Réforme de l'enseignement) Un paysan échange un ensemble P de pommes de terre contre un ensemble M de pièces de monnaies. Le cardinal de l'ensemble M est égal à 100, et chaque élément sigma de M vaut $1. Dessine 100 gros points représentant les éléments de l'ensemble M. L'ensemble F des frais de production comprend 20 gros points de moins que l'ensemble M. Représente F comme un sous ensemble de M et donne la réponse à la question :"Quel est le cardinal de l'ensemble B des bénéfices (à dessiner en rouge)?" 1.3 Enseignement rénové 1980Un agriculteur vend un sac de pommes de terre pour $100. Les frais de production s'élèvent à $80 et le bénéfice est de $20. Devoir : Souligne les mots "pomme de terre" et discutes-en avec ton voisin. 1.4 Enseignement réforme 1990Un peizan kapitalist privilegie sanrichi injustement de $20 sur un sac de patat. Analiz le tesks er recherc la fote de contenu, de gramère, d'ortograf, de ponktuacion et ansuite di se ke tu panse de cete maniaire de sanrichir. 1.5 Enseignement assisté par ordinateur 2004Un producteur de l'espace agricole câblé sur ADSL consulte en conversationnel une data bank qui display le day-rate de la patate. Il load son progiciel SAP/R3 de computation fiable et détermine le cash flow sur cran pitch 0,25mm Energy Star. Dessine-moi avec ton mulot le contour 3D du sac de pommes de terre puis logue-toi au réseau Arpanot (Deep Blue Potatoes). Via le SDH boucle 4.5, extraire de MIE le graphe des patates. Devoir : Respecte-t-il la norme ANSI, ISO, ElAN, CCITT, AAL? 1.6 Enseignement de l'an 2020
CD-ROM labels
To create the above pictures, I had to learn a lot in a short amount of time, and despite the pressure, it has been rather fun. The goal for this page is mainly for sharing technical tips, and maybe some pleasure! The main tools for building image components have been Sced, POVray, Python, Skencil and Gimp, all discussed below. 1 Vectors for 2-D images1.1 SkencilSkencil (but really Sketch at the time, the name change did not occur yet) allowed me to redraw a few scanned logos that I wanted in the CD box montage, in such a way that they could be scaled at will without fearing any loss of precision. The idea was to import the scanned image in Skencil background, much scaled, and redraw the fuzzy boundaries with precise contours. 1.2 FreetypeFor making the numerous needed lettering, I decided for Freetype, which is able, among other things, to generate high-quality alpha channels with the produced images. Here as well, I wanted to produce each letter in its final resolution and position, and so, with proper scaling, rotation and translation, from the start. Considering Freetype does all its computations in 64'th of a pixel, you mess everything if you do it differently (that is, trying to scale or rotate later in the process). I found PyFT, which is a Freetype wrapper for Python: it greatly sped up my work for organising higher level bundling and justification of text in tables, bending planned text along curves, and other special effects. 2 Pixels for 2-D images2.1 PILTo get quality, I wanted to generate all pixel images in their final print resolution and position, and to do so, built a few empty templates, both to adjust the printer geometry, and to produce containers for actual images. Skencil was not well suited for this, and after a few tries, I saw that Gimp was not really better, it would just take me forever in practice. For a few days, I pondered using Metapost, which is clever in those things, but feeling I do not grasp all unit conversions well enough, and seeing I cannot escape programming anyway, I rather learned the Python Imaging Library, and used it. This was really the perfect tool in this case. 2.2 GimpGimp combined everything together. My main surprise was to discover that to be usable at printer resolution, Gimp needs a fast machine having a lot of central memory (my initial trials and study at Web/screen resolution could use almost any machine available to me, without much problems). Some Gimp operations crashed Linux kernels, I had to learn avoiding them. Another thing is that, despite the user interface is handy and appealing, I underestimated the time it takes to get acquainted with Gimp operations, as there is a distance between theory and practice. One has to concentrate on alpha channel handling, and unveil some of all the Gimp magic around it. Once climbed the above obstacles, I mainly used Gimp to mix injection and transparency of all components. But Gimp has also been useful in many other tasks. It enhanced colours for POVray output (stressing refraction artifacts), produced false perspectives, fuzzied shadows for lettering. It added some depth effects to logos, distorted them, added simulated Gouraud, etc. All in all, I found it to be a wonderful and versatile tool. 3 Vectors for 3-D images3.1 ScedTo produce some
basic artwork, Sced built a 3d representation of our BPI
logo with a mathematical precision, as it finds various
coordinates by resolving constraints put between
surfaces, axis and vertices. It was also used to input
light model parameters for various objects transmitted to
POVray, which is a ray tracer that did the rendering.
With some simple trickery, I got Sced to trigger POVray
previews in mosaic mode, yielding fast feedback while
selecting those parameters.
Bof!
Having many English correspondents, and because English and French have many words in common, I sometimes use French words in my texts which I wrongly thought were English as well. When I used Bof! for stressing that I felt indifferent to a particular matter, my correspondent asked me to explain the meaning of that word. Good question! ☺ I would translate Bof! by something like Who cares!, but even more passive. That word conveys the feeling of giving in, of an abandon, combined with a kind of obsolescent sadness. This is why, even if it was never meant like this, I always found a bit humorous the BOF acronym, at Usenix, as a short for Birds Of a Feather meetings. About 15 years
ago, Université de Montréal (UdeM) was making a great
deal of television publicity to recruit students. In
these commercials, where people had to explain why they
selected this particular university, the common cut line
was Parce que c'est l'Université de Montréal, that
is, roughly translated: Because!. For one, I found
this set of commercials a bit insignificant and
pretentious. In a kind of reaction to this publicity, the
TV daily News people drove interviews on the streets,
nearby UdeM, asking students why they chose UdeM;
and later broadcast a selection of representative
answers. With surprise, I saw one of my former college
fellows (nicknamed Dennis), who was not know to us as
particularly fond on studies. To the reporter question,
he merely replying an heavy, elongated, convincing
Bwof!. Quite spectacular on television!
Finding Ackerman(4, 4)
Here a Python version of the Ackerman function: def Ackerman(i, j): I first read about it when I was a teenager, just starting university. Algol (that is: Algol-60) was not taught, but yet, my friends and I were pretty curious, so when we found Christian Boitet's book about this language, we closely studied it, and this is where we read a definition for the Ackerman function. Of course, we
tried it for small values of Between my first
and second year, I got a permanent job in the systems
analyst group of the computer center, and with it,
extended capabilities for using the machine. Still a
student nevertheless, and with the same gang of friends,
I wrote a tightly coded assembler program for computing
This whole effort
became a running gag in the gang. For some of us, even
once graduated and out of the university, randomly
walking on one another on the street, we would say So,
what's Of course, I
always knew that With this
explicit formulation in hand, I could illustrate
why we all failed at computing the monster when we
were younger. Indeed, What about time
as a resource? How much time could take the computation
of this number? Let's suppose first that I have a very,
very fast computer, with a very short clock cycle. How
short could a computer cycle can be? I decided for a
lower bound: the time it would take for the fastest thing
I know to travel the smallest physical distance I could
imagine. So, the time taken by a light ray through a
proton diameter (most people know that a proton is much
thinner than an electron, even if quite heavier). So,
with such a fast computer, able to perform one addition
per cycle, if it started to compute Isn't it
fascinating that such big a number, while being
undoubtedly both well defined and computable
theoretically, yet intractable in practice, could be
represented by so little code?
Choix de Blender
Le texte qui suit est extrait d'une lettre à mon frère Gilles, écrite le 2005-04-23. L'image accompagnant ce texte date d'ailleurs du même moment. Depuis toujours, je suis demeuré vaguement curieux de la manière de modéliser des images en 3D dans le domaine du logiciel libre. Après avoir examiné toutes sortes d'avenues, je me suis pendant un bon moment concentré sur Sced (scene editor) pour la fabrication des modèles 3d et sur PovRay (Point-of-view Raytracer) pour les modèles d'éclairage, la texturation et le rendering lui-même. Mais Sced vieillit mal, et à plusieurs reprises, j'ai cherché des outils de remplacement pour la modélisation. J'ai décidé de faire un bon nettoyage dans toutes mes notes à ce sujet, et après examen, me suis senti prêt à choisir Blender (ou Maya peut-être) pour modéliser, compromis bien raisonnable, sachant que je ne retournerai probablement jamais au niveaux de qualité que la production de vrais films demande. Eh bien, ce Blender est assez étonnant. De la même manière que Gimp (ou PhotoShop) sont excellents pour le 2D, Blender vaut la peine pour le 3D (et l'animation, que je n'ai pas vraiment essayée au moment du choix). Je suis plutôt convaincu que cet outil, une fois l'habitude prise de son interface usager, me permettra de construire, sculpter et pétrir rapidement tout objet 3D. Il intègre aussi un textureur et un renderer bien devisés, versatiles et rapides. Ce Blender tire
bon avantage, pour fonctionner agréablement, de ces
cartes graphiques accélérées pour le 3D. Plus j'avance
dans Blender, plus je me sens enthousiaste. Absents des
tutoriels, je découvre quelques outils puissants, par
exemple pour la coloration ou le pétrissage d'objets de
structure possiblement touffue.
Control Data times
1 Université de MontréalI find myself very lucky of being appointed as a "systems analyst" for the very first job I got in my life (this might be worth the tale, one of these days!) The small team of people (five or six) were taking care of the CDC mainframes of the computing center, at Université de Montréal. Personal computers did not exist yet, it was only natural that hundreds of users had to split the power of a single machine. Those CDC mainframes, while among the biggest computers available in their time, are tiny by nowadays standards. So, having these machines handle job requests from hundreds of users was quite an achievement. Every second was precious, and charged as such: CPU time and IO time were sold. We were doing strong accounting. Moreover, there was absolutely no kind of ethical problem, at the time, for our team to routinely study how various users were using the mainframe, and pointing them to possible improvements. So, users were educated at being good citizens and sparing resources as much as they could. Merely fooling around or random exploring was not very welcome, offenders could even be expelled and loose their computing privileges. I immensely enjoyed having to relate with hundreds of researchers, and I guess many liked me as well: the exchanges were surely diverse, fascinating and fruitful. Very often, people stood in my office, enthusiastically teaching me about their work, entertaining me, often with the hope that we can find ways to somehow optimize ther works. No one was really counting his time, we were working nights and days, weekends did not exist (surely weekends existed for many, yet the computing centre was so crowded at all times that, all naive that I was then, this was the impression I got). Everything was batch on such computers: input from punched cards, output on printed listing (or more rarely, on punched cards), with big magnetic tapes for long term storage (disk storage systems, despite physically huge, were too small and too fragile for that). Interactive work was requiring so much more precious resources than batch processing that it was introduced reluctantly, with circumspection and extreme care. Many computing centre wrote their editor, meant to do appropriate compromises. Ours was called ED, and part of TELUM, a locally developed full telecommunication system for SCOPE, which had none. ED was more an interactive programming shell with an embedded (powerful) editor and a batch submission interface, than a mere editor. TELUM was involving PP programming, of course, but also, PDP-11 code. Two people created a hardware interface between a PP channel and the PDP. Besides participating in the design discussion, my main involvement in it was to create programs to produce hardware cabling diagrams and recipes, and also, a full PDP-11 macro assembler, written in CPU COMPASS. Later, I wrote BONJOUR, which was an alternative shell for ED under TELUM, yet able to collaborate with ED. Hmph! This was one project among a lot of others. I realise that we were doing a lot of things at that time. 2 Optimization concernsThe nanosecond (which was really a short time interval in these eons) was really deified. I remember having spent three full days optimising about 25 lines of CPU assembler (yet I also remember, many years after, that I was very tired). It was the chore of a relocating loop for a LISP loader a friend and I were writing, and the idea was to be able to fully process the tables at least as fast as they were delivered from disk by the PPU. Some might remember all attention that was given, at the time, to not loose disk revolutions. The problems to ponder, for a good assembler coder, were to keep busy as many arithmetic units as simultaneously possible, to resolve register allocation conflicts (three types for them) that would prevent the scoreboard from issuing instructions, to tighten loops enough so they fit in the small instruction stack, to minimise the number of no-ops for realigning jump goals, to re-equilibrate code between jumps and flow through tests so RNI is more efficient, to properly "wrap" code around the entry/exit point. Maniacs were considering memory bank conflicts, but this, I usually did not. The FTN compiler (an optimizing FORTRAN) was taking care of many of these tasks automatically, and was also generating clever code in many circumstances, often to minimise the number of conditional jump instructions and to normalise arithmetic. FTN was a wonder. Many assembler hand coders would not easily outperform FTN generated-code, speed-wise. Very few people considered or praised the other compilers, but I guess I studied the code generated by everything available. Nobody knows how absolutely clever the COBOL compiler was at doing decimal arithmetic, on a machine not meant for that. So clever, in fact, that I wondered if Seymour Cray did not know it all in advance when he designed the machine. The Pascal compiler, later, was astonishingly sharp generating code avoiding multiplications and divisions, especially while indexing packed structures. When I see myself programming Python, nowadays, and caring so little about CPU cycles, I sometimes feel I lived many lives ☺. 3 PPU programmingAs one of the very few allowed to do PP programming, I had to be very careful. Any PP bug would usually fully throw the system down, needing a deadstart, and then disturbing a lot of users. Deadstart was sometimes needed to reload new versions of PP code as well (depending on the situation). Always scheduled late in the night, so they less impact users. And lastly, PP bugs could also physically damage the hardware (like PP core memory, or the display tubes of the console, for example). So, this was less fun, and I always have been nervous while performing tests. 4 HardwareWe got the whole hardware schematics for the CDC machines, as well. I have a funny story about this, where I play the hero! ☺ After the CDC 6000 series, and after Seymour left the company, CDC created the Cyber 70 series. If I remember well, the designer was named Gary Tom — and also a bit known for having an extraordinarily beautiful wife! ☺. Our Cyber 74 was the fourth or fifth of the series. Even if we had all the schematics, the series was new and the tutorial documentation for technicians was still sketchy and incomplete. The machine suddenly became quite unstable, it deadstarted spontaneously many times a day (we had a bit more than 600 such deadstarts in one month, that makes 20 a day!) and the technicians were just unable to isolate the cause. It lasted for nearly half a year. CDC was a bit desperate, flying in new teams every week, on the premise that if a team does not find quickly what is wrong, they need new blood to try other thinking avenues. They had teams of specialists to study ambient electro-magnetic radiations. All cabling was multiply shielded. Coincidence patterns were tried with the operation of the nuclear laboratory in the university, usage of big machinery in nearby hospitals, etc. The machine was cooked a great deal (that is, the length of the cables were adjusted to augment the synchronicity of transmitted signals). I have a lot of almost incredible tales from that period. One of these nights, for a single example, I surprised the EIC, running out of avenues after having been under sustained pressure for months, with a radiasthesist's device around the machine, in hope the pendulum would hint him at were the problem could be… At last, Gary Tom himself was flown in to defend the reputation of his design. This is how I met and knew him, and we spent a lot of time together, working and eating on as coincident schedules as possible, and he explained good parts of his design to me, rather thoroughly. Being a software guy, I was fascinated by all this new knowledge. We surely had a lot of fun! After many days peeking around with diagnostics programs and oscilloscopes, Gary went away of the machine, and started studying the detail of how the machine has been cooked for the last months (any change in the length of any cable had to be reported in the cookbook). Gary found the problem by pure thinking, and I was much impressed. It turned out to be one of the transistors, serving as an amplifier for one of the phase clocks, which was very progressively becoming slow (how this was triggering a deadstart sequence, which is a fairly complex process, is fascinating in itself, but would make this blog entry a bit too technical). This slowdown was masked out by all the cable cooking, which had the unrecognized effect of counterbalancing it. A good while later, long after Gary's visit, one physicist came to us with a strange problem, in which he was telling that one of his eigenvalues was wrong. He took us many days to figure out that at one step of the computation, x = y*z was in fact computed as x = y*z^2. It was not bad code from some compiler bug. The hardware was indeed spontaneously squaring one of the floating operands, without being instructed to do so. Something far from trivial in the opinion of everybody. After many days, technicians still had no clue for this astonishing mystery, so I decided to get with them and study enough maintenance software to become useful. They were a bit reluctant at first, but finally accepted me. Using better testing tools, I finally found out that the double multiplication occurred if the multiplication instruction was located in a particular spot in the instruction stack (a small hardware cache for tight loops), and only when the first multiply unit was already busy (there were two such units). Then, remembering Gary, I went away from the computer, and started to follow the circuit diagrams carefully (not being used to them). It came to my intuition that the second multiply unit was probably receiving its trigger twice instead of once, maybe because of some pulse reflexion, somewhere. I made the hypothesis that one of the cable was probably not punched in correctly. From the diagrams, there were three possibilities, which I submitted to the technicians (they were not allowing me to handle the thick mass of cables myself). They found a floating cable as predicted. From that time on, and for many years, I enjoyed a lot of respect and collaboration from the technicians, and from all neighboring sites! ☺ 5 Other anecdotesSome users never entered a machine room, and for some of them, it was really all mysterious. On CDC-6600 running SCOPE, the command REWIND(file) on punched cards was usable to bring a magnetic tape back to its beginning, and either UNLOAD(file) or EJECT(file) could be used to fully unwind the tape from the vacuum columns and open the protective door. Unbelievable but true, a user once asked me if using the EJECT command was representing a potential hazard for appointed operators… CDC changed a convention in the naming of files, and a few of specialised applications failed. My boss asked me to write the PSR (programming summary report), euphemism for bug report at the time. He told me the exercise would help me to learn English and get acquainted with the problem submission mechanism, but told he wanted to revise my text before it goes out. So, I took a dictionary for looking up words one by one (using the usual way: seek for French, take English, seek that English to cross-check French, iterating a few times until you think you get a stable meaning among all those being offered). In one introductory sentence, I just wanted to say that the strange file names could not be handled in various ways by the group of applications. I was quite proud to find that fiddle means handling, staying vague on the precise operations being performed. Trying to translate strange yielded queer. After revising the text, once typed on the proper forms by the local secretaries, my boss told me that it could not let my report go, as in English, one should never use those two words in the same sentence. A bit annoyed to start the cycle over, I tried to assimilate yet another English rule. This is only later that I figured out the meaning of what I wrote. A few years ago, a guy said he found C, as a novice, easier to grasp than Python. Pondering his arguments thrown me into the past and reminded me of Pierre Garneau, an architect (someone who design houses) who was using these CDC machines. Pierre was then giving into FORTRAN programming, with a bit of assembler. Since he had a lot of energy, dynamism and enthusiasm, I had a lot of pleasure diving into various discussions with him. To my surprise, he was pretty reluctant to any form of higher abstractions, like those found in Pascal, LISP or Simula (all popular at the time). He explained to me that whenever using these abstractions, he just could never stop his own mind from translating these into more machine oriented paradigms all along, and this constant translation was more burdening than helpful. So, for him at least, these abstractions were encumbrances. So yes, everything is possible, and it helps me to understand that some people are hardwired so strangely that they might, even today, prefer C to Python! ☺ 6 Opening to the worldMy main regret of that time is that it was mostly closed and local. All that work invested in the international networking community could have been pretty useful, and while some was getting through and widespread, most was humble. The time for planetary exchanges, as we know it today, was far from having come yet. People were mainly writing for themselves or for their neighbouring collaborators, it was fairly humble on average. And even when not so humble, as the not invented here syndrome was still strong, this was another reason for wider exchanges to not occur frequently. From my own little selfish viewpoint, I started what later became Recode in such times. It has been successively written in CDC FORTRAN, COMPASS and Pascal, or a mix thereof. (Overall, Recode has been a long adventure. From Pascal, it was later ported to Turbo Pascal on Apple ][, then IBM-PC, and only later, to Microsoft C. When I learned Unix, I brought Recode there, and adapted it to GNU standards, just for learning them. Someone from GNU discovered it, and liked it enough to make it available there. Only then, Recode became known outside my circle of friends or local CDC users.)
Français sur ce blog?
Un confrère de travail, Marc Dagenais, me demande pourquoi donc j'ai rédigé les premiers articles de ce blogue en anglais! C'est une bonne question, et comme j'ai toujours beaucoup écrit en anglais, il est bon que je me la repose à moi-même de temps en temps. Comme au tout premier jour de ce blogue, d'ailleurs. Le fait est que la très grande majorité de mes correspondants (il y en eu plusieurs milliers au cours de toutes ces années), et d'un peu partout sur la planète, se sont généralement exprimés en anglais, quelle que soit leur langue véritable. Bon, il y a bien quelques français, belges, suisses ou québécois qui ont correspondu en langue française (et exceptionnellement, des américains, des russes, des allemands, etc. bien plus cultivés que la moyenne des gens et que moi-même). Il semble qu'en règle générale, l'anglais soit l'esperanto ou le latin de l'Internet. Depuis quelques années, le volume quotidien de ma correspondance a considérablement diminué, et l'anglais est probablement moins nécessaire qu'avant. Est-ce par habitude? Ou y a-t-il d'autres raisons? Il m'arrive de me dire, à tous les cinq ou dix ans peut-être, que je devrais davantage participer à la vie informatique communautaire de mes milieux plus naturels: Montréal, le Québec, ou plus peut-être plus vastement la francophonie. J'ai essayé plusieurs fois d'ailleurs, mais le peu de respect que je vois de ma langue sur les forums appropriés, me rebute et m'indispose. Les choses ont probablement changé depuis mon dernier essai (je n'ai pas vérifié récemment), mais de mon souvenir, d'un peu partout dans la francophonie, trop de gens émasculent le français de ses nécessaires accents, et au Québec plus spécialement, certains joualisent leur langue autant que faire se peut, d'autres s'amusent du mauvais sort qu'ils font subir à l'orthographe, allant jusqu'à prétendre protéger ainsi une culture pittoresque. Devant mes remontrances, beaucoup de malheureux électrons ont été bousculés par certains, pour justifier leur total manque de bonne volonté, ou pour maquiller une paresse coupable. Bon, évidemment, plusieurs correspondants francophones se comportent très correctement, mais les moutons noirs bêlent suffisamment fort et faux pour rendre mon expérience de participation assez désagréable. Tout le monde peut accidentellement produire de fausses notes, moi le premier. Je me crois tolérant et doux, mais j'ai choisi de ne pas tolérer ceux qui, devant moi, s'en foutent totalement, et qui manifestement, hormis pour créer des panoplies d'excuses échevelées, ne font absolument aucun effort. De plus, mon franc parler, ou le seul fait d'avoir des opinions, me crée quelques ennemis chez les francophones du coin, et une atmosphère désagréable s'ensuit pour tout le monde. À mes propos, on voit quelques réactions irrationnelles, à la fois féroces et disproportionnées, comme si une simple opinion avait le pouvoir d'atteindre l'intégrité physique de certains, ou de restreindre leur liberté. Suffit-il d'une opinion un peu plus affirmée, colorée, pour déstabiliser la terne grisaille à laquelle ces gens-là sont habitués? Dans cette espèce de rectitude ennuyeuse, prudente, voire frileuse, dans laquelle ils semblent baigner, sont-ils pris de panique dès la moindre vague? J'ai souvent lu des invectives en-dessous de l'élégance, et diverses menaces. Oh, rien qui ne m'effraie. Mais néanmoins, assez fréquemment pour détruire le plaisir du partage. Donc, à moins d'une juste cause à promouvoir, je ne vois pas trop pourquoi j'irais volontairement patauger dans ces eaux désagréables. Il y a tellement d'endroits sympathiques et accueillants un peu partout : il m'est facile de simplement oeuvrer ailleurs. Oh, bien sûr, la plupart des milieux sont entachés de gens désagréables. Dans une communauté plus vaste, leur influence est davantage diluée, on les sent moins, on les ignore plus facilement. Partout, j'ai rencontré beaucoup de gens intéressants, certains sont extraordinaires, fascinants ou attachants. Dans le fond, le cercle restreint de l'informatique locale est peut-être un peu trop petit, dans les deux sens que l'on accorde à ce mot. En bref, pour
revenir au coeur du propos, et sans l'ombre d'un doute,
je préfère lire et écrire en français! Malgré cela,
l'usage de l'anglais (et toute boiteuse que soit ma façon
de l'utiliser) me donne accès à une vaste communauté de
gens agréables, et c'est probablement pour cette raison
que j'y recours si souvent. Il est bien possible que
j'écrive quelques articles de ce blogue en français de
temps en temps, un peu avec l'impression de m'y reposer,
pour des gens proches peut-être, ou pour m'écrire à
moi-même. Ces tergiversations-ci, par exemple?
Trigonometry, revisited
Many years ago, my younger brother Gilles told me he wanted to learn trigonometry, and merely to help him at doing so, I wrote a fairly compact trigonometry course, yet with an unusual approach: I avoided geometry drawings, sticked to bare essentials, and tried to sketch reasonable proofs. That course succinctly covers exponentials and complex numbers, as well as circular and hyperbolic trigonometry. And besides, this was a good LaTeX exercise for me! The truth is that, this morning, I needed to check a derivation which I remembered was in that document, so I went for it. Why not take this as an opportunity for making it available? Quickly done! So, here is Trigonométrie revisitée, as well as the equivalent LaTeX sources. I prepared the document with: recode -d u8..tex trigo.tex Be warned,
however, that this trigonometry course is written in
French.
choose(n, k) is an integer!
The number of
combination of
Because
If we forget the relation between this quotient of products and the number of combinations, it struck me as non-evident and even astonishing that the above always yield an integer. Consider, for example:
For the result to be integer, each factor in the denominator has to be completed consumed by some part of the numerator. How does it work here? The 5 ought to be matched with the 10. Let's match 3 with 9. The 7 is not useful, here. 4 could be matched with 8 and 2 by 6. Now, consider:
Both 7 and 11 are useless. 3 has to go with 9. 4 could go with 8 and 2 with whatever is left from 8 or 10. As you see, the strategy is different, and working more examples show that there is no simple preset strategy for getting rid of the whole denominator, or at least, I did not see it. How comes the guarantee that simplification is always possible? This looks far more obscure than evident. Moreover, the challenge may be extended from the binomial case, as above, to the multinomial case:
As From a purely
mathematical standpoint, how comes multinomial numbers
are always integers? What certainty do we have that the
simplification always occurs? Strangely, I did not find a
direct proof of this (I did not overly tried, and am not
sure I would have succeeded). However, in a book, I found
an inductive proof for this theorem stating that the
product of any Let's say
The first term of
the sum is already divisible by From this
theorem, the integral property for multinomials quickly
follows, and consequently, the integral property for
binomials as well. Despite the proof exists, the magic of
factor matching between numerators and denominators,
remains an intriguing matter!
Computing with huge arrays
In a message to the R mailing list, Thomas Lumley was recently pointing to a Summer of Code project meant to use an SQLite database, for seamlessly accessing a big array from the R Language, that is, much more transparently than with RSQLite. Thomas also said there are only few such projects as a consequence of Moore's law. This is an intriguing project indeed! However, if R requires uses more swapping because arrays do not all fit in physical memory, crudely replacing swapping with database accesses is not necessarily going to buy a drastic speed improvement: the paging gets done in user space instead of being done in the kernel. Long ago, while working on CDC mainframes, astonishing machines at the time but tiny by nowadays standards, there was a program (named APEX if I remember well) able to invert or do simplexes on very big matrices. I never studied it but superficially (I was in computer support for researchers, but not a researcher myself). The program was documented as being extremely careful at organising accesses to rows and columns (or parts thereof) in such a way that real memory was best used. In other words, at the core of this program was a paging system very specialised and cooperative with the problems meant to be solved. However, the source of this program was just plain huge (let's say from memory, about three or four times the size of the sources for the optimizing FORTRAN compiler, which I already knew better as an impressive algorithmic undertaking). So, good or wrong, the prejudice stuck solidly in me at the time, if nothing else, that handling big arrays the right way, speed-wise, ought to be very difficult. On the other
hand, the computational needs for scientific problems
grow fairly quickly to the size of our ability to solve
them. Let me take weather forecasting for example. 3-D
geographical grids are never fine enough for the
resolution meteorologists would like to get, and the time
required for each prediction step grows very rapidly, to
increase precision by not so much. By merely tuning a few
parameters, these people may easily pump nearly all the
available cycles out the supercomputers given to them,
and they do so without hesitation. Moore's Law will never
succeed at calming their starving hunger! ☺.
Welcome to my new Blog!
Feeling a bit like experimenting with blogs, I perceive them as a way to quickly push thoughts and ideas out through the door, without necessarily having to overly formalize them right away, if ever. We'll see if this new toy is fruitful or not. Nothing prevents me, anyway, to later move parts of this blog within more formal documents… Writing English or French? I'm a bit torn, here. My long years of maintenance brought me to write English most of the time. Yet using French is so refreshing! I guess I'll probably do a bit of both, still not sure about how to best sort out the mix, visually. In any case, I looked around for some blogger which would be at the same time: simple, powerful enough, widely used already, and Pythonesque if possible. Not relying on Web browsers to edit pages is a very strong requirement for me. reStructuredText support was also to be welcome. This is how I picked PyBlosxom as my best bet, to start somewhere. The initial difficulty, which required a few hours to solve, was to make it work within CherryPy. This Web server seduced me not so long ago, being elegant and simple, while being powerful and Pythonesque, enough for me to ditch my own Web server. Yet, doing so, I was even able to salvage and reuse my templating system, for which many pages have been written already. It was also easy
to kludge things within the blogger so it keeps the
overall style of my own web sites. Doing it neatly,
however, will require more work: I'll postpone until I
get a bit more experience with the beast. Oh joy: the
reST parser plugin worked immediately! As for the
calendar, seeing that the links are improper, I dummied
them for now, and kept the calendar displayed.
From Cfengine to PythonThe following thoughts were written in response to various posts from people wandering if Python is a good language for administering systems. 1 Cfengine experienceI tried Cfengine very seriously and for a long while, and the idea of a configuration engine seduced me. In a word, Cfengine is a wonderful concept, detailed into a very good set of ideas, especially well documented and explained. There are many good things about Cfengine. I gave it a real honest deep try. While doing so, I duly reported a lot of problems to the author, as any good citizen would do, including some comprehensive patches. While interested at first, I felt the author got irritated a bit about many details I reported, which were often cosmetic in nature, and unrelated to the entrails of the engine, dismissing them as not important enough. Maintaining all these patches myself, from one Cfengine release to the next, was not really productive, despite I deemed it necessary. How can I say that in a few words. I'm a bit anal. (I could spend hours revising all comments of a project to make them more consistent, renaming variables so they get more legible, or just ensuring whitespace is uniformly used.) When one uses Cfengine to administrate the hearth of dozens of machines, it has to be perfect, in and out, everywhere. I need that feeling of confidence. I do not believe, deep in my hearth, that someone is able to be lousy on so many unimportant details, and be dependably perfect when the time comes to be. In a word, despite Cfengine is a wonderful concept, the implementation lacked bit on the quality of details. 2 Switching to PerlTo make the history short, I progressively came to regret having used this Cfengine package, for its lack of maintainability. But as I was so dependent on Cfengine for a lot of administrative tasks, it was just not possible for me to dismiss it. After having suffered enough, I bit the bullet, rewrote those parts I needed in Perl, and dropped out of Cfengine for good. It took me one heavy week of work for doing this first transition. My configuration setup was not written with publication in head, and I did not retain from Cfengine the things I did not use nor need. Moreover, since I wrote it for me, I was not shy to push many of my own habits in the code. What required the most attention, if I remember well, was proper sorting and merging of all requested actions for efficiency, for example, a single pass through the file system did it all. Another point was proper logging of actions (for debugging or otherwise), with due references to the controlling files: and this proved very useful. Speed was also very acceptable: such beasts are typically IO-bound, Cfengine IO optimizations were not that difficult to transpose into a scripting language. For a while, I still read the bug reports about Cfengine, just for the satisfaction of enjoying all those I never suffered ☺. Oh, my Perl rewrite surely had its own problems. But at least, I could fight them as needed, and things were not to be pushed aside anymore as not being important enough. 3 Python rewriteWhen I adopted Python instead of Perl for my day-to-day works, I rewrote all the configuration scripts from Perl to Python, and was surprised to observe the sudden increase in legibility (and so in maintainability), while it required so little effort. My Python was pretty Perlish at the time. This is only later that I revised many scripts to take better advantage of the object-oriented features of Python. It was also easy to design all controlling files so they use Python syntax, and use Python itself as a configuration description language; this gave me a tremendous power and flexibility for almost free. The result was not significantly slower than Cfengine or Perl in practice, teaching me that Python interpretation overhead merely disappears in I/O bound contexts. Over years, I got my configuration engine to take care of many things that would likely escape Cfengine capabilities, like firewall build-up automatically derived from (Python) descriptions of the network topology and distribution of services, easy fetching and deployment for various external tools we depend upon, and other such things, so the overall collection does not much look like Cfengine anymore. All in all, I found that Python is a marvellous framework for automatic system-administrative tasks, and shaping this framework is not that difficult, even if it requires some work. For me, it was quite worth it. In these years, I do not do much real system administration anymore. But in the team I work in, the main system administrator, who saw my framework, understood that it was not that difficult to do, and prefers making his own (in Python, of course), at least as a way to make sure he understands everything inside out. And that's very OK! ☺ 4 The Conf pseudo-projectBecause a few
people asked me to see my scripts, I once published them
as the Conf pseudo-project. It was a set of Python tools,
a bit random, a bit organised, which I use for various
system administration duties. It was never meant as a
formal (self-contained and usable) distribution, but more
as vehicle to exchange ideas with people having similar
concerns. But since this publication brought very little
feedback, I withdrawn it after a while, keeping it
in-house instead. Even if once fairly elaborate, I slowly
and progressively dismantled it while taking distance
from system administration. Nothing much remains of it
nowadays, besides a few disjoint, special-purpose utility
scripts. But I vividly remember that, whatever the
approach, Python is a wonderful language for such
duties.
DocumentationThis Web page is merely planned, and the bulk of information I have accumulated for this topic is kept elsewhere, in another format. 1 Man pages, --help and InfoIn the old times and traditionally, Unix uses so called man pages for documenting programs, system calls, libraries, file formats and many such technical matters. The GNU project, which indented to provide a free Unix clone, chose Info files instead. While many people understood the virtues of Info, others were rather irritated by it, and I've seen many arguments from both camps over the years. Some confusion also existed as for many packages, documentation existed in both formats, sometimes written by different people, with synchronisation problems at update or correction time. I'm merely throwing a few ideas here, quickly, and am not trying to write an essay about all this. My own opinion is that we can produce better documentation aiming the Info paradigm that we could using man pages. If I'm telling my bias right now, this is so people having religious feelings on this issue could stop reading right away, and so protect their faith! ☺ Despite many man pages are extensive, the overall goal of man pages is to present a synoptic synthesis of what needs to be known about a particular topic. Many man pages are concise and even terse. 2 Conversions reST à TomboyJe pense me limiter à reStructuredText pour les documents qui doivent être publiés par ailleurs (dans des distributions de logiciels par exemple) et qui doivent contenir des éléments plus complexes (comme des tableaux). Voici une liste des fichiers reStructuredText que j'aimerais peut-être convertir en notes Tomboy, si je trouvais une solution à quelques problèmes techniques qui y sont associés:
Thoughts on editors(Emacs in particular) 1 Pondering Emacs1.1 IntroductionWhen, after having been a passionate Emacs user for more than two decades, I switched to Vim for my day to day work, many friends and co-workers were a bit astonished. Even if I never dived into holy wars about which editor is best, some people knew my long reluctance (should I say repulsion?) to any kind of vi. Besides, with a few closer people, Emacs versus Vim was the frequent subject of friendly teases. Many people asked me to explain what they perceive as a defection, and this Web page is meant to summarise my thoughts on the matter. However, if I had to concentrate my overall experience into a single piece of advice, it would go like this. Whatever editor you choose, learn it well. A good part of the comfort you have while programming comes from the ease you develop with an editor. It has to somehow become part of yourself. It is much better to know one well, then many partially. Yet, choose an editor with many virtues, so it will be on your side in the long run. If you grok French, you might like to read about my very first contact with Emacs. At the time I wrote this article, I was known around here as an Emacs proponent and specialist, and this is why the article was read as humorous. 1.2 Emacs virtuesEmacs is really a wonderful editor, and newcomers to Emacs just cannot really appreciate its incredible power and versatility. The Emacs tutorial only gives the bare minimum so one is able to enter and leave the editor and do simple edit jobs. Even if the tutorial gives the base for handling many files, buffers and windows, it is likely to take some while before one becomes able to comfortably and confidently edit hundreds of files, simultaneously ☺. The tutorial does not give a clear idea of the powerfulness of program editing modes. I especially appreciate Emacs capacity for cleverly indenting source code, moving in and out structural units, and also its ability to precisely locate (and automatically position the cursor at) syntactic errors within source files, without even having to wait until compilation has finished. So-called shell windows are extremely and constantly useful, where one may edit system commands and receive interaction results right in an editable window. And this is equally true for remote editing and execution. There are astonishing tools in Emacs. For example, one may work on a mathematical text, and after having a written numerical, algebraic or statistical formulas, Emacs may compute the integral, resolve an equation system numerically or symbolically, do a Taylor expansion, display graphics, and many other things just as well. Emacs also offers an integrated, simultaneous view over the email one receives, Usenet News, and Web searches, so one may read, sort, process or reply to these, with a command set which likely goes beyond, in capacity, everything else one might have seen. Finally, and this is important, there is about no limit to how one may fine tune Emacs behaviour no matter how detailed or extravagant your wishes. Besides all the predefined variables and knobs, one may override or augment on the fly the set of available commands, without the need of recompiling anything. So, if something does not fully please you, you have the means for satisfaction. Someone was wondering if he would ever learn 10% of the Emacs keystrokes. He did not realise than pre-made keystrokes are only a small part of all available commands. And then, that all available commands are only a small part of all available functions. And, of course, that all of the above is only a small drop in the ocean of possibilities given by the extensible properties of Emacs. At times, I wonder if this should be seen as comforting or frightening. ☺ People sometimes ask me if Emacs is worth learning. One can easily get started with Emacs, but really understanding Emacs capabilities is another matter, for which the learning curve is either steep, or has to extend over a long period of time. I'm quite sure that Emacs is well worth learning, if you use computers a great deal in your professional life. Once you know it well, it speeds you up tremendously. For people using computers only casually, I sometimes feel Emacs might be overkill. It happens that I see some of my coworkers doing long, tedious and boring editing tasks using lesser editors. While observing their sorrow, I know it could have been easier. They apparently know just as well, as they sometimes ask me (and so, Emacs) for help! ☺ 1.3 Why not Emacs, then?One problem is that both Emacs and I are growing old. For Emacs, it means that its complexity is progressively increasing, and for me, that this ability to understand complex things is slowly melting. When we were both younger, I was frequently diving into Emacs sources, even C sources, for repairing the little nits I was finding, or for implementing a few ideas that were dear to me, all this with a reasonable confidence that I would succeed. But this is not true anymore. For example, I came to much like the graphical user interface features of Emacs while working under X, even if Emacs is still very usable in more traditional text-based user interfaces. Emacs addresses the graphical facilities at Xlib level, most probably to guarantee speed, but this low level for X is foreign to me, and if I ever correctly learn to do GUI programming, I would prefer doing it at a much higher level. I reported a few tiny problems against the Emacs GUI, that are not going to be corrected until someone knowledgeable enough in this area tackles the issues. Mule, the international character support in Emacs, is in constant state of slow redesign, so its documentation is always a bit lagging. Besides very few dedicated or specialised people, no one could really say they understand Mule. Mule also ignored Unicode, and Unicode support in Emacs is currently partial, and might be for a while. I'm far from being a Unicode fanatic, but yet, something as important as Emacs may not ignore Unicode nowadays. There are Mule bugs in Emacs by which \201 characters pop up unexpectedly, here and there, which I reported many times. I have many filters that get rid of thousands of these in my files, nearly transparently, so they do not bother me that much overall. However, what bothers me is the growing impression that being an Emacs maintainer, as time passes, becomes an increasingly difficult challenge. A lot of technical skills are required, not to speak about the ability to peacefully coordinate the work of really many volunteers. I have a lot of admiration for Emacs maintainers, yet more it goes, more it becomes impossible to recruit the right guys. And even for the right guys, organising a new distribution has become a daunting task. Most maintainers exhaust themselves at the job, and never do more than a few releases in a row. Forming a new Emacs maintainer takes a long time. 1.4 The Lisp in EmacsI surely wrote a fair amount of Emacs Lisp code in my computer life. This language has plenty of useful features, abundant documentation, good debuggers, nice profilers, and is assorted with many good writing and stylistic conventions. In fact, this Lisp was more than once the language in which I chose to express, extensively, the algorithmic solution of some problems which were somehow related to editing tasks. But also, I sometimes needed the very same algorithms in contexts not really tied to editing. The practical choices left to me were either to artificially push myself into Emacs more often than I really needed to, or else, to execute some stunts for calling Emacs from within batch scripts. I did both for years actually, yet with the constant feeling that Emacs Lisp was not my preferred programming language, however sophisticated it may be. In fact, the language was a bit forced upon me as I sometimes or often needed these algorithms within editing contexts. There is in Emacs a Common Lisp compatibility package, which I had to fight sometimes while writing Emacs Lisp because of naming clashes, which existed even between standard Emacs modules. Through various bug reports, these clashes were lifted and resolved along the years, but yet, I perceived the confusion as a proof of some untamed complexity. Besides a few useful macros, which Gnus amply used and demonstrated, and which were later integrated in Emacs proper, most of the Common Lisp compatibility package seemed to me like another layer of learning over something already featureful. As far as programming languages are concerned, for all those I studied, I noticed my overall preference for those having simpler syntaxes or clean libraries. For example, I was much more on the Pascal side than on the PL/I side. Oh, no doubt that C kept me busy for a long while, it is a necessary evil when one aims wide portability. But deep down, Scheme attracted me much more. So, when Richard Stallman announced that all extensible package in GNU would eventually use Scheme, it was good news. However, the news was not a good one for very long. We soon realised that the vision was to be a mix of Scheme and current Emacs Lisp, shamelessly altering the Scheme standard wherever it seemed interesting to do so. The result was to be named Guile, and for creating its first release, the FSF appointed a strange maintainer who was far from respecting GNU standards. (A lot of straightening occurred later, when more reasonable people worked on the project, but in my mind, the huge false start was hardly repairable.) Whenever Guile will find its way into Emacs, another layer of complexity and confusion will be created, as Emacs will host a third flavour of Lisp, and I predict that this particular confusion will last for quite a while before Guile takes over for real. Especially given, at least to my intuition, that Emacs will not likely move to Guile soon. Let me explain a bit more. When the FSF decided that all GNU packages would switch to Rx, a replacement for regexp, it was also decided that Emacs would be one of the last to switch, as Richard did want Rx to be debugged by all other maintainers (like me) first. In his defense, Emacs could not afford being destabilised by a package like Rx. (Since then, Rx has been pronounced a failure, so I spent my time supporting it in my packages.) Despite GNU gettext has been in existence for a while now, Emacs is not using it yet; and it has been known for years that it will use it in its own special ways. I guess that Guile is just the same, Emacs will follow its acceptance by other packages in GNU, much more than it will precede them. For me, all this means that in some indeterminate future, Emacs is doomed to traverse difficult times. 1.5 Emacs and PythonIn my long saga for a good programming language for day-to-day works, after Bash, GNU m4, Awk, Perl and Scheme, I finally chose Python. Python is not only good for quick scripting, it allows me to tackle big projects in a structured way, producing legible and very maintainable prototypes. Combined with profiling, then Pyrex, it also well sustains the stress of non-prototype, production environments. One thing that happened is that I got more interested in Python than Lisp, even though I wrote a lot of Lisp. Emacs ties me to Lisp, while I knew many things I wrote in Lisp would be better written in Python. This is the first time I seriously considered getting away from Emacs, towards an editor which is more Python-aware. Looking around, I found nothing much convincing (I did not even consider vi, because I never felt comfortable with it in the past). It was also true that my Emacs customisation was rather huge by then, and I had a lot of Emacs dependencies in my work habits. I stuck with Emacs. But I was not satisfied, and felt that the Emacs dependency grew to the point of not being that comfortable. I was still starving for Python instead of Lisp. Some people tried integrating Python within Emacs, failed, and were kind enough to tell me why. One showed me an experiment of a communication protocol between Python and Emacs kept as separate processes, as a proof of concept. I re-designed the protocol so it gets much more clean and simple, more practical than theoretical, and added clarity and elegance to the API. This has been the birth of Pymacs. Other correspondents helped me at solving some uneasy problems related to garbage collection on Emacs side. While Pymacs is elegant in my opinion, one cannot effectively use Pymacs (the Python part) without knowing at least the specification of many Lisp functions, and I found that it requires some doing for a Pymacs developer to decouple the Emacs interaction part from the purer algorithmic part in applications. Moreover, if you do not consider speed issues, they bite you. Guile, as being a long term direction for the FSF, is also an obstacle to any contradicting direction. Even if I, and a few of us, would consider than a tighter integration of Emacs and Python would be a nice thing, it would probably be perceived as an unwelcome distraction from the Guile plan by the FSF. And since Guile might take forever to really find its way within Emacs, Python may not become a real extension language for Emacs in our lifetime. In September 2003, I worked at extending the Emacs Lilypond mode (Lilypond is a musical score editing system) for my own precise needs, and naturally for me, wrote these extensions in Python, using Pymacs. A few users asked if and how the extensions I wrote could be made available for Vim as well, whatever the way. One of them insisted so much that, one evening I was too tired for being useful at anything, I peeked at Vim and its Python extensibility. Although the Vim API is much weaker than Pymacs (so far that I know), the integration with Vim seemed more tight and Pythonesque. Not having to feel so much the underneath presence of Vim, at least compared to Pymacs, writing purer Python promised to be easier. The promise was so strong that I pondered for a while the idea of rewriting all Pymacs examples included in its distribution so they could be usable from Vim as well as from Emacs. I have not yet done it, but am letting the idea mature. The good thing is that I finally recognised extensibility as being more important than the editor, given the editor is reasonable enough to start with. Whatever the editor, I will extend it, as I have so many personal habits. Python is easy to write, and Python modules are highly reusable. I took a better look at Vim itself, and it basically offers (more than vi) most things I use in Emacs all the time. Many things are still lacking for me, but Vim seems mature enough to allow them as extensions. Vim is also more in-lined with GTK and Pango, X input methods, Unicode, and those internationalisation things which were making Emacs a distinguished tool not so long ago. I'm curious about exploring how to work in an environment of many modular tools, and learning to interact between all these tools using common idioms, like cut-and-pasting between heterogenous applications, rather than living within a single huge do-it-all design. I know that there is suffering ahead for me while re-learning to work differently, but I may not experiment these new directions (new to me, I mean!) if I continue sticking with Emacs. So, I guess, still hesitating, not fully sure, that I'll have to accept some pain sooner than later and dare diving away. 1.6 Emacs as a cargoWhen Richard Stallman started the GNU project (and the FSF), long before Linux existed, he established through GNU Manifesto and standards, a firm direction, but especially through programming examples, a quality level which astonished the community and enthused many good programmers. People received Emacs, the C compiler and debugger, Make, Bison, and a flurry of other tools, as wonders. The GNU project, behind the charismatic figure that Richard was then, channelled a great deal of interest and energy. Everybody had such a strong quality prejudice for anything coming out of the FSF, that new GNU programs were immediately adopted and installed world-wide. Richard Stallman once had an immense moral authority in the world of free programming. Wherever he was going, everybody followed. People did not always agree, but so yearned to attain the goal of a complete, free operating system, that they managed to unite despite their differences. However, when this system started to exist, and so, when the need of reaching the goal started to fade, Richard's authority soon began to dismantle. Especially since Linux has been created quite outside the FSF wing, and was initially considered by the FSF as an unwelcome drain of energies away from the Hurd, which was then the FSF project of choice. Linux development style, a kind of open collaboration between a lot of trends, was also quite different from GNU habits, and the Linux community ferociously resisted the GNU model of authority. At the time, the FSF made itself many enemies it did not need. To destroy its authority a bit more, the GNU project allowed in a few projects of lesser quality, and never paid much attention to the human qualities of its maintainers. Software is less free than it appears to be when maintainers are haughty or despising. The FSF never fully recovered from all the damage, nor adapted to the changes. Used for a good while to going its own way without much looking around, with the planet blindly following behind, the FSF did not recognise soon enough that it will loose followers if it does not learn to really collaborate as an equal with other partners, instead of as the necessary leader of everything. A lot of worth efforts are going out in this world, which did not originate from the GNU project and which are not driven by the GNU project. (These projects might have never existed without the prior momentum created by GNU and the GPL, but this is another debate.) GNU traditionally ignores what it does not drive, until it cannot escape it. For Emacs, it means that while collaborators are expected, Emacs itself is not going to be especially collaborative. I feel that Emacs is a heavy cargo that, even if it used to establish a direction for everybody, might now have trouble manoeuvring along directions established elsewhere, because of its terrible inertia, both political and technical. Not that it does move, but a great deal of energy is required every time. All summarised, I perceive Emacs as one of those huge ships where people embark a luxurious life while they intend to travel around the planet. However, the ship is an heavy cargo for which it is difficult to find captains, and which consumes a great deal of fuel to effect only slight changes in direction. This cargo is not fully tracked on the mainstream routes, where the real crowd is, all active and diverse than it may be. Because captains are not that concerned with the mainstream, and also because when corrections become unavoidable, the inertia of the cargo is such that it always lags a bit from the aimed route. So this cargo very slowly diverges, progressively isolating its happy passengers from the rest of the world. It is not easy for any passenger, abandoning all the comfort they currently enjoy, diving in the cold waters and courageously swimming back to where the bazaar really stands, and learning to survive in the happy chaos which rules there. One sure thing is that more one waits, longer and harder the swim will be. This particular concern finally triggered me into abandoning a non-sinking ship, or at least, leaving it long before we begin to perceive a degradation of life quality aboard, yet this degradation is likely unavoidable in the long run. 2 Surviving without Emacs2.1 The overall planEditors are addictive. That's why so many people have quasi-religious feeling about them. They feel threatened very deeply whenever they see criticism. Salvaging the reputation of their editor is akin to salvaging themselves. ☺ With Emacs, I do a lot of special editing for special files. A big part of the special editing has already converted to Python using Pymacs, and this will ease migrating the special processing to another editor like Vim, which is Python aware and featureful enough to start with. Yet, going from Emacs to Vim leaves a few holes in work habits, that need to be filled with some replacements. Let me list a few of these, in roughly decreasing order of importance. After a few years of Emacs abstinence (I had to heal out of a very long and deep addiction), I restarted using it, parsimoniously at first, and then more regularly. But it is now one tool among others, and not the tool as it used to be for me. Currently, I use Emacs merely to edit Erlang sources, XML code, to read Usenet News or Gmane, or to achieve big directory hierarchy cleanup. 2.2 Surviving without GnusFor Gnus, the fact I get much less volume than I used to (like in the time I was maintaining tar, say!) might help me. I got away from Babyl files already to favour traditional Unix mailbox format, that is a great relief. Since I use the email paradigm a great deal, even to save notes within messages to myself which I then file into thematic folders, I will have to find a fairly efficient replacement. Gnus was really marvellous, nothing can really compare with it. I looked around a bit for a replacement, and the best I came with is Mutt (supplemented with fetchmail, some procmail, Spambayes, and many home-made scripts). Getting Mutt and some of my Python scripts to really cooperate required some doing, and a few kludges, and I still feel very far from having a mail agent offering Python as an extension language. I also saw Python extensible mail agents, but which had some weakness in the underlying mail engine, so far that I could judge. Mutt is not perfect overall, but I'm trying to compromise with it for now, it's still give-and-take. But at least, I now feel installed in a much more modular design for my work habits, and if I find something that pleases me more than Mutt, I could change this aspect without having to change everything else with it. In my case at least, the big move is now part of the past, the main suffering is behind. After an irritating journey into Evolution, I finally switched to Thunderbird which, without being perfect, is quite reasonable. I still use Emacs and Gnus for news reading, however. 2.3 Surviving without Shell modeSurviving without Shell mode has been suprisingly easy for me. We have plenty of good terminal emulators around. The readline capabilities in popular shells are satisfying enough. 2.4 Surviving without DiredFor a few years, I used Tim Daneliuk's Twander, while slowly taming myself to GNOME and Nautilus, which I usually prefer nowadays. Yet, once in a while, when I really have a big perusal and cleanup to do, and seek operational speed, I still launch Emacs for its Dired mode, which is still unequaled in my experience. 2.5 Surviving without AlloutAllout has been, for quite a long time, my best choice for synoptic editing. I grew quite a lot of notes using it. Getting away of Emacs, I needed a way to access and handle all that material, so I wrote an Allout mode for Vim (using its Python extension). Later, when I found out about the very nice Tomboy tool, I patiently and tediously moved over all my Allout notes to Tomboy. Nowadays, I'm not using Allout much anymore. 2.6 Surviving without PSGMLFor SGML, it might require a good amount of work before I'm happy. PSGML is really a wonder under Emacs. (I still have no idea on the Vim capabilities for controlling highlighting, which is somewhat orthogonal to SGML analysis, but especially useful there.) I wrote something for Emacs called xxml.el, that does the job of combining colour attributes likely beyond the Vim way of doing such things. I may be wrong: my knowledge of Vim is still very fragmentary. My associate, who is a linguist more than in computer science, usually likes to adopt and stick with my work habits, because he then gets more full support from me. He does not object switching to Vim from Emacs as I did, but only given that Vim has the equivalent of xxml.el first. The fact is that I understand him: I have been unsuccessful so far at enjoying HTML editing support in Vim. I pondered a bit about how I could rewrite xxml.el in Python, for later becoming a Vim extension say, but I guess it would require a fairly good amount of work on the Python side only, and no doubt that I would also need to learn Vim advanced usage much more deeply than I know it currently. Nowadays, I still launch Emacs for its nXML mode, whenever I need to handle XML code, which occurs relatively often given XML popularity. I do not see much SGML anymore. 2.7 Surviving without ELSEUsing Python as my main day-to-day language much alleviated the need for ELSE, as this language is rather terse, and does not have the same syntactical overhead as other languages. I wrote Pynits to help me with various Python idiosyncrasies of mine, and the few ELSE needs I would have are covered in this tool. At the other end of the language spectrum, there is Java, for which ELSE would be useful indeed. But Java has it own flurry of problems, for which Eclipse offers a much better solution (despite its discouraging complexity and heaviness).. 2.8 Surviving without CalcCalc, I do not use that often, but whenever I need it, it has a very efficient user API, and a wide, eclectic set of capabilities. Another wonder. To survive without it, I moved towards R mainly for most things, with bits of Maxima for symbolic computations, and a few Python scripts whenever convenient. 3 Getting used to Vim3.1 Installing it properlyOne sure thing is
that I wanted Python support in Vim. This meant
re-installing it from sources. Here an approximation of
my installation recipe:: 3.2 Teaching the fingersEmacs and Vim key-bindings are pretty different, down to the logical organisation and structure of commands. One thing which has been difficult for me is to learn to shift the right hand one position left on the HJKL keys and unshift it on JKL; depending on what I want to do, this detail often slowed me down initially. I'm not as speedy in Vim as I was in Emacs. The more it goes, the easier it gets. I expect and accept that it will require a few more months before the spinal chord adapts. ☺ I think Vim key-bindings are a bit softer on the hand and fingers than Emacs, because most usual commands use simple lower case letters, others use upper case letters, and only rarely you have to resort to the control key. However, the Escape key is often needed, and a bit remote. This advantage somewhat vanishes when I type French text, as the cf keyboard uses a mix of dead keys (some shifted). Other combinations require a full repositioning of the right hand, Python brackets and braces in particular. 3.3 Using gvim (Vim with GTK)While I like the standard Vim-in-a-terminal, I prefer gvim whenever possible. One of the advantage is the ability to use the mouse for some quick operations, like positioning the cursor between two characters, moving big distances by dragging scroll bars, changing window dimensions by dragging the bars between windows, wandering in help through clicking on index items, clicking within the fold margin for opening and closing folds, etc. I'm usually not so fond on the mouse, but strangely (to me at least), gvim is effectively taming me into using it. One thing which I often do is repeating the sequence of using the mouse for fast positioning of the cursor, then using . typed with the left hand. It is surprising how many other vim operations you can quickly do with the left hand alone! ☺ One thing which helped me a lot is that, right from the beginning, I took the time of carefully customising gvim so it uses readable fonts, consistent colours, and such things. As for Python editing, of course, vim customisation is equally available within and outside X.
Dieu, la douleur et l'informaticien(dans la série François gazouille) Tout ça à cause d'une Pomme. Oh, pour une fois, Apple et le MacIntosh ne sont pas coupables. C'était bien avant. Il faut retourner à la Génèse, chapitre 3, verset 16: À la femme, Il dit: Je multiplierai les peines de tes grossesses, dans la peine tu enfanteras des fils. À cette époque reculée, en dehors des pommes et des serpents, on connaissait les hommes, les femmes et le bonheur, mais aucun informaticien. Dieu était pressé de punir les fautifs, et Il n'avait sûrement pas le goût d'attendre après Johannes von Neumann pour faire savoir Sa mauvaise humeur. Sinon, Il l'aurait dit tout de suite: Tu programmeras dans la douleur!, et Il aurait laissé les femmes tranquilles. J'étais tout jeune lorsque j'ai commencé à comprendre. Dans le cours de sciences naturelles, on m'avait expliqué que les spores s'enkistaient, et pouvaient survivre longtemps ainsi, au ralenti, tant que le milieu ambiant était hostile. Par une magie que les scientifiques ne comprennent toujours pas, le kiste disparaîtrait et la spore germe lorsque les conditions s'améliorent. Quand on y pense, ça n'est pas très différent de ces jeunes couples qui, tant qu'ils n'ont pas fini de payer la maison, le bateau et les dettes de jeu, préfèrent simplement ne pas avoir d'enfant. Dans l'incubateur, déposées sur l'agar-agar légèrement enrichi de solutés nutritifs, les bactéries vont s'y développer jusqu'à l'opacité, à moins que, monstres terrifiants pour elles, de toutes petites moisissures érigent d'impénétrables frontières dans ce microcosme. Les chevreuils et les gazelles rempliraient complètement nos forêts, s'il n'y avait pas l'hiver ou les prédateurs pour y mettre un terme. Et les loups meurent sans nourriture. C'est la très dure Loi. Les laboratoires universitaires forment et engagent de nouveaux chercheurs en période de subventions et d'opulence, ils se subdivisent en sous-laboratoires et se relogent dans des locaux plus vastes. Les syndicats établissent et affermissent leur pouvoir. Quand la douleur survient, un peu partout, plus tard, on parle de rationaliser les effectifs, et on fusionne les municipalités. Les éthologues qui ont étudié les religieuses ont statistiquement prouvé que, tenues en captivité dans des couvents, elles ne se reproduisent plus. Par contre, une naissance au grand air dans un parc zoologique, ou même l'apparition d'un petit oeuf dans la cage de nos pinsons, nous rassure sur le bien-être des animaux. Le feu se propage autant que possible. En fait, la caractéristique du bonheur, chez tout organisme, c'est de se répandre. Quoiqu'en disent les plus vaches, il n'y a pas de joie dans l'immobilisme: un peu de repos tout au plus, ça ne dure pas. Pour véritablement freiner l'expansion, il faut le froid, la faim, l'insécurité, et vraiment tout ce qui fait la douleur. Dans L'homme qui aimait les femmes, Truffaut fait dire au médecin: Le travail a été inventé pour que les hommes cessent de faire l'amour, de temps en temps. La douleur, pour nous et parfois, c'est de faire autre chose! Puisque l'espace et les ressources sont mathématiquement limités, la douleur devient inévitable, inéluctable, nécessaire. Dans le fond, et cela me semble être un concept extrêmement important, la douleur est l'expression de ce frein, absolument incontournable, sans lequel notre expansion n'aurait aucune fin, et déborderait la mesure du possible. Tous les informaticiens sentent en eux cet appétit de faire de beaux et vastes programmes, tous prêts qu'ils sont à révolutionner notre art et établir de nouveaux canons de perfection ou d'élégance. Si seulement nous n'avions pas toutes ces obligations, d'une utilité tellement douteuse, que nous imposent usagers et patrons, et autres Béotiens qui ne comprennent, mais alors alors pas du tout, la grandeur que pourrait avoir notre génie! Si par chance un mécène avait la bonne intuition de me prêter confiance, pouvoir et argent, qu'il me deviendrait alors facile de réaliser tous ces projets grandioses que j'imagine sans les faire. Quelle merveille ça serait pour l'humanité tout entière! Ne sentez-vous pas la même chose? Le dépit de certains est inconsolable. Les autres sont la cause du grand gaspillage de leur talent, de leur temps et de leur vie. À la semaine longue, ils jaspinent contre tout le monde, le destin, les preneurs de mauvaises décision, le système. Ils ressentent du soir au matin la douleur du péché originel et la partagent volontiers, à leur manière, plaignarde ou rude selon le caractère, à tous ceux qui les côtoient. D'un autre côté, je comprends fort bien que ça n'est pas toujours facile. Même si je garde un souvenir heureux de la plupart des emplois que j'ai occupés, certains m'ont laissé un goût de cauchemard dans la mémoire. J'aurais tellement de choses à vous raconter, que je ne vois pas par quel bout commencer. Mais justement, cette indécision me donne un fil conducteur. Car l'indécision est à la base même de la douleur spécifique de l'informaticien, lorsqu'il a la sagesse d'apprendre à reconnaître que la douleur provient de lui-même, et non pas de ceux qui l'entourent. C'est Olivier Lecarme, d'auguste mémoire, qui m'a vraiment fait prendre conscience de ma finitude. Je lui dois beaucoup, parce qu'à cette époque, beaucoup voulaient bien m'aduler comme un excellent programmeur, et mon humilité était toute disposée à prendre des vacances, tellement je trouvais confortable de donner raison à tout le monde sur ce point. Envers et contre tous, Olivier a réussi à me convaincre que je ne savais pas vraiment programmer, et qu'il me fallait tout apprendre. Il m'a dûrement mis en contact avec l'humilité prônée par Dijkstra (si vous ne connaissez pas, c'est le mot Dieu lorsque prononcé en hollandais!). Je vous gazouillerai tout ça, peut-être, un moment donné. Programmer, c'est souffrir. À l'époque du Cyber, une carte mal perforée, et plusieurs heures venaient d'être perdues. Les gens travaillaient aussi la nuit, moins nombreux. C'est donc la nuit que nous les dérangeions malgré tout pour faire des essais de système. Il fallait de longues heures pour préparer un essai. Une petite erreur, et nous perdions la nuit. Plus féroce encore, il était possible d'endommager le matériel (brûler la mémoire par échauffement, surexposer le phosphore des très coûteux écrans) par le seul effet d'une programmation système maladroite. Une erreur survenait, et en quelques minutes, plusieurs dizaines d'usagers, mécontents, inquisiteurs et curieux, se massaient devant nos fenêtres, et nous regardaient réparer. Je me sentais comme exposé dans un zoo. Ne pas nuire aux usagers. Ne pas perdre de fichiers. Ne pas gaspiller de nuit. Ce stress, toujours intense pour moi, faisait partie du métier. Il y a la douleur de choisir un langage de programmation pour un projet donné, sachant qu'aucun n'est parfait, et qu'il ne sera pas possible d'en changer une fois le projet bien engagé. Moins maintenant qu'autrefois, certains langages sont tout de même séparés par des murs épais, que l'on ne traverse pas impunément. Au niveau global comme au niveau menu, il y a la douleur de devoir choisir un algorithme, une structure de donnée, un style d'écriture, un nom pour une variable, alors que plusieurs s'offrent à l'esprit et qu'aucun n'est nécessairement meilleur qu'un autre, alors qu'un projet s'ébauche souvent au fur et à mesure qu'on le construit, et qu'un changement de direction demandera nécessairement un bon investissement d'énergie. Dans certains langages, une réorganisation de structure ne demande guère qu'une recompilation, alors que pour d'autres, il faut des semaines de travail. Ça n'est pas toujours simple, ni facile. À force d'y penser, j'ai fini par comprendre que mon métier, c'est essentiellement de mettre ensemble dans ma tête un paquet de tendances contradictoires, et de les opposer les unes aux autres avec énergie, avec obstination, avec douleur, tant et aussi longtemps qu'il faudra, jusqu'à temps qu'une harmonie naisse de ce chaos, et qu'il en résulte une solution cohérente, et avec un peu de chance, élégante parfois. Quant à tout le reste, auquel mon aveuglement donnait pourtant tant d'importance autrefois, je constate aujourd'hui que c'est de la petite cuisine, de la routine. Fondamentalement, mon rôle d'informaticien, c'est de prendre des tensions formelles sur moi, et d'utiliser mon paradigme humain de tensions nerveuses et d'intelligence animale, qui sort son individu de situations difficiles, pour trouver un relâchement à cet ensemble de tensions. La programmation que l'on observera ensuite, ça n'est rien de plus que l'expression externe de la solution retenue. Au début, je me désolais de constater l'impact physique important que les problèmes informatiques avaient sur moi. Maintenant, j'ai compris que c'est dans son essence profonde que le programmeur se réduit à l'état d'une mécanique, qui met la douleur humaine au service de la résolution des problèmes. Un informaticien, ca n'est rien de plus qu'une boîte à souffrir que l'on peut louer, et dans laquelle on place ses problèmes: ils ressortent résolus à l'autre extrémité. Voilà le vrai châtiment de Dieu! François Pinard,
février 1997.
Le téléphone de la terreur(dans la série François gazouille) Je devais partir en mission dans un autre pays, pour un petit temps. Comme il arrive parfois avant un départ, plusieurs d'entre vous ont des expériences semblables, il fallait régler plusieurs urgences, éteindre quelques feux et stabiliser l'ensemble, de telle manière que mon absence ne se remarque pas trop et que surtout, mon retour me soit plus agréable. La nuit précédente, et plusieurs autres avant d'ailleurs, je travaillais encore de longues heures, dans un état mental imprécis, situé quelque part entre l'éveil, le sommeil et le somnambulisme. D'un terminal à la maison, je communiquais avec l'une des quelques machines Unix dont j'avais la responsabilité. C'est expressément que mon patron m'avais demandé de mettre en place un nouveau dialer UUCP, pour couper sur les frais d'interurbains, avant mon départ. N'ayant ni le temps ni l'opportunité d'aller tout vérifier sur place, et pour m'assurer que tout était bien en fonction, j'ai rapidement configuré un voisin UUCP bidon, avec un nom inventé, mais utilisant mon propre numéro de téléphone, qui devait être appelé bientôt, soit à 4:03 du matin. Eh puis, à la course, j'ai coupé ma connection informatique. Effectivement, deux minutes plus tard, mon téléphone a sonné. Bravo, enfin, tout fonctionnait! J'ai soulevé le récepteur et l'ai laissé retomber en place. Fourbu, épuisé, je me suis tombé comme une roche dans le sommeil, me suis levé tôt pour prendre l'avion, et j'ai tout oublié de ce dernier test. La grande ivresse et la grande fatigue ont souvent eu l'oubli total en commun. Quelques semaines plus tard, après un voyage fructueux, en pleine forme, j'étais de retour. En plein milieu de la nuit, j'ai été réveillé par l'un de ces appels stupides, vous savez, où personne ne parle à l'autre extrémité. Probablement un faux numéro, commis par quelqu'un qui n'aura pas même eu la décence de s'excuser. Misère! Il y en a qui ne savent vraiment pas vivre… Le jour suivant, encore une fois, un téléphone en pleine nuit. Plutôt étrange. Et le jour suivant, la même chose… Quelque masturbateur (trice?) stimulé par ma voix? Et tous les jours suivants, avec une grande régularité, chaque nuit autour de quatre heures, un téléphone silencieux! Non, définitivement, ça ne ressemblait en rien à des appels d'intention obscène. Il fallait que ça soit autre chose. Ça relevait plus de la terreur. Mais qu'est-ce donc qui pouvait amener un individu à une telle persistance? Quelqu'un qui voulait me persécuter, au point de nuire à son propre sommeil avec une telle férocité? Parce que quand même, pour me réveiller, il fallait bien qu'il se réveille lui-même d'abord! Allons donc! Un bon gars comme moi, franc, sympathique et avenant avec tout le monde, ne pourrait pas avoir de tels ennemis! Non, ça n'était pas croyable. Il faut croire que c'est ça, vivre à Montréal! Allais-je faire intervenir le Bell? La police? J'étais pourtant sûr d'avoir le cuir plus dur que ça… Bof, toute désagréable qu'elle soit, ne me suffirait-il d'apprendre à vivre avec cette nouvelle misère? Je n'allais quand même pas permettre à un dément (ou une démente) de déranger ma vie, ni lui donner un tel pouvoir. Alors, le plus simplement du monde, tous les soirs, j'ai pris l'habitude de fermer le volume de la sonnerie, et de laisser mon répondeur s'occuper de recevoir l'appel nocturne à ma place. Pourquoi m'en faire? Une machine, j'en étais sûr, allais bientôt décourager le plus féroce des dérangés. Pourquoi s'y obstinerait-on, une fois compris que, manifestement, la persécution ne m'affecte plus? Mais contre mes espoirs, tout a continué. Jour après jour, semaine après semaine. Ce qu'il faut être siphonné pour fixer ainsi, éperduement, sur un numéro de téléphone particulier. Était-il Dieu possible que quelqu'un puisse me haïr à ce point? Ça dépassait mon entendement. Alors, penaud d'avoir tant attendu sans avoir réussi à décourager mon bourreau, ne serait-ce qu'un peu, je me suis finalement résolu a prendre information auprès de la compagnie de téléphone et de la police, qui m'ont envoyé les paperasseries légales par lesquelles je m'engageais à poursuivre en justice l'offenseur, une fois que les appareils de pistage l'auraient bien identifié. Le téléphone afficheur n'était pas encore inventé à ce moment-là, et c'était alors une condition préalable, posée par le Bell, avant de mettre en place l'artillerie lourde. Mais, chanceux dans ma malchance, et avant d'avoir retourné les papiers signés, j'ai eu à travailler à nouveau sur la configuration UUCP de la machine pour laquelle j'avais installé un nouveau dialer. (Bien sûr, je me souvenais au moins d'avoir fait cette installation, quand même!) Mais mon oeil a été attiré par ce nom de site UUCP étrange, que je ne connaissais pas. Ma curiosité attisée, et en scrutant davantage, imaginez ma surprise ébahie d'y découvrir mon numéro de téléphone. Mais comment donc mon propre numéro, à la maison, a-t-il pu atterir dans ce fichier? Puis, tout d'un coup, frappé par l'éclair, tout m'est revenu à la mémoire. L'essai, plusieurs mois auparavant, juste avant de m'envoler au loin! Et ce 4:03, très clair, tellement évident dans les fichiers de configuration! Et l'essai qui s'est poursuivi, automatiquement, jour après jour. En une seconde, toute l'horreur m'est apparue. C'était moi, le forcené qui m'avait persécuté pendant des mois! Avec mon gazou un
peu paranoïde!
Conway, Fractran et autres broutilles(dans la série François gazouille) John Conway nous fait surtout penser au modèle d'automates cellulaires qui porte son nom, que Scientific American a popularisé sous le nom Life (le jeu de la vie), il y a peut-être une trentaine d'années déjà. La plupart d'entre vous connaissez assez bien ce jeu. Il avait provoqué un engouement universel dans les Universités, à l'époque. Les ordinateurs étaient encore difficiles d'accès, et fort peu interactifs, plusieurs ont passé de longues soirées à barbouiller des générations de cellules, d'une feuille de papier quadrillé à l'autre, absolument mystifiés d'apercevoir un comportement global complexe, mais issu des influences d'un voisinage restreint et d'actions extrêmement locales. Voir émerger la complexité d'une simplicité quasi dérisoire, cela étonne toujours. Nous avons plutôt l'habitude du contraire: la désintégration radio-active est bien prévisible prise globalement, la loi de la limite centrale banalise toutes les distributions aléatoires, et certains comportements de foule sont bien plus simples que celui des individus qui la composent. Nous sommes fascinés par les ensembles de Mandelbrot, ou même par ces images que xmartin (fractals itératifs) affiche sur le fond de nos écrans. Au-delà de l'effet visuel et des jolies couleurs, une complexité infinie résulte de l'application de règles absolument simples, pourtant. Les mathématiques transportent en elles de telles étrangetés, qui nous hypnotisent. J'ai passé de longs moment à observer un autre jeu, peut-être moins connu, mais fort simple. Une grille est complètement peuplée de points noirs ou blancs, au hasard. Chaque point représente un individu, et sa couleur une opinion politique, dans une société où seulement deux opinions existent. L'influence de chaque individu ne va pas plus loin que ses huit voisins immédiats, un à la fois. Un individu fera prendre sa propre couleur à son interlocuteur, ou encore, prendra la sienne, dépendamment lequel des deux est le plus convainquant. En fait, chaque itération choisit une paire de points voisins tout à fait au hasard, et au hasard aussi, l'un des points choisi prendra la couleur de l'autre. Comme un ordinateur peut exécuter une telle simulation à bonne vitesse, en autant que l'on soigne un peu la programmation, il est passionnant de voir évoluer une telle sociéte. La grisaille du départ est assez rapidement remplacée par des petits pays, qui grossissent et deviennent des continents, dont les frontières se dessinent et s'affermissent avec le temps. Est-ce qu'une opinion finira par complètement l'emporter sur l'autre? Je vous suggère d'en faire l'essai, et de me partager vos trouvailles. Voici un autre exemple de complexité cachée, que l'on doit encore une fois au John Conway de tout-à-l'heure, dit-on. Un ordinateur reçoit des données, exécute un programme, et produit des résultats. Voici donc une machine hypothétique, qui reçoit une donnée sous la forme d'un nombre entier, placé dans son unique accumulateur. Elle reçoit aussi un programme sous la forme d'une série de fractions. Par exemple: l'accumulateur pourait recevoir la donnée 2, et le programme consisterait dans la suite de fractions: 17/91, 78/85, 19/51, 23/38, 29/33, 77/29, 95/23, 77/19, 1/17, 11/13, 13/11, 15/14, 15/2 et 55/1. Je vous donne les détails, pour que vous puissiez faire fonctionner tout ça sur votre ordinateur préféré. La machine tente la multiplication l'accumulateur par la première fraction, ou la seconde, et ainsi de suite dans l'ordre, mais n'accepte de le faire uniquement que si le résultat est un nombre exactement entier. Si toutes les fractions sont essayées et qu'aucune ne fournit un résultat entier, alors la machine cesse de fonctionner, elle s'arrête. Dans l'exemple donné plus haut, la dernière fraction possède 1 comme dénominateur, on peut en déduire que la machine ne s'arrêtera jamais pour ce programme-là. Aussitôt qu'une multiplication réussit en donnant un nombre entier, alors une étape de la machine est complétée, et l'on ne va plus avant dans la liste des fractions. Plutôt, l'accumulateur est examiné pour voir s'il contient un exposant exact de deux (autrement dit, si en binaire, l'accumulateur contient un seul bit à un suivi uniquement de bits à zéro). Dans ce cas uniquement, l'exposant de deux (le nombre de bits zéro après le bit un) est imprimé, et l'on continue. L'étape suivante débute alors immédiatement avec la première fraction de la liste. Je ne vous ai pas donné au hasard, plus haut, l'accumulateur initial et la suite de fractions. Ce programme exécute un algorithme précis, reconnaissable facilement aux résultats imprimés. Mais je vous laisse le soin de découvrir ce que ce programme calcule exactement. Si nous travaillons bien de la même manière, le premier résultat sera imprimé après 19 étapes, le second résultat apparaîtra après 69 étapes, et le troisième après 280 étapes. Ce seront trois nombres plus petits que 10. Conway aurait donné le nom Fractran à cette machine, pour rire de FORTRAN probablement, et en faisant un jeu de mot sur fraction. Seriez-vous capables d'imaginer un programme Fractran, c'est-à-dire une série de fractions, capable d'imprimer bêtement la valeur de l'accumulateur au départ? Ou d'imprimer le carré de cette valeur? Ou d'imprimer une valeur constante? Vous avez le droit de coder la donnée de départ spécialement, si cela vous aide. Un minuscule
problème que vous rencontrerez, en implantant une machine
Fractran, sera de vérifier si un nombre entier est un
exposant exact de deux. Dans le langage C, cela se
vérifie par l'énoncé suivant: Sur le même air d'aller, en réfléchissant un peu, on voit bien qu'un nombre est un exposant exact de deux (ou la somme de deux exposants de deux), il suffit de compter le nombre de bits à un dans l'accumulateur et vérifier que cette somme vaut un (ou deux). Certains ordinateurs possèdent une instruction unique qui fait le décompte des bits valant un, dans un registre. Mais le langage C n'y donne pas accès. Existerait-il alors, dans le langage C, quelque façon efficace de compter le nombre de bits allumés, dans la représentation binaire d'un entier? C'est le temps, je crois, de laisser votre curiosité vous amuser un peu. En cherchant des réponses aux petites questions données plus haut, vous trouverez au moins un peu de plaisir! Avec mon gazou le
plus amical!
Les éditeurs, et Emacs: plus jamais(dans la série François gazouille) J'en avais ras-le-bol d'apprendre et de réapprendre des éditeurs à chaque fois que je changeais de pupitre. Au début, c'était amusant, ces éditeurs de ruban de papier pour PDP-11, Interdata, et autres petites machines qu'il m'a fallu tous comparer et digérer. Le Cyber, énorme écraseur à l'époque, pourtant pauvre en logiciels, en avait foison, parce que chaque site avait apporté sa solution. Au Centre de Calcul de l'Université de Montréal, mon alma mater, ce fut d'abord TELUM (Mulet à l'envers, comme disait Gilles Brassard), et plus tard, partie d'un Telum profondément refondu, ED. Une centaine d'usagers simultanément présents s'arrachaient un seul CPU muni d'une petite mémoire. C'était un tour de force que d'y parvenir, et la prestigieuse réussite de l'équipe système du temps qui, sous la paternelle surveillance de Guy Basque, a permis à des Alain Rochon, Godefroy Lemonnier et Pierre Gaumond d'exprimer leur point de vue. On pourrait faire un roman de cette épopée. Plusieurs de ceux qui ont pesté contre les /I et les /*D n'ont pas vu à quel point ces compromis étaient adéquats, et permettaient à l'implantation de faire tant avec si peu. En bout de course, avec les Groupes d'Intervalles Admissibles, et un grand nombre de commandes nuancées, ED préfigurait la luxuriance totale, et l'orgasme cybernétique. Les usagers ont été fort bien servis! Mais ED n'existait qu'à l'Université. À la défunte Société de Mathématiques Appliquées, qui a d'abord optimisé le placement des fauteuils à la place des arts, puis calculé les listes de payes de débardeurs du port, avant de faire du film porno, puis disparaître, nous parlions Télesma, un éditeur très différent, mais fort puissant, conçu par André Dupras. Pas trop d'usagers à la fois, par contre. BONJOUR avait son AIDIT, j'ai avalé UCEDIT, l'éditeur d'INTERCOM, d'autres pour NOS, j'en passe sûrement. Au Centre Météorologique de Dorval, un nid de fonctionnaires canadiens, peut-être le seul on l'on a horreur de passer la journée à parler de la pluie et du beau temps ☺, j'aurai au moins découvert TXED, à l'honneur là-bas, admirable dans l'orthogonalité de ses concepts, élégant, et produit par un étudiant brillant de Concordia. J'ai tapagé pour TXED à l'Université, qui l'a finalement installé, mais Guy Basque, qui s'y est senti forcé, m'en a voulu un peu. J'ai le cuisant souvenir d'un éditeur innommable qui, après deux fois un deux-points dans une même ligne, brisait et bloquait la ligne de communication entre Montréal et Québec pendant un bon quart d'heure, sans pardon possible. Aucun éditeur alternatif. Il ne fallait qu'attendre. Mon écriture dense, avec les := de Pascal, combinés à l'habitude, rendait la chose épouvantablement malcommode. L'équipe informatique locale avait appris à vivre très harmonieusement avec la situation et développé, en plus d'une grande désinvolture, une expertise certaine au backgammon. Mais pour moi, alors déchiré entre plusieurs contrats et pour qui chaque heure était précieuse, c'était l'horreur totale. Le PDP-10, une machine magnifique, et qui répondait Not war? à la commande make love, m'a révélé TECO, unique en son genre, cryptique, puissant. On pouvait tout faire en TECO: mon bon ami Gilles Brassard y avait commis un macro capable de jouer au Nim avec l'usager. Puis, à la toute autre extrémité du spectre, SOS, une espèce de super-TXED, verbeux, utile, excellent, que j'ai étudié très profondément, aussi. Et le EDT de RSX-11 et du VAX? Trois éditeurs en un, disait la publicité! C'était fort vrai: il m'a fallu les examiner et les apprendre tous les trois, et en grand détail. Sur mon petit Apple ][, principalement Wordstar, et le bijou de concision que Borland en a fait par la suite, plus tard Wordperfect sur MSDOS, et quelques autres, c'est sans fin. Pour Odyssée Recherches Appliquées alors naissant, j'ai appris Unix tout seul dans un coin sombre, sans autres ressources qu'une pile de manuels. Pour installer et réseauter leurs machines, j'ai dû avaler vite et beaucoup. ed, ex, vi (sans enthousiasme), et oh donc! Alors, quand Alain Polguère, homme aux innombrables caprices, a cherché à me convaincre avec ardeur qu'il me fallait absolument apprendre un nouvel éditeur nommé Emacs, j'ai simplement pensé Pas encore un autre! et n'ai vraiment rien voulu savoir. Lorsqu'il m'a pressé de le lui installer et m'a fourni, sur ruban QIC, une distribution de plusieurs Megs et partiellement écrite en LISP, je me suis dit: Mais qu'est-ce que cette abonimable horreur!. Devant l'insistance d'Alain et, comme chacun le sait, toujours bon prince en tout ☺, l'un de ces tranquilles vendredi soirs, je m'y suis mis. C'était des siècles avant Autoconf, croyez-moi. Installer Emacs à cette époque, pour un néophyte comme moi, c'était la croix et la bannière, mais j'ai vaincu. Bon, bien! Hors de Suntools, sur l'écran brut, j'appelle emacs, une fois seulement, juste pour voir si mon installation donne quelque chose. Bon, parfait, ça répond, c'est installé! Comment sortir d'ici maintenant? quit? exit? q? x? e? Mais qu'est-ce que cette histoire… Bon, s'il faut être brutal alors: Ctrl-C? Ctrl-Y? Ctrl-\? Esc? Rien!? Mais c'est une abomination! mon, sys, system, shell, out, merde… Allons donc, un administrateur de système Unix ne va tout de même pas à aller jusqu'à réamorcer une station de travail pour sortir d'un éditeur! On a sa fierté, fichtre! Alors, vous savez ce que j'ai fait? La mort dans l'âme, à mon corps défendant, furieux, je me suis résolu à suivre les instructions données au départ, et j'ai lu le tutoriel de Emacs, en grognant, en gémissant, en maugréant, jusqu'au moment où, beaucoup trop d'écrans plus tard, je finisse par découvrir la combinaison de clefs, magique et damnée, qui me permettra de sortir du ventre du monstre. Et je me suis bien promis, ce jour-là, que les poules auraient des dents avant qu'on m'y revoie, dans cet éditeur! François Pinard,
août 1995.
Jack, opinions et société(dans la série François gazouille) «Ouvrez-moi!», quel nom inattendu pour un journal! À une autre époque, ne croyez-vous pas, un titre pareil aurait sûrement attiré l'attention de Jack l'éventreur! Oh, je sais bien, les temps ont changé, et nous n'en sommes plus là, paraît-il. Et pourtant, chez certains de mes lecteurs, mes opinions réveillent parfois, encore, un petit éventreur au fond de leur âme! ☺ Non, que certains se rassurent, que d'autres me pardonnent, je ne vous entretiendrai pas tout de suite de l'usage d'un français correct en messagerie informatique. Pas ce coup-ci, en tout cas. Laissez-moi d'abord décanter le million de caractères accumulés sur nos pratiques québécoises, pour en distiller la quintessence, pour fractionner elixirs et venins, que nous boirons ensuite tout ensemble. L'équipe du journal me laisse la voie libre pour discuter ici, à chaque parution, d'un sujet de mon choix, et j'ai bien l'intention de m'y amuser! Mes interventions pourraient être anecdotiques et rappeler des fragments d'histoire. Je pourrais présenter des petits problèmes concrets ou théoriques, et esquisser leur solution. Ou faire des mini-sondages sur des sujets précis et commenter les résultats. Bien sûr, partager quelques problèmes ou avenues que j'aperçois dans GNU, ou même, dans ma programmation personnelle. Et pourquoi pas, si le coeur m'en dit, parler de mon orgue, tout simplement, pour le plaisir de sa mathématique! Aujourd'hui, j'aurais voulu vous parler des grandes oeuvres, vous faire l'apologie des dictatures, et chicaner un peu la démocratie. Il me reste bien peu d'espace pour aborder toutes ces grandes questions. À une autre fois, donc, les avantages de la dictature! Pour l'instant, laissez-moi esquisser quelques réflexions sur les méfaits de la démocratie. Et pourtant, il y aurait tant à dire! Les malaises de l'informatique reflètent, plus que l'on pense, ceux de la société. En cette fin de siècle, la démocratie se réduit de plus en plus à un ensemble de mécanismes pour protéger obsessivement les libertés dites individuelles, pour devenir une espèce de pacte collectif dans lequel chacun s'entend pour tout laisser faire autour de lui, pourvu qu'en retour où on lui laisse tout faire de son côté. La distinction entre mollesse et tolérance est totalement confuse, et il est de plus en plus rare de voir quelqu'un oser prendre une décision qui serve autre chose que d'appronfondir ce pacte orienté vers un laisser-faire général. En informatique comme dans la vie, il est plutôt mal vu d'avoir une opinion, et très indélicat d'aller jusqu'à l'exprimer. Dites n'importe quoi de significatif, et l'on vous servira un tollé de protestations. Prenez une décision exécutoire, ou son contraire exact si vous préférez, vous recolterez de toute façon une grève et des pancartes. Pour faire taire la clameur ou éviter le procès, vous vous excuserez d'avoir parlé. Pour débloquer les rouages, vous retirerez votre projet de loi, et amenderez vos coupures. En tant qu'informaticiens, nous goûtons depuis longtemps à l'anarchie originale de Usenet, et son prolongement naturel sur l'Internet. De plus, notre époque transporte une espèce de terreur d'obéir à quelque chose, ou de nous plier à une exigence collective, à moins que le «sacrifice» soit rentable à très court terme. Les gens ne font plus crédit! Ce cosme cybernétique caricature habilement notre société mondiale, et nous laisse un avant-goût de ce que nous sommes en train de devenir, en moyenne. Je vois trop souvent cette terreur latente s'exprimer par une susceptibilité à fleur de peau, à fleur d'âme, à fleur d'égo. Un égo d'ailleurs gonflé à l'extrême, tendu, souvent vide et terne, plutôt mince, et très très fragile… Avec un peu de chance, si je ne suis pas en procès, et si vous n'éclatez pas tous entre-temps ☺, nous devrions nous rejoindre plus tard, dans un autre «Ouvrez-moi!». Jack? François Pinard,
avril 1995.
Choix d'un orgue
... Effectivement, j'aurais pu mettre de la pression et avoir l'orgue au printemps, mais dans ce genre d'ouvrage fait pour durer 200 ou 300 ans, il serait fou de vouloir sauver 2 mois sans raison. Les artisans se suivent et se remplacent selon leur spécialité, mais ils sont peu nombreux à travailler en même temps. Pratiquement tout est fait à la main. Toute la mécanique de l'orgue est essentiellement une pièce d'ébénisterie de haute précision. Le buffet est de l'ébénisterie décorative. Les tuyaux sont amalgamés, titrés, coulés, étendus, martelés, roulés et assemblés à la main, mais ailleurs, en Allemagne. L'harmonisation des 1245 tuyaux, qui consiste à sculpter le son qu'ils produisent en fonction de critères esthétiques bien définis, d'abord à l'usine, ensuite au point de livraison. Quoique certains organiers partent d'arbres entiers et fasse eux-mêmes le sciage des planches et le séchage, dans mon cas, les matériaux bruts sont préparés et obtenus d'ailleurs. Il s'agit d'abord de toute une panoplie de types de bois séchés à la perfection, venant de divers pays selon la dureté, la porosité, les qualités sonores et la beauté du grain. Les tuyaux utilisent des mélanges précisément dosés de plomb, d'étain, et de traces d'antimoine pour les durcir. Les abrégés utilisent des tiges d'aluminium et des fils de laiton obtenus d'ailleurs. Dans les registres, il y a des anneaux télescopiques en plastique qui ont été moulés ailleurs, et de grandes lames de matériel synthétique qui, usinées sur place, sont quand même achetées d'autres industries. Notre organier ne fabrique pas lui-même ses colles. La soufflerie, constituée d'un moteur électrique très silencieux et d'une centrifugeuse, est toute entière achetée d'usines spécialisées. Par contre, le soufflet cunéiforme sera assemblé sur place, pans et peaux. L'organier sait très bien où il s'en va. Mais je suis les travaux au nom de la paroisse, pour bien connaître la manière dont notre orgue sera fait, et interagir si le cas me semble critique. Mais le contrat est explicite sur un très grand nombre de points, la marge de manoeuvre n'est pas très grande. Des gens m'ont suggéré de plonger et de me gaver de musique, autant que je le puis, de manière à me préparer à faire un meilleur choix. Voici un peu de quelle manière j'ai procédé. En musique, je pratique l'orgue régulièrement à l'Assomption (un Casavant 1926 électropneumatique de 28 jeux sur 3 claviers, devis romantique servant la musique française) et à Repentigny (un Guilbault-Thérien 1988 mécanique de 22 jeux sur 2 claviers, devis classique servant les musiques françaises et allemande). En plus du répertoire «classique» auquel j'ose m'attaquer, je voudrais apprendre quelques pièces québécoises composées récemment. Je pense de ce temps-ci à écrire quelques harmonisations de courtes pièces, plutôt que toujours les improviser lorsqu'on me demande d'accompagner aux offices. J'ai en tête de faire la transcription pour orgue d'une grande pièce orchestrale, de Holst. Je participe aussi à plusieurs groupes d'organistes: l'AOM et Laudem à Montréal, et sur invitation, quelques activités des AO de Québec ou d'ailleurs. Justement, je passe la journée de lundi à l'abbaye cistercienne de Rougemont à un atelier sur l'improvisation d'accompagnement. Je m'occupe aussi, à temps perdus, d'organiser une association locale d'Amis de l'Orgue dans mon village. J'assiste aussi à plusieurs concerts, bien sûr. Justement, Mario Duella joue dimanche à 14:30 à l'église Saint-Marc-de-Rosemont (Beaubien, quelques blocs à l'est d'Iberville), sur un Casavant 1961 de 38 jeux répartis sur 3 claviers. C'est un orgue de tradition romantique française qui a la bizarre originalité de ne pas avoir de buffet. Viens faire un tour: c'est gratuit (il y a quête à la fin). En informatique, de ce temps-ci, le projet GNU m'occupe avec l'entretien de m4, de gptx et de wdiff, mais aussi par quelques contributions au projet Autoconf et à Taylor UUCP, et un grand nombre de broutilles qu'il serait long d'énumérer. Comme projet spécial, j'ai en tête un convertisseur automatisé de texte ASCII vers Texinfo, dans le but de traiter la majorité des FAQ sur Usenet. Je veux apprendre de manière approfondie l'usage de TeX, METAFONT et le système de fenêtrage X. J'ai quelques projets libres en infographie ou en traitement d'images; depuis quelques semaines, je réfléchis au problème de la vision stéréoscopique, mais cela me semble très ardu. Je combine
musique et informatique dans un projet scoredit,
qui n'est pas très avancé mais qui devrait prendre de
l'ampleur. Il s'agit d'un système d'édition de partitions
musicales, conduit interactivement. Je veux aussi
m'attaquer au problème de la reconnaissance optique de
partitions déjà écrites. En moindre priorité, je voudrais
traiter de la production de séquences MIDI, parce que
plusieurs me le demandent. Contents |
||||||||||||||||||||||||||||||||||||||||||||||
notation. I was not patient enough to try more
substantial LaTeX, in view of really using the
rendering I hoped for, so this is a compromise.
tomboy-LaTeX does not provide an easy way for
augmenting LaTeX with one's own definitions, as each
mathematical snippet starts with a virgin
environment.
and
,
and were amazed to see the intense recursion, and the
numbers it could produce. After all, the most
aggressive operation towards bloating the
resulting value is adding 1 to 
,
and got permission to run it as a low priority job, so to
not disrupt operations nor impact users. Using
checkpoints and restarts to go through scheduled system
deadstarts, I let it run for many weeks, but at no
time I even saw the shadow of a success.
objects
(from 0 to 
) taken
among 
or
, is
computed by:
.
, let's
replace 
wherever it is greater than half of 
.
.
.
,
is merely a particular case of the multinomial.
.
, but we
do not use this). Because 
, the
theorem trivially holds for all 
. If it
holds for 
. Merely
consider this:
and,
because it has 
