Tu as raison sur le principe, pour éviter le padding d'une structure on ordonne les champs dans l'ordre de taille décroissante. Mais tu ne choisi pas forcément le codage d'une trame BUS que tu reçois par exemple.
Sinon, il y a une petite erreur sur ton premier exemple :
structtoto_s{uint8_tf1;uint32_tf2;uint16_tf3;uint64_tf4;uint8_tf5;};// Avec paddingstructtoto_s{uint8_tf1;// offset 0charpadding1[3];//offset 1uint32_tf2;// offset 4 : Aligné sur 32bitsuint16_tf3;// offset 8 : Aligné sur 16charpadding2[6];// offset 10uint64_tf4;// offset 16 : Aligné sur 64uint8_tf5;// offset 24 : Aligné sur 1 ;-)};
Un simple sizeof entre une structure bien rangé et une autre est vraiment parlant. C'est utile quand la RAM peut manquer, sinon, je trouve plus clair de mettre des champs qui ont des affinités ensembles.
En effet, les patrons de fonctions été compilé localement dans chaque fichier cpp sans exporter les symbols. Du coup les binaires grossissais pas mal. Mais il y avait un hack :
Tu compilais avec une option pour pas générer les template.
Plein d'erreur d'édition des liens.
Avec les erreurs de l'édition de lien tu activais les template juste une fois.
Je n'aurais pas été jusqu'à ne garantissent rien du tout mais c'est un peu ça. Les compilateurs se comporte globalement de la même façon. Dans l'embarqué, tu connais généralement l'ensemble donc les structures sont plus esthétiques à mon sens et plus lisible. L'avantage des macros, c'est que tu n'as que l'endianess à gérer. C'est plus simple de faire du code portable. Par contre, même punition que les structure, les macro doivent être cantonnées à l'accès avec l'extérieur et recopier les données dans une structure interne propre.
Le padding dépend effectivement des deux, même si la principale contrainte vient du CPU. Sur le Power PC par exemple, il ne sait pas faire d'accès mémoire non aligné. Donc si tu force le compilo à ne pas aligner, pour chaque mot, il a 3 chances sur 4 de faire 2 accès mémoires (la deuxième en cache) plus de la recombinaison des données.
avec les champs de bits C, incertitude sur le padding ?
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut packed à la structure par exemple, sous visual c'est un #pragma
avec les champs de bits C, incertitude sur l'ordre des champs, des bits, des octets, des mots ?
Là encore, c'est connue mais dépend de l'endianness… Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'int ne fait pas 32 bits.
avec les champs de bits C, incertitude sur la taille du type crée ?
Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.
des projets en C n'ont absolument aucune raison d'être en C.
Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final, à choisir le langage avec le meilleurs paradigme et pour chaque paradigme, avoir une vision suffisamment clairvoyante pour analyser en avance de phase lequel des langages sera le plus adapté. Je n'en suis hélas pas capable. :'( Par défaut et comme beaucoup, je code avec ce que je connais. Je me fais des TPs pour tester de nouveaux langages (j'ai tenté haskell dernièrement), mais de là à démarrer un projet pouvant devenir gros… je préfère rester en terrain connu en connaissance de cause et sachant à l'avance les problèmes que je risque de rencontrer.
De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.
Je ne crois pas. Après, je n'ai pas essayé avec gparted. Je tenterai sur une clé usb pour voir la réaction de gparted sur un disque sans table de partitions.
Tu as une instruction de moins, la belle affaire si entre l'instruction deux et trois, tu dois attendre 20 cycles la valeur en RAM. Alors qu'avec tes quatre instructions, le compilateur en rajoute une cinquième à un endroit stratégique pour éviter ce temps d'attente.
En caricaturant, avec 4 instruction initialement tu utilises 5 cycles et avec tes 3 tu utilises 23 cycles… où est l'optimisation ?
Sur un int il n'y aura aucun1 impact. Les compilateurs moderne se débrouille très bien pour savoir quand le faire au mieux. Il y a peu être un impact avec une copie de registre si vraiment les deux valeurs sont utiles. Mais généralement, c'est du a++ dans un for, while sans besoin de la valeur initiale. On peut avoir b=a++ mais là, le compilo va d'abord copier puis incrémenter. Pareil pour les expression du type c=a + b++ où on va faire le add regA, regB (le résultat est stocké dans regA) puis inc regB. Le seul cas que je vois c'est c=a++ + b je ne sais pas si le compilateur fait jouer la commutativité pour gagner un cycle… je ne suis pas sûr de la pertinence de se genre d'optimisation.
enfin, vraiment mineur avec les compilateurs modernes. Si tu en es à gratter au cycle près, c'est qu'il y a un problème de conception générale du programme àmha. ↩
Parce que ça optimise quelque chose en termes de performances de passer à la version pre-increment ?
Oui, en c++.
Quand tu déclares en pré-incrément, tu n'a pas de copie.
// .hClasse&operator++();//.cppClasse&operator++(){// Code d'incrément (plus ou moins long)return*this;}
Ici, on retourne une référence sur l'objet incrémenté.
// .hClasseoperator++(int);// le paramètre signifie post incrément// .cppClasseoperator++(int){Classetmp=*this;// Copie de l'objet// Code d'incrément// On retourne une copie de l'objet avant l'incrément. Ce ne peut-être une réf, car il est sur la pile.returntmp;// Copie de l'objet}
Ici, on a deux copies, ce qui peut poser un problème si l'objet est gros. C'est pour ça, notamment sur les fonctions template où tu ne présuppose pas ce que tu as comme objet qu'il vaut mieux faire des pré-incrément en c++.
Je ne sais pas si c++11 permet avec le && d'écrire les post-incrément mieux ?
Un dev C aurait utilisé une arithmétique de pointeurs, un dev C++ des itérateurs.
Oui pour les itérateurs, mais pour les pointeurs, il faut faire attention. Si tu boucles avec des pointeurs, le compilateur ne présuppose plus rien. Alors qu'avec les indices, il est capable d'optimiser aussi bien que les pointeurs, voir mieux car comme il sait où il va, il peut faire du prefetch.
Comme disais Carmack : Ne supposez pas que ça va plus vite, vérifiez-le !
Le cache en CPU, fonctionne par ligne appelée ligne de cache. Celle-ci contient 4 ou plus mot de 32bits. Lorsque l'on lit une variable, le CPU demande à la RAM la valeur et en profite pour mettre dans la ligne de cache la RAM autour de la valeur demandée.
En C et C++, sur un tableau à deux dimensions, si on a un pointeur sur la ligne 3 et la colonne 4, un pointeur++ pour voir le mot suivant en RAM donnera la valeur de la ligne 3 colonne 5 ou dans le cas de 4 colonnes, la ligne 4 colonne 1.
En complément, pour optimiser de manière simple, on peut mettre ensemble (côte à côte) des valeurs d'une structure souvent accédée ensemble, comme ça, on a de bonne chance qu'elle soit sur la même ligne de cache et que une fois le premier champ accédé, les autres soient déjà dans le cache.
Donc la physique n'est pas une science (ref).
Extrait :
On nomme principe physique une loi physique apparente, qu'aucune expérience n'a invalidée jusque là bien qu'elle n'ait pas été démontrée, et joue un rôle voisin de celui d'un postulat en mathématiques.
Ce qui me semble aller contre :
tant que tu ne démontres pas l'existence, la science prendra le parti que ça n'existe pas ou plus jusqu'à preuve du contraire car démontrer l'inexistence est impossible.
C'est faux, et c'est ce que j'essaye de dire. Dans le cas qui nous intéresse, soit tu pars du principe(postulat) que dieu n'existe pas, et tu ne peux le mettre en défaut. Donc la science prouve que dieu existe. Soit tu pars du principe(postulat) que dieu existe, et tu ne peux le mettre en défaut donc la science prouve que dieu existe :-/.
1) la science affirme que Dieu n’existe pas.
2) la science prouve que Dieu n’existe pas.
J'affirme simplement, que ce qu'il dit est faux. Car la science ne peut prouver ni l'existence ni la non existence de dieu. La sciences ne nous étant d'aucune aide sur le sujet, il faut se tourner vers la croyance et la philosophie.
Mais la philosophie est elle une science ? Vous avez 4h ;-)
Non, car tu ne limites pas les valeurs au 3 angles requis (90, 180, 270). Si tu mets 360 + 180 = 540 tu vas renvoyer une rotation, alors qu'on doit renvoyer indice d'après le code d'exemple.
il faudrait ajouter un test du genre :
C'est faux. En sciences, c'est vrai en physique comme en math, on peut utiliser la Démonstration par l'absurde.
Tu pars du contraire de ce que tu veux démontrer. En l'occurrence tu veux nous montrer que dieu n'existe pas.
Donc tu pars du postulat que dieu existe. Tu suis un raisonnement, qui aboutira forcément à une incohérence. L'incohérence prouvera que ton hypothèse de départ est fausse et que donc dieu n'existe pas.
Dans ce cas, quel que soit le postulat de départ, il n'y a rien qui puisse prouvé l'existence ou la non existence de dieu.
Pour l'indentation, je fais différemment (je ne connaissais pas le '==', merci). Je passe en mode visuel, sélectionne les lignes qui m'intéressent et puis '<' ou '>', précédé ou pas d'un nombre pour indenter plus d'une fois.
Si tu utilises le mode visuel tu appuies une fois sur = lorsque le texte est sélectionné.
(…) indentation automatiquement. Le problème, c'est que quand on copie un bout de code sur le net, il indente. C'est gentil, mais comme le code est souvent déjà indenté, faut remettre un coup d'astyle à chaque fois.
Bah, = est ton ami. Pour réindenter tout ton fichier suivant tes règles : gg=G
Sinon, pour indenter n lignes : Tu te places sur la bonne ligne(lg) :lg<enter> puis n== si n vaut 1, alors == est suffisant.
Ben, fin année 90 début 2000, les machines, surtout les cartes graphiques ont commencées à pouvoir faire des effets jolis pour l'interface. Notamment des transitions, des fondus… En essayant de faire la même chose sous X, on explose la bande passante, et encore, quand le réseau n'est pas trop lent. Cette culture du joli effet, a montré des limitations de X. Du coup, les framework ont cherché à résoudre le problème de cette manière qui en plus se mixe bien à la façon de faire de Windows (il me semble)
En 2004 ou 2005, j'avais fait un test :
Je lançais un navigateur sur mon PC chez moi depuis le boulot en exportant le DISPLAY à travers internet (enfin en tunnel ssh). Le dessin du bouton page précédent quand on clique dessus on avait l'impression qu'il s'enfonçait.
2 cas :
firefox a l'époque, et via mon ADSL en upload, je voyais le bouton redessinner son contour, ça prenais plusieurs secondes. Là où konqueror, passais directement à bouton enfoncé. Je pense que le temps d'envoyer le bitmap et l'afficher, il voyait que c'était fini et passait directement à la dernière image.
Personnellement, j'apprécie X pour sa souplesse, j'aimais bien MOTIF pour la personnalisation individuelle des applications. Aujourd'hui passer par une interface 100% locale comme wayland puis lancer un serveur X pour faire du distant (comme sous Windows) n'est pas forcément déconnant. Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Tu as raison sur le principe, pour éviter le padding d'une structure on ordonne les champs dans l'ordre de taille décroissante. Mais tu ne choisi pas forcément le codage d'une trame BUS que tu reçois par exemple.
Sinon, il y a une petite erreur sur ton premier exemple :
Un simple
sizeof
entre une structure bien rangé et une autre est vraiment parlant. C'est utile quand la RAM peut manquer, sinon, je trouve plus clair de mettre des champs qui ont des affinités ensembles.[^] # Re: Et les nouveaux langages de programmation...
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
En effet, les patrons de fonctions été compilé localement dans chaque fichier cpp sans exporter les symbols. Du coup les binaires grossissais pas mal. Mais il y avait un hack :
[^] # Re: Mount
Posté par Anthony Jaguenaud . En réponse au message Slax ne voit pas DD externe. Évalué à 2.
Mon système graphique me détecte quand même la clé. Et la monte automatiquement.
Quand gparted, il m’affiche une partition
/dev/sdc1
qui n’est pas modifiable…Voila pour info.
[^] # Re: Ready for the desktop, pas encore pour le bureau.
Posté par Anthony Jaguenaud . En réponse au journal Windows est il prêt pour le Desktop ? . Évalué à 3.
Driver latin 9, et si tu es fou
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Je n'aurais pas été jusqu'à ne garantissent rien du tout mais c'est un peu ça. Les compilateurs se comporte globalement de la même façon. Dans l'embarqué, tu connais généralement l'ensemble donc les structures sont plus esthétiques à mon sens et plus lisible. L'avantage des macros, c'est que tu n'as que l'endianess à gérer. C'est plus simple de faire du code portable. Par contre, même punition que les structure, les macro doivent être cantonnées à l'accès avec l'extérieur et recopier les données dans une structure interne propre.
Le padding dépend effectivement des deux, même si la principale contrainte vient du CPU. Sur le Power PC par exemple, il ne sait pas faire d'accès mémoire non aligné. Donc si tu force le compilo à ne pas aligner, pour chaque mot, il a 3 chances sur 4 de faire 2 accès mémoires (la deuxième en cache) plus de la recombinaison des données.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut
packed
à la structure par exemple, sous visual c'est un#pragma
Là encore, c'est connue mais dépend de l'endianness… Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'
int
ne fait pas 32 bits.Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final, à choisir le langage avec le meilleurs paradigme et pour chaque paradigme, avoir une vision suffisamment clairvoyante pour analyser en avance de phase lequel des langages sera le plus adapté. Je n'en suis hélas pas capable. :'( Par défaut et comme beaucoup, je code avec ce que je connais. Je me fais des TPs pour tester de nouveaux langages (j'ai tenté haskell dernièrement), mais de là à démarrer un projet pouvant devenir gros… je préfère rester en terrain connu en connaissance de cause et sachant à l'avance les problèmes que je risque de rencontrer.
De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.
[^] # Re: Mount
Posté par Anthony Jaguenaud . En réponse au message Slax ne voit pas DD externe. Évalué à 2.
Je ne crois pas. Après, je n'ai pas essayé avec gparted. Je tenterai sur une clé usb pour voir la réaction de gparted sur un disque sans table de partitions.
# Mount
Posté par Anthony Jaguenaud . En réponse au message Slax ne voit pas DD externe. Évalué à 3.
Salut,
J'ai lu les autres commentaires, le fait qu'il n'y ait pas de partition n'est pas forcément grave, même si c'est rare.
Essaye de taper :
Si mount ne retourne pas d'erreur, tu devrais trouver les fichiers dans le sous-répertoire
MonDisque
.Par contre, je ne suis pas certain que tu sois en mesure de lire les fichiers car souvent se genre d'enregistreur les chiffre.
[^] # Re: La différence entre une secte et une religion ?
Posté par Anthony Jaguenaud . En réponse au journal Manu se lance dans une croisade numérique contre les terroristes intégristes musulmans. Évalué à 3.
J’ai ri : (je me suis permis de graisser un mot)
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 7.
Tu as une instruction de moins, la belle affaire si entre l'instruction deux et trois, tu dois attendre 20 cycles la valeur en RAM. Alors qu'avec tes quatre instructions, le compilateur en rajoute une cinquième à un endroit stratégique pour éviter ce temps d'attente.
En caricaturant, avec 4 instruction initialement tu utilises 5 cycles et avec tes 3 tu utilises 23 cycles… où est l'optimisation ?
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 4.
Sur un
int
il n'y aura aucun 1 impact. Les compilateurs moderne se débrouille très bien pour savoir quand le faire au mieux. Il y a peu être un impact avec une copie de registre si vraiment les deux valeurs sont utiles. Mais généralement, c'est dua++
dans unfor
,while
sans besoin de la valeur initiale. On peut avoirb=a++
mais là, le compilo va d'abord copier puis incrémenter. Pareil pour les expression du typec=a + b++
où on va faire leadd regA, regB
(le résultat est stocké dans regA) puisinc regB
. Le seul cas que je vois c'estc=a++ + b
je ne sais pas si le compilateur fait jouer la commutativité pour gagner un cycle… je ne suis pas sûr de la pertinence de se genre d'optimisation.enfin, vraiment mineur avec les compilateurs modernes. Si tu en es à gratter au cycle près, c'est qu'il y a un problème de conception générale du programme àmha. ↩
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 2. Dernière modification le 27 juin 2014 à 14:46.
Oui, en c++.
Quand tu déclares en pré-incrément, tu n'a pas de copie.
Ici, on retourne une référence sur l'objet incrémenté.
Ici, on a deux copies, ce qui peut poser un problème si l'objet est gros. C'est pour ça, notamment sur les fonctions template où tu ne présuppose pas ce que tu as comme objet qu'il vaut mieux faire des pré-incrément en c++.
Je ne sais pas si c++11 permet avec le
&&
d'écrire les post-incrément mieux ?[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 7.
Oui pour les itérateurs, mais pour les pointeurs, il faut faire attention. Si tu boucles avec des pointeurs, le compilateur ne présuppose plus rien. Alors qu'avec les indices, il est capable d'optimiser aussi bien que les pointeurs, voir mieux car comme il sait où il va, il peut faire du prefetch.
Comme disais Carmack : Ne supposez pas que ça va plus vite, vérifiez-le !
[^] # Re: et avec pypy ?
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 8.
Le cache en CPU, fonctionne par ligne appelée ligne de cache. Celle-ci contient 4 ou plus mot de 32bits. Lorsque l'on lit une variable, le CPU demande à la RAM la valeur et en profite pour mettre dans la ligne de cache la RAM autour de la valeur demandée.
En C et C++, sur un tableau à deux dimensions, si on a un pointeur sur la ligne 3 et la colonne 4, un pointeur++ pour voir le mot suivant en RAM donnera la valeur de la ligne 3 colonne 5 ou dans le cas de 4 colonnes, la ligne 4 colonne 1.
En complément, pour optimiser de manière simple, on peut mettre ensemble (côte à côte) des valeurs d'une structure souvent accédée ensemble, comme ça, on a de bonne chance qu'elle soit sur la même ligne de cache et que une fois le premier champ accédé, les autres soient déjà dans le cache.
[^] # Re: La différence entre une secte et une religion ?
Posté par Anthony Jaguenaud . En réponse au journal Manu se lance dans une croisade numérique contre les terroristes intégristes musulmans. Évalué à 1.
En quoi l'un est plus (ir)réfutable que l'autre ?
[^] # Re: La différence entre une secte et une religion ?
Posté par Anthony Jaguenaud . En réponse au journal Manu se lance dans une croisade numérique contre les terroristes intégristes musulmans. Évalué à 1.
Donc la physique n'est pas une science (ref).
Extrait :
On nomme principe physique une loi physique apparente, qu'aucune expérience n'a invalidée jusque là bien qu'elle n'ait pas été démontrée, et joue un rôle voisin de celui d'un postulat en mathématiques.
Ce qui me semble aller contre :
C'est faux, et c'est ce que j'essaye de dire. Dans le cas qui nous intéresse, soit tu pars du principe(postulat) que dieu n'existe pas, et tu ne peux le mettre en défaut. Donc la science prouve que dieu existe. Soit tu pars du principe(postulat) que dieu existe, et tu ne peux le mettre en défaut donc la science prouve que dieu existe :-/.
[^] # Re: La différence entre une secte et une religion ?
Posté par Anthony Jaguenaud . En réponse au journal Manu se lance dans une croisade numérique contre les terroristes intégristes musulmans. Évalué à -2.
Je répond à un gars qui écrit :
J'affirme simplement, que ce qu'il dit est faux. Car la science ne peut prouver ni l'existence ni la non existence de dieu. La sciences ne nous étant d'aucune aide sur le sujet, il faut se tourner vers la croyance et la philosophie.
Mais la philosophie est elle une science ? Vous avez 4h ;-)
[^] # Re: ca marche ton truc ?
Posté par Anthony Jaguenaud . En réponse au message Algorithme : permutation. Évalué à 2. Dernière modification le 26 juin 2014 à 14:12.
Non, car tu ne limites pas les valeurs au 3 angles requis (90, 180, 270). Si tu mets 360 + 180 = 540 tu vas renvoyer une rotation, alors qu'on doit renvoyer
indice
d'après le code d'exemple.il faudrait ajouter un test du genre :
[^] # Re: La différence entre une secte et une religion ?
Posté par Anthony Jaguenaud . En réponse au journal Manu se lance dans une croisade numérique contre les terroristes intégristes musulmans. Évalué à -1.
C'est faux. En sciences, c'est vrai en physique comme en math, on peut utiliser la Démonstration par l'absurde.
Tu pars du contraire de ce que tu veux démontrer. En l'occurrence tu veux nous montrer que dieu n'existe pas.
Donc tu pars du postulat que dieu existe. Tu suis un raisonnement, qui aboutira forcément à une incohérence. L'incohérence prouvera que ton hypothèse de départ est fausse et que donc dieu n'existe pas.
Dans ce cas, quel que soit le postulat de départ, il n'y a rien qui puisse prouvé l'existence ou la non existence de dieu.
[^] # Re: galculator, diagramme et éditeur de texte
Posté par Anthony Jaguenaud . En réponse au message divers utilitaires . Évalué à 3.
Si tu utilises le mode visuel tu appuies une fois sur
=
lorsque le texte est sélectionné.[^] # Re: galculator, diagramme et éditeur de texte
Posté par Anthony Jaguenaud . En réponse au message divers utilitaires . Évalué à 2.
Quand j'écris
lg
je voulais dire un numéro de ligne… genre pour aller à la 12ième ligne du fichier:12<enter>
.Pareil pour
n
pour indenter les six prochaines lignes :6==
.[^] # Re: galculator, diagramme et éditeur de texte
Posté par Anthony Jaguenaud . En réponse au message divers utilitaires . Évalué à 3. Dernière modification le 25 juin 2014 à 13:24.
Bah,
=
est ton ami. Pour réindenter tout ton fichier suivant tes règles :gg=G
Sinon, pour indenter
n
lignes : Tu te places sur la bonne ligne(lg):lg<enter>
puisn==
si n vaut 1, alors==
est suffisant.Sinon, une commande intéressante :
:help<enter>
[^] # Re: Vraiment impressionnant!
Posté par Anthony Jaguenaud . En réponse à la dépêche G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 7.
Tu voulais écrire :
Le fait de ne pas fournir tout ça que sous forme de greffon gimp rend vraiment la chose intéressante pour un usage réel!
[^] # Re: Comment c’est possible ?
Posté par Anthony Jaguenaud . En réponse au journal [bookmark] 30 ans de X. Évalué à 3.
Ben, fin année 90 début 2000, les machines, surtout les cartes graphiques ont commencées à pouvoir faire des effets jolis pour l'interface. Notamment des transitions, des fondus… En essayant de faire la même chose sous X, on explose la bande passante, et encore, quand le réseau n'est pas trop lent. Cette culture du joli effet, a montré des limitations de X. Du coup, les framework ont cherché à résoudre le problème de cette manière qui en plus se mixe bien à la façon de faire de Windows (il me semble)
En 2004 ou 2005, j'avais fait un test :
Je lançais un navigateur sur mon PC chez moi depuis le boulot en exportant le DISPLAY à travers internet (enfin en tunnel ssh). Le dessin du bouton page précédent quand on clique dessus on avait l'impression qu'il s'enfonçait.
2 cas :
firefox a l'époque, et via mon ADSL en upload, je voyais le bouton redessinner son contour, ça prenais plusieurs secondes. Là où konqueror, passais directement à bouton enfoncé. Je pense que le temps d'envoyer le bitmap et l'afficher, il voyait que c'était fini et passait directement à la dernière image.
Personnellement, j'apprécie X pour sa souplesse, j'aimais bien MOTIF pour la personnalisation individuelle des applications. Aujourd'hui passer par une interface 100% locale comme wayland puis lancer un serveur X pour faire du distant (comme sous Windows) n'est pas forcément déconnant. Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.