J'avais déjà vu un site similaire dont j'ai oublié le nom. C'était un aggrégateur de RSS + des news postées par les utilisateurs. Tout était trié par le nombre de clics, les votes utilisateurs et d'autres paramètres que je connais pas (je suppose la date de l'insertion). Non, ce n'est pas linuxfr, c'était un site généraliste avec "wiki" dans le nom de domaine je crois.
J'étais trouvé ça pas mal, mais ça boguait (web 2.0 qui marche pas sous Konqueror) et puis j'suis tombé amoureuuuuuu d'Akregator.
Personne n'a souligné que Python 3000 est 33% plus lent que Python 2.5 : « The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 33% slower than Python 2.5. ».
Je vois que la guerre de l'indentation n'est pas morte et c'est bien pour ça que Python 3000 ne change rien. Perso, je serai pour interdir les mélanges tabulations / espaces dans le même fichier. Chacun a ses raisons (qu'il trouve très bonne) pour utiliser l'un ou l'autre. Par contre, c'est vraiment le bordel quand on mélange les deux dans le même fichier ! Voir les exemples de Matthieu Moy pour celà.
--
Maintenant pour contribuer au troll, les arguments de Moonz ne sont pas recevables.
> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
2. Le rendu dépend aussi de la police utilisée
C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ?
Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible. Car le mode "wrap" est souvent pénible à utiliser. Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle
C'est bien naïf ça. L'aspect visuel du code apporte des informations sur l'organisation du code. En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define). Voir le concours IOCCC pour voir ce que donne les cas extrêmes. http://www.ioccc.org/
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:
C'est bien là que le bas blaisse. Tu avoues toi même avoir besoin de mélanger espace et tabulation. Or c'est exactement là que les tabulations foutent la merdent car elles perdent tout leur intérêt ! Voir l'expemple ci-dessous :
Alors tu expliques dans tes longs commentaires que les tabulations c'est la solution au problème de mise en forme pour la simple et bonne raison que l'utilisateur peut choisir la largeur des tabulations. Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.
Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN » et c'est là qu'on retrouve les horribles pied de page qui indiquent la configuration vim/emacs.
Mais à part cette situation,
C'est pourtant exactement pour cette situation (pourtant très courante) que les tabulations c'est de la merde en sac.
Python 3000 est la première version qui décide de faire table rase du passé et de supprimer les erreurs de jeunesse.
Les identifieurs (variables,...) ne sont plus limités aux caractères ascii
Certains vont tomber de leur chaise en lisant ça : « Mais... mais... comment je vais faire pour utiliser une bibliothèque écrite en tibétain, vietnamien ou encore coréen ? mon clavier est frappé d'un coq et n'a que quelques lettres accentuées ! ». La réponse est simple : c'est à l'auteur de choisir d'utiliser des noms ASCII (a-z, A-Z, 0-9, _) ou bien des noms unicode (dans leur langue). C'est l'auteur de la bibliothèque qui décide si d'autres pourront le relire ou non. Quelqu'un qui écrit du logiciel libre et veut des contributeurs écrira forcément en anglais avec des noms ASCII.
Une nouvelle alternative à l'opérateur '%' a faite son apparition, str.format().
format() a l'air surpuissant ! Pour l'internationalisation d'un programme, on peut aisément changer l'ordre des arguments dans la chaîne de formatage car les arguments sont numérotés (ex: "{0} {1}!".format('Hello', 'World')). En fait, c'était déjà plus au moins possible avec printf() mais beaucoup plus tordu. format() est très personalisable au niveau des rêgles de formatage. Lire la PEP pour les détails.
bytes ne peut pas être utilisé comme index d'un dictionnaire.
Pour ceux qui parlent le Python, on dit que le type mutable est mutable. C'est-à-dire qu'on peut le modifier : « x=b"abc"; x[0]=42 » ce qui n'était pas possible avec le type str de Python2. Conséquence : le type bytes n'est pas hashable, or la clé d'un dictionnaire doit être hashable. J'ai posé la question de comment faire pour avoir un bytes non modifiable mais je n'ai pas bien compris la réponse. On m'a parlé du l'outil « buffer » ou du type batard « str8 » (qui est en fait l'ancien type str mais ce dernier ma disparaitre). Pour des raisons de compatibilités avec Python2 ou pour pouvoir utiliser bytes comme clé de dictionnaire, ça serait bien d'avoir un frozen_bytes.
Annotation de fonctions
Un des objectifs est de permettre d'annoter les types des arguments et type de retour pour permettre aux outils tels que pychecker de vérifier les erreurs de typage.
Faire de print une fonction a beau être une bonne idée pour la cohérence du langage,
C'est surtout pour permettre de remplacer la fonction par du code perso. On peut très bien écrire « print = logging.info » pour transférer la sortie dans le système de logging !
Y'a un autre gros changemetn que j'ai appris au passage : PEP 3119 qui introduit les classes abstraites qui sont similaires aux interfaces Java. http://www.python.org/dev/peps/pep-3119/
En ce qui concerne le code existant, un outil de conversion appelé « 2to3 » est disponible et fait 95% du boulot. Guido van Rossum conseille de ne pas toucher son code Python 2.x et de n'utiliser que l'outil de conversion. Python 3000 ne sera pas disponible avant 2008 (été 2008 ?).
Je vous conseille quand même de commencer à :
- utiliser a//b plutôt que a/b pour la division entière (car 2/1 donne 2.0 et non pas 2 dans Python 3000)
- éviter de mélanger chaîne de caractère ('unicode') et chaînes d'octets ('str') car de toute façon c'est source de nombreux bugs. Il vaut mieux rester en Unicode le plus longtemps possible.
Python 3000 vise à limiter les erreurs liées au langage. Exemple : 0666 est une erreur, il faut écrire explicitement 0o666 (forme octale). Ceci évite les erreurs quand l'utilisateur saisi un zéro en trop. Le mélange entre caractère et octet était aussi source de bug. Enfin, la fusion de int et long simplifient le code. Bref, Python 3000 c'est que du bon.
En parlant de films de daube, il y a aussi la « Stratégie de l'échec » avec Dominique Farugas, Maurice Barthélémy et Jean-Paul Rouve (entre autres). Le ton est donné dès le début : ce film est un échec (dit dans le film). Il apprend à louper sa vie. Exemple : annoncer le 1er jour de son embauche qu'on appartient à une secte visant à faire disparaitre l'espèce humaine de la terre par la sodomie. http://fr.wikipedia.org/wiki/La_Stratégie_de_l'échec_(film)
L'auteur de libcaca qui possède une large collection de DTC ( http://sam.zoy.org/fun/dtc/ ) et de goatse (http://sam.zoy.org/goatse/ ). Il a bossé sur plein de super projets comme VLC et Debian, et c'est aussi l'auteur zzuf, monsterz et plein d'autres trucs. J'ai cru comprendre qu'il est à l'origine du reverse enginering des sous-titres DVD.
En octobre 2005, Check Point a tenté d'aquérir Sourcefire pour 225 millions de dollar US, mais en mars 2006 le CFIUS a suspendu la transaction en invoquant des raisons de sécurité nationales.
Je connais mal OWL et peu VCL, donc c'est possible que j'ai tout mélangé. Je voulais juste insister sur le fait que dépendre d'un composant propriétaire rend un projet dépend de l'éditeur de ce composant. En quelques sortes, l'éditeur va décider pour vous du moment de la mort de votre projet.
C'est la plaie des RAD. Quand ils sont désuets, les logiciels écrits avec sont à réécrire pour un autre RAD (ou version suivante incompatible). Je pense par exemple à la bibliothèque Borland OWL remplacée par Borland VCL (Visual Component Library). Peut-être que la nouvelle version est mieux, mais quid des anciens logiciels ? À l'école, j'avais récolté comme projet de porter un logiciel Windows (écrit pour OWL) pour Linux (avec wxWidgets). Et bien, quelle misère. En 6 mois, le portage était fait à environ... disons entre 60 et 80%. Pourtant je m'étais donné du mal. Le soucis est aussi que le code était mal écrit (fonction avec 28 arguments nommés a, b,c, ..., x, y, z, aa, bb \o/) et que le code mélangeait logique de l'application et partie interface graphique...
Le code source des logiciels libres étant public, n'importe qui peut l'auditer. De nombreux bugs mineurs et inexploitables sont corrigés de cette manière. Au contraire, quand Microsoft publie un bulletin de sécurité, seuls les failles critiques et exploitables sont notifiées. J'ai bien l'impression que de très nombreux bugs (failles inexploitables) sont marqués comme « faille de sécurité ». Je le sais car je suis à l'auteur de quelques bulletins de sécurité.
« En plus, ils oublient par magie que le système de corrections des distributions est universel a tout les logiciel, quand Microsoft ne corrige que Microsoft. »
Disons qu'une distribution Linux c'est 10.000 paquets alors que Windows c'est 1 noyau et (je dis au pif) une centaine d'applicatifs. Comparons ce qui est comparable !
Les distributions Linux corrigent de nombreuses failles dans des applications qui ne sont pas installées par défaut.
Attention aux homonymes : « Do you know this famous program written in C? It will calculate PI value with 800 digits. » Entre 800 et 1 2411 000 000 000 décimales, il y a une légère différence.
« The current record holder is Yasumasa Kanada of the University of Tokyo, who used a supercomputer to calculate pi to 1.2411 trillion digits in only 600 hours. » extrait de http://starbulletin.com/2007/05/06/business/brill.html (record de 2002, invaincu jusqu'à aujourd'hui)
On peut trouver le logiciel super pi sur le FTP de l'Université de Tokyo (compilé pour différents systèmes d'exploitations) : ftp://pi.super-computing.org/
Il semble que le logiciel ait été écrit majoritairement en Fortran avec un peu de C, mais que le fortran a ensuite été converti en C. Le code source a été écrit par Daisuke Takahashi mais une partie (message passing routines) a été écrite par Yasumasa Kanada.
« Si un virus arrive à se propager dans un organisme, il y en a très peu qui arrivent à passer d'une espèce à une autre »
Il y en a peu, mais ça existe. Il existe des programmes s'exécutant sous MS-Dos, Windows et Linux (le même fichier). Il existe des virus OpenOffice (macro OpenOffice). Je me demande s'il n'existe pas déjà des virus Firefox/Thunderbird "portable". Étant donné que Linux devient plus populaire chaque jour, ça devient une cible intéressante pour un cracker. Techniquement, Linux est plus solide que Windows mais de là à dire que Linux est exempte de faille, c'est faux.
[^] # Re: Optimisation
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 3.
[^] # Re: Déjà vu
Posté par Victor STINNER (site web personnel) . En réponse au journal Rss, scriptaculous, 2.0 et cie.. Évalué à 2.
http://www.wikio.fr/
Le site existe encore.
# Déjà vu
Posté par Victor STINNER (site web personnel) . En réponse au journal Rss, scriptaculous, 2.0 et cie.. Évalué à 2.
J'étais trouvé ça pas mal, mais ça boguait (web 2.0 qui marche pas sous Konqueror) et puis j'suis tombé amoureuuuuuu d'Akregator.
Victor
# Optimisation
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 7.
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 2.
--
Maintenant pour contribuer au troll, les arguments de Moonz ne sont pas recevables.
> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
2. Le rendu dépend aussi de la police utilisée
C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ?
Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible. Car le mode "wrap" est souvent pénible à utiliser. Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle
C'est bien naïf ça. L'aspect visuel du code apporte des informations sur l'organisation du code. En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define). Voir le concours IOCCC pour voir ce que donne les cas extrêmes.
http://www.ioccc.org/
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:
C'est bien là que le bas blaisse. Tu avoues toi même avoir besoin de mélanger espace et tabulation. Or c'est exactement là que les tabulations foutent la merdent car elles perdent tout leur intérêt ! Voir l'expemple ci-dessous :
T[sendSomeLongMessage: arg1
TSSSwithManyArguments: arg2
TSSandAnotherArgument: arg3
TSSSSSSSSmoreArgument: arg4
TSSScontinueArguments: arg5]
Alors tu expliques dans tes longs commentaires que les tabulations c'est la solution au problème de mise en forme pour la simple et bonne raison que l'utilisateur peut choisir la largeur des tabulations. Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.
Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN » et c'est là qu'on retrouve les horribles pied de page qui indiquent la configuration vim/emacs.
Mais à part cette situation,
C'est pourtant exactement pour cette situation (pourtant très courante) que les tabulations c'est de la merde en sac.
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 3.
Certians vont disparaitre et d'autres vont maigrir. Il doit y avoir une PEP qui détaille ça, disons :
http://www.python.org/dev/peps/pep-3001/
Ce travail n'est pas encore fait mais le sera avant août 2008.
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 5.
Les identifieurs (variables,...) ne sont plus limités aux caractères ascii
Certains vont tomber de leur chaise en lisant ça : « Mais... mais... comment je vais faire pour utiliser une bibliothèque écrite en tibétain, vietnamien ou encore coréen ? mon clavier est frappé d'un coq et n'a que quelques lettres accentuées ! ». La réponse est simple : c'est à l'auteur de choisir d'utiliser des noms ASCII (a-z, A-Z, 0-9, _) ou bien des noms unicode (dans leur langue). C'est l'auteur de la bibliothèque qui décide si d'autres pourront le relire ou non. Quelqu'un qui écrit du logiciel libre et veut des contributeurs écrira forcément en anglais avec des noms ASCII.
Une nouvelle alternative à l'opérateur '%' a faite son apparition, str.format().
format() a l'air surpuissant ! Pour l'internationalisation d'un programme, on peut aisément changer l'ordre des arguments dans la chaîne de formatage car les arguments sont numérotés (ex: "{0} {1}!".format('Hello', 'World')). En fait, c'était déjà plus au moins possible avec printf() mais beaucoup plus tordu. format() est très personalisable au niveau des rêgles de formatage. Lire la PEP pour les détails.
bytes ne peut pas être utilisé comme index d'un dictionnaire.
Pour ceux qui parlent le Python, on dit que le type mutable est mutable. C'est-à-dire qu'on peut le modifier : « x=b"abc"; x[0]=42 » ce qui n'était pas possible avec le type str de Python2. Conséquence : le type bytes n'est pas hashable, or la clé d'un dictionnaire doit être hashable. J'ai posé la question de comment faire pour avoir un bytes non modifiable mais je n'ai pas bien compris la réponse. On m'a parlé du l'outil « buffer » ou du type batard « str8 » (qui est en fait l'ancien type str mais ce dernier ma disparaitre). Pour des raisons de compatibilités avec Python2 ou pour pouvoir utiliser bytes comme clé de dictionnaire, ça serait bien d'avoir un frozen_bytes.
Annotation de fonctions
Un des objectifs est de permettre d'annoter les types des arguments et type de retour pour permettre aux outils tels que pychecker de vérifier les erreurs de typage.
Faire de print une fonction a beau être une bonne idée pour la cohérence du langage,
C'est surtout pour permettre de remplacer la fonction par du code perso. On peut très bien écrire « print = logging.info » pour transférer la sortie dans le système de logging !
Haypo
# Autres sur Python 3000
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Python 3 alpha. Évalué à 4.
* Types bytes et str
* Annotation des fonctions
* Argument sous forme de mot-clé
http://www.haypocalc.com/blog/index.php/2007/07/30/63-change(...)
Y'a un autre gros changemetn que j'ai appris au passage : PEP 3119 qui introduit les classes abstraites qui sont similaires aux interfaces Java.
http://www.python.org/dev/peps/pep-3119/
Autre billet présentant les développements d'il y un mois :
http://www.haypocalc.com/blog/index.php/2007/08/14/67-etat-d(...)
--
En ce qui concerne le code existant, un outil de conversion appelé « 2to3 » est disponible et fait 95% du boulot. Guido van Rossum conseille de ne pas toucher son code Python 2.x et de n'utiliser que l'outil de conversion. Python 3000 ne sera pas disponible avant 2008 (été 2008 ?).
Je vous conseille quand même de commencer à :
- utiliser a//b plutôt que a/b pour la division entière (car 2/1 donne 2.0 et non pas 2 dans Python 3000)
- éviter de mélanger chaîne de caractère ('unicode') et chaînes d'octets ('str') car de toute façon c'est source de nombreux bugs. Il vaut mieux rester en Unicode le plus longtemps possible.
Python 3000 vise à limiter les erreurs liées au langage. Exemple : 0666 est une erreur, il faut écrire explicitement 0o666 (forme octale). Ceci évite les erreurs quand l'utilisateur saisi un zéro en trop. Le mélange entre caractère et octet était aussi source de bug. Enfin, la fusion de int et long simplifient le code. Bref, Python 3000 c'est que du bon.
Haypo
[^] # Re: Python sur la voie du tout objet ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Python 3 alpha. Évalué à 2.
# La stratégie de l'échec
Posté par Victor STINNER (site web personnel) . En réponse au journal La classe américaine. Évalué à 3.
http://fr.wikipedia.org/wiki/La_Stratégie_de_l'échec_(film)
[^] # Re: Petites explications...
Posté par Victor STINNER (site web personnel) . En réponse au journal La classe américaine. Évalué à 10.
# Sourcefire et Check Point
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le propriétaire de Snort achète ClamAV. Évalué à 2.
J'ai ajouté cette phrase avec des références sur l'article Wikipédia :
http://fr.wikipedia.org/wiki/Sourcefire
[^] # Re: Bonne nouvelle!
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Nouvelle version du Fork de DBDesigner. Évalué à 4.
Il existe un projet de Delphi libre : Lazarus qu'on peut trouver par ici :
http://www.lazarus.freepascal.org/
Il semble se base sur FreePascal qui est un projet ancien (dans le sens positif : robuste) et multi-plateforme.
[^] # Re: Toolkit
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Nouvelle version du Fork de DBDesigner. Évalué à 5.
[^] # Re: Toolkit
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Nouvelle version du Fork de DBDesigner. Évalué à 2.
C'est la plaie des RAD. Quand ils sont désuets, les logiciels écrits avec sont à réécrire pour un autre RAD (ou version suivante incompatible). Je pense par exemple à la bibliothèque Borland OWL remplacée par Borland VCL (Visual Component Library). Peut-être que la nouvelle version est mieux, mais quid des anciens logiciels ? À l'école, j'avais récolté comme projet de porter un logiciel Windows (écrit pour OWL) pour Linux (avec wxWidgets). Et bien, quelle misère. En 6 mois, le portage était fait à environ... disons entre 60 et 80%. Pourtant je m'étais donné du mal. Le soucis est aussi que le code était mal écrit (fonction avec 28 arguments nommés a, b,c, ..., x, y, z, aa, bb \o/) et que le code mélangeait logique de l'application et partie interface graphique...
# Vidéo impressionante
Posté par Victor STINNER (site web personnel) . En réponse au journal Un redimensionnement de science-fiction. Évalué à 9.
Le fichier FLV :
http://74.125.13.32/get_video?video_id=vIFCV2spKtg
J'ai bien aimé le bouton « eraser » :-)
# L'offre inclut du support ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Dell propose des logiciels libres.... Évalué à 4.
[^] # Re: Explication
Posté par Victor STINNER (site web personnel) . En réponse au journal Bench de la sécurité des différents systèmes d'exploitation en Juillet 2007. Évalué à 4.
[^] # Re: Explication
Posté par Victor STINNER (site web personnel) . En réponse au journal Bench de la sécurité des différents systèmes d'exploitation en Juillet 2007. Évalué à 8.
Disons qu'une distribution Linux c'est 10.000 paquets alors que Windows c'est 1 noyau et (je dis au pif) une centaine d'applicatifs. Comparons ce qui est comparable !
Les distributions Linux corrigent de nombreuses failles dans des applications qui ne sont pas installées par défaut.
Cette analyse est totalement biaisée.
# Infos sur heise security
Posté par Victor STINNER (site web personnel) . En réponse au journal Bench de la sécurité des différents systèmes d'exploitation en Juillet 2007. Évalué à 5.
http://www.heise-security.co.uk/news/91593
Plus d'information sur l'article de Jeff :
http://www.heise-security.co.uk/news/94657
Il me semble que Jeff Jones soit employé par Microsoft mais je n'en suis pas sûr.
[^] # Re: C'est moche
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le propriétaire de Snort achète ClamAV. Évalué à 3.
# Drop pur et simple
Posté par Victor STINNER (site web personnel) . En réponse au message [Web/Réseau] Utiliser un deuxième serveur pour des adresses ip sur liste noire. Évalué à 2.
[^] # Re: Pour faire un lien avec un dépêche récente
Posté par Victor STINNER (site web personnel) . En réponse au journal un petit super pi ?. Évalué à 1.
[^] # Re: Pour faire un lien avec un dépêche récente
Posté par Victor STINNER (site web personnel) . En réponse au journal un petit super pi ?. Évalué à 8.
On peut trouver le logiciel super pi sur le FTP de l'Université de Tokyo (compilé pour différents systèmes d'exploitations) :
ftp://pi.super-computing.org/
Il semble que le logiciel ait été écrit majoritairement en Fortran avec un peu de C, mais que le fortran a ensuite été converti en C. Le code source a été écrit par Daisuke Takahashi mais une partie (message passing routines) a été écrite par Yasumasa Kanada.
Si vous voulez un logiciel libre, regardez par exemple :
http://projectpi.sourceforge.net/
[^] # Re: Préventif ou curatif ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Tests d'efficacité des antivirus Linux. Évalué à 7.
Il y en a peu, mais ça existe. Il existe des programmes s'exécutant sous MS-Dos, Windows et Linux (le même fichier). Il existe des virus OpenOffice (macro OpenOffice). Je me demande s'il n'existe pas déjà des virus Firefox/Thunderbird "portable". Étant donné que Linux devient plus populaire chaque jour, ça devient une cible intéressante pour un cracker. Techniquement, Linux est plus solide que Windows mais de là à dire que Linux est exempte de faille, c'est faux.