SL <nospam@nospam.com> writes:

[...]

> Ben j'ai essayé, mais je connais pas la méthode pour lui
> prendre des températures réalistes. Voilà ce que j'ai fait :
> - au repos il est à 46C.

45°C pour le mien...

> - après trois quatre minutes dans une boucle
> while 1
> foo = foo + 1;
> end
> il est à 58C.

C'est trop, surtout en si peu de temps. Le mien monte très doucement
en température, jusqu'à un plafond de 53°C au bout d'une heure et demi
(compil noyau en boucle).

Et je n'ai pas tous les trucs de fou en refrodissement indiqués dans
ton URL ci-dessous...

> Si j'en crois
>
> http://forum.hardware.fr/hardwarefr/...t-236398-1.htm
>
> c'est un peu beaucoup pour un Athlon XP 3200 ?

oui.

Par contre, le lien ne fournit pratiquement que des exemples avec des
systèmes de refroidissement terribles (notamment à base de
water-cooling), ce qui donne évidemment des résultats très au-dessus
de la moyenne.

Le kit fourni par AMD lui-même (radiateur + ventilo) est très loin de
ces chiffres (proche de ce que j'ai donné plus haut; un peu moins
bon... 55°C).

N'oublie pas aussi qu'un mauvais placement de la pâte et/ou du
radiateur grève totalement les résultats...

PK

--
|\_,,,---,,_PatriceKARATCHENTZEFF
ZZZzz/,`.-'`'-.;-;;,_mailto:p.karatchentzeff@free.fr
|,4-))-,_.,\(`'-'http://p.karatchentzeff.free.fr
'---''(_/--'`-'\_)

Emmanuel Florac a écrit :

> Le Sun, 07 May 2006 11:55:23 +0200, SL a écrit :
>
>>> Ou à tout le moins, réduit sérieusement le timing des RAM dans le
>>> BIOS et refais un test.
>>
>> Je sais pas comment on fiat tout ça et je voudrais éviter.
>
> Charge les réglages "failsafe" dans le BIOS, c'est très simple.
>
>>> À moins que les erreurs ne soient dûes à une surchauffe? Tu
>>> surveilles la température de ton système en fonctionnement ?
>>
>> Ben j'ai essayé, mais je connais pas la méthode pour lui prendre des
>> températures réalistes. Voilà ce que j'ai fait : - au repos il est à
>> 46C. - après trois quatre minutes dans une boucle while 1 foo = foo +
>> 1; end il est à 58C.
>>
>> Si j'en crois
>>
>> http://forum.hardware.fr/hardwarefr/...oolingTuning/\

BDD-Temperature-fonctionnement-Intel-AMD-sujet-236398-1.htm

>> c'est un peu beaucoup pour un Athlon XP 3200 ?

Non, chez moi(tm), il faut dépasser (largement) 80° pour planter
(assez) régulièrement de façon (pseudo) aléatoire. Ceci avec des 1800
et 2600Xp (avec AMD Athlon(tm) 64 Processor 3000+, on peut couper le
ventilo). Pour la mémoire, c'est une autre histoire.

> Je ne sais pas, mais pour mon 2600+ à partir de 60° ça délire
> sévère. En tout cas ce sont des chiffres réalistes.

tu ulisises lm_sensors ?

--
| Mon 1er est bête, l' horreur si sale ou méchant, fait pitié si n' |
| est que pauvre. Mon 2ème l' est aussi, mais plutôt benêt. Mon 3ème |
| adore les trous de serrure. Mon tout, bien ciblé, achète n' importe |
| quoi, même (surtout ?) si c' est cher. ^<©>^ http://rajao.net |

Gilles-Claude Rajaobelina a écrit :
> >> c'est un peu beaucoup pour un Athlon XP 3200 ?
>
> Non, chez moi(tm), il faut dépasser (largement) 80° pour planter
> (assez) régulièrement de façon (pseudo) aléatoire. Ceci avec des 1800
> et 2600Xp (avec AMD Athlon(tm) 64 Processor 3000+, on peut couper le
> ventilo). Pour la mémoire, c'est une autre histoire.

Le fait est que cet ordi ne s'est jamais vautré pendant uen
utilisation intensive quelconque, mais toujours pendant une
utilisation intensive qui impliquait des choses bien particulières :
vidéo d'un côté et opengl via matlab de l'autre. Donc je vais changer
cette mémoire dans tous les cas foireuse (après l'avoir testée à 100)
et ce ventilateur bas de gamme, mais j'espère surtout que c'est le
remplacement de la carte vidéo premier prix qui va aider (quoique je
n'ai toujours pas compris si l'exécution d'opengl impliquait la carte
vidéo ou pas).

SL wrote:
> Emmanuel Florac a écrit :
>
>> Bon, je suppose que tu as compris que je ne voulais pas dire que le
>> matériel cher ne tombait pas en panne, hein
>
> Ben...
>
>> Mais j'ai remarqué par exemple que :
>> -les alims bas de gamme ne fournissent pas les voltages spécifiés,
>> et fluctuent. Rien de tel pour faire planter un proc.
>> -les RAM bas de gamme ne fonctionnent pas à la spécification CAS
>> inscrite dessus fiablement. Un memtest86 avec un réglage CAS agressif le
>> montre sans équivoque.
>> -les cartes mères bas de gamme ont des BIOS horriblement buggés, et des
>> bus PCI au fonctionnement aléatoire (j'ai longtemps eu mon écran qui ne
>> s'allumait qu'une fois sur 3 au démarrage du PC : problème de BIOS...)
>> -les cartes graphiques bas de gamme surchauffent et plantent.
>> -les boitiers bas de gamme sont mal ventilés, le système surchauffe et
>> plante ou pire fait des erreurs bizarres impossible à reproduire.
>
> Tiens, tout ceci décrit assez exactement mon ordinateur. Il faut
> rajouter les disques durs qui fuient et le son qui pue la
> friture. Sauf la carte mère c'est une Asus-bidule. "C'est de la
> marque" quand même ça, merde. Conclusion la prochaine fois j'irais pas
> chez un assembleur. De toute façon j'espère bien que ce sera pas un
> PC. Y'a les niagaras de Sun qui me font baver depuis un moment.
>

Il y a assembleur et assembleur. Je me rappelle d'un type qui avait
monté un atelier d'assemblage informatique dans un local de son garage
auto (mécanique), pour profiter de la manne financière que l'assemblage
créait il y a 5-6 ans. Enormément d'"assembleurs" de cette époque ont
disparu, et heureusement, cela tenait plus du charlatanisme qu'autre
chose, mais il en existe encore.

Pour moi, les bonnes solutions sont :

- Acheter de la marque, mais de la bonne, style Alienware, Apple, Sun,
IBM, HP, et éviter les sombres conneries genre Dell bas de gamme (celui
qu'on voit à la télé) et encore plus Packard-Bell et les autres
conneries qu'on trouve à Carrefour, FNAC ou autres.

- Assembler sa machine soit-même avec des composants choisis avec amour
et intelligence, après avoir un minimum économisé afin d'y mettre le
prix d'une certaine qualité.

--
Laurent

Le Mon, 08 May 2006 09:17:11 +0200, SL a écrit:

>
> J'ai marrant j'ai toujours cru que le ventilateur c'était une
> plaisanterie. Que les performances dépendent d'un système de
> refroidissement aussi primitif ça fait archaïque. Bon, je vais changer
> le ventilo aussi, sans lésiner.

Oui, c'est vraiment essentiel, un ventilateur grillé est une cause
fréquente de grosse panne...

--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.

Le Mon, 08 May 2006 12:21:42 +0200, Gilles-Claude Rajaobelina a écrit:

>
> > Je ne sais pas, mais pour mon 2600+ à partir de 60° ça délire
> > sévère. En tout cas ce sont des chiffres réalistes.
>
> tu ulisises lm_sensors ?

Oui, bien sûr.

--
Il y a toujours un bug de plus.
Loi de Lubarsky.

Le Mon, 08 May 2006 14:12:50 +0200, SL a écrit:

> (quoique je
> n'ai toujours pas compris si l'exécution d'opengl impliquait la carte
> vidéo ou pas).

Forcément, après ça dépend si tu utilises un pilote accéléré ou
pas. Les cartes récentes ne fonctionnent qu'avec un driver proprio en
accélération 3D, et les BLOBs sont connus pour être de sacrés nids de
bugs.

--
L'église est une secte qui a réussi.
Ernest Renan.

On Sat, 6 May 2006, JKB wrote:

> Montre-moi un seul de tes programmes écrit en C, que je le critique.
> Je ne connais pas beaucoup de personnes qui récupèrent les codes
> renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
> simple fprintf()). Le simple fait qu'un truc comme :
>
> fprintf(fp, "%s\n", chaine);

Ben non. Autant le retour de malloc() est intéressant à tous les coups à
récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
nombre de caractères imprimés n'est pas souvent très intéressant à
connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.

> compile est une absurdité. fprintf renvoie un int et non un void !
> Lorsqu'on travaille sur des programmes complexes de plusieurs
> centaines de milliers de lignes de codes en C et qu'on essaye de
> tracer un segfault aléatoires sur un tel problème, on peste et on y
> passe du temps.

.... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.

> Personnellement, j'ai rarement ouvert un debugger en ADA, très
> rarement en Fortran,

Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Ainsi Parlait Gilles-Claude Rajaobelina <gilles.rajaobelina@free.fr>
> > J'y comprends rien à c'est quoi que vous voulez dire.
> Normal.

Quelqu'un à un titre à proposer pour le GNU ?

--
Franck Yvonnet <fyvonnet@gmail.com>
"Are you sure that a floor cannot also be a ceiling? Are you absolutely
certain that you go up when you walk up a staircase?"
- M.C. Esher

On Sat, 6 May 2006, Emmanuel Florac wrote:

> Le Sat, 06 May 2006 11:14:26 +0000, JKB a écrit:
>
>> Mais il a un seul défaut... Lorsqu'on parle ADA ou Fortran, on passe
>> toujours pour des vieux schoques. Les langages en question ont beau
>> être très bien ficelés, il devient très difficile de trouver un bon
>> programmeur Fortran ou ADA, alors que des bidouilleurs C, C++, C# et
>> java, on en trouve à la pelle !
>
> Tu retardes. Aujourd'hui les jeunes apprennent C# et PHP. Java, un peu,
> mais c'est dépassé dans l'esprit de beaucoup. C, ils en ont vaguement
> fait; C++, c'est strictement réservé aux vieux schnoques, plus personne
> n'apprend ça depuis 10 ans.
>

On va prendre ça pour de l'humour. :-)
J'ai appris le C, un peu de C++, Java, et quelques menus autres langages
en IUT. Ceux qui ne faisaient pas de Java avaient droit à du COBOL.

C'était il y a quatre ans.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

On Sat, 6 May 2006, Michel Talon wrote:

> Ce qui est d'ailleurs typique des élucubrations françaises, que ce soit
> Ada, ou Eiffel ou Caml. Il y a une tradition de bateleurs de foire chez
> nous, où on t'explique qu'un langage va tout révolutionner, faire qu'un
> programme ne sera jamais faux, qu'on travaillera 10 fois plus vite et
> avec 10 fois moins de lignes, qu'on pourra prouver l'exactitude du
> programme et toutes autres poudres de perlinpinpin et huiles de serpent.

C'est un peu vrai. :-)
D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et
tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur
de type avec un programme "stuck" à cause de ça. Et c'est franchement un
mieux par rapport à C.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
> On Sat, 6 May 2006, JKB wrote:
>
>> Montre-moi un seul de tes programmes écrit en C, que je le critique.
>> Je ne connais pas beaucoup de personnes qui récupèrent les codes
>> renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
>> simple fprintf()). Le simple fait qu'un truc comme :
>>
>> fprintf(fp, "%s\n", chaine);
>
> Ben non. Autant le retour de malloc() est intéressant à tous les coups à
> récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
> nombre de caractères imprimés n'est pas souvent très intéressant à
> connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
> d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
> vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.

C'est un simple exemple. Maintenant, dans certains programmes, il
est utile de savoir par exemple que tout ce qu'on voulait écrire
dans un fichier a bien été écrit.

>> compile est une absurdité. fprintf renvoie un int et non un void !
>> Lorsqu'on travaille sur des programmes complexes de plusieurs
>> centaines de milliers de lignes de codes en C et qu'on essaye de
>> tracer un segfault aléatoires sur un tel problème, on peste et on y
>> passe du temps.
>
> ... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.

Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
fichier à cause d'un bug bien avant dans le programme en question et
lorsqu'on essaye de relire, le truc se casse la figure.

>> Personnellement, j'ai rarement ouvert un debugger en ADA, très
>> rarement en Fortran,
>
> Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
> Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
> reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
> FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...

Autant entre F66 et F77, je suis d'accord, mais la syntaxe du F77
est très bien fichue. Bien au contraire, F90 (et les 95 et 2003)
apportent plein de trucs permettant à un programme de devenir
illisible.

JKB

On Tue, 9 May 2006, JKB wrote:

> Le 09-05-2006, à propos de
> Re: language,
> Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
>> On Sat, 6 May 2006, JKB wrote:
>>
>>> Montre-moi un seul de tes programmes écrit en C, que je le critique.
>>> Je ne connais pas beaucoup de personnes qui récupèrent les codes
>>> renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
>>> simple fprintf()). Le simple fait qu'un truc comme :
>>>
>>> fprintf(fp, "%s\n", chaine);
>>
>> Ben non. Autant le retour de malloc() est intéressant à tous les coups à
>> récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
>> nombre de caractères imprimés n'est pas souvent très intéressant à
>> connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
>> d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
>> vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
>
> C'est un simple exemple. Maintenant, dans certains programmes, il
> est utile de savoir par exemple que tout ce qu'on voulait écrire
> dans un fichier a bien été écrit.

Bien sûr. Mais bon, si l'on est un minimum sérieux pour faire du C, on lit
la FAQ de clc ou fclc, et on apprend tout un tas de trucs intéressants,
voire on pose des questions là-bas, on se fait un peu maltraiter au début
parce qu'on a oublié de vérifier le retour des fonctions (et généralement
c'est signalé par le compilateur...), puis on progresse.

>> ... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
>
> Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
> fichier à cause d'un bug bien avant dans le programme en question et
> lorsqu'on essaye de relire, le truc se casse la figure.

Nous sommes donc d'accord : ce n'est pas exactement la faute au printf,
mais à un bug plus en amont. C'est ce que je voulais dire : un printf qui
"plante" un programme n'est généralement que le symptôme.

>> Pardon ? ADA je veux bien te croire, je ne connais pas du tout le langage.
>> Mais FORTRAN, j'ai plus de mal à le croire... D'autant plus que ce que je
>> reproche aux programmeurs FORTRAN, c'est de toujours vouloir utiliser
>> FORTRAN 77, et pas F90, qui améliore quand même pas mal de choses ...
>
> Autant entre F66 et F77, je suis d'accord, mais la syntaxe du F77
> est très bien fichue. Bien au contraire, F90 (et les 95 et 2003)
> apportent plein de trucs permettant à un programme de devenir
> illisible.
>

Parce que tout un tas de mécanismes "modernes" (pas pour des vieux
schnoques, donc :-) ) y font leur apparition, rendant le langage bien plus
complexe. On n'a rien sans rien.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Michel Talon a écrit :

> J'ai une machine qui a des problèmes de mémoire comme ça, je lui ai
> dit dans le bios de tourner à 100Mhz au lieu de 133, depuis plus de
> problème. Avant elle n'arrivait même pas à booter.

Pas de problème pendant 9h30 de test sur la mémoire en 100Mhz, mais je
vais recommencer sur 24h.

Le 09-05-2006, à propos de
Re: language,
Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
> On Tue, 9 May 2006, JKB wrote:
>
>> Le 09-05-2006, à propos de
>> Re: language,
>> Stéphane Zuckerman écrivait dans fr.comp.os.linux.debats :
>>> On Sat, 6 May 2006, JKB wrote:
>>>
>>>> Montre-moi un seul de tes programmes écrit en C, que je le critique.
>>>> Je ne connais pas beaucoup de personnes qui récupèrent les codes
>>>> renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
>>>> simple fprintf()). Le simple fait qu'un truc comme :
>>>>
>>>> fprintf(fp, "%s\n", chaine);
>>>
>>> Ben non. Autant le retour de malloc() est intéressant à tous les coups à
>>> récupérer ("j'ai réussi/j'ai échoué dans mon alloc"), autant connaître le
>>> nombre de caractères imprimés n'est pas souvent très intéressant à
>>> connaître... Il peut y avoir une erreur bien sûr, mais ce sera une erreur
>>> d'affichage. Alors mis à part pour faire décoller des fusées ;-), je ne
>>> vois pas trop l'intérêt de récupérer la sortie de {f|sn|vsn}printf.
>>
>> C'est un simple exemple. Maintenant, dans certains programmes, il
>> est utile de savoir par exemple que tout ce qu'on voulait écrire
>> dans un fichier a bien été écrit.
>
> Bien sûr. Mais bon, si l'on est un minimum sérieux pour faire du C, on lit
> la FAQ de clc ou fclc, et on apprend tout un tas de trucs intéressants,
> voire on pose des questions là-bas, on se fait un peu maltraiter au début
> parce qu'on a oublié de vérifier le retour des fonctions (et généralement
> c'est signalé par le compilateur...), puis on progresse.

Je n'ai _jamais_ vu un compilo râler sérieusement parce qu'on ne
vérifie pas le retour d'une fonction du style fscanf (et encore
moins râler parce qu'on ne regarde pas le errno juste après).

>>> ... mais pas à cause d'un printf dont on n'a pas récupéré la sortie.
>>
>> Et si... Ça m'est déjà arrivé. On écrit un truc, mal écrit dans un
>> fichier à cause d'un bug bien avant dans le programme en question et
>> lorsqu'on essaye de relire, le truc se casse la figure.
>
> Nous sommes donc d'accord : ce n'est pas exactement la faute au printf,
> mais à un bug plus en amont. C'est ce que je voulais dire : un printf qui
> "plante" un programme n'est généralement que le symptôme.

Et si le compilo interdisait d'utiliser une telle fonction sans _au
moins_ que l'utilisateur récupère l'entier en question ?

JKB

JKB , dans le message <slrne60qos.d82.knatschke@rayleigh.systella.fr>, a
écrit:
> Je n'ai _jamais_ vu un compilo râler sérieusement parce qu'on ne
> vérifie pas le retour d'une fonction du style fscanf (et encore
> moins râler parce qu'on ne regarde pas le errno juste après).

Les compilateurs qui râlent quand on ne vérifie pas les retours d'erreur,
c'est l'exemple typique de la fausse bonne idée. Un exemple marquant est les
exceptions en java: on est obligé de les rattraper même quand on est
structurellement sûr qu'elles ne peuvent pas se produire, juste pour les
ignorer et faire taire le compilateur. Ce qui fait que le jour où
l'exception se produit réellement de manière non-prévue, non seulement le
programme n'est pas prêt, mais en plus elle est silencieusement ignorée et
propage des résultats aberrants. C'est pire que le départ.

À croire que certains concepteurs de langages n'ont jamais entendu
l'histoire de Pierre et le loup.

Le 09-05-2006, à propos de
Re: language,
Nicolas George écrivait dans fr.comp.os.linux.debats :
> JKB , dans le message <slrne60qos.d82.knatschke@rayleigh.systella.fr>, a
> écrit:
>> Je n'ai _jamais_ vu un compilo râler sérieusement parce qu'on ne
>> vérifie pas le retour d'une fonction du style fscanf (et encore
>> moins râler parce qu'on ne regarde pas le errno juste après).
>
> Les compilateurs qui râlent quand on ne vérifie pas les retours d'erreur,
> c'est l'exemple typique de la fausse bonne idée. Un exemple marquant est les
> exceptions en java: on est obligé de les rattraper même quand on est
> structurellement sûr qu'elles ne peuvent pas se produire, juste pour les
> ignorer et faire taire le compilateur. Ce qui fait que le jour où
> l'exception se produit réellement de manière non-prévue, non seulement le
> programme n'est pas prêt, mais en plus elle est silencieusement ignorée et
> propage des résultats aberrants. C'est pire que le départ.
>
> À croire que certains concepteurs de langages n'ont jamais entendu
> l'histoire de Pierre et le loup.

Je maintiens qu'un compilo devrait râler sans vergogne contre ce
genre de trucs quitte à avoir une option pour ignorer ces erreurs
lorsqu'on sait _exactement_ ce que l'on fait.

JKB

Stéphane Zuckerman , dans le message
<Pine.OSF.4.64.0605091018190.365039@vega.utc.fr> , a écrit:
> D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et
> tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur
> de type avec un programme "stuck" à cause de ça. Et c'est franchement un
> mieux par rapport à C.

À condition de parler de java 1.5, et le programmer de manière incompatible
avec les versions précédentes, et de n'utiliser que des bibliothèques
prévues en conséquence. Là, on commence à avoir quelque chose de vaguement
prévisible statiquement. Sinon, ce qui est le cas de l'immense majorité des
développeurs java, on a des casts vers et depuis Object, c'est exactement le
même niveau de fiabilité que le C, la seule différence est l'aspect de la
sanction en cas d'erreur.

JKB , dans le message <slrne60s81.d82.knatschke@rayleigh.systella.fr>, a
écrit:
> Je maintiens qu'un compilo devrait râler sans vergogne contre ce
> genre de trucs quitte à avoir une option pour ignorer ces erreurs
> lorsqu'on sait _exactement_ ce que l'on fait.

Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup
d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.

Il n'y a pas à en sortir: un compilateur ne peut pas comprendre un
programme de manière suffisante pour déterminer dans quel cas les tests sont
nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout
ce qui reste ce sont des heuristiques.

Ce que je dis, c'est que quand ces heuristiques ne disent pas que le test
est nécessaire de manière _très_ fiable, il vaut mieux ne rien mettre, parce
que les structures pour juste faire taire le compilo sont très souvent
largement pires que les erreurs elles-mêmes.

Nicolas George a écrit :

> on est obligé de les rattraper même quand on est structurellement
> sûr qu'elles ne peuvent pas se produire, juste pour les ignorer

[...]

> Ce qui fait que le jour où l'exception se produit réellement de
> manière non-prévue,

On avait donc tort d'être "structurellement sûr" (il n'y a que vous
pour être structurement sûr :-)) qu'elles ne peuvent pas se produire,
puisque de fait, elles se produisent, non ?

> non seulement le programme n'est pas prêt, mais en plus elle est
> silencieusement ignorée et propage des résultats aberrants. C'est
> pire que le départ.

C'est effectivemetn pire que le départ *si* on "ignore
silencieusement" des exceptions (j'imagine que ça veut dire mettre un
catch vide par exemple), mais ne suffit-il pas de ne *jamais* le faire
et de toujours avoir une politique pour traiter les exceptions
déclarées comme pouvant se produire, même si on est "sûr" qu'elles ne
peuvent pas se produire ?

SL , dans le message <u1wv3mq0l.fsf@nospam.com>, a écrit:
> On avait donc tort d'être "structurellement sûr" (il n'y a que vous
> pour être structurement sûr :-)) qu'elles ne peuvent pas se produire,
> puisque de fait, elles se produisent, non ?

Évidemment.

> C'est effectivemetn pire que le départ *si* on "ignore
> silencieusement" des exceptions (j'imagine que ça veut dire mettre un
> catch vide par exemple), mais ne suffit-il pas de ne *jamais* le faire
> et de toujours avoir une politique pour traiter les exceptions
> déclarées comme pouvant se produire, même si on est "sûr" qu'elles ne
> peuvent pas se produire ?

C'est contraire au principe d'une exception: le principe des exceptions,
c'est qu'il ne faut la traiter que quand elle est pertinente, et que dans
tous les autres cas, elle court-circuite le flot normal du code, de sorte
que son traitement s'hérite suivant la structure dynamique du programme.

Ainsi, la politique que tu évoques peut -- et doit -- être mise en place au
plus haut niveau du programme, et agit en permanence sur toutes les
exceptions non traitées. C'est un fonctionnement sain et intelligent.

Les exceptions déclarées mettent en échec ce principe, justement en
obligeant une gestion locale des exceptions.

Nicolas George a écrit :
> Stéphane Zuckerman , dans le message
> <Pine.OSF.4.64.0605091018190.365039@vega.utc.fr> , a écrit:
>> D'un autre côté, Java est prouvé pour les types (y'a du lambda calcul et
>> tout le toutim pour le faire), ce qui fait qu'il n'y aura jamais d'erreur
>> de type avec un programme "stuck" à cause de ça. Et c'est franchement un
>> mieux par rapport à C.
>
> À condition de parler de java 1.5, et le programmer de manière incompatible
> avec les versions précédentes,

Je trouve complètement ahurissant le niveau d'incompatibilité entre
java 5 et java 1.4. Même quelque chose d'aussi incroyablement trivial
que récupérer la valeur d'une variable d'environnement ne *peut pas*
être fait de la même façon en java 1.4 et 5, où alors je suis
complètement à la masse. Il faut utiliser System.getenv() qui est
remis en java 5 mais qui est deprecated en java 1.4, et qui fait se
plaindre le compilateur.

Je ne parle pas le l'emmerdement absolument démentiel que produit
l'inclusion de jaxp dans la distribution standard, ce qui fait que
depuis les factory il est impossible de contrôler les processeurs XML
retournés, alors qu'ils sont parfois incompatibles. Je m'arrache les
cheveux là dessus.

Le 09-05-2006, à propos de
Re: language,
Nicolas George écrivait dans fr.comp.os.linux.debats :
> JKB , dans le message <slrne60s81.d82.knatschke@rayleigh.systella.fr>, a
> écrit:
>> Je maintiens qu'un compilo devrait râler sans vergogne contre ce
>> genre de trucs quitte à avoir une option pour ignorer ces erreurs
>> lorsqu'on sait _exactement_ ce que l'on fait.
>
> Ce qui fait qu'on se retrouve à mettre activer cette option à beaucoup
> d'endroits, et tôt ou tard on finit par la mettre à mauvais escient.
>
> Il n'y a pas à en sortir: un compilateur ne peut pas comprendre un
> programme de manière suffisante pour déterminer dans quel cas les tests sont
> nécessaires et dans quels cas ils sont superflus. Dans ces conditions, tout
> ce qui reste ce sont des heuristiques.

Une fonction qui retourne un int qui n'est pas récupéré par
l'appelant _doit_ être signalée. Si on veut un tel truc, on
introduit des paramètres optionnels façon Fortran et on n'en parle
plus. Une fonction retourne quelque chose ou ne retourne rien.

JKB

Nicolas George a écrit :
> SL , dans le message <u1wv3mq0l.fsf@nospam.com>, a écrit:
>> On avait donc tort d'être "structurellement sûr" (il n'y a que vous
>> pour être structurement sûr :-)) qu'elles ne peuvent pas se produire,
>> puisque de fait, elles se produisent, non ?
>
> Évidemment.
>
>> C'est effectivemetn pire que le départ *si* on "ignore
>> silencieusement" des exceptions (j'imagine que ça veut dire mettre
>> un catch vide par exemple), mais ne suffit-il pas de ne *jamais* le
>> faire et de toujours avoir une politique pour traiter les
>> exceptions déclarées comme pouvant se produire, même si on est
>> "sûr" qu'elles ne peuvent pas se produire ?
>
> C'est contraire au principe d'une exception: le principe des
> exceptions, c'est qu'il ne faut la traiter que quand elle est
> pertinente, et que dans tous les autres cas, elle court-circuite le
> flot normal du code, de sorte que son traitement s'hérite suivant la
> structure dynamique du programme.

"Court circuiter", d'après ce que je lis plus bas, c'est "être une
exception descendant de java.lang.RuntimeException" et non "être
propagée à l'appelant avec un 'throws' dans la signature de la
méthode" ?

Pourquoi est-ce que le "principe" des exceptions non descendantes de
java.lang.RuntimeException est mauvais ? Il consiste finalement à dire
que ce n'est pas l'utilisateur de la classe qui decide si l'exception
est "pertinente", mais son concepteur : d'une certaine façon, si je
comprends bien la logique, la politique de traitement des exceptions
(le fait de la décider pertinente ou pas) est définis dans l'API, pas
dans son utilisation. En quoi ce n'est pas défendable ?

J'avoue qu'il m'arrive de changer une exception "checkée" en exception
"non checkée", particulièrement en ayant recours au sympathique
IllegalArgumentException ou IllegalStateException, de façon à faire
remonter sans emmerdements une exception d'une couche basse à une
couche haute à travers une couche intermédiaire, de la récupérer dans
la couche haute et de la retransformer en exception "checkée". Je sais
pas si c'est défendable.

> Ainsi, la politique que tu évoques peut -- et doit -- être mise en
> place au plus haut niveau du programme, et agit en permanence sur
> toutes les exceptions non traitées.

Oui, c'est une sécurité super. J'ai en effet tout en haut du programme
un nombre incroyable de catch, et même des try les uns dans les autres
pour utiliser les bons finally. Le finally, au passage, implique il me
semble pour être utile de traiter toujours les exceptions.

> Les exceptions déclarées mettent en échec ce principe, justement en
> obligeant une gestion locale des exceptions.

On peut se contenter de récupérer une exception locale reçu d'une
couche basse, et de lancer une autre exception, d'un autre type,
spéciale à la couche supérieure. Il y a même le sympatique mécanisme
iniCause() qui permet de ne pas effacer la mémoire de l'exception.

JKB , dans le message <slrne60tui.d82.knatschke@rayleigh.systella.fr>, a