Installation is easy:

git clone git://github.com/acieroid/py-t2n
cd py-t2n
python setup.py install

py-t2n has been tested successfully on FreeBSD and Linux, and should work on Microsoft Windows and any other OS where nxt-python is running.

usage: t2n.py [-h] [-b] [-i] [-ls] [-put <file>] [-get <file>] [-version]

Talk to NXT with Python

optional arguments:
  -h, --help   show this help message and exit
  -b           Check battery level
  -i           Print NXT info
  -ls          List files
  -put <file>  Upload file
  -get <file>  Download file
  -version     Print this software's version

Dans cet article nous allons voir plusieurs outils permettant de développer vos applications en Common Lisp plus efficacement. Ces outils vont d'un bon éditeur avec une bonne configuration à de bons moyens de débuggage, tout en passant par une connaissance de la documentation existante et l'utilisation de bibliothèques appropriées.

Le Common Lisp ayant un modèle de développement itératif et interactif, il vous faudra un éditeur qui facilite l'interactivité. C'est le cas de GNU Emacs, l'éditeur généralement préféré par les programmeurs Lisp. Ce n'est évidemment pas le seul éditeur adapté au Lisp, citons par exemple Vim avec les plugin slimv ou Limp, ou bien l'IDE non libre de Lispworks. Néanmoins, slimv et Limp ne font qu'imiter ce qu'Emacs peut faire avec SLIME, et Lispworks n'étant pas libre, Emacs reste préférable.

Pour installer Emacs, référez vous à la documentation de votre distribution.

Néanmoins, si vous êtes plus confortable avec un éditeur autre qu'Emacs, ou que pour quelconque raison vous ne voulez pas utiliser Emacs, vous allez passer beaucoup de temps dans le REPL de votre Lisp, il vaut donc mieux bien le configurer.

Le REPL de CLISP est assez bon de base (support de type readline, autocomplétion etc.).

Pour ce qui est de SBCL, il n'y a pas de telles fonctionnalitées par défaut. Il faut donc:

• soit utiliser rlwrap pour avoir un support de readline
• soit installer linedit qui apporte des fonctionnalitées similaires à celles du REPL de CLISP (linedit est installable via Quicklisp, voir plus loin).

Si vous installez linedit, veillez à ajouter ceci à votre ~/.sbclrc:

;;; Check for --no-linedit command-line option.
(if (member "--no-linedit" sb-ext:*posix-argv* :test 'equal)
    (setf sb-ext:*posix-argv* 
          (remove "--no-linedit" sb-ext:*posix-argv* :test 'equal))
    (when (interactive-stream-p *terminal-io*)
      (require :sb-aclrepl)
      (require :linedit)
      (funcall (intern "INSTALL-REPL" :linedit) :wrap-current t)))

SLIME, le Superior Lisp Interaction Mode for Emacs est le mode ultime pour programmer en Common Lisp. Il permet d'avoir un buffer connecté à votre processus Lisp, et d'y envoyer du code à évaluer depuis un fichier Lisp avec un simple raccourci. Il inclut également de nombreuses features très pratique aussi liées à la documentation, l'indentation, la recherche de défitions, le débuggage etc.

Paredit est un mode mineur (qu'on peut donc charger en même temps que d'autres modes) permettant de manipuler plus facilement les expressions parenthésées. Cela est donc très pratique pour ce qui est de l'édition de code Lisp. Néanmoins son utilisation peut être assez rebutante au début, donc n'hésitez pas à prendre SLIME et Emacs bien en main avant d'utiliser Paredit.

Si votre code ne fonctionne pas, ANSI Common Lisp nous propose quelques mécanismes afin de faciliter le débuggage.

Common Lisp possède de nombreuses bibliothèques, couvrant de nombreux domaines d'applications. Le meilleur endroit pour trouver une bibliothèque correspondant à ce que vous cherchez est sur cliki, et spécialement sur la page reprenant les bibliothèques recommandées actuellement.

Utiliser les bons outils ne suffit pas, il faut aussi savoir coder en Lisp. Pour cela, les livres peuvent d'être d'une grande aide. Cette section reprends donc les bons livres traitant ou utilisant le Common Lisp.

Nous avons donc vu ici un bon nombre de techniques et d'outils adaptés au développement de programmes en Common Lisp. Bien évidemment, tout ce qui a été vu ici ne doit pas spécialement être utilisé, bien que cela puisse rendre parfois la vie bien plus facile. Cet article n'est en rien une référence pour aucun des sujets présentés ici, pour cela, référez-vous à la documentation correspondante (dont les liens sont fournis dans cet article).

Ce document regroupe un ensemble de conseils et de liens vers des ressources externes afin de faciliter l'apprentissage de la programmation fonctionnelle avec Scheme.

Ce document s'adresse à toute personne intéressée par la programmation fonctionnelle (ou par la programmation en général) et ne requiert pas spécialement de connaissances en programmation.

Il faudra néanmoins un niveau correct d'anglais (savoir comprendre un texte avec des termes spécifiques à l'informatique) afin de pouvoir exploiter les ressources données ici. Bien qu'il existe de nombreux documents en français, la plupart sont en anglais et la connaissance de l'anglais est plus que nécessaire de nos jours.

Avant tout, sachez que la meilleure méthode pour apprendre un langage n'est pas de lire des livres, mais de pratiquer. Certes la lecture de livres vous aiguillera sur le bon chemin, mais rien ne pourra remplacer la pratique qui vous permettra d'assimiler le langage et d'apprendre de vos erreurs.

Ce document a été formaté grâce à org-mode.

Vous êtes autorisés à utiliser, modifier, distribuer ce document sous les termes le la licence Creative Commons Attribution 2.0 (CC-BY).

Tout commentaire est le bienvenu, par mail à acieroid -at- awesom -dot- eu.

Robotime is a robots-like game. Robots is an old turn-based game (you can test the original one by installing bsdgames if you're under Linux) with a very simple principle:

Robots is played on a two-dimensional rectangular grid. The objective of the game is to escape from a number of robots, which have been programmed with only a single objective: to kill the player. – Wikipedia

Robotime has some differences with the original robots games:

Any feedback, suggestions, bug reports, etc. is welcome at #lispgames (irc.freenode.org) or in french at #GCN (irc.langochat.org).

La première chose à faire avant d'écrire une macro est d'écrire un ou deux exemples d'utilisation de cette macro, afin de clarifier nos idées. Comme la syntaxe '#(…)' est déjà utilisée pour les vecteurs, nous allons utiliser des crochets pour délimiter les fonction anonymes raccourcies, comme dans arc, mais nous allons garder le symbole pourcent suivit d'un nombre de clojure pour identifier les paramètres. Ainsi, l'exemple précédent s'écrira comme suit en Common Lisp grâce à notre macro:

(mapcar [format t "Hello, ~a~%" %] '("world!" "you!"))

Et sera équivalent à:

(mapcar (lambda (x) (format t "Hello, ~a~%" x)) '("world!" "you!"))

Mais premièrement, on va laisser les crochets de côté et écrire une macros qui sera équivalente. On verra à la fin de cet article comment faire pour manipuler le code avant le reader et donc pouvoir utiliser les crochets. Contentons nous pour le moment de manipuler le code après le reader et avant l'évaluation.

Dans le développement de macros, il est préférable de coder la macros en plusieurs étapes. Nous allons donc écrire une première version de fn (notre macro), qui ne prendra pas en compte le nombre et l'ordre de ses arguments (le premier qui apparaîtra dans le code sera le premier argument, peu importe son numéro, et (fn (1+ %3)) ne prendra qu'un argument plutôt que trois).

Pour récupérer tous les symboles commençant par un % au sein de notre macro, nous auront besoin des fonctions flatten (voir On Lisp, p. 49) et percent-symbol-p. La première, très utile pour les macros, « aplatit » une liste, par exemple:

> (flatten '(1 (2 (3 4) 5) 6))
(1 2 3 4 5 6)

La seconde permet simplement de savoir si un symbole commence par un %:

> (percent-symbol-p '%foo)
T
> (percent-symbol-p 'foo)
NIL

Voici leur définitions:

(defun flatten (x)
  (labels ((rec (x acc)
             (cond ((null x) acc)
                   ((atom x) (cons x acc))
                   (t (rec
                       (car x)
                       (rec (cdr x) acc))))))
    (rec x nil)))

(defun percent-symbol-p (sym)
  (string= (subseq (symbol-name sym) 0 1)
           "%"))

On peut alors définir fn assez simplement: on récupère tous les symboles commençant par %, et on encapsule le code dans un lambda qui prend les symboles récupérés comme arguments:

(defmacro fn (code)
  (let ((args
         (remove-duplicates
          (remove-if-not #'percent-symbol-p
                         (flatten code)))))
    `(lambda ,args
       ,code)))

Il est donc déjà possible d'utiliser cette macro:

> (mapcar (fn (1+ %)) '(1 2 3))
(2 3 4)

Maintenant que l'on a une macro de base qui fonctionne, on peut commencer à régler ses défauts petit à petit. La façon la plus simple pour gérer l'ordre des symboles et prendre en argument des symboles qui n'apparaissent pas dans le code et de récupérer l'argument maximal et de générer la liste de tous les arguments inférieurs.

On va donc avoir besoin de quelques fonctions supplémentaires:

• mkstr (On Lisp, p. 58) qui transforme tous ses arguments en string
• symb (On Lisp, p. 58) qui convertit la chaîne de caracère formé par ses arguments en symbol
• percent-value qui permet de connaître la valeur d'un symbole commençant par % (par exemple, % et %1 valent 1 et %3 vaut 3)
• gen-percents-syms qui génère tous les symboles pourcents entre 1 et la valeur maximale

(defun mkstr (&rest args)
  (with-output-to-string (s)
    (dolist (a args) (princ a s))))

(defun symb (&rest args)
  (values (intern (apply #'mkstr args))))

(defun percent-value (sym)
  (if (symbolp sym)
    (let ((sym-name (symbol-name sym)))
      (handler-case
          (if (string= (subseq sym-name 0 1) "%")
              (if (= (length sym-name) 1)
                  1
                  (parse-integer (subseq sym-name 1)))
              0)
        (parse-error () 0)))
    0))

(defun gen-percents-syms (max)
  (loop for i from 1 to max
       collect (symb "%" i)))

La nouvelle macro se définit alors:

(defmacro fn (code)
  (let ((arg-max (loop for sym in (flatten code)
                      maximize (percent-value sym))))
    `(lambda ,(gen-percents-syms arg-max)
         ,code)))

Notre macro est presque complète, il ne nous reste plus que deux cas à gérer:

• clojure permet aussi d'utiliser %& pour définir des arguments de type &rest
• il faut que % soit équivalent à %1

Cela se fait assez facilement:

(defun replace-symbol (symbol1 symbol2 list)
  (typecase list
    (list (mapcar (lambda (x) (replace-symbol symbol1 symbol2 x))
                  list))
    (t (if (eq list symbol1)
           symbol2
           list))))

(defun gen-percents-and-rest (max restp)
  (if restp
    (append (gen-percents-syms max) '(&rest %&))
    (gen-percents-syms max)))

(defmacro fn (code)
  (let ((arg-max (loop for sym in (flatten code)
                      maximize (percent-value sym)))
        (restp (find '%& (flatten code))))
    `(lambda ,(gen-percents-and-rest arg-max restp)
       ,(replace-symbol '% '%1 code))))

Nous allons maintenant avoir recours aux read-macros pour modifier le code avant que le reader ne le lise. Tout ce que notre read-macro a à faire ici, c'est de transformer une expression du type [...] en (fn (...)). On définit donc une fonction qui sera appelée chaque fois qu'un crochet ouvrant est rencontré dans le code, qui se charge de lire le code jusqu'au crochet fermant et de retourner le code lu. Le premier argument d'une telle fonction est le flux depuis lequel lire le code, et le second correspond au caractère qui a déclenché son appel. Comme nous ne l'utilisons que pour un [, on peut ignorer ce second argument.

(defun bracket-reader (stream c)
  (declare (ignore c))
  (let (chars)
    (do ((char (read-char stream) (read-char stream)))
        ((char= char #\]))
      (push char chars))
    (read-from-string
     (format nil "(fn (~a))" (coerce (nreverse chars) 'string))))

Et on définit finalement [ comme macro-character:

(set-macro-character #\[ #'bracket-reader)

Voilà, au travers de cet exemple j'espère avoir permis à certaines personnes de mieux comprendre l'intérêt des macros et en quoi elles sont si pratique. Le code final pour cette macro est disponible ici

Notez que les read-macros ne sont pas tellement utilisées en pratiques (on aurait très bien pu se limiter à la forme (fn (…)), qui n'est pas tellement plus longue à taper). Néanmoins elles peuvent être assez utiles, par exemple dans CLSQL, où elles permettent de distinguer le code Lisp et les requêtes SQL.

Si vous souhaitez lire plus à propos des macros, je vous recommande la lecture de On Lisp de Paul Graham et de Let Over Lambda de Doug Hoyte.

Article original écrit le 14 mai 2010

La première, assez évidente, consiste à convertir le dépôt mercurial en un dépôt git, et simplement utiliser n'importe quelle méthode citée ci dessus pour gérer le dépôt git.

Pour cela, il faut utiliser hg-git qui vous permettra de garder votre dépôt mercurial, et de pusher/puller comme si c'était git. Les instructions sur le site de hg-git sont assez claires je pense et je ne vais pas les répéter ici.

hg-git nous permet aussi de convertir nos anciens dépôts git en dépôts mercurial si on le souhaite (il suffit de cloner le git), ce qui peut être assez pratique si souhaitez vous rattraper après avoir utiliser git pendant tout un temps.

Ici on va plutôt avoir recours à notre serveur web pour gérer l'authentification, et ça va nous permettre d'autoriser le push via le port 80, ce qui peut être pratique quand les autres ports sont bloqués.

La configuration se fait donc au niveau de votre serveur web, avec par exemple mod_auth pour lighttpd et auth_basic pour nginx.

Ainsi, la conf lighttpd ressemblera à ceci:

$HTTP["host"] == "hg.foo.bar" {
    server.document-root = "/usr/local/www/foo/hg"
    server.name = "%3%0"

    cgi.assign = ( ".cgi" => "/usr/local/bin/python" )
    url.rewrite-once = ("^(/hgwebdir.cgi/.*)$" => "$1", "^(/.*)$" => "/hgwebdir.cgi$1" )

    auth.backend = "htpasswd"
    auth.backend.htpasswd.userfile = "/usr/local/etc/hg.passwd"

    $HTTP["querystring"] =~ "cmd=unbundle" {
        auth.require = (   "" => (
            "method"  => "basic",
            "realm"   => "mercurial",
            "require" => "valid-user"
            )   
        )   
    }   
}

Pour modifier les options des repos, vous pouvez tout faire dans le fichier .hg/hgrc du repo. C'est par exemple là que vous pouvez indiquer qui aura le droit de push dans ce repo:

[web]
contact = foo
description = foo's repository
allow_push = foo, bar

Il vous reste alors ajouter vos repos dans la conf de hgwebdir.

Si par contre on peut se passer du push via le port 80, il est possible d'imiter le comportement de gitosis avec hg-ssh, un script fourni avec mercurial (dans /usr/local/share/mercurial/contrib/hg-ssh sous FreeBSD, disponible ici si vous ne l'avez pas).

Ce script, combiné avec une bonne configuration du ~/.ssh/authorized_keys, vous permet de définir quel utilisateur peut pusher où, avec une authentification basée sur les clés ssh. C'est donc exactement le même principe que gitosis.

Il faut d'abord créer un utilisateur hg, qui ne va servir qu'à gérer nos repo avec hg-ssh. Il faut aussi que le script hg-ssh soit dans le path, si ce n'est pas le cas, placez le par exemple dans /home/hg/bin/ et ajoutez ce répertoire dans le path de l'utilisateur hg.

Pour permettre à un utilisateur de pusher sur un ou plusieurs repos on peut donc ajouter la ligne suivante dans le ~/.ssh/authorized_keys de l'user hg:

command="hg-ssh repo1 repo2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding <la clé ssh de l'utilisateur>

Et comme on est des grosses feignasses et qu'on veut pas avoir besoin de gérer ce fichier à la main, rien de tel qu'un petit script qui fait le tout à notre place.

Par exemple, pour ajouter l'utilisateur foo et le repo bar, en écriture par foo, il suffit de faire:

% hg-ssh.sh add foo bar
% hg-ssh.sh add_key foo `cat foo.pub`
% hg-ssh.sh dump > ~/.ssh/authorized_keys

Vous pouvez aussi supprimer des utilisateurs, modifier les droits des utilisateurs sur les repos etc. Je pense que l'aide est assez complète pour cela:

% hg-ssh help
hg-ssh.sh command args
commands:
  list                  lists all the users and their repos
  add user [repos]      give write-access to the repos for user, create the 
                        user or the repos if needed
  dump                  dump the new authorized_keys file
  add_key user ssh-key  add the key to the user's keys
  del_user user         delete an user
  del_repos repos       remove repositories from hard drive and configuration
  del_write user repo   remove the write access of one user to a repo
  help:                 print this help screen

Une fois le tout bien configuré, vous pourrez pusher via ssh, même en n'ayant pas de compte sur le serveur:

% hg push ssh://hg@hg.foo.bar/repo

Pour rendre les repos visibles de l'extérieur, vous devrez utiliser hgwebdir, comme vu plus haut, et la conf au niveau des infos sur les repos se fera aussi dans le .hg/hgrc des repos dans le home de l'utilisateur hg.

Voilà donc trois façons de mieux gérer vos repos avec mercurial. Je n'ai pas vraiment été dans les détails pour ce billet, donc si vous avez des questions n'hésitez pas.

Article original écrit le 25 avril 2010

Vous pouvez installer Tinyscheme via votre gestionnaire de paquet ou bien plus simplement le placer dans un sous dossier de votre projet par exemple. Vous pourrez alors linker le tout facilement grâce au paramètre -L de gcc:

gcc foo.c -o foo -Ltinyscheme-1.39/

Parcourez aussi les fichiers scheme.h et scheme-private.h (que vous incluerez bien évidemment dans chaque fichier utilisant tinyscheme), ils vous en apprendront bien plus sur tinyscheme que ce que billet vous apprendra.

Avant toute chose, il faut connaître les deux types utilisés par Tinyscheme:

• un pointer représente un « objet » Scheme, c'est-à-dire n'importe quelle valeur manipulable en Scheme ;
• un scheme représente l'environnement Scheme dans son état actuel.

L'initialisation de Tinyscheme se fait via la fonction scheme_init_new, qui retourne un nouveau scheme * que l'on passera par la suite en premier argument à toute fonction de Tinyscheme. Pour finaliser cette initialisation, il faut aussi charger le fichier init.scm qui définit une grosse partie du langage (en effet, il est beaucoup plus simple d'implémenter Scheme en Scheme qu'en C). Pour charger ce fichier on passe par scheme_load_file. Il est aussi utile de définir stdout comme port de sortie en passant par la fonction scheme_set_output_port.

On peut donc définir une fonction initialize_scheme qui fera tout ça pour nous:

scheme *
initialize_scheme()
{
        FILE *init;
        scheme *sc;

        sc = scheme_init_new();
        if ((init = fopen("init.scm", "r")) == NULL) {
                perror("fopen");
                return NULL;
        }
        scheme_load_file(sc, init);
        fclose(init);

        scheme_set_output_port_file(sc, stdout);
        return sc;
}

Il faudra aussi appeler scheme_deinit à la fin de notre programme pour arrêter proprement Tinyscheme.

Pour charger un fichier Scheme il suffit d'utiliser la fonction scheme_load_file de la même façon qu'on l'a utilisée pour charger init.scm Pour directement évaluer du code Scheme depuis le C on utilisera scheme_load_string:

scheme_load_string(sc, "(display \"Hello, world!\") (newline)");

Il est très simple de créer des objets Scheme depuis le code C. Pour cela, regarder les fonctions du type mk_* dans scheme.h. On peut aussi définir des variables via scheme_define, une variable étant caractérisée par:

• sa portée
• son nom (un symbole)
• sa valeur

Ainsi, pour faire (define foo 42):

pointer value = mk_integer(sc, 42);
scheme_define(sc, sc->global_env, mk_symbol(sc, "foo"), value);

Une fonction se définit comme une variable en Scheme, par exemple:

(define 1+
  (lambda (x)
    (+ 1 x)))

On utilisera donc toujours scheme_define pour définir une fonction et il suffit d'utiliser mk_foreign_func pour récupérer un pointer à partir d'une fonction définie en C. Cette fonction doit retourner un pointer et prendre en argument un scheme * représentant l'état actuel de l'interpréteur ainsi qu'un pointer qui contient les arguments passés à cette fonction.

Grâce à cela, on peut donc ajouter de nouvelles fonctions qu'il serait impossibles de définir en Scheme, par exemple getenv (redéfinir 1+ en C n'aurait aucun intérêt vu la simplicité de cette définition en Scheme) :

pointer
scm_getenv(scheme *sc, pointer args)
{
        char *value;
        if (args == sc->NIL 
              || !is_string(pair_car(args))
              || (value = getenv(string_value(pair_car(args)))) == NULL)
                return sc->F;
        return mk_string(sc, value);
}

La valeur sc->NIL est assez explicite, et sc->F représente le booléen #f (sc->T représente quant à lui #t). Il faut bien évidemment informer Tinyscheme de l'existence de cette fonction:

scheme_define(sc, sc->global_env,
              mk_symbol(sc, "getenv"), mk_foreign_func(sc, scm_getenv))

Ce qui a été présenté ici couvre − je pense − la plupart des fonctionnalitées de Tinyscheme utilisées par des programmes tels que Tiny-Fu, le système de script-fu de GIMP.

Il est donc très facile d'embarquer Tinyscheme dans vos applications, et il est aussi simple d'écrire des extensions pour Tinyscheme (il suffira de définir un ensemble de fonctions et de compiler le tout en -shared). Pour des exemples concrets d'extensions, regardez TSX ainsi que l'extension regex.

La documentation de Tinyscheme étant inexistante (excepté les fichiers Manual.txt et hack.txt inclus avec Tinyscheme) si vous souhaitez plus d'exemples, il est essentiel de se plonger dans les sources de Tiny-Fu, de TSX ainsi que d'autres logiciels utilisant Tinyscheme si nécessaire.

Article original écrit le 20 mars 2010

fastest_sites est un petit script python qui trie les MASTER_SITE en fonction de leur temps de réponse, ce qui permet de redéfinir l'ordre d'utilisation des mirroirs pour utiliser les plus rapides en priorité. Comme il doit se connecter à chaque mirroir, son éxécution prend un certain temps, n'hésitez pas à continuer la lecture de cet article pendant ce temps.

cd /usr/ports/ports-mgmt/fastest_sites
make install clean
fastest_sites > /usr/local/etc/ports_sites.conf
echo '.include "/usr/locale/etc/ports_sites.conf"' >> /etc/make.conf

ccache, comme son nom l'indique, garde en cache les compilations de programmes C ou C++, et permet donc de ne pas recompiler quelque chose qui a déjà été compilé auparavant ce qui améliore grandement le temps de compilation.

Il est disponible dans le port devel/ccache. Une fois installé, on lit le fichier /usr/local/share/doc/ccache/ccache-howto-freebsd.txt comme indiqué. Dans mon cas, il faut donc ajouter ceci à /etc/make.conf:

.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE)
  CC=/usr/local/libexec/ccache/world-cc
  CXX=/usr/local/libexec/ccache/world-c++
.endif

ainsi que ceci dans le /etc/profile (attention, j'utilise mksh comme shell root mais le shell par défaut pour est un csh, à adapter donc):

export PATH=/usr/local/libexec/ccache:$PATH
export CCACHE_PATH=/usr/bin:/usr/local/bin

On peut aussi adapter CCACHE_DIR qui contient le dossier où ccache stockera ses données (/root/.ccache/ par défaut), et CCACHE_LOGFILE qui contient le chemin vers le fichier de log. On peut finalement adapter la taille maximale du cache via l'option -M:

# ccache -M 5G
Set cache size limit to 5242880k

cpuflags est un script shell qui vous donne les CFLAGS adaptés à votre processeur. Cepandant il n'est pas encore disponible dans les ports FreeBSD, bien qu'il soit compatible avec FreeBSD. Néanmoins, il est disponible dans pkgsrc, voici donc une démarche plus ou moins propre pour l'installer via les ports¹.

Tout d'abord, on récupère les fichiers le concernant depuis le cvs de pkgsrc:

export CVSROOT=anoncvs@anoncvs.de.netbsd.org:/cvsroot
export CVS_RSH=ssh
cvs checkout -PA pkgsrc/devel/cpuflags

Il faut ensuite convertir ce pkgsrc en un port, pour pouvoir l'installer via les ports:

cd pkgsrc/devel/cpuflags
mv PLIST pkg-plist
mv DESCR pkg-descr
wget http://awesom.eu/~acieroid/files/ports/cpuflags/Makefile.diff
patch -p1 Makefile < Makefile.diff
rm Makefile.diff
make install clean

Il suffit ensuite d'ajouter ce que nous sort cpuflags aux CFLAGS, dans le make.conf:

echo "CFLAGS+=`cpuflags`" >> /etc/make.conf

Article original écrit le 28 février 2010

Après l'installation, l'USB n'était pas détecté par l'OS à cause du support Plug And Play du BIOS, il suffit donc le désactiver cette option ainsi que le support USB (sinon on se retrouve avec **énormément** d'interruptions, ce qui rends le système peu utilisable).

On peut se rendre compte de la non-détection des périphériques USB via usbdevs(8):

# avec le support PnP et USB activés dans le bios:
$ usbdevs -v
usbdevs: no USB controllers found

Par contre, en désactivant le support de l'USB dans le BIOS, on perd la possibilitée d'utiliser un clavier USB avec GRUB et avec le bootloader de DragonFly BSD.

J'ai donc acheté une carte wifi USB pour pouvoir me passer de mes cartes Broadcom (BCM3418¹ sur le desktop et BCM4312 sur le netbook), même si la BCM4318 est supportée par bwi(4) (le driver fonctionne, mais est inutilisable, les vitesses de téléchargement sont de l'ordre du bit par seconde). La nouvelle carte est une TP-Link TL-WN321G, du chipset rum(4), et est détectée directement (à partir du moment où l'USB fonctionne). Un petit coup d'ifconfig(8) et de route(8), et hop, on est connecté. Le driver à l'air de fonctionner assez bien la plupart du temps, même si il lui arrive d'avoir un comportement bizarre (le débit tombe parfois aux alentours des 20kB/s, sans raison apparente)

Je vais indiquer ici les étapes de la configuration qui ne sont pas mentionnées dans la documentation de DragonFly BSD. Lors d'une première installation, le handbook est très pratique mais il faut savoir chercher par soi même car il n'est pas totalement à jour (par exemple, depuis la version 2.4 DragonFly utilise un /dev dynamique, ce qui n'est mentionné nulle part dans le handbook où ils utilisent le vieux /dev/MAKEDEV pour créer les devices).

Ma carte son étant une ATI IXP, il a suffit de charger le module snd_atiixp.ko et de l'ajouter au rc.conf:

# kldload snd_atiixp.ko
# echo 'snd_atiixp_load="YES"' >> /etc/rc.conf

Et pour tester le son, rien de tel qu'un petit

# cat /dev/urandom > /dev/audio

Pour finir, voici les principaux logiciels que j'utilise et le nom de leur pkgsrc:

Il reste encore beaucoup de choses à regarder de plus près (monter de l'ext4 et du reiserfs, le bépo dans la console, …), dont certaines propres à DragonFly BSD (hammer, vkernel). Cela fera peut-être l'objet de futurs billets.

J'aimerais aussi me pencher sur la création de pkgsrc, notamment pour installer proprement mupdf et pouvoir me passer de xpdf.

Article original écrit le 2 février 2010

Arc est un langage de la famille des lisp, conçu par Paul Graham, un hacker Lisp assez renommé qui écrit beaucoup, aussi bien des essais que des bons livres sur le Common Lisp.

La particularité de Arc est qu'il est incroyablement bien adapté pour développer des applications web avec ou même n'importe quelle application qui utilise le réseau¹ (la gestion des sockets est simple avec Arc contrairement aux sockets de Common Lisp qui s'utilisent de façon différente sur chaque implémentation, même s'il existe des bibliothèques plus ou moins portables). Arc a beau être léger, il implémente énormément de fonctions très utiles pour le développement web, ce qui permet de se concentrer sur l'application en soi plutôt que de coder encore et encore les même fonctions qui manquent dans le langage.

Évidemment, Arc étant un dérivé de Lisp, vous pouvez toujours définir des macros (lisez les chapitres 7 et 8 de Practical Common Lisp si vous débutez en Common Lisp et que vous ne conaissez pas les macros, pour ceux qui ont un niveau plus élevé, regardez du côté de On Lisp ou même de Let Over Lambda), ce qui simplifie grandement le développement.

Je ne vais pas parler plus en détail de Arc, si vous voulez plus d'informations, je vous recommande Design Philosophy (ou en français) et Why Arc Isn't Especially Object-Oriented qui peuvent vous donner une première impression sur la façon dont Arc est conçu. Pour avoir un aperçu d'Arc, regardez aussi Take the Arc Challenge et comparez le avec les solutions dans d'autres langages.

Plusieurs implémentations d'Arc sont disponibles, dont les deux principales, implémentées en PLT-Scheme:

• tout d'abord, la version « officielle » de Paul Graham, qui date un peu ;
• ensuite, Anarki une version dérivée de la version officielle, qui est bien plus à jour et peut-être légèrement incompatible avec celle de Graham.

Il existe aussi d'autres versions moins actives, moins utilisées et surtout moins complètes, mais qui valent quand même le coup d'œil:

• un compilateur Arc vers C, arc2c ;
• une implémentation en Java, rainbow ;
• une implémentation en Javascript, arclite ;
• une implémentation en .NET avec MBase ;
• une implémentation en Common Lisp avec SBCL, arc-sbcl.

Personnellement j'utilise Anarki, qui est de loin la version la plus complète et active. Pour l'installation, un coup de

git clone http://github.com/nex3/arc
ln -s arc/arc.sh ~/bin

et c'est parti pour de folles heures de hack. N'oubliez pas d'installer les fichiers relatif à votre éditeur de texte, disponibles dans extras (il y a un arc-mode et un inferior-arc-mode pour GNU Emacs ainsi que les fichiers d'indentation, de syntaxe et une extension pour intégrer la REPL d'Arc à Vim)

Pour commencer à programmer avec Arc, lisez d'abord l'introduction de Paul Graham et utilisez la documentation disponible sur l'Arc Language Blog, qui est quasi complète, mais pas totalement, il vous restera donc à trouver votre documentation en lisant les sources d'Arc. Parcourez aussi les deux exemples d'applications disponibles avec Arc: un simple blog et le code source de Hacker News. N'hésitez pas non plus à jeter un œil au code source de tips (qui s'inspire de ces deux exemples).

J'ai aussi mis en place une [page](http://awesom.eu/~acieroid/arc) regroupant les ressources francophones disponibles pour Arc, toute contribution est la bienvenue².

Arc a été installé dans une jail et il a simplement suffit de récupérer tips dessus (via son dépôt mercurial (que je commence d'ailleurs à préférer à git, car plus simple et plus logique tout en restant puissant)), il ne restait donc plus qu'à configurer le serveur web (en l'occurrence, lighttpd).

Ce dernier point a été assez dur a mettre en place car le `mod<sub>proxy`</sub> de lighttpd refusait simplement de marcher avec Arc (la seule réponse qu'on obtenait du serveur était une page blanche). On a donc mis en place un nginx (qui est très simple à configurer soit dit en passant) dans la jail qui écoute sur le port 80 et qui fait proxy vers tips (qui lui tourne sur le 8080).

Arc étant lancé dans une REPL, on peut facilement modifier les paramètres (url, etc.) et surtout, mettre à jour tips sans même devoir couper le service (en rechargeant simplement les fichiers sources).

Voilà, on a enfin quelque chose pour gérer nos tips, sur tips.awesom.eu, il faut juste espérer que ça se remplisse petit à petit.

Article original écrit le 25 janvier 2010

Les cinq thèmes fournis avec Chronicle ne sont pas parfait, en fait ils sont tous moches, sauf le thème « simple », mais qui a certains défauts (les liens en jaune clair quand on passe dessus, c'est immonde). Je suis donc parti de ce thème que j'ai légèrement modifié. La modification se fait très facilement, quelques valeurs à changer dans les CSS, quelques modifications dans les .templates utilisés pour générer l'html et le travail est fait. Le thème final est disponible ici.

Ensuite vient le problème de la coloration syntaxique, qui est assez indispensable au niveau esthétique pour un blog qui est destiné à parler programmation. Hélas, il n'y a pas de coloration syntaxique dans Chronicle, mais ça peut s'ajouter facilement.

Au niveau du logiciel utilisé pour la coloration, mon choix s'est d'abord porté vers Pygments via XML-RPC (le serveur XML-RPC doit avoir une fonction highlight_code qui prends en premier paramètre le code à colorer et en second paramètre le langage, ce qui est par exemple le cas du script écrit par delroth), mais finalement j'utilise la coloration syntaxique de Vim (via Text::VimColor), que j'avais d'abord éliminé car dans mes souvenirs ça ne convenait pas, ce qui était le cas pour paste.pl, qui devait éxécuter Vim pour colorer le texte (ce qui n'est pas génial niveau sécu pour un script CGI), mais dans ce cas-ci, le script étant éxécuté par l'utilisateur uniquement à la génération, ça ne pose aucun problème.

J'ai aussi ajouté la possibilitée d'utiliser Kate, un autre module de coloration syntaxique directement implémenté en Perl. L'utilisateur peut donc choisir la méthode qu'il préfère en l'indiquant dans le fichier de configuration (paramètre highlight qui est mis soit à kate, vim ou pygments).

Pour ma part, j'utilise donc la coloration avec Vim, car plus de langages sont supportés (520 fichiers dans /usr/local/share/vim/vim72/syntax/), et dans le cas de langages peu utilisés, il y a peu de chances d'avoir une coloration dans Pygments ou avec Kate, tandis que dans Vim, oui (c'est par exemple le cas de arc).

Pour spécifier du code à colorer, il doit commencer par highlight:langage, avec langage qui est un langage supporté par la méthode de coloration que vous avez choisie.

Je mets à votre disposition le diff, pour que vous puissiez patcher Chronicle si jamais vous avez envie d'avoir une coloration syntaxique de dingue, et voilà le résultat:

(defun hello (who)
  (format t "Hello, ~a!~%" who))

On pourrait aussi ajouter un paramètre qui permettrait à l'utilisateur d'utiliser une commande shell de son choix pour formatter le code (un script python pour utiliser Pygments par exemple, c'est plus simple que d'utiliser XML-RPC), et on pourrait faire de même pour le formattage du texte (pour utiliser mdown ou d'autres logiciels). Je le ferait peut être un jour si l'envie me vient.

Article original écrit le 26 décembre 2009