En fait ca se tient si tu consideres qu'il est tout le temps en deplacement, qu'il n'a pas internet tout le temps et qu'il travaille donc de maniere offline
L'histoire de la traque de ce bug est d'ailleurs assez cocasse:
Il s'agit d'un bug dans l'initialisation de variables globales par autre chose qu'une constante dans G++, qui n'etait pas effectue...
... qui provocait un bug dans bochs, l'emulateur de PC, executant de maniere incorrecte certaines instructions de calcul flottant...
... qui provocait un bug dans un programme en user space sur un noyau que j'essayait de debuguer.
Vu le temps que j'ai passe a trouver son origine, j'aurais bien aime que quelqu'un s'en occupe! Surtout que si ca tombe une bonne partie de l'archive debian etch est compilee avec ce compilateur...
Sinon, vous faites quoi quand personne ne repond a votre bug report, y compris dans des projets actifs (genre Emacs ou Debian)?
Precision: ces deux notions sont evidemment independentes; i.e
on peut tres bien avoir un langage securise qui fournisse une commande "system" permettant ainsi de detruire tous les fichiers du disque; et un language qui fournisse des fonctionalites de securite mais qui peut planter (comme Java).
Dans la premiere notion, on veut surtout dire que le langage ne permet pas de faire n'importe quoi avec la memoire. Ca
comprend le bound-checks pour les tableaux, l'interdiction de faire des type casts sans verification, interdiction des unions etc.. etc.. Une autre caracteristique des langages securises est que leur execution ne peut pas s'arreter; ce qui ne veut pas dire qu'ils ne peuvent pas boucler sans rien faire, mais qu'il ne vont pas se retrouver dans des situations bloquantes du style devoir dereferencer un pointeur illegal, ou ajouter un entier et une chaine de charactere.
On dit qu'ils sont securises, parce que si j'ai le code source d'un programme dans un tel language, et que je l'execute,
je sais qu'il peut pas faire de dommage (a part boucler, mais c'est facile de s'en prevenir). C'est pour ca qu'ils sont souvent utilises comme moyen de faire des extensions securisees (par exemple, le noyau du systeme d'exploitation Spring comprend un compilateur pour un language securise, permettant l'ajout dynamique d'extensions).
En resume, dans de tels langages on sait a la compilation que le programme va se comporter "correctement".
Dans cette notion, des languages comme CaML ou Haskell sont securises par exemple, mais pas C ou Java (ce dernier ne l'est pas notamment a cause des NullPointerException)
Dans la deuxieme notion, on bride en quelque sorte la bibliotheque pour empecher des interactions malencontreuses avec l'exterieur. Par exemple on interdit la destruction de fichiers, les requetes SQL non verifiees.. Dans cette notion, on empeche l'interaction malheureuse du programme avec le reste du systeme d'exploitation.
Mais a mon avis pour cette derniere notion, il serait plus approprie de parler de "fonctionnalites de securite" du langage et de ses bibliotheques, plutot que de langage securise.
A mon avis ca permet de creer un nouveau type, ce qui permet d'eviter de melanger les patates et les carottes.
exemple (en pseudocode):
type Carotte = Int;
type Patate = Int;
Carotte c = Carotte(5);
Patate p = Patate(3);
Int total= c + p; //Impossible, erreur de compilation.
Par opposition, si tu as
Int c = 5;
Int p = 3;
Int total = c + p;
la, ca marche.
En general, creer de nouveaux types pour representer des donnees differentes est un bon style de programmation. Malheureusement, on ne peut pas faire ca avec un certain nombre de languages (dont C, car typedef ne cree pas un nouveau type mais juste un nouveau nom pour un type).
* Ecris differents petits projets dont peut de monde a entendu parle (mais quelques personnes quand meme)
* Envoye qqes bugfixes ou rapports de bugs a un certain nombre de projets (surtout relatifs a Emacs)
* Ete un des principal contributeurs au maintenant mort Hurd sur L4
* Actuellement je developpe mon propre gros projet, un compilateur pour mon langage de programmation, L (http://savannah.nongnu.org/projects/l-lang/ )
Sans devenir des usines à gaz, un paquet d'éditeurs graphiques fournissent une intégration dans un cvs/ftp, une arborescence, des outils supplémentaires (navigation dans le code, différence de texte, etc). Il y a beaucoup de choses annexes à l'"écriture du code", et pour ça le coté ergonomique prend un peu plus de sens : en quelques clics, voire automatiquement, on peut faire beaucoup de choses.
Emacs fait tout ca out of the box, et en plus tu peux acceder a ces fonctions avec un menu. De plus emacs est un editeur graphique ET texte (d'ailleurs avec gvim, vim doit l'etre aussi).
Genre je lance un emacs non parametre:
Tools/Compare (Ediff) => difference de texte
J'ouvre un ficher dans un CVS => ca me le marque en bas, je peux aussi cliquer dans tools/pcl-cvs/examine directory.
Donc ca a rien de complique, c'est juste une question de mauvaise habitude a perdre, et de volonte de s'y mettre, et si t'y est trop attache t'as le CUA-mode qui permet de reutiliser les meme raccourcis dans Emacs. Je connais plein de gens qui se sont mis a Emacs a 25 ans et ca les as pas empeche de devenir tres efficace.
Et pour l'avoir observe, un gars qui maitrise bien Emacs/Vim est BEAUCOUP plus rapide qu'un gars qui maitrise bien Eclipse ou autre.
Justement c'est comme pour Starcraft: un bon Emacsien/Vimeux tu comprends rien a ce qu'il fait, ca va trop vite; un gars qui utilise eclipse tu suis tous ses deplacements a la souris c'est pas difficile.
Ben oui quoi, pourquoi ils ne font pas un noyau parfait dès le départ !!!
Ils sont vraiment mauvais ces développeurs Linux.
Je dis pas, mais de la a faire 19 versions d'un scheduler en 3 mois...
Mais c'est bien le pb de POSIX (et des interfaces POSIX-like en general): comme c'est sense faire fonctionner pleins de taches differentes, qui ont plein de workloads completements differents, avec la meme interface, on se retrouve a faire un scheduler qui doit inferer le comportement de tout un tas d'application avant d'agir en consequence.
Alors je comprends bien: avec tous les workloads "classiques" qui doivent exister, il doit en falloir du temps pour tous les faire marcher... Jusqu'a ce qu'on trouve un nouvel exemple qui marche pas. Et hop, une version de plus!
Et après on se demande pourquoi Microsoft ne peux pas suivre le rythme !
Oui enfin il faut se dire que si les "bonnes" lignes avaient ete ecrites directement au lieu d'etre reecrites incrementalement on serait arrive au meme resultat avec bien moins de patchs...
La qualite d'un logiciel ne se mesure pas a son nombre de ligne de code (j'aurais tendance a penser le contraire: un bon logiciel en fait beaucoup en peu de lignes).
Note: non, je ne suis pas pro-microsoft (qui a d'ailleurs le meme genre de strategie je pense)
L'exemple que tu cites est frappant. Je monte ma machine en bidouillant un système bi-proc, je code un OS en assembleur et au finale j'ai quelque chose d'hyper intéressant.
La thèse de Massalin resselle aussi une intéressante contribution sur la concurrence et la synchronisation.
Il désirait en effet éviter de désactiver les interruptions à tout bout de champ sur son système, éviter d'utiliser des systèmes à verrou pour gérer la concurence sur sa machine dotée de deux 68030.
Il faut savoir justement que le 68k a une instruction DCAS (double compare and swap), ce qui la rend particulierement interessante pour programmer des multiprocesseurs. En particulier, synthethis est completement lock-free (i.e. sans verrou)
Les processeurs modernes n'incluent pas cette instruction, ce qui rend la chose encore plus difficile, ce qui fait que tres peu de systemes d'exploitation empruntent cette voie.
Je pense, moi aussi, que l'avenir est aux DSL (domain-specific languages), et plus precisement a un language unique permettant d'incorporer differents DSL simultanement dans un meme langage.
L'utilisation de certains DSL peut paraitre evident (comme cites ci-dessus: Xpath, SQL etc); ce qui l'est moins c'est l'utilisation de DSL integres au languages par exemple, des sous-langages permettant d'ecrire des parseurs comme Bison, ou des
extensions SQL a C). Peu de langages encouragent a l'utilisation systematique de DSL, a part Lisp (a ce propos, j'encourage fortement la lecture de On Lisp, de Paul Graham, disponible gratuitement sur internet).
Cette utilisation systematique permet effectivement de rendre les programmes de plus en plus declaratifs, et de permettre de faire des verifications au "compile-time".
Un exemple: un DSL precis pourrait etre les interfaces utilisees dans le noyau Linux.
Ce type de DSL permettrait de gerer plus facilement les changements d'interface binaires (pas besoin de retoucher aux sources), et permet de faire des verifications a la compilation (typage par exemple).
Utiliser un tel DSL n'est pas apprendre un nouveau langage; c'est extremement simple, et plus simple que d'apprendre a utiliser une librairie par exemple.
Le langage L (http://www.nongnu.org/l-lang , attention la page est un peu outdated) est concu pour pouvoir ecrire ce type de DSL. A titre d'exemple, voici un extrait d'un parseur ecrit dans le DSL de parseur:
Dans cet exemple, on mixe la DSL du parseur (permettant d'exprimer la grammaire) avec du code L (permettant d'exprimer des actions semantiques). Dans ce cas precis, on est en train de calculer la valeur des entiers parses tout en les parsant.
En resume, je pense que ce type de langage permet une plus grande surete, flexibilite, et facilite d'utilisation par la programmation declarative. Par contre, je ne pense pas que le langage naturel soit la cle, mais plutot d'avoir des syntaxes specifiques bien adaptees a chaque DSL.
Si vous etes interesses par ce type de langage, L est en plein developpement mais est deja fonctionnel (il dispose d'un compilateur dynamique, de DSL facilitant le developpement, et d'un translateur vers C, et une partie de L est deja ecrite en L);
un exemple de projet serait l'ecriture d'un DSL pour l'inline assembleur (qqchose qui fonctionne mieux que le asm de GCC, qui ne comprend pas l'assembleur inline).
Je peux temoigner ici: j'ai ecris un compilateur pour un nouveau langage de programmation, une sorte d'evolution de C (www.nongnu.org/l-lang), qui comporte pas mal d'innovations par rapport a C; pour l'instant, ce n'est pas encore un franc succes mais j'attend d'etre plus avance pour lancer une "campagne de publicite" :)
Apres avoir fait l'experience de la contribution sur un autre projet, je trouve que les deux sont interessants: d'un cote la contribution est interessante car le chef de projet est la pour encadrer et aider a mieux comprendre le projet; de l'autre le projet tout seul apporte une liberte totale qui je pense est le moteur de la nouveaute et du renouveau dans les logiciels d'un meme type, avant que de nouveaux contributeurs n'apportent leurs idees pour ameliorer le projet.
De ce que je comprends c'est juste qu'une API est a moitie "deprecated" (et il se trouve que c'est l'API de la libc), et qu'il faut utiliser les fonctions win32 proprio.
Qu'importe, il suffit d'utiliser une libraire qui wrappe les appels a malloc vers les fonctions win32 comme le font les compilos proprio.
GCC n'est pas bride sous vista, il n'est juste pas adapte aux nouvelles APIs. Un meilleur titre que "Windows Vista restricts GNU GCC apps to 32 MB" serait "GNU GCC is restricted to 32MB under Windows Vista".
PS: je ne suis pas un defenseur de MS mais un pourfendeur des alarmistes qui donnent des arguments sans credibilite.
Surtout, fortran c'est je crois le premier language compile. A l'epoque les gens etaient pas convaincu du concept de compilateur par rapport a coder en assembleur a la main. Donc beaucoup de techniques pionnieres dans la compilation sont issues de cette premiere version de Fortran.
Les premieres versions de fortran n'avaient pas de if then else qui a ete invente plus tard avec Lisp, c'est dire l'etat de l'art en langage de prog de l'epoque.
Je ne connais pas specialement KSE (le mecanisme pour la gestion des threads dans FreeBSD), mais je connais le mecanisme de scheduler activations sur lequel il est base (et qui permet le M:N scheduling); et les schedulers activations permettent de gerer les contentions sur un lock (dans un meme espace d'adressage) sans aucun appel au noyau. Si il y a un fort taux de contention dans MySQL les performances seront donc meilleures sous FreeBSD que sous Linux.
Pour donner un exemple, imaginons qu'un thread (a) prenne un mutex et que son timeslice se termine avant qu'il le deverouille; sous Linux (on me corrigera) mais a priori tout le monde est bloque tant qu'il est pas reveille.
Avec les scheduler activations, il est possible qu'un autre kernel thread (b) qui attendait pour le mem lock reprenne l'execution du thread (a) la ou elle en etait, jusqu'a ce qu'il sorte du lock; et la continue l'execution normale du thread (b). D'ou des excellents temps de latence a attendre le lock.
Attention, ce mecanisme de scheduler activation est tres judicieux pour un programme multithread au sein d'un meme espace d'adressage; on ne peut pas faire ca pour des threads situes dans des processus differents.
Quelle difference de philosophie? Tu veux parler plutot de methodologie de developpement peut etre; il est vrai que FreeBSD est plus conservateur que Linux sur ce point la.
Ceci etant dit, les deux noyaux sont relativement semblable: dans les deux cas il s'agit d'un gros noyau monolithique fournissant une interface UNIX similaire (evidemment avec quelques extensions de chaque cote). Ils sont beaucoup plus proche que par exemple, de Minix ou QNX (pour rester dans le UNIX-Like).
Pour faire des noyaux SMP-safe, il "suffit" de faire en sorte que les appels de fonctions et macros pour prendre des locks, faire des updates atomiques dans Linux soient transcrits en leur equivalents FreeBSD (et il y a toujours un equivalent, puisque les noyaux sont structures identiquement). Il y a quelques differerences comme les locks RCU sous Linux, mais de toute facon rien n'interdit de porter une primitive de locking d'un OS a un autre.
Ce travail a surement de plus ete facilite par le fait que la couche USB de Linux tente d'etre generique et accessible depuis l'espace utilisateur.
C'est quand meme un gros travail, et je felicite le courage des personnes qui l'ont fait. Peut etre que ce travail peut d'ailleurs reservir a d'autres systemes libres?
Non, car la majorite du code de Linux est sous GPLv2 (et non pas GPLv2 ou ulterieure, comme conseille par la FSF). Du coup les deux licenses sont incompatibles.
Notons que si ils avaient mis le code de Linux sous GPLv2 ou ulterieur, et qu'ils avaient voulu recuperer des codes en GPLv3, ils auraient du passer tout le noyau en GPLv3 de toute facon.
oui le remplacement de code a chaud c'est surtout utile pour retirer du code
quand t'as un systeme monoprocesseur (tout ce qui est spin lock ... hop a la trappe). Sous Linux en dehors du noyau je ne vois pas d'autres applications qui pourraient en tirer parti.
Exact, mais scheme n'est pas type statiquement (OK, il y a des extensions qui le font).
Et quand je parle de modification de syntaxe, je parle de syntaxe concrete, pas de syntaxe abstraite. Les macros lisp/scheme permettent de changer de syntaxe concrete, les modifications du reader lisp permettent de changer (dans une certaine mesure) de syntaxe concrete.
L permet de changer completement la syntaxe concrete ET la syntaxe abstraite.
Pour ma part, j'ai teste beaucoup de langages de programmations, parmi lesquels C, Common Lisp/Scheme, Ruby, Caml, Perl, PHP, Java, et de l'assembleur.
J'ai beaucoup apprecie le style de programmation de Lisp, dans lequel on peut etendre son language completement en ajoutant de nouveaux operateurs.
Il se trouve que je programme beaucoup en C que j'aime beaucoup, et j'aime bien appliquer cette pratique en C, mais le preprocesseur C ne permet pas tout. Ce qu'il faut, c'est que l'outil de metaprogrammation soit integre au langage. D'ou l'idee de L.
Par ailleurs, le style de developpement de Ruby est aussi interessant. Je ne suis pas forcement un afficionado du concept "tout est objet", mais l'integration entre
les cotes fonctionnels et imperatifs de Ruby est remarquable.
J'aime aussi les langages fortement types statiquement a la Caml; je trouve que definir des nouveaux types permet de clarifier fortement un programme.
J'ai eu la chance de suivre des cours de compilation lors de mon cursus, et j'ai donc tente de creer un langage qui combinait toutes les fonctionnalites que j'aime bien : extensible, bas-niveau, type fortement, multi paradigme, plus quelques idees auxquelles j'avait deja pense, mais jamais pu realiser faut de support du langage.
Juste pour preciser: L ne depend ni de flex ni de yacc.
Pour l'analyse lexicale (equivalent de flex), j'ai ecris une librairie qui analyse un ensemble d'expressions rationnelles, en construit un automate deterministe, et le compile en assembleur. Il n'a pas besoin de dependences exterieures comme la libflex.
La difference avec flex, c'est que flex construit une table pour l'analyse lexicale, qu'il "interprete". Tandis que mes automates sont compiles.
L'interet de ma technique est essentiellement la rapidite, le fait qu'on peut generer des scanners sans dependance exterieure, et le fait que je vais pouvoir directement utiliser ca pour creer ma librairie de regexp. Le desavantage c'est la place prise en memoire (par exemple, on ne peut pas utiliser des tables compressees).
Je n'ai pas fait de tests comparatifs de rapidite avec flex, mais j'en avais fait avec la libpcre (pour une seule expression rationnelle "matchee" en meme temps), et le resultat etait 10x plus rapide que la PCRE. Par contre, on ne gere pas tout ce qui n'est pas vraiment des expressions rationnelles (les trucs comme "<(\w+)>.*<\1>" par exemple), parce que ca ne peut pas etre compile en automate deterministe. Et puis, les extensions necessaires pour recuperer les resultats d'un match ne sont pas encore ecrites.
De meme, je n'utilise pas bison : j'ai ecrit un parser en descente recursive. Ca me permet justement de pouvoir etendre ma syntaxe en rajoutant des parsers au run-time. Pour faciliter l'ecriture de nouveaux parseurs, je prevois l'ecriture d'un "parse language", qui permet d'ecrire la regle de grammaire directement, et qui sera compilee en une fonction de parsing.
Ah, et au final, mon programme genere du code x86 directement en memoire
(ce qui permet un processus de developpement interactif), mais je suis en train de rajouter la possibilite de sortir du C.
[^] # Re: 3D
Posté par Matthieu Lemerre . En réponse au journal Xen 3.2.0. Évalué à 1.
[^] # Re: Tss
Posté par Matthieu Lemerre . En réponse au journal La Flame War de l'année ?. Évalué à 1.
[^] # Re: Et Ogg/Vorbis ?
Posté par Matthieu Lemerre . En réponse au journal Des vulnérabilités dans FLAC. Évalué à 6.
http://people.debian.org/~terpstra/message/20071010.095132.e(...)
L'histoire de la traque de ce bug est d'ailleurs assez cocasse:
Il s'agit d'un bug dans l'initialisation de variables globales par autre chose qu'une constante dans G++, qui n'etait pas effectue...
... qui provocait un bug dans bochs, l'emulateur de PC, executant de maniere incorrecte certaines instructions de calcul flottant...
... qui provocait un bug dans un programme en user space sur un noyau que j'essayait de debuguer.
Vu le temps que j'ai passe a trouver son origine, j'aurais bien aime que quelqu'un s'en occupe! Surtout que si ca tombe une bonne partie de l'archive debian etch est compilee avec ce compilateur...
Sinon, vous faites quoi quand personne ne repond a votre bug report, y compris dans des projets actifs (genre Emacs ou Debian)?
[^] # Re: Il y a deux notions de langage securise
Posté par Matthieu Lemerre . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 2.
on peut tres bien avoir un langage securise qui fournisse une commande "system" permettant ainsi de detruire tous les fichiers du disque; et un language qui fournisse des fonctionalites de securite mais qui peut planter (comme Java).
# Il y a deux notions de langage securise
Posté par Matthieu Lemerre . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 3.
Dans la premiere notion, on veut surtout dire que le langage ne permet pas de faire n'importe quoi avec la memoire. Ca
comprend le bound-checks pour les tableaux, l'interdiction de faire des type casts sans verification, interdiction des unions etc.. etc.. Une autre caracteristique des langages securises est que leur execution ne peut pas s'arreter; ce qui ne veut pas dire qu'ils ne peuvent pas boucler sans rien faire, mais qu'il ne vont pas se retrouver dans des situations bloquantes du style devoir dereferencer un pointeur illegal, ou ajouter un entier et une chaine de charactere.
On dit qu'ils sont securises, parce que si j'ai le code source d'un programme dans un tel language, et que je l'execute,
je sais qu'il peut pas faire de dommage (a part boucler, mais c'est facile de s'en prevenir). C'est pour ca qu'ils sont souvent utilises comme moyen de faire des extensions securisees (par exemple, le noyau du systeme d'exploitation Spring comprend un compilateur pour un language securise, permettant l'ajout dynamique d'extensions).
En resume, dans de tels langages on sait a la compilation que le programme va se comporter "correctement".
Dans cette notion, des languages comme CaML ou Haskell sont securises par exemple, mais pas C ou Java (ce dernier ne l'est pas notamment a cause des NullPointerException)
Dans la deuxieme notion, on bride en quelque sorte la bibliotheque pour empecher des interactions malencontreuses avec l'exterieur. Par exemple on interdit la destruction de fichiers, les requetes SQL non verifiees.. Dans cette notion, on empeche l'interaction malheureuse du programme avec le reste du systeme d'exploitation.
Mais a mon avis pour cette derniere notion, il serait plus approprie de parler de "fonctionnalites de securite" du langage et de ses bibliotheques, plutot que de langage securise.
[^] # Re: Nous ne lisons pas le même rapport.
Posté par Matthieu Lemerre . En réponse au journal PS sans OS. Évalué à 5.
[^] # Re: Python sur la voie du tout objet ?
Posté par Matthieu Lemerre . En réponse au journal Sortie de Python 3 alpha. Évalué à 3.
exemple (en pseudocode):
type Carotte = Int;
type Patate = Int;
Carotte c = Carotte(5);
Patate p = Patate(3);
Int total= c + p; //Impossible, erreur de compilation.
Par opposition, si tu as
Int c = 5;
Int p = 3;
Int total = c + p;
la, ca marche.
En general, creer de nouveaux types pour representer des donnees differentes est un bon style de programmation. Malheureusement, on ne peut pas faire ca avec un certain nombre de languages (dont C, car typedef ne cree pas un nouveau type mais juste un nouveau nom pour un type).
[^] # Re: Reponse a L'auteur du journal qui se répond
Posté par Matthieu Lemerre . En réponse au journal Et vous, avez-vous déjà participé à un LL?. Évalué à 6.
* Ecris differents petits projets dont peut de monde a entendu parle (mais quelques personnes quand meme)
* Envoye qqes bugfixes ou rapports de bugs a un certain nombre de projets (surtout relatifs a Emacs)
* Ete un des principal contributeurs au maintenant mort Hurd sur L4
* Actuellement je developpe mon propre gros projet, un compilateur pour mon langage de programmation, L (http://savannah.nongnu.org/projects/l-lang/ )
[^] # Re: Les avocats sans fil
Posté par Matthieu Lemerre . En réponse au journal Paris wifi = paris sans fil out !. Évalué à 3.
Ce qui, somme toutes, n'est pas forcement faux.
Simple question: pourquoi l'association ne change pas de nom tout simplement? En quoi ca la fait mourir?
Autre question: si vous dissolvez l'association, faut-elle encore qu'elle paye?
[^] # Re: 100%
Posté par Matthieu Lemerre . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 2.
Emacs fait tout ca out of the box, et en plus tu peux acceder a ces fonctions avec un menu. De plus emacs est un editeur graphique ET texte (d'ailleurs avec gvim, vim doit l'etre aussi).
Genre je lance un emacs non parametre:
Tools/Compare (Ediff) => difference de texte
J'ouvre un ficher dans un CVS => ca me le marque en bas, je peux aussi cliquer dans tools/pcl-cvs/examine directory.
Donc ca a rien de complique, c'est juste une question de mauvaise habitude a perdre, et de volonte de s'y mettre, et si t'y est trop attache t'as le CUA-mode qui permet de reutiliser les meme raccourcis dans Emacs. Je connais plein de gens qui se sont mis a Emacs a 25 ans et ca les as pas empeche de devenir tres efficace.
Et pour l'avoir observe, un gars qui maitrise bien Emacs/Vim est BEAUCOUP plus rapide qu'un gars qui maitrise bien Eclipse ou autre.
Justement c'est comme pour Starcraft: un bon Emacsien/Vimeux tu comprends rien a ce qu'il fait, ca va trop vite; un gars qui utilise eclipse tu suis tous ses deplacements a la souris c'est pas difficile.
[^] # Re: Fast forward
Posté par Matthieu Lemerre . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 1.
Je dis pas, mais de la a faire 19 versions d'un scheduler en 3 mois...
Mais c'est bien le pb de POSIX (et des interfaces POSIX-like en general): comme c'est sense faire fonctionner pleins de taches differentes, qui ont plein de workloads completements differents, avec la meme interface, on se retrouve a faire un scheduler qui doit inferer le comportement de tout un tas d'application avant d'agir en consequence.
Alors je comprends bien: avec tous les workloads "classiques" qui doivent exister, il doit en falloir du temps pour tous les faire marcher... Jusqu'a ce qu'on trouve un nouvel exemple qui marche pas. Et hop, une version de plus!
En tout cas je lui souhaite bien du courage.
[^] # Re: Fast forward
Posté par Matthieu Lemerre . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 6.
Oui enfin il faut se dire que si les "bonnes" lignes avaient ete ecrites directement au lieu d'etre reecrites incrementalement on serait arrive au meme resultat avec bien moins de patchs...
La qualite d'un logiciel ne se mesure pas a son nombre de ligne de code (j'aurais tendance a penser le contraire: un bon logiciel en fait beaucoup en peu de lignes).
Note: non, je ne suis pas pro-microsoft (qui a d'ailleurs le meme genre de strategie je pense)
[^] # Re: 68k
Posté par Matthieu Lemerre . En réponse au journal Un OS réécrit son code à la volée. Évalué à 1.
Il faut savoir justement que le 68k a une instruction DCAS (double compare and swap), ce qui la rend particulierement interessante pour programmer des multiprocesseurs. En particulier, synthethis est completement lock-free (i.e. sans verrou)
Les processeurs modernes n'incluent pas cette instruction, ce qui rend la chose encore plus difficile, ce qui fait que tres peu de systemes d'exploitation empruntent cette voie.
[^] # Re: Superbe ! mai je me pose une question...
Posté par Matthieu Lemerre . En réponse au journal L'expressivité des langages. Évalué à 2.
L'utilisation de certains DSL peut paraitre evident (comme cites ci-dessus: Xpath, SQL etc); ce qui l'est moins c'est l'utilisation de DSL integres au languages par exemple, des sous-langages permettant d'ecrire des parseurs comme Bison, ou des
extensions SQL a C). Peu de langages encouragent a l'utilisation systematique de DSL, a part Lisp (a ce propos, j'encourage fortement la lecture de On Lisp, de Paul Graham, disponible gratuitement sur internet).
Cette utilisation systematique permet effectivement de rendre les programmes de plus en plus declaratifs, et de permettre de faire des verifications au "compile-time".
Un exemple: un DSL precis pourrait etre les interfaces utilisees dans le noyau Linux.
Par exemple, un driver reseau utilise ceci:
static struct pci_driver ne2k_driver = {
.name = DRV_NAME,
.probe = ne2k_pci_init_one,
.remove = __devexit_p(ne2k_pci_remove_one),
.id_table = ne2k_pci_tbl,
#ifdef CONFIG_PM
.suspend = ne2k_pci_suspend,
.resume = ne2k_pci_resume,
#endif /* CONFIG_PM */
};
L'utilisation d'un DSL pour les drivers PCI du noyau resulterai en qqchose comme ceci:
pci_driver ne2k = {
name : DRV_NAME;
probe : ne2k_pci_init_one;
remove : ne2k_pci_remove_one;
id_table : ne2k_pci_tbl;
suspend : ne2k_pci_suspend;
resume : ne2k_pci_resume;
}
Ce type de DSL permettrait de gerer plus facilement les changements d'interface binaires (pas besoin de retoucher aux sources), et permet de faire des verifications a la compilation (typage par exemple).
Utiliser un tel DSL n'est pas apprendre un nouveau langage; c'est extremement simple, et plus simple que d'apprendre a utiliser une librairie par exemple.
Le langage L (http://www.nongnu.org/l-lang , attention la page est un peu outdated) est concu pour pouvoir ecrire ce type de DSL. A titre d'exemple, voici un extrait d'un parseur ecrit dans le DSL de parseur:
grammar Numeric = {
rule Digit:Character = d:[0-9] { d - Character( '0')};
rule Decimal_Number:Int = n:( d:[1-9] {d - Character( '0')})
(d:Digit {{n = n*10; n = n+d}})* {n};
rule Hexa_Digit:Character = (Digit | d:[a-f] { d - Character( 'a')});
rule Hexadecimal_Number:Int = "0x" n:{0}
(d:Hexa_Digit {{n = n*16; n = n+d}})* {n};
rule Number:Int = Decimal_Number | Hexadecimal_Number
}
Dans cet exemple, on mixe la DSL du parseur (permettant d'exprimer la grammaire) avec du code L (permettant d'exprimer des actions semantiques). Dans ce cas precis, on est en train de calculer la valeur des entiers parses tout en les parsant.
En resume, je pense que ce type de langage permet une plus grande surete, flexibilite, et facilite d'utilisation par la programmation declarative. Par contre, je ne pense pas que le langage naturel soit la cle, mais plutot d'avoir des syntaxes specifiques bien adaptees a chaque DSL.
Si vous etes interesses par ce type de langage, L est en plein developpement mais est deja fonctionnel (il dispose d'un compilateur dynamique, de DSL facilitant le developpement, et d'un translateur vers C, et une partie de L est deja ecrite en L);
un exemple de projet serait l'ecriture d'un DSL pour l'inline assembleur (qqchose qui fonctionne mieux que le asm de GCC, qui ne comprend pas l'assembleur inline).
[^] # Re: Bitlbee + screen + irssi
Posté par Matthieu Lemerre . En réponse au sondage Quel client Jabber/XMPP j'utilise tous les jours ?. Évalué à 1.
Ca depend du desktop; moi j'utilise emacs + ERC + bitlbee et tout est tres bien integre
[^] # Re: ...
Posté par Matthieu Lemerre . En réponse au journal Pourquoi je ne réinventerai plus la roue. Évalué à 1.
Je peux temoigner ici: j'ai ecris un compilateur pour un nouveau langage de programmation, une sorte d'evolution de C (www.nongnu.org/l-lang), qui comporte pas mal d'innovations par rapport a C; pour l'instant, ce n'est pas encore un franc succes mais j'attend d'etre plus avance pour lancer une "campagne de publicite" :)
Apres avoir fait l'experience de la contribution sur un autre projet, je trouve que les deux sont interessants: d'un cote la contribution est interessante car le chef de projet est la pour encadrer et aider a mieux comprendre le projet; de l'autre le projet tout seul apporte une liberte totale qui je pense est le moteur de la nouveaute et du renouveau dans les logiciels d'un meme type, avant que de nouveaux contributeurs n'apportent leurs idees pour ameliorer le projet.
# GCC n'est pas bride sous vista
Posté par Matthieu Lemerre . En réponse au journal GCC bridé sous vista .... Évalué à 5.
Qu'importe, il suffit d'utiliser une libraire qui wrappe les appels a malloc vers les fonctions win32 comme le font les compilos proprio.
GCC n'est pas bride sous vista, il n'est juste pas adapte aux nouvelles APIs. Un meilleur titre que "Windows Vista restricts GNU GCC apps to 32 MB" serait "GNU GCC is restricted to 32MB under Windows Vista".
PS: je ne suis pas un defenseur de MS mais un pourfendeur des alarmistes qui donnent des arguments sans credibilite.
[^] # Re: Le Fortran
Posté par Matthieu Lemerre . En réponse à la dépêche Décès du père du Fortran et de la notation BNF. Évalué à 3.
Les premieres versions de fortran n'avaient pas de if then else qui a ete invente plus tard avec Lisp, c'est dire l'etat de l'art en langage de prog de l'epoque.
[^] # Re: Re:
Posté par Matthieu Lemerre . En réponse au journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6. Évalué à 3.
Pour donner un exemple, imaginons qu'un thread (a) prenne un mutex et que son timeslice se termine avant qu'il le deverouille; sous Linux (on me corrigera) mais a priori tout le monde est bloque tant qu'il est pas reveille.
Avec les scheduler activations, il est possible qu'un autre kernel thread (b) qui attendait pour le mem lock reprenne l'execution du thread (a) la ou elle en etait, jusqu'a ce qu'il sorte du lock; et la continue l'execution normale du thread (b). D'ou des excellents temps de latence a attendre le lock.
Attention, ce mecanisme de scheduler activation est tres judicieux pour un programme multithread au sein d'un meme espace d'adressage; on ne peut pas faire ca pour des threads situes dans des processus differents.
[^] # Re: Bonne idée ?
Posté par Matthieu Lemerre . En réponse à la dépêche FreeBSD utilise les pilotes Linux. Évalué à 3.
Ceci etant dit, les deux noyaux sont relativement semblable: dans les deux cas il s'agit d'un gros noyau monolithique fournissant une interface UNIX similaire (evidemment avec quelques extensions de chaque cote). Ils sont beaucoup plus proche que par exemple, de Minix ou QNX (pour rester dans le UNIX-Like).
Pour faire des noyaux SMP-safe, il "suffit" de faire en sorte que les appels de fonctions et macros pour prendre des locks, faire des updates atomiques dans Linux soient transcrits en leur equivalents FreeBSD (et il y a toujours un equivalent, puisque les noyaux sont structures identiquement). Il y a quelques differerences comme les locks RCU sous Linux, mais de toute facon rien n'interdit de porter une primitive de locking d'un OS a un autre.
Ce travail a surement de plus ete facilite par le fait que la couche USB de Linux tente d'etre generique et accessible depuis l'espace utilisateur.
C'est quand meme un gros travail, et je felicite le courage des personnes qui l'ont fait. Peut etre que ce travail peut d'ailleurs reservir a d'autres systemes libres?
[^] # Re: Compatibilité GPL v2/v3 ?
Posté par Matthieu Lemerre . En réponse au journal Solaris sous GPLv3. Évalué à 2.
Notons que si ils avaient mis le code de Linux sous GPLv2 ou ulterieur, et qu'ils avaient voulu recuperer des codes en GPLv3, ils auraient du passer tout le noyau en GPLv3 de toute facon.
[^] # Re: Parce que
Posté par Matthieu Lemerre . En réponse au journal utilité du i386. Évalué à 3.
quand t'as un systeme monoprocesseur (tout ce qui est spin lock ... hop a la trappe). Sous Linux en dehors du noyau je ne vois pas d'autres applications qui pourraient en tirer parti.
[^] # Re: Comme XP^WPerl6 ?
Posté par Matthieu Lemerre . En réponse au journal Le langage L. Évalué à 3.
Et quand je parle de modification de syntaxe, je parle de syntaxe concrete, pas de syntaxe abstraite. Les macros lisp/scheme permettent de changer de syntaxe concrete, les modifications du reader lisp permettent de changer (dans une certaine mesure) de syntaxe concrete.
L permet de changer completement la syntaxe concrete ET la syntaxe abstraite.
[^] # Re: Expliquer...
Posté par Matthieu Lemerre . En réponse au journal Le langage L. Évalué à 3.
J'ai beaucoup apprecie le style de programmation de Lisp, dans lequel on peut etendre son language completement en ajoutant de nouveaux operateurs.
Il se trouve que je programme beaucoup en C que j'aime beaucoup, et j'aime bien appliquer cette pratique en C, mais le preprocesseur C ne permet pas tout. Ce qu'il faut, c'est que l'outil de metaprogrammation soit integre au langage. D'ou l'idee de L.
Par ailleurs, le style de developpement de Ruby est aussi interessant. Je ne suis pas forcement un afficionado du concept "tout est objet", mais l'integration entre
les cotes fonctionnels et imperatifs de Ruby est remarquable.
J'aime aussi les langages fortement types statiquement a la Caml; je trouve que definir des nouveaux types permet de clarifier fortement un programme.
J'ai eu la chance de suivre des cours de compilation lors de mon cursus, et j'ai donc tente de creer un langage qui combinait toutes les fonctionnalites que j'aime bien : extensible, bas-niveau, type fortement, multi paradigme, plus quelques idees auxquelles j'avait deja pense, mais jamais pu realiser faut de support du langage.
[^] # Re: Expliquer...
Posté par Matthieu Lemerre . En réponse au journal Le langage L. Évalué à 3.
Pour l'analyse lexicale (equivalent de flex), j'ai ecris une librairie qui analyse un ensemble d'expressions rationnelles, en construit un automate deterministe, et le compile en assembleur. Il n'a pas besoin de dependences exterieures comme la libflex.
La difference avec flex, c'est que flex construit une table pour l'analyse lexicale, qu'il "interprete". Tandis que mes automates sont compiles.
L'interet de ma technique est essentiellement la rapidite, le fait qu'on peut generer des scanners sans dependance exterieure, et le fait que je vais pouvoir directement utiliser ca pour creer ma librairie de regexp. Le desavantage c'est la place prise en memoire (par exemple, on ne peut pas utiliser des tables compressees).
Je n'ai pas fait de tests comparatifs de rapidite avec flex, mais j'en avais fait avec la libpcre (pour une seule expression rationnelle "matchee" en meme temps), et le resultat etait 10x plus rapide que la PCRE. Par contre, on ne gere pas tout ce qui n'est pas vraiment des expressions rationnelles (les trucs comme "<(\w+)>.*<\1>" par exemple), parce que ca ne peut pas etre compile en automate deterministe. Et puis, les extensions necessaires pour recuperer les resultats d'un match ne sont pas encore ecrites.
De meme, je n'utilise pas bison : j'ai ecrit un parser en descente recursive. Ca me permet justement de pouvoir etendre ma syntaxe en rajoutant des parsers au run-time. Pour faciliter l'ecriture de nouveaux parseurs, je prevois l'ecriture d'un "parse language", qui permet d'ecrire la regle de grammaire directement, et qui sera compilee en une fonction de parsing.
Ah, et au final, mon programme genere du code x86 directement en memoire
(ce qui permet un processus de developpement interactif), mais je suis en train de rajouter la possibilite de sortir du C.