depuis quelques jours, le freeb sur mon pc reboot tout seul.
Ça arrive comme ça... de manière aléatoir. J'ai regarder comme ça tantôt
le résultat de last(1) et il semble que j'ai rebooté... sans en avoir eu
conscience.
Bon, je me demande si je suis seul dans mon ordinateur (ce qui devrait
être le cas!). Par où est-ce que je commence pour vérifier que mon ordi
ne reboot pas par l'action de quelqu'un d'autre. Je ne connais vraiment
pas grand chose au réseau. Un lien sur internet? Liens vers des ports,
appli etc.
À (at) 19 Nov 2004 15:07:02 GMT, Miod Vallat écrivait (wrote):
Le deuxième problème, qui y est fortement lié, c'est que toutes les parties basses de gcc qui ne traitent que de la manipulation du rtl (donc essentiellement un interpréteur lisp pour traiter les fichiers .md et écrire du code assembleur en sortie) sont très mal documentées (je parle ici du code, pas seulement de gccint.texi), et écrites de façon suffisamment touffue et hermétique pour que personne, parmi les développeurs actuels de gcc, n'ose y toucher, de peur de provoquer des dommages collatéraux sans s'en rendre compte...
C'est vrai que ces parties (qui sont très importantes) sont toujours mal (pas) documentées même si gccint amène un peu d'éclaircissement.
En fait, j'avais essayé de m'y intéresser vers 1992 car à l'époque, je faisais du C++ et il y avait encore beaucoup de bug dans g++. C'était un foutoir sans nom et aucune documentation. A l'époque, cela m'avait beaucoup surpris et décu.
Puis, récemment, j'ai vu ggcint et je me suis dit qu'enfin, ces parties là allaient être éclaircies. Mais n'en ayant plus la nécessité, je n'ai pas vraiment replonger dans le biniou. Au vu de ce que vous dites, ça ne semble pas être encore complètement cela ;-)
Espérons que, comme vous le signalez, gcc 4 retrouvera le bon chemin. Je ne pense que ces défauts soient inhérents au modèle FSF (qu'on pourrait opposer au modèle BSD). Mais c'est peut-être mon optimisme naturel (et la patience qui va avec) qui parle...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) 19 Nov 2004 15:07:02 GMT,
Miod Vallat <miod@online.fr> écrivait (wrote):
Le deuxième problème, qui y est fortement lié, c'est que toutes les
parties basses de gcc qui ne traitent que de la manipulation du rtl
(donc essentiellement un interpréteur lisp pour traiter les fichiers
.md et écrire du code assembleur en sortie) sont très mal documentées (je
parle ici du code, pas seulement de gccint.texi), et écrites de façon
suffisamment touffue et hermétique pour que personne, parmi les
développeurs actuels de gcc, n'ose y toucher, de peur de provoquer des
dommages collatéraux sans s'en rendre compte...
C'est vrai que ces parties (qui sont très importantes) sont toujours mal (pas)
documentées même si gccint amène un peu d'éclaircissement.
En fait, j'avais essayé de m'y intéresser vers 1992 car à l'époque, je faisais
du C++ et il y avait encore beaucoup de bug dans g++. C'était un foutoir sans
nom et aucune documentation. A l'époque, cela m'avait beaucoup surpris et
décu.
Puis, récemment, j'ai vu ggcint et je me suis dit qu'enfin, ces parties là
allaient être éclaircies. Mais n'en ayant plus la nécessité, je n'ai pas
vraiment replonger dans le biniou. Au vu de ce que vous dites, ça ne semble
pas être encore complètement cela ;-)
Espérons que, comme vous le signalez, gcc 4 retrouvera le bon chemin. Je ne
pense que ces défauts soient inhérents au modèle FSF (qu'on pourrait opposer
au modèle BSD). Mais c'est peut-être mon optimisme naturel (et la patience qui
va avec) qui parle...
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) 19 Nov 2004 15:07:02 GMT, Miod Vallat écrivait (wrote):
Le deuxième problème, qui y est fortement lié, c'est que toutes les parties basses de gcc qui ne traitent que de la manipulation du rtl (donc essentiellement un interpréteur lisp pour traiter les fichiers .md et écrire du code assembleur en sortie) sont très mal documentées (je parle ici du code, pas seulement de gccint.texi), et écrites de façon suffisamment touffue et hermétique pour que personne, parmi les développeurs actuels de gcc, n'ose y toucher, de peur de provoquer des dommages collatéraux sans s'en rendre compte...
C'est vrai que ces parties (qui sont très importantes) sont toujours mal (pas) documentées même si gccint amène un peu d'éclaircissement.
En fait, j'avais essayé de m'y intéresser vers 1992 car à l'époque, je faisais du C++ et il y avait encore beaucoup de bug dans g++. C'était un foutoir sans nom et aucune documentation. A l'époque, cela m'avait beaucoup surpris et décu.
Puis, récemment, j'ai vu ggcint et je me suis dit qu'enfin, ces parties là allaient être éclaircies. Mais n'en ayant plus la nécessité, je n'ai pas vraiment replonger dans le biniou. Au vu de ce que vous dites, ça ne semble pas être encore complètement cela ;-)
Espérons que, comme vous le signalez, gcc 4 retrouvera le bon chemin. Je ne pense que ces défauts soient inhérents au modèle FSF (qu'on pourrait opposer au modèle BSD). Mais c'est peut-être mon optimisme naturel (et la patience qui va avec) qui parle...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Marwan Burelle
On 19 Nov 2004 15:02:52 GMT Miod Vallat wrote:
Ça marche pour tout langage compilable, en fait.
Oui, mais j'ai bien prendre des pincettes quand je parle de C, surtout depuis que je suis chargé de TP pour une TER (le nom des projets à Orsay) où le sujet est l'écriture d'un compilo C (restreint.) Je découvre des choses tous les jours ;)
Et les développeurs de gcc s'en rendent compte, puisque dans gcc 4, le travail sur la représentation SSA porte ses fruits et devrait, passé l'étape de nettoyage et de retrait des branches mortes dans le code, redonner des temps de compilation plus proches de ceux des versions 2.x.
Et bien, c'est rassurant !
Pour ma part je serais assez intéressé par l'apparition d'un backend bien documenté et générique que tout le monde pourrait utiliser avec son propre compilo.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et les dev de langages pourraient se concentrer sur leurs langages et pas sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être voir l'émergence de langage correct (avec une sémantique bien fondée, quoi) tout en étant efficace (en tout cas, pas freiné par une génération de code pourri comme c'est le cas de bcp de langages académiques ... )
Bon, j'arrète de refaire le monde ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 19 Nov 2004 15:02:52 GMT
Miod Vallat <miod@online.fr> wrote:
Ça marche pour tout langage compilable, en fait.
Oui, mais j'ai bien prendre des pincettes quand je parle de C, surtout
depuis que je suis chargé de TP pour une TER (le nom des projets à
Orsay) où le sujet est l'écriture d'un compilo C (restreint.) Je
découvre des choses tous les jours ;)
Et les développeurs de gcc s'en rendent compte, puisque dans gcc 4, le
travail sur la représentation SSA porte ses fruits et devrait, passé
l'étape de nettoyage et de retrait des branches mortes dans le code,
redonner des temps de compilation plus proches de ceux des versions
2.x.
Et bien, c'est rassurant !
Pour ma part je serais assez intéressé par l'apparition d'un backend
bien documenté et générique que tout le monde pourrait utiliser avec son
propre compilo.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et
les dev de langages pourraient se concentrer sur leurs langages et pas
sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être
voir l'émergence de langage correct (avec une sémantique bien fondée,
quoi) tout en étant efficace (en tout cas, pas freiné par une génération
de code pourri comme c'est le cas de bcp de langages académiques ... )
Bon, j'arrète de refaire le monde ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Oui, mais j'ai bien prendre des pincettes quand je parle de C, surtout depuis que je suis chargé de TP pour une TER (le nom des projets à Orsay) où le sujet est l'écriture d'un compilo C (restreint.) Je découvre des choses tous les jours ;)
Et les développeurs de gcc s'en rendent compte, puisque dans gcc 4, le travail sur la représentation SSA porte ses fruits et devrait, passé l'étape de nettoyage et de retrait des branches mortes dans le code, redonner des temps de compilation plus proches de ceux des versions 2.x.
Et bien, c'est rassurant !
Pour ma part je serais assez intéressé par l'apparition d'un backend bien documenté et générique que tout le monde pourrait utiliser avec son propre compilo.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et les dev de langages pourraient se concentrer sur leurs langages et pas sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être voir l'émergence de langage correct (avec une sémantique bien fondée, quoi) tout en étant efficace (en tout cas, pas freiné par une génération de code pourri comme c'est le cas de bcp de langages académiques ... )
Bon, j'arrète de refaire le monde ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Miod Vallat
Pour ma part je serais assez intéressé par l'apparition d'un backend bien documenté et générique que tout le monde pourrait utiliser avec son propre compilo.
C'est le cas pour les compilo qui font partie de la collection gcc : ils traduisent leur langage en rtl, et sont liés à libbackend.a qui traduit le rtl en assembleur.
Bien sûr, la FSF est hostile à toute séparation tranchée en deux binaires (cc1 qui pondrait du .rtl, et un hypothétique rtl2as qui pondrait le .s), comme Thomas l'a indiqué plus haut dans cette discussion.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et les dev de langages pourraient se concentrer sur leurs langages et pas sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être voir l'émergence de langage correct (avec une sémantique bien fondée, quoi) tout en étant efficace (en tout cas, pas freiné par une génération de code pourri comme c'est le cas de bcp de langages académiques ... )
Là, j'avoue que je n'ai pas fait particulièrement attention si l'optimisation a lieu dans libbackend, ou au-dessus.
Pour ma part je serais assez intéressé par l'apparition d'un backend
bien documenté et générique que tout le monde pourrait utiliser avec son
propre compilo.
C'est le cas pour les compilo qui font partie de la collection gcc : ils
traduisent leur langage en rtl, et sont liés à libbackend.a qui traduit
le rtl en assembleur.
Bien sûr, la FSF est hostile à toute séparation tranchée en deux
binaires (cc1 qui pondrait du .rtl, et un hypothétique rtl2as qui
pondrait le .s), comme Thomas l'a indiqué plus haut dans cette
discussion.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et
les dev de langages pourraient se concentrer sur leurs langages et pas
sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être
voir l'émergence de langage correct (avec une sémantique bien fondée,
quoi) tout en étant efficace (en tout cas, pas freiné par une génération
de code pourri comme c'est le cas de bcp de langages académiques ... )
Là, j'avoue que je n'ai pas fait particulièrement attention si
l'optimisation a lieu dans libbackend, ou au-dessus.
Pour ma part je serais assez intéressé par l'apparition d'un backend bien documenté et générique que tout le monde pourrait utiliser avec son propre compilo.
C'est le cas pour les compilo qui font partie de la collection gcc : ils traduisent leur langage en rtl, et sont liés à libbackend.a qui traduit le rtl en assembleur.
Bien sûr, la FSF est hostile à toute séparation tranchée en deux binaires (cc1 qui pondrait du .rtl, et un hypothétique rtl2as qui pondrait le .s), comme Thomas l'a indiqué plus haut dans cette discussion.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et les dev de langages pourraient se concentrer sur leurs langages et pas sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être voir l'émergence de langage correct (avec une sémantique bien fondée, quoi) tout en étant efficace (en tout cas, pas freiné par une génération de code pourri comme c'est le cas de bcp de langages académiques ... )
Là, j'avoue que je n'ai pas fait particulièrement attention si l'optimisation a lieu dans libbackend, ou au-dessus.
talon
Miod Vallat wrote:
Pour ma part je serais assez intéressé par l'apparition d'un backend bien documenté et générique que tout le monde pourrait utiliser avec son propre compilo.
C'est le cas pour les compilo qui font partie de la collection gcc : ils traduisent leur langage en rtl, et sont liés à libbackend.a qui traduit le rtl en assembleur.
Bien sûr, la FSF est hostile à toute séparation tranchée en deux binaires (cc1 qui pondrait du .rtl, et un hypothétique rtl2as qui pondrait le .s), comme Thomas l'a indiqué plus haut dans cette discussion.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et les dev de langages pourraient se concentrer sur leurs langages et pas sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être voir l'émergence de langage correct (avec une sémantique bien fondée, quoi) tout en étant efficace (en tout cas, pas freiné par une génération de code pourri comme c'est le cas de bcp de langages académiques ... )
Là, j'avoue que je n'ai pas fait particulièrement attention si l'optimisation a lieu dans libbackend, ou au-dessus.
Là une information peut être utile: les programmes que j'ai testés sont en Fortran. Je les ai testés de deux manières: - une en compilant directement le Fortran et en jouant sur les options d'optimisation - l'autre en transformant le Fortran en C avec f2c et en compilant le C avec les mêmes optimisations.
A ma grande surprise, la compilation directe du Fortran avait donné des exécutables beaucoup plus lents que ceux obtenus avec f2c puis gcc. Et ce avec exactement les mêmes flags d'optimisation. Bref je doute beaucoup beaucoup que l'optimiseur soit complètement découplé de la partie haute. En tout cas, si j'ai bien compris, le nouveau machin tree-ssa consiste à faire des optimisations à un niveau plus haut que le RTL. Une fois ces optimisations faites on émet le RTL puis on fait des optimisations de bas niveau sur le RTL.
--
Michel TALON
Miod Vallat <miod@online.fr> wrote:
Pour ma part je serais assez intéressé par l'apparition d'un backend
bien documenté et générique que tout le monde pourrait utiliser avec son
propre compilo.
C'est le cas pour les compilo qui font partie de la collection gcc : ils
traduisent leur langage en rtl, et sont liés à libbackend.a qui traduit
le rtl en assembleur.
Bien sûr, la FSF est hostile à toute séparation tranchée en deux
binaires (cc1 qui pondrait du .rtl, et un hypothétique rtl2as qui
pondrait le .s), comme Thomas l'a indiqué plus haut dans cette
discussion.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et
les dev de langages pourraient se concentrer sur leurs langages et pas
sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être
voir l'émergence de langage correct (avec une sémantique bien fondée,
quoi) tout en étant efficace (en tout cas, pas freiné par une génération
de code pourri comme c'est le cas de bcp de langages académiques ... )
Là, j'avoue que je n'ai pas fait particulièrement attention si
l'optimisation a lieu dans libbackend, ou au-dessus.
Là une information peut être utile: les programmes que j'ai testés
sont en Fortran. Je les ai testés de deux manières:
- une en compilant directement le Fortran et en jouant sur les options
d'optimisation
- l'autre en transformant le Fortran en C avec f2c et en compilant le C
avec les mêmes optimisations.
A ma grande surprise, la compilation directe du Fortran avait donné
des exécutables beaucoup plus lents que ceux obtenus avec f2c puis gcc.
Et ce avec exactement les mêmes flags d'optimisation. Bref je doute
beaucoup beaucoup que l'optimiseur soit complètement découplé de la
partie haute. En tout cas, si j'ai bien compris, le nouveau machin
tree-ssa consiste à faire des optimisations à un niveau plus haut que le
RTL. Une fois ces optimisations faites on émet le RTL puis on fait des
optimisations de bas niveau sur le RTL.
Pour ma part je serais assez intéressé par l'apparition d'un backend bien documenté et générique que tout le monde pourrait utiliser avec son propre compilo.
C'est le cas pour les compilo qui font partie de la collection gcc : ils traduisent leur langage en rtl, et sont liés à libbackend.a qui traduit le rtl en assembleur.
Bien sûr, la FSF est hostile à toute séparation tranchée en deux binaires (cc1 qui pondrait du .rtl, et un hypothétique rtl2as qui pondrait le .s), comme Thomas l'a indiqué plus haut dans cette discussion.
L'effort orienté optimisation (et portage, d'ailleurs) se ferait là, et les dev de langages pourraient se concentrer sur leurs langages et pas sur des problèmes génériques. Dans cette hyppothèse, on pourra peut être voir l'émergence de langage correct (avec une sémantique bien fondée, quoi) tout en étant efficace (en tout cas, pas freiné par une génération de code pourri comme c'est le cas de bcp de langages académiques ... )
Là, j'avoue que je n'ai pas fait particulièrement attention si l'optimisation a lieu dans libbackend, ou au-dessus.
Là une information peut être utile: les programmes que j'ai testés sont en Fortran. Je les ai testés de deux manières: - une en compilant directement le Fortran et en jouant sur les options d'optimisation - l'autre en transformant le Fortran en C avec f2c et en compilant le C avec les mêmes optimisations.
A ma grande surprise, la compilation directe du Fortran avait donné des exécutables beaucoup plus lents que ceux obtenus avec f2c puis gcc. Et ce avec exactement les mêmes flags d'optimisation. Bref je doute beaucoup beaucoup que l'optimiseur soit complètement découplé de la partie haute. En tout cas, si j'ai bien compris, le nouveau machin tree-ssa consiste à faire des optimisations à un niveau plus haut que le RTL. Une fois ces optimisations faites on émet le RTL puis on fait des optimisations de bas niveau sur le RTL.
--
Michel TALON
Marwan Burelle
On 19 Nov 2004 17:11:56 GMT Miod Vallat wrote:
Là, j'avoue que je n'ai pas fait particulièrement attention si l'optimisation a lieu dans libbackend, ou au-dessus.
Ça dépend du type de langage, des optimisations considérées et de l'architecture.
Certaines optims (gestions des registres par exemple) ne peuvent se faire qu'au niveau rtl, d'autre nécessite plus d'information sur la source ...
Mais, d'un autre côté, le rôle du compilo (avant la production de code machine, donc niveau production du rtl) est aussi d'optimiser vis à vis d'un langage source.
Mon idée est que pas mal de "compilo" pour des langages académiques (et autre langage "jeunes") ne s'intéressent réellement qu'à la partie concernant le langage source. On se retrouve avec des compilateurs produisants du langage machine pourri, souvent limités à une seule architecture. Ces compilos profiteraient grandement d'un "backend universel".
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 19 Nov 2004 17:11:56 GMT
Miod Vallat <miod@online.fr> wrote:
Là, j'avoue que je n'ai pas fait particulièrement attention si
l'optimisation a lieu dans libbackend, ou au-dessus.
Ça dépend du type de langage, des optimisations considérées et de
l'architecture.
Certaines optims (gestions des registres par exemple) ne peuvent se
faire qu'au niveau rtl, d'autre nécessite plus d'information sur la
source ...
Mais, d'un autre côté, le rôle du compilo (avant la production de code
machine, donc niveau production du rtl) est aussi d'optimiser vis à vis
d'un langage source.
Mon idée est que pas mal de "compilo" pour des langages académiques (et
autre langage "jeunes") ne s'intéressent réellement qu'à la partie
concernant le langage source. On se retrouve avec des compilateurs
produisants du langage machine pourri, souvent limités à une seule
architecture. Ces compilos profiteraient grandement d'un "backend
universel".
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Là, j'avoue que je n'ai pas fait particulièrement attention si l'optimisation a lieu dans libbackend, ou au-dessus.
Ça dépend du type de langage, des optimisations considérées et de l'architecture.
Certaines optims (gestions des registres par exemple) ne peuvent se faire qu'au niveau rtl, d'autre nécessite plus d'information sur la source ...
Mais, d'un autre côté, le rôle du compilo (avant la production de code machine, donc niveau production du rtl) est aussi d'optimiser vis à vis d'un langage source.
Mon idée est que pas mal de "compilo" pour des langages académiques (et autre langage "jeunes") ne s'intéressent réellement qu'à la partie concernant le langage source. On se retrouve avec des compilateurs produisants du langage machine pourri, souvent limités à une seule architecture. Ces compilos profiteraient grandement d'un "backend universel".
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Arnaud Launay
Le Thu, 18 Nov 2004 17:53:47 GMT, Serge Gagnon écrivit:
D'un autre côté, j'ai refait le monde hier soir
Tiens, moi aussi. Tu étais dans quel bar ?
Arnaud.
Le Thu, 18 Nov 2004 17:53:47 GMT, Serge Gagnon écrivit:
Le Thu, 18 Nov 2004 17:53:47 GMT, Serge Gagnon écrivit:
D'un autre côté, j'ai refait le monde hier soir
Tiens, moi aussi. Tu étais dans quel bar ?
Arnaud.
Arnaud Launay
Le Fri, 19 Nov 2004 16:32:10 +0100, Eric Masson écrivit:
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter Miod> les fichiers .md et écrire du code assembleur en sortie) Il y tient à sa marotte le père stallman...
Il commence à être grand temps de s'en débarrasser.
Le Fri, 19 Nov 2004 16:32:10 +0100, Eric Masson écrivit:
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter
Miod> les fichiers .md et écrire du code assembleur en sortie)
Il y tient à sa marotte le père stallman...
Il commence à être grand temps de s'en débarrasser.
Le Fri, 19 Nov 2004 16:32:10 +0100, Eric Masson écrivit:
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter Miod> les fichiers .md et écrire du code assembleur en sortie) Il y tient à sa marotte le père stallman...
Il commence à être grand temps de s'en débarrasser.
On Tue, 23 Nov 2004 10:12:55 +0000 (UTC), Arnaud Launay wrote:
Le Fri, 19 Nov 2004 16:32:10 +0100, Eric Masson écrivit:
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter Miod> les fichiers .md et écrire du code assembleur en sortie) Il y tient à sa marotte le père stallman...
Il commence à être grand temps de s'en débarrasser.
<petit jeu>
Duquel ?
[ ] interpréteur lisp [ ] RMS [ ] les deux
</petit jeu>
NB : Je pense déjà connaître la réponse de bon nombre d'entre vous :)
-- Serge
On Tue, 23 Nov 2004 10:12:55 +0000 (UTC), Arnaud Launay wrote:
Le Fri, 19 Nov 2004 16:32:10 +0100, Eric Masson écrivit:
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter
Miod> les fichiers .md et écrire du code assembleur en sortie)
Il y tient à sa marotte le père stallman...
Il commence à être grand temps de s'en débarrasser.
<petit jeu>
Duquel ?
[ ] interpréteur lisp
[ ] RMS
[ ] les deux
</petit jeu>
NB : Je pense déjà connaître la réponse de bon nombre d'entre vous :)
On Tue, 23 Nov 2004 10:12:55 +0000 (UTC), Arnaud Launay wrote:
Le Fri, 19 Nov 2004 16:32:10 +0100, Eric Masson écrivit:
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter Miod> les fichiers .md et écrire du code assembleur en sortie) Il y tient à sa marotte le père stallman...
Il commence à être grand temps de s'en débarrasser.
<petit jeu>
Duquel ?
[ ] interpréteur lisp [ ] RMS [ ] les deux
</petit jeu>
NB : Je pense déjà connaître la réponse de bon nombre d'entre vous :)
Si les deux sont choisis, il faudrait se débarrasser de Stallman avant l'interpréteur lisp. En effet en procédant en sens inverse, RMS serait capable de recoder un interpréteur lisp dans la fenêtre de temps disponible ;)
Éric Masson
-- Ol: ..un plan perdu au fond d'une armoire dont seul Steve Jobs a la clé. BL: Qu'il a laissée dans un pantalon déposé chez un teinturier dont il a perdu l'adresse et le ticket ! -+- BL in Guide du Macounet Pervers : Bien cacher sa stratégie -+-
Si les deux sont choisis, il faudrait se débarrasser de Stallman avant
l'interpréteur lisp. En effet en procédant en sens inverse, RMS serait
capable de recoder un interpréteur lisp dans la fenêtre de temps
disponible ;)
Éric Masson
--
Ol: ..un plan perdu au fond d'une armoire dont seul Steve Jobs a la clé.
BL: Qu'il a laissée dans un pantalon déposé chez un teinturier dont il a
perdu l'adresse et le ticket !
-+- BL in Guide du Macounet Pervers : Bien cacher sa stratégie -+-
Si les deux sont choisis, il faudrait se débarrasser de Stallman avant l'interpréteur lisp. En effet en procédant en sens inverse, RMS serait capable de recoder un interpréteur lisp dans la fenêtre de temps disponible ;)
Éric Masson
-- Ol: ..un plan perdu au fond d'une armoire dont seul Steve Jobs a la clé. BL: Qu'il a laissée dans un pantalon déposé chez un teinturier dont il a perdu l'adresse et le ticket ! -+- BL in Guide du Macounet Pervers : Bien cacher sa stratégie -+-
