C'est vrai que LaTeX c'est la maitrise total pour la production de doc... enfin bon, moi ca ma toujours donné l'impression d'ecrire du rtf a la main... signe que je maitrise pas la doc non plus ...snif
meme clippy le maitrise pas, le premier truc que fait un utilisateur un peu experimenté, c'est de désactiver cette nuisance .... et il n'existe personne qui maitrise word, car dès que quelqu'un commence a vraiment connaitre word en genéral il install Open Office pour preserver sa santé mental :-)
ca a l'air pas mal tout ca ... en cluster ca doit permettre de calculer des sequences d'images de synthèse assez sympat ...
Par contre je me vois toujours pas utiliser une télé comme ecrant...
Moi c'est pas tellement la ram que je trouve limitant ... c'est qu'une game cube ca se connecte sur une Tele non ? C'est pas un peu limite niveau resolution? En fait j'aurais plus compris qu'ils essayent de faire des clusters de gamecubes ...
Posté par chaostech .
En réponse au sondage Je suis.
Évalué à 1.
nan, y dis qu'il pisse du code... y doit etre sous-traitant, tu sais les trucs que les grosses boîtes achetent pour leurs ordinateurs.
Pour qu'il puisse voter, il faudrait ajouter "[ ] peripherique" ;-)
Au fin fond d'une regie on ne vous entendra pas hurler...
oui, mes neuneu sont des developpeurs ... ca fout la trouille hein ... en fait ils ne meritent pas trop l'appelation de developpeur ...
bugger serait plus addapté, comme l'inverse de debugger ... et regardes sur un dico anglais ce que ca veut exactement dire et tu sauras ce que je pense de mes neuneu ...
Sinon, on filtre les commit et c'est vraie que ca limite bien les problèmes, mais personne n'est designé pour vérifier que les modifications faites par les autres sont valides...
Et c'est quoi les vieux opcodes qu'ils ont enlevé ? Parceque dans le volume 1 du manuel de programmation AMD64 y'a ecrit "The AMD64 architecture supports the full legacy x86 instruction set" et j'ai rien vu parlant d'opcode enlevé, par contre certain mnemonique ne sont plus gérés de la meme manière (inc et dec pour ce que j'en ai vu).
Sinon pour les nouveau opcode c'est clair qu'il y en a pas mal de nouveaux, mais quand je parlais de compatibilité, c'etait compatibilité ascendante que je voulais dire.
Pourquoi ? les mnemonique IA32 sont tous defini dans l'AMD64 et les opcode sont les même (a un ou deux truc pres) , donc, a mon sens, un fichier ecrit en assembler X86 doit pouvoir etre assemblé par un assembler X86-64 et donner sensiblement la meme chose ...
Y'a un truc que j'ai pas compris qqpart ? X86-64 est bien un sur enssemble de X86, comme l'etait le jeux d'instructions du 386 par raport a celui du 8086?
heu, je prefere pas l'assembleur ... quand je dis que la compatibilité de l'assembleur est directe, je ne fait qu'enfocer une porte ouverte : c'est le but de l'architecture X86-64.
Compatibilité binaire ca veut dire qu'un mov eax, 10 sera assemblé de la meme manière sur un X86 et un X86-64 puisque de toute manière l'opcode reste le meme. Sinon comme tu dis seul les languages de haut niveau pouront profiter rapidement des nouvelles possibilité de cette architecture. Par contre je craint qu'on se traine des trucs compilés pour X86 pendant un bon bout de temps ,t'as qu'a regarder le nombre de programme qui n'utilisent que le jeux d'instruction du 386 ...
Enfin moi je dis ca, c'est pour les gens qui ne peuvent pas compiler ce qu'ils utilisent ... et ne pas avoir les sources c'est un choix non ? :-)
oui, et aussi pour tout ceux qui n'utilise jamais sizeof pour les types de base ...
Les seuls truc qui seront pas impactés c'est les programmes ecris directement en assembleur ... moins intuitif l'assembleur ... mais compatibilité direct.
Sinon je connais un language mal specifiés mais moins penible a utiliser ;-)
sinon pour gcc 2.95 gere le 64 bit comme suit :
"-m32
-m64
Generate code for a 32 bit or 64 bit environment. The 32 bit environment sets int, long and pointer to 32 bits. The 64 bit environment sets int to 32 bits and long and pointer to 64 bits. "
"The ANSI/ISO C standard specifies that C must support four signed and four unsigned integer data types: char, short, int, and long. There
are few requirements imposed by the ANSI standard on the sizes of these data types. According to the standard, int and short should be
at least 16 bits; and long should be at least as long as int, but not smaller than 32 bits."
"Traditionally, Kernighan and Ritchie (K&R) C assumes int is the most efficient or fastest integer data type on a machine. ANSI C, with its
integral promotion rule, continues this assumption. "
Mais bon, vu le nombre de programma en C existant actuellement, et sachant que le passage de int16 a int32 a été assez douloureux avec
un nombre de programme moindre, la tradition est elle vraiment a respecter ?
Et Normalement ce serait a l'ANSI de trancher sur la taille de type sur une architecture 64b mais vu leur vitesse de decision je pense qu'on peu attendre.
Pour ce qui est des sizeof, je prie tres fort pour qu'il n'ai fait qu'ajouter le type long long et fait passer le sizeof(pointer) a 8.
Parceque sinon je pense qu'on va avoir des petits sousis de portage ... deja qu'avec une changement de taille de pointer ca rique d'etre chaud ...
K&R frappent encore avec leur 'int' a tout faire ...
Surtout que c'est vraiment un copier/coller du 64bit d'AMD ...D'ici a ce qu'intel paye des royalties a AMD :-)
sinon les nouveau nom de registre sont toujours aussi rigolos: RIP,REX, ...
D'ailleur, s'ils font un AMD128 un jour, je leur conseil le 'S' comme prefixe...
j'ai vu c'est article sur ZDnet vendredi ... et dans le carrée publicitaire,
il y avait un pub pour VisualStudio.net ... c'est ca qu'on appel de la pub
dirigée ? J'ai fait une catpure de la page et je me lasse pas de la
regarder :-)
sur mon projet on a "resolu" le reserved checkout a coup de cvs admin -l et -u ce qui n'est pas top car ca sous entend que tout le monde a acces au commande admine ce qui peu conduire a des catastrophes si quelqu'un joue avec cvs admin -o.
Sinon le fait que cvs ne gere pas le reserved checkout et un choix phylosophique de l'equipe de developpement de CVS. Si plusieurs personnes travaillent sur un meme fichier ils sont sensés se prevenir a coup de cvs edit ... mais edit n'interdit pas de remonter un fichier edité par qq1 d'autre. Je pense que le mode edit+merge est tres bien pour les projet developé sur le net , ca t'evite d'envoyer des mails a plein de gens pour qu'il deloquent leurs fichiers et te laisse travailler...mais si tu travail sur un projet où les gens ne sont pas trop conserné par ce qu'ils font tu t'appercois que le merge a des defaut aussi ... J'ai deja vu des fichiers remontés dans la repository avec des conflit dedans ...
[^] # Re: Combien de temps avez-vous mis avant de maîtriser Linux ?
Posté par chaostech . En réponse au sondage Combien de temps avez-vous mis avant de maîtriser Linux ?. Évalué à 2.
[^] # Re: Combien de temps avez-vous mis avant de maîtriser Linux ?
Posté par chaostech . En réponse au sondage Combien de temps avez-vous mis avant de maîtriser Linux ?. Évalué à 6.
[^] # Re: Oui mais ?
Posté par chaostech . En réponse à la dépêche Linux sur Gamecube: le terminal X. Évalué à 1.
Par contre je me vois toujours pas utiliser une télé comme ecrant...
[^] # Re: Oui mais ?
Posté par chaostech . En réponse à la dépêche Linux sur Gamecube: le terminal X. Évalué à 2.
[^] # Re: Je suis
Posté par chaostech . En réponse au sondage Je suis. Évalué à 1.
Pour qu'il puisse voter, il faudrait ajouter "[ ] peripherique" ;-)
Au fin fond d'une regie on ne vous entendra pas hurler...
[^] # Re: Autre chose
Posté par chaostech . En réponse au sondage Je suis. Évalué à 2.
[^] # Re: Je suis
Posté par chaostech . En réponse au sondage Je suis. Évalué à 3.
[^] # Re: Subversion RC-1
Posté par chaostech . En réponse à la dépêche Subversion RC-1. Évalué à 1.
bugger serait plus addapté, comme l'inverse de debugger ... et regardes sur un dico anglais ce que ca veut exactement dire et tu sauras ce que je pense de mes neuneu ...
Sinon, on filtre les commit et c'est vraie que ca limite bien les problèmes, mais personne n'est designé pour vérifier que les modifications faites par les autres sont valides...
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 2.
Sinon pour les nouveau opcode c'est clair qu'il y en a pas mal de nouveaux, mais quand je parlais de compatibilité, c'etait compatibilité ascendante que je voulais dire.
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 0.
Y'a un truc que j'ai pas compris qqpart ? X86-64 est bien un sur enssemble de X86, comme l'etait le jeux d'instructions du 386 par raport a celui du 8086?
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 0.
Compatibilité binaire ca veut dire qu'un mov eax, 10 sera assemblé de la meme manière sur un X86 et un X86-64 puisque de toute manière l'opcode reste le meme. Sinon comme tu dis seul les languages de haut niveau pouront profiter rapidement des nouvelles possibilité de cette architecture. Par contre je craint qu'on se traine des trucs compilés pour X86 pendant un bon bout de temps ,t'as qu'a regarder le nombre de programme qui n'utilisent que le jeux d'instruction du 386 ...
Enfin moi je dis ca, c'est pour les gens qui ne peuvent pas compiler ce qu'ils utilisent ... et ne pas avoir les sources c'est un choix non ? :-)
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 0.
Les seuls truc qui seront pas impactés c'est les programmes ecris directement en assembleur ... moins intuitif l'assembleur ... mais compatibilité direct.
Sinon je connais un language mal specifiés mais moins penible a utiliser ;-)
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 2.
"-m32
-m64
Generate code for a 32 bit or 64 bit environment. The 32 bit environment sets int, long and pointer to 32 bits. The 64 bit environment sets int to 32 bits and long and pointer to 64 bits. "
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 2.
"The ANSI/ISO C standard specifies that C must support four signed and four unsigned integer data types: char, short, int, and long. There
are few requirements imposed by the ANSI standard on the sizes of these data types. According to the standard, int and short should be
at least 16 bits; and long should be at least as long as int, but not smaller than 32 bits."
"Traditionally, Kernighan and Ritchie (K&R) C assumes int is the most efficient or fastest integer data type on a machine. ANSI C, with its
integral promotion rule, continues this assumption. "
Mais bon, vu le nombre de programma en C existant actuellement, et sachant que le passage de int16 a int32 a été assez douloureux avec
un nombre de programme moindre, la tradition est elle vraiment a respecter ?
Et Normalement ce serait a l'ANSI de trancher sur la taille de type sur une architecture 64b mais vu leur vitesse de decision je pense qu'on peu attendre.
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 0.
Parceque sinon je pense qu'on va avoir des petits sousis de portage ... deja qu'avec une changement de taille de pointer ca rique d'etre chaud ...
K&R frappent encore avec leur 'int' a tout faire ...
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par chaostech . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 1.
sinon les nouveau nom de registre sont toujours aussi rigolos: RIP,REX, ...
D'ailleur, s'ils font un AMD128 un jour, je leur conseil le 'S' comme prefixe...
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par chaostech . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à 2.
[^] # Re: Anti-spam : adoptons SPF maintenant !
Posté par chaostech . En réponse à la dépêche Anti-spam : adoptons SPF maintenant !. Évalué à -1.
# Re: Richard Stallman prend la plume pour les 20 ans de GNU
Posté par chaostech . En réponse à la dépêche Richard Stallman prend la plume pour les 20 ans de GNU. Évalué à 1.
il y avait un pub pour VisualStudio.net ... c'est ca qu'on appel de la pub
dirigée ? J'ai fait une catpure de la page et je me lasse pas de la
regarder :-)
[^] # Re: Subversion RC-1
Posté par chaostech . En réponse à la dépêche Subversion RC-1. Évalué à 1.
Sinon le fait que cvs ne gere pas le reserved checkout et un choix phylosophique de l'equipe de developpement de CVS. Si plusieurs personnes travaillent sur un meme fichier ils sont sensés se prevenir a coup de cvs edit ... mais edit n'interdit pas de remonter un fichier edité par qq1 d'autre. Je pense que le mode edit+merge est tres bien pour les projet developé sur le net , ca t'evite d'envoyer des mails a plein de gens pour qu'il deloquent leurs fichiers et te laisse travailler...mais si tu travail sur un projet où les gens ne sont pas trop conserné par ce qu'ils font tu t'appercois que le merge a des defaut aussi ... J'ai deja vu des fichiers remontés dans la repository avec des conflit dedans ...