je viens d'installer Mandriva 2007 sur un portable acer TM230
Probleme :
le systeme arrete pour un soucis de temperature critique 77°
Bon je fais un tour sur google et je vois qu'il faut faire un acpi=off
au boot.
Mais là un autre probleme apparait : Kernel Panic
Bon ben je me dis que la migration vers linux commence bien :o(
Effectivement, je pense que les templates sont une monstruosité en C++, et les avoir introduit (même sous une forme atténuée) en Java pour copier le C# une erreur grossière.
Je ne pense pas que les génériques de java puissent se comparer aux templates du c++. C'est au contraire quelque chose de très naturel. Avant, si tu voulais faire une liste chaînée de String et une autre d'Integer, il fallait faire attention à ne pas ajouter un Integer à la première et un String à la seconde, et utiliser un cast quand on lit les objets. Avec les génériques, on n'a plus deux LinkedList tout court, on a une LinkedList de String et une LinkedList d'Integer.
cela n'apporte pas grand chose
Le compilateur va vérifier, à la compilation, qu'on ajoute des éléments du bon type, et à la lecture, les éléments auront directement le bon type. C'était déjà le cas pour les tableaux, ça devient vrai pour le reste.
C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus besoin d'écrire explicitement les génériques, et de laisser le compilateur déterminer le type des objets, et vérifier qu'il est utilisé de manière cohérente partout dans le programme. perso je trouve que cela alourdi le code
et en plus tu vas en trouver un peu partout parce que les generiques vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
je suis clair -- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Michel Talon, dans le message <eniknj$1jfv$3@asmodee.lpthe.jussieu.fr>,
Effectivement, je pense que les templates sont une monstruosité en C++,
et les avoir introduit (même sous une forme atténuée) en Java pour
copier le C# une erreur grossière.
Je ne pense pas que les génériques de java puissent se comparer aux
templates du c++. C'est au contraire quelque chose de très naturel. Avant,
si tu voulais faire une liste chaînée de String et une autre d'Integer, il
fallait faire attention à ne pas ajouter un Integer à la première et un
String à la seconde, et utiliser un cast quand on lit les objets. Avec les
génériques, on n'a plus deux LinkedList tout court, on a une LinkedList de
String et une LinkedList d'Integer.
cela n'apporte pas grand chose
Le compilateur va vérifier, à la compilation, qu'on ajoute des éléments du
bon type, et à la lecture, les éléments auront directement le bon type.
C'était déjà le cas pour les tableaux, ça devient vrai pour le reste.
C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus
besoin d'écrire explicitement les génériques, et de laisser le compilateur
déterminer le type des objets, et vérifier qu'il est utilisé de manière
cohérente partout dans le programme.
perso je trouve que cela alourdi le code
et en plus tu vas en trouver un peu partout parce que les generiques
vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
je suis clair
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
la preuve http://remyaumeunier.chez-alice.fr/
remy
Effectivement, je pense que les templates sont une monstruosité en C++, et les avoir introduit (même sous une forme atténuée) en Java pour copier le C# une erreur grossière.
Je ne pense pas que les génériques de java puissent se comparer aux templates du c++. C'est au contraire quelque chose de très naturel. Avant, si tu voulais faire une liste chaînée de String et une autre d'Integer, il fallait faire attention à ne pas ajouter un Integer à la première et un String à la seconde, et utiliser un cast quand on lit les objets. Avec les génériques, on n'a plus deux LinkedList tout court, on a une LinkedList de String et une LinkedList d'Integer.
cela n'apporte pas grand chose
Le compilateur va vérifier, à la compilation, qu'on ajoute des éléments du bon type, et à la lecture, les éléments auront directement le bon type. C'était déjà le cas pour les tableaux, ça devient vrai pour le reste.
C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus besoin d'écrire explicitement les génériques, et de laisser le compilateur déterminer le type des objets, et vérifier qu'il est utilisé de manière cohérente partout dans le programme. perso je trouve que cela alourdi le code
et en plus tu vas en trouver un peu partout parce que les generiques vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
je suis clair -- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Nicolas George
remy , dans le message <eninld$92b$, a écrit :
perso je trouve que cela alourdi le code et en plus tu vas en trouver un peu partout parce que les generiques vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
Au contraire, ça allège le code, puisque ça élimine quantité de casts inutiles, et que ça place l'indication de type toute au même endroit.
je suis clair
Non.
remy , dans le message <eninld$92b$1@s1.news.oleane.net>, a écrit :
perso je trouve que cela alourdi le code
et en plus tu vas en trouver un peu partout parce que les generiques
vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
Au contraire, ça allège le code, puisque ça élimine quantité de casts
inutiles, et que ça place l'indication de type toute au même endroit.
perso je trouve que cela alourdi le code et en plus tu vas en trouver un peu partout parce que les generiques vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
Au contraire, ça allège le code, puisque ça élimine quantité de casts inutiles, et que ça place l'indication de type toute au même endroit.
je suis clair
Non.
remy
perso je trouve que cela alourdi le code et en plus tu vas en trouver un peu partout parce que les generiques vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
Au contraire, ça allège le code, puisque ça élimine quantité de casts inutiles, et que ça place l'indication de type toute au même endroit.
je suis clair
Non.
un exemple
pas claire mais simple
{ int, int => int } plus = { int a, int b => a + b };
le meme plus claire et toujours aussi simple
interface Closure1 { public int invoke(int i, int b); }
Closure1 plus = new Closure1() { public int invoke(int i, int b) { return a + b; } };
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
perso je trouve que cela alourdi le code
et en plus tu vas en trouver un peu partout parce que les generiques
vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
Au contraire, ça allège le code, puisque ça élimine quantité de casts
inutiles, et que ça place l'indication de type toute au même endroit.
je suis clair
Non.
un exemple
pas claire mais simple
{ int, int => int } plus = { int a, int b => a + b };
le meme plus claire et toujours aussi simple
interface Closure1 {
public int invoke(int i, int b);
}
Closure1 plus = new Closure1() {
public int invoke(int i, int b) {
return a + b;
}
};
perso je trouve que cela alourdi le code et en plus tu vas en trouver un peu partout parce que les generiques vont se specialiser et vont se transformer en generique specifique
a l'arrivee tu ne comprends plus rien
Au contraire, ça allège le code, puisque ça élimine quantité de casts inutiles, et que ça place l'indication de type toute au même endroit.
je suis clair
Non.
un exemple
pas claire mais simple
{ int, int => int } plus = { int a, int b => a + b };
le meme plus claire et toujours aussi simple
interface Closure1 { public int invoke(int i, int b); }
Closure1 plus = new Closure1() { public int invoke(int i, int b) { return a + b; } };
C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus besoin d'écrire explicitement les génériques, et de laisser le compilateur déterminer le type des objets, et vérifier qu'il est utilisé de manière cohérente partout dans le programme.
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité. En fait , à mon avis, toutes ces vérifications à la compilation sont totalement inutiles, et n'ont jamais garanti la correction d'un programme. Par contre, vérifier automatiquement à l'exécution la cohérence des types est faisable, c'est ce que fait python. Ca permet d'avoir une syntaxe réduite à l'ensemble vide, et d'offrir au moins autant de garanties de correction du programme.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus
besoin d'écrire explicitement les génériques, et de laisser le compilateur
déterminer le type des objets, et vérifier qu'il est utilisé de manière
cohérente partout dans le programme.
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
En fait , à mon avis, toutes ces vérifications à la compilation sont
totalement inutiles, et n'ont jamais garanti la correction d'un
programme. Par contre, vérifier automatiquement à l'exécution la
cohérence des types est faisable, c'est ce que fait python. Ca permet
d'avoir une syntaxe réduite à l'ensemble vide, et d'offrir au moins
autant de garanties de correction du programme.
C'est un pas dans le bon sens. Le pas suivant, c'est qu'il n'y ait plus besoin d'écrire explicitement les génériques, et de laisser le compilateur déterminer le type des objets, et vérifier qu'il est utilisé de manière cohérente partout dans le programme.
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité. En fait , à mon avis, toutes ces vérifications à la compilation sont totalement inutiles, et n'ont jamais garanti la correction d'un programme. Par contre, vérifier automatiquement à l'exécution la cohérence des types est faisable, c'est ce que fait python. Ca permet d'avoir une syntaxe réduite à l'ensemble vide, et d'offrir au moins autant de garanties de correction du programme.
--
Michel TALON
Nicolas George
remy , dans le message <enj02g$d8v$, a écrit :
mais bon entre la class objet plus des transtipage
ou creer une class pour chaque type utilise
Et justement, les génériques, ça permet de n'avoir ni l'un ni l'autre.
ok c'est un peu plus long a l'execution mais de si peu
C'est surtout beaucoup moins fiable.
remy , dans le message <enj02g$d8v$1@s1.news.oleane.net>, a écrit :
mais bon entre la class objet plus des transtipage
ou creer une class pour chaque type utilise
Et justement, les génériques, ça permet de n'avoir ni l'un ni l'autre.
ok c'est un peu plus long a l'execution mais de si peu
ok c'est un peu plus long a l'execution mais de si peu
C'est surtout beaucoup moins fiable.
pipo
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception la preuve http://remyaumeunier.chez-alice.fr/ remy
Nicolas George
Michel Talon, dans le message <enivg0$1n1o$, a écrit :
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
Ah, alors pourquoi dis-tu exactement le contraire juste en dessous ?
En fait , à mon avis, toutes ces vérifications à la compilation sont totalement inutiles, et n'ont jamais garanti la correction d'un programme.
Ce n'est pas parfait donc ça ne sert à rien ? C'est bancal, comme position.
RIEN ne garantit la correction d'un programme. Mais certaines classes de bugs sont fréquentes, et faciles à détecter. Un outil qui les détecte avec un bon rapport (bugs détectés) / (emmerdement du programmeur) est toujours bon à prendre. Et justement, la détection des erreurs de type, ça a un excellent rapport.
Par contre, vérifier automatiquement à l'exécution la cohérence des types est faisable, c'est ce que fait python. Ca permet d'avoir une syntaxe réduite à l'ensemble vide,
Détecter les erreurs de type à la compilation sans syntaxe, ça se fait très bien.
et d'offrir au moins autant de garanties de correction du programme.
Non, les garanties ne sont pas aussi fortes. Plus exactement, la détection à la compilation trouve les erreurs plus tôt. Imagine un programme qui vient de faire un calcul pendant dix minutes / deux heures / deux semaines, et qui se plante au moment d'afficher le résultat parce qu'on a mis une variable à la place d'une autre. Eh bien si le problème est une erreur de type, alors un outil qui fait la vérification à la compilation t'aurait fait gagner dix minutes / deux heures / deux semaines. Tu trouves que ça ne vaut pas le coût ?
Sans compter, évidemment, que quand la vérification de type est faite à la compilation, certaines optimisations deviennent possibles qui peuvent faire gagner une vitesse considérable.
Michel Talon, dans le message <enivg0$1n1o$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
Ah, alors pourquoi dis-tu exactement le contraire juste en dessous ?
En fait , à mon avis, toutes ces vérifications à la compilation sont
totalement inutiles, et n'ont jamais garanti la correction d'un
programme.
Ce n'est pas parfait donc ça ne sert à rien ? C'est bancal, comme position.
RIEN ne garantit la correction d'un programme. Mais certaines classes de
bugs sont fréquentes, et faciles à détecter. Un outil qui les détecte avec
un bon rapport (bugs détectés) / (emmerdement du programmeur) est toujours
bon à prendre. Et justement, la détection des erreurs de type, ça a un
excellent rapport.
Par contre, vérifier automatiquement à l'exécution la
cohérence des types est faisable, c'est ce que fait python. Ca permet
d'avoir une syntaxe réduite à l'ensemble vide,
Détecter les erreurs de type à la compilation sans syntaxe, ça se fait très
bien.
et d'offrir au moins
autant de garanties de correction du programme.
Non, les garanties ne sont pas aussi fortes. Plus exactement, la détection à
la compilation trouve les erreurs plus tôt. Imagine un programme qui vient
de faire un calcul pendant dix minutes / deux heures / deux semaines, et qui
se plante au moment d'afficher le résultat parce qu'on a mis une variable à
la place d'une autre. Eh bien si le problème est une erreur de type, alors
un outil qui fait la vérification à la compilation t'aurait fait gagner dix
minutes / deux heures / deux semaines. Tu trouves que ça ne vaut pas le
coût ?
Sans compter, évidemment, que quand la vérification de type est faite à la
compilation, certaines optimisations deviennent possibles qui peuvent faire
gagner une vitesse considérable.
Michel Talon, dans le message <enivg0$1n1o$, a écrit :
Je suis d'accord avec ce que tu dis, encore plus avec l'automaticité.
Ah, alors pourquoi dis-tu exactement le contraire juste en dessous ?
En fait , à mon avis, toutes ces vérifications à la compilation sont totalement inutiles, et n'ont jamais garanti la correction d'un programme.
Ce n'est pas parfait donc ça ne sert à rien ? C'est bancal, comme position.
RIEN ne garantit la correction d'un programme. Mais certaines classes de bugs sont fréquentes, et faciles à détecter. Un outil qui les détecte avec un bon rapport (bugs détectés) / (emmerdement du programmeur) est toujours bon à prendre. Et justement, la détection des erreurs de type, ça a un excellent rapport.
Par contre, vérifier automatiquement à l'exécution la cohérence des types est faisable, c'est ce que fait python. Ca permet d'avoir une syntaxe réduite à l'ensemble vide,
Détecter les erreurs de type à la compilation sans syntaxe, ça se fait très bien.
et d'offrir au moins autant de garanties de correction du programme.
Non, les garanties ne sont pas aussi fortes. Plus exactement, la détection à la compilation trouve les erreurs plus tôt. Imagine un programme qui vient de faire un calcul pendant dix minutes / deux heures / deux semaines, et qui se plante au moment d'afficher le résultat parce qu'on a mis une variable à la place d'une autre. Eh bien si le problème est une erreur de type, alors un outil qui fait la vérification à la compilation t'aurait fait gagner dix minutes / deux heures / deux semaines. Tu trouves que ça ne vaut pas le coût ?
Sans compter, évidemment, que quand la vérification de type est faite à la compilation, certaines optimisations deviennent possibles qui peuvent faire gagner une vitesse considérable.
Nicolas George
remy , dans le message <enj0i0$dbj$, a écrit :
c'est quoi la différences ?
Qu'il n'y aura pas de casts.
pipo
Reviens quand tu sauras de quoi tu parles.
remy , dans le message <enj0i0$dbj$1@s1.news.oleane.net>, a écrit :
