Le fichier qui nous intéresse est src/widgets/NumericTextCtrl.cpp; il définit le contenu de const BuiltinFormatString TimeConverterFormats[] et contient donc (j'enlève les commentaires et une partie du code) : C
const BuiltinFormatString TimeConverterFormats[] = {
{
_("seconds"),
_("01000,01000 seconds")
},
{
_("hh:mm:ss + milliseconds"),
_("0100 h 060 m 060.01000 s")
},
[...]
}
Comme la lecture du fichier l'indique, le contenu de chaînes comme "01000,01000 seconds" est analysé : le nombre est affiché suivant le format ainsi décrit.
Bon, désolé d'avance si l'affichage est foireux, je ne sais pas comment citer un passage incluant un bout de code.
Perso, quand j'ai vu le code, je me suis dit: "Tiens, des magic values. Et l'OP semble avoir besoin de recompiler pour les altérer? Dommage…".
Je m'explique. Modifier une magic value, ça permettra de satisfaire ton besoin immédiat, mais demain quelqu'un aura peut-être besoin de faire un truc encore différent (j'y connais que dalle en multimédia, alors je peux me tromper). Si à chaque fois il faut recompiler… je trouve ça gênant.
Ne serait-il pas faisable, en revanche, d'aller récupérer les informations dans un fichier de configuration? Dans le cas présent, il s'agit d'un ensemble de paires de string, contenant pour chacune le nom du mode d'affichage, et la description du format qui lui est associé.
Je ne connais pas l'état du source, si c'est propre ou pas, comment est gérée la configuration (base de données lourde? XML? Répertoire contenant divers fichiers de configuration de petite taille? Utilisation de la classe de gestion de la config de wxwidgets?) donc ce n'est peut-être pas aussi trivial que ça, mais si tu hôtes d'un bout de code des constantes magiques, en expliquant ton besoin d'origine et le fait que du coup, cette modification permets de gérer d'une part ton besoin, sans rien détruire, et qu'en plus les éventuels autres besoins liés à cet affichage seront gérés sans modification du source, j'imagine mal le patch être mal reçu par les dev.
En fait, de base, je vois mal des patch améliorant une fonctionnalité déjà présente être rejetés, contrairement à des demandes de fonctionnalités, comme déjà indiqué dans un autre fil par quelqu'un d'autre.
PS: c'est sûr que les dépêches ont une meilleure visibilité, mais, en fait, c'est une entrée de forum que tu nous as fait non?
Mais dans ce cas, les hommes se sentiraient insultés au même titre que les femmes le sont actuellement. Bref, je suis d'accord que c'est aberrant, mais pas pour une question de sexisme… juste de praticité.
je l'ai mappée à la place du CapsLock, touche qui ne sert pas à grand chose
Je m'en sers pour les «macros constantes» en C, bien que je doive admettre que j'utilise de moins en moins de C, et encore pire pour ce qui est des constantes. Donc pourquoi pas, il faudra que j'y réfléchisse.
C'est vrai, on peut passer d'une fenêtre à l'autre d'un simple raccourcis clavier.
Sauf que, à ce que je sais, c'est plutôt pénible d' "alttaber" jusqu'à tomber sur la bonne fenêtre. Avec un tiling wm, il n'y à pas cette contrainte, mais ça reste une frappe clavier supplémentaire, pour changer de fenêtre.
On peut aussi parler du fait que ça permette de ne pas avoir à modifier les dimensions des fenêtres que l'on utilise (je considère le mode fullscreen comme un redimensionnement).
Par contre, je n'ai pas compris ta seconde phrase? Utiliser des clients? C'est à dire?
C'est vrai que pouvoir sortir le prototype quand on appelle une fonction est quelque chose d'utile quand on utilise un IDE. Les IDEs ont leur lot d'avantages, je ne dis pas le contraire, vim aussi, grâce au fait qu'il soit possible de l'utiliser dans un terminal et donc d'en entrer/sortir rapidement, éventuellement après avoir greppé sur un terme, télécharger un fichier, remis en style (via astyle p. ex. ), commité, etc.
Bon, je sais, on peut faire pas mal de ces actions directement à partir de vim, mais je n'ai pas encore suffisamment l'habitude. N'empêche, à mon humble niveau, avec mon usage, je trouve bash+vim+cmake+git bien plus confortable à utiliser qu'un IDE avec un plugin pour git.
Question de goûts, je suppose.
c'est plus rapide que Caps lock suivi de e suivi de Caps lock
Sinon, ALT.GR+SHIFT+é marche aussi. (J'ai lu ça sur linuxfr il y à pas bien longtemps, mais ça à changé ma vie, depuis j'utilise des majuscules accentuées…)
J'ai aussi œ directement accessible avec AltGr.
La touche au dessus de tab, et à gauche de & le fait sans combinaison en "azerty linux".
Par contre, j'avoue que pouvoir avoir les chiffres accessibles sans bloquer un doigt sur shift serait bien pratique.
Ben, il y à au moins la traditionnelle F1, qui permets d'afficher l'aide sur 95% des soft que j'utilise. L'air de rien, c'est bien utile.
Par contre, j'ai beaucoup moins d'intérêt pour les touches multimédia, parce que je binde des raccourcis de mon window manager à mpc, par exemple (à une exception près: au boulot, car elles sont idéalement placées entre les touches fléchées et le pavé inser/supprs/pgup/pgdown/orig/end).
Conclusion: l'utilisateur qui configure son clavier n'en à de toute façon rien à foutre, mais alors strictement, de la dispo standard, et des contrôles par défaut des applications. Parce qu'il les à adapté à son comportement. Mais ce n'est pas une raison pour casser les habitudes qui ne font de mal à personne, genre F1 pour l'aide, F2 pour renommer, ESC pour annuler (ben oui, personne n'en à parlé de celle-là encore :p ).
Non, le problème (je parle de ce qui est imprimé sur les claviers, et qui répond tel que sous windows de mémoire), c'est plutôt le truc sur le alt.gr du $£ (je sais même pas ce que ça représente, ici ça tape un ê… utilité moyenne, e est plus simple amha), le ² qui est à côté du &, etc.
C'est pareil pour les touches "pause", "arret defil", "impr ecran", "orig", "fin", "insert", "suppr", "page up" et "page down" ou encore les touches de fonction. Ca n'est plus utilisé par personne ou presque (sauf qq geeks et qq gars malchanceux qui utilisent encore des logiciels metier des annees 80)
Alors, pause ça sert quand tu dois mettre en pause un jeu, une vidéo, arrêt de défilement, certes c'est un peu ancien, mais quand on à un OS digne de ce nom qui ne nous cache pas les emmerdes, ça permets de prendre le temps de lire.
L'impression d'écran, crois-moi, plein de gens s'en servent, j'en veux pour prendre que les gens qui travaillent envoient des rapports de bugs avec des captures, plutôt qu'un copier/coller de l'erreur du navigateur.
La touche suppression, sert à plein de gens pour supprimer des fichiers ou du texte. Quand je dis plein de monde, c'est vraiment plein de monde hein, je parle bien sûr pas de Mme Michu qui travaille en usine, mais des gens qui travaillent sur un PC de bureau. Les barbus, eux, s'en servent également pour couper du texte, certes.
Quant aux 5 autres touches, origine, fin, défilement de page vers le haut ou le bas, elles peuvent, encore une fois, servir à toute personne qui travaille régulièrement sur écran, à aller plus vite là ou elle souhaite aller dans son texte. Oui, c'est plus rapide que CTRL+F dans bien des cas… L'insertion, elle, ok, elle est moins utilisée. Pour ta gouverne, elle permets de copier ou coller du texte, ainsi que de basculer entre les mode écrasement et insertion du texte. Les 2 premiers usages sont anciens et quelques peu obsolètes (et encore, ça m'arrive de m'en servir encore) mais le second est très utile quand, encore une fois, on travaille sur du texte et que l'on utilise pas vim (qui dispose d'un mode d'écrasement, qui rend donc cette touche moins utile).
Maintenant que je t'ai manifestement appris que ces touches sont utiles, et pas que pour les geek ou utilisateurs d'applications anciennes (qui existent encore en nombre, que tu apprécies ce fait ou non! Certains sont adeptes du: if it's not broken, don't fix it!).
Mais, plus important, il faut vraiment, mais alors vraiment, que tu comprennes que… hé bien… tiens-toi bien, tu es assis? Ces touches ne font pas partie de ce qui pose problème avec les disposition clavier, et quand tu regardes les différents claviers autour de toi, elles ne sont ni toujours présentes, ni toujours au même places.
Autrement dit: elles ne sont pas standard.
Si déjà on pouvait taper les caractères spéciaux en majuscule, l'espace insécable, 2-3 caractères spéciaux absents (œ, tiret cadratin, points de suspension…) et les guillemets français (en gros comme avec n'importe quelle keymap disponible sous Linux)
On fait comment sous linux? Bon, les majuscules accentuées, je sais, le œ aussi, mais le reste, du tout, alors je sais la balle pour apprendre :)
Il dit que ça lui évite de quitter la fenêtre de son émulateur de terminal pour modifier un texte.
Autrement dit, il est peut-être (comme moi dans ce cas?) le genre de personne qui à oublié que l'on peut faire les choses à la souris dans un explorateur de fichier graphique, préférant le faire à coup de commandes shell.
les curseurs multiples tu t'en sert pour tout et n'importe quoi quasiment tout le temps et bien plus rapidement.
Oui, dommage que la seule implem que j'en aie vu (notepad++, codeblocks, scite, et 2-3 autres basés sur scintilla) soit bugguée (un certain nombre d'actions n'ont pas le comportement attendu, par exemple, quand on veut coller un truc à des endroits différents, ou quand on veut insérer une ligne: ça n'affecte qu'un seul curseur, quand ça ne fait pas sauter les autres curseurs…) et inutilisable sans prendre en main la souris.
Accessoirement, pour du code, je trouve ça pas plus mal de ne pas l'avoir.
Avant, je m'en servais. Depuis, j'évite de dupliquer du code, même si c'est vrai que dans le cas des switch case ça évite des frappes… mais avec vi, '10o[\t]case :[ENTER]' génère mes 10 lignes de copié collé. Plus qu'à revenir à chaque fois mettre la bonne valeur dans le case… l'avantage contrairement aux pointeurs multiples que j'aie utilisés, c'est… qu'on peut générer des blocs de code de plusieurs lignes de cette façon. La dernière fois ça ne marchait pas avec n++.
Par contre, le seul truc qui me gêne vraiment avec les nouveaux éditeurs de texte, et qui m'a séduit avec vim (avec lequel je suis encore un grand débutant) c'est le fait de ne pas avoir besoin de la souris ou de raccourcis clavier multipliant les appuis simultanés (bien que vim aie un certain nombre d'actions que l'on déclenche ainsi…mais je ne m'en sers jamais, principalement parce que je ne les connais pas et/ou qu'il s'agisse de gestion de fenêtres, chose que je délègue à mon WM).
À l'origine, j'ai toujours utilisé des IDE, puis quand je suis passé à linux j'ai commencé à apprendre à utiliser vim. Je n'utilise plus d'IDE, et je ne suis pas persuadé d'y avoir perdu en productivité…
Debian arrive en deux versions : la « testing », qui reçois un flot de paquet en continu (rolling release)
Petit points de détails…
Rolling release signifie que de nouvelles versions des logiciels sont intégrées régulièrement, qui ajoutent des fonctionnalités (et donc peut-être des bugs, tandis que les mises à jour de sécurité elles sont moins enclines à ce genre d'ajouts indésirables).
Debian Jessie, l'actuelle Testing, est sur le point (ou l'est-elle déjà?) d'un "freeze", ce qui signifie qu'elle ne recevra plus que des bugfixs jusqu'à devenir la version stable de Debian. Du coup, appeler Debian Testing une rolling release me gêne: ça dépend du moment.
Enfin, il y à une 3ème mouture de Debian, dite unstable, qui est elle réellement en rolling release. À noter quand même que les rolling release ont plus de risques à casser lors d'une MaJ.
En l’occurrence pour Ubuntu, c'est i386 (x87) contre du x86_64 "de base" (SSE2 et c'est tout).
Je dis peut-être une connerie, mais il me semble qu'Ubuntu est sur du i486?
Si tu veux une anecdote, sur mes VM serveur au boulot, je leur met du 64 bits systématiquement. Les machines qui n'ont que 400 Mo de RAM tournent très bien et certainement plus efficacement que si j'avais du 32 bits dessus.
J'aurai du préciser: sur une machine de bureau :)
Je pense, notamment, aux navigateurs web, de loin l'application qui me bouffe le plus de RAM… quand je ne joue pas :)
Tu ne me feras pas croire que apt ne sait pas gérer les dépendances.
Je n'essaierai même pas. Mais justement, une des dépendance qu'il gère est: "break". Du coup, il m'est arrivé de devoir passer plus de 5 minutes à sélectionner les bonnes versions sur N paquets. 5 minutes, c'est sûr, c'est pas la mort, mais pour un débutant, ça ne sera pas nécessairement si peu.
Et si l'OP installe des paquets de sources non officielles (genre, par exemple, les paquets wine-unstable, pour une raison où une autre, genre pour une appli pas encore supportée par wine-stable, qui est la seule présente dans les repo debian) il pourrait avoir ce genre de surprises.
Ouai enfin là tu cherches loin. Je me demande qui a besoin de faire tourner un logiciel Windows 64 bits dans Wine. L'univers Windows est tellement à la ramasse niveau 64 bits que tu auras de toute façon forcément une version de ton programme Windows en 32 bits à disposition.
Je pensais ici très précisément à AutoCAD. Vécu récemment (ça s'est fini dans une VMs avec windows 7). Bon, certes, il existe une version 32bits, je ne sais plus quels soucis j'avais dessus en essayant de l'installer, mais je n'ai pas télécharger 1.3Go puis 1.7Go juste pour le fun, tu peux me croire.
J'avais bien essayé de choper une version plus ancienne, mais introuvable sur le site officiel (pas trouvé comment, en tout cas) et pas la moindre motivation pour télécharger des trucs à la provenance douteuse pour le taf.
Il l'a dit dans les commentaires qu'il allait prendre un ordi récent.
Faux. Il à dit:
mon PC actuel sera reconverti à d'autres usages, potentiellement avec son Linux aussi
ainsi que:
ma config acutelle est un Asus A6KM avec 2go de RAM…
et
je pense partir sur un Lenovo reconditionné, genre X200
Hors, le X200 ne dispose, manifestement que de 2 Go de RAM… (améliorable à 4, à priori)
Bref, le hors sujet, c'est?
Euh non. La RAM inutilisée par les applications est en fait utilisée pour les caches par le kernel. Et la différence sur l'autonomie n'existe pas.
Mea culpa, j'aurai du dire que moins il y à de barettes de RAM installées, moins on tire sur la batterie, ce qui est en effet sensiblement différent.
Mais montre moi une machine neuve avec un Go… Ben oui : y'en a pas.
Mais, personne n'à parlé de machine neuve. Mon netbook n'à que 3 ans, c'est vrai c'est pas tout récent, mais voila, c'est pas non plus super vieux. Et si je voulais jouer sur les mots, je parlerai de RPI, mais ce serait vraiment me moquer de toi.
Ça fait des années que 2 Go est moins que la norme (qui est de 4 à 6 Go). Et je change de machine tous les 5 ans environ.
Preuves? Non, parce que, comme je l'ai dis dans ce message, il y à 3-4 ans on trouvait encore des machines à 1Go sans souci, sous emballage neuf. Bon, après, c'est vrai, on peut parler de plusieurs années à partir de 2 ans…
J'ai plusieurs machines qui disposent d'un seul Go.
Et qui t'as dit que l'OP utiliseras une machine récente?
D'ailleurs, sur une machine portable, moins on utilise la RAM, moins on tire sur la batterie, donc plus on à d'autonomie.
Bref, toi, tu t'en fous peut-être, mais ce n'est pas nécessairement le cas de tout le monde. Certains, comme toi manifestement, veulent juste du cutting edge. C'est leur droit, de changer de machine tous les 2 ans.
D'autres, comme moi, veulent pouvoir utiliser leur système dans la longueur, même quand mes machines ont 5, 6 ans, je continue à m'en servir.
Donc, on s'en fout de ta vulgarité, oui, c'est clair.
Ouais enfin la différence en performance entre 32 bits et 64 bits est inexistante 9,9 fois sur 10.
Mouai. Si tu le dis. Moi, je dis que le 64 bouffe plus de RAM. Je peux l'expliquer, mais, comme toi, je ne vais faire qu'une simple assertion inutile, une sorte de demi-argument.
Je n'ai même pas parlé d'espace disque… ou alors je veux bien que tu me cites l'endroit (je viens de faire un CTRL+F sur "disq" et il n'y à que 4 occurrences sur ce thread, dont 3 dans ton message, la dernière dans la réponse de Neox, mais rien à voir avec le multiarch) .
problème de performance à cause des caches ? Pourtant tous les benchmarks ont toujours montrés des performances globalement supérieures en 64 bits.
En fait, ça dépend des options d'optimisation utilisées. Ça dépend aussi de si l'appli génère un trafic important entre la RAM et les caches.
J'ai peut-être un peu trop raccourcis mon argument, je ne voulais pas dire que le 32 bits est moins performant que le 64 bits: ça dépend des usages.
Si tu utilises beaucoup de grosses valeurs numériques (sur plus de 32 bits) le 64 bit t'apporte quelque chose. Si ton applications en revanche n'utilise que des petites valeurs, c'est moins sûr, mais ça, le bench qui ne prend que des outils de compression/décompression/3D/stress test, il ne peux pas le montrer: ces applications sont très gourmandes en gros calculs, donc le 64 est clairement avantagé.
Un autre avantage du 64, c'est d'avoir un certain nombre de registres supplémentaires, dont on bénéficie en fonction du compilo et des options. Ça compense en partie le problème des pointeurs 2 fois plus gros, mais pas complètement.
Dommage que je ne parviennes pas à remettre la main sur les expérimentations que j'avais lues pour utiliser des pointeurs 32 bits en utilisant la puissance du proc 64… ils y expliquaient les choses bien mieux que moi.
Maintenant, je ne me souviens pas non plus avoir vu les spec de la machine que l'OP compte utiliser. J'ai cru comprendre que ça sera un PC portable, et s'il est un peux vieux, ce n'est pas déconnant d'imaginer qu'il n'y ait que 1Go de RAM. De nos jours, 1 Go ça pars vite, surtout sur internet, et quand tu commences à swapper, les perfs ne sont pas les mêmes.
Quand je regarde le bench que tu cites, et que je vois les spec de la machine, j'ai pas l'impression qu'il s'agisse d'une vieille bécane (8Go, core i7)… plutôt une bête de course! Et nulle part n'est indiqué combien de RAM est utilisé par les 2 systèmes.
Franchement, si je n'avais pas dû compiler sur mon netbook, j'y aurai peut-être installé du 32 bits, pour éviter de swapper quand je lançais le browser.
Après, je t'accorde une chose, je ne connais que la théorie à ce sujet, et comme je fais personnellement un usage plutôt intensif côté CPU de mes machines (la programmation, quand ça compile ça peut traîner, et d'ailleurs j'ai été très heureux de découvrir que clang avait une occupation mémoire de 20 bons % de moins que GCC en compilation… ça m'évitait de swapper quand j'utilisais tous les threads CPU.) je n'ai jamais fait de comparatif.
Pour les applications Windows, la seule chose extrêmement compliquée à faire, c'est d'installer wine.i386 et non pas wine.x86_64. Voilà. C'est dur pour un débutant.
Ainsi que les libs dont wine dépends. Certaines pouvant être nécessitées par d'autres logiciels du système, et si, pour une raison ou une autre, on à un conflit entre la version de lib 32 et celle en 64 (bon, c'est indiqué par le gestionnaire de paquets, donc le système pètera pas…) on peut se poser des questions, quand on n'a jamais touché que du Windows.
Ah, et pour debian, il faut aussi activer manuellement l'architecture i386, avant d'installer wine.
Certes, c'est très simple, mais bon, un débutant imaginera-t-il qu'il faille mélanger les archi? Je pense qu'un débutant se dirait juste "bon, je fais comme d'hab, j'installe et voila" et ensuite se demandera pourquoi wine refuse d'exécuter telle ou telle appli, et risque d'imaginer que c'est de la faute au système.
Je ne parlerais pas non plus des applications windows compilées en 64 bits, dont le packageur est lui en 32 bits, il semble que wine ne gère pas encore ce genre de joyeusetés (expérience vécue récemment en tentant d'installer autocad, l'install foirait à cause de cette distinction).
[^] # Re: Félicitations
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 3.
De mémoire, on peux aussi télécharger un zip, qui ne nécessite donc pas les droits administrateurs.
# Autre solution de patch
Posté par freem . En réponse à la dépêche Modeste contribution à Audacity sur l'affichage des temps. Évalué à 7.
Bon, désolé d'avance si l'affichage est foireux, je ne sais pas comment citer un passage incluant un bout de code.
Perso, quand j'ai vu le code, je me suis dit: "Tiens, des magic values. Et l'OP semble avoir besoin de recompiler pour les altérer? Dommage…".
Je m'explique. Modifier une magic value, ça permettra de satisfaire ton besoin immédiat, mais demain quelqu'un aura peut-être besoin de faire un truc encore différent (j'y connais que dalle en multimédia, alors je peux me tromper). Si à chaque fois il faut recompiler… je trouve ça gênant.
Ne serait-il pas faisable, en revanche, d'aller récupérer les informations dans un fichier de configuration? Dans le cas présent, il s'agit d'un ensemble de paires de string, contenant pour chacune le nom du mode d'affichage, et la description du format qui lui est associé.
Je ne connais pas l'état du source, si c'est propre ou pas, comment est gérée la configuration (base de données lourde? XML? Répertoire contenant divers fichiers de configuration de petite taille? Utilisation de la classe de gestion de la config de wxwidgets?) donc ce n'est peut-être pas aussi trivial que ça, mais si tu hôtes d'un bout de code des constantes magiques, en expliquant ton besoin d'origine et le fait que du coup, cette modification permets de gérer d'une part ton besoin, sans rien détruire, et qu'en plus les éventuels autres besoins liés à cet affichage seront gérés sans modification du source, j'imagine mal le patch être mal reçu par les dev.
En fait, de base, je vois mal des patch améliorant une fonctionnalité déjà présente être rejetés, contrairement à des demandes de fonctionnalités, comme déjà indiqué dans un autre fil par quelqu'un d'autre.
PS: c'est sûr que les dépêches ont une meilleure visibilité, mais, en fait, c'est une entrée de forum que tu nous as fait non?
[^] # Re: Hum
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 3.
Mais dans ce cas, les hommes se sentiraient insultés au même titre que les femmes le sont actuellement. Bref, je suis d'accord que c'est aberrant, mais pas pour une question de sexisme… juste de praticité.
[^] # Re: Objectif réel du projet ?
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 3.
Je m'en sers pour les «macros constantes» en C, bien que je doive admettre que j'utilise de moins en moins de C, et encore pire pour ce qui est des constantes. Donc pourquoi pas, il faudra que j'y réfléchisse.
Merci à vous deux en tout cas.
[^] # Re: Objectif réel du projet ?
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 2.
Je n'ai pas de touche compose, ou du moins pas que je sache, mais déjà les «» c'est pas mal à savoir.
[^] # Re: Menu en mode console
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 0.
Je suppose que tu as essayé ESC pour sortir? Voire CTRL+C, sait-on jamais? 'fin bon, suis pas utilisateur d'emacs, alors je ne sais pas, je suggère :)
[^] # Re: Félicitations
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 2.
C'est vrai, on peut passer d'une fenêtre à l'autre d'un simple raccourcis clavier.
Sauf que, à ce que je sais, c'est plutôt pénible d' "alttaber" jusqu'à tomber sur la bonne fenêtre. Avec un tiling wm, il n'y à pas cette contrainte, mais ça reste une frappe clavier supplémentaire, pour changer de fenêtre.
On peut aussi parler du fait que ça permette de ne pas avoir à modifier les dimensions des fenêtres que l'on utilise (je considère le mode fullscreen comme un redimensionnement).
Par contre, je n'ai pas compris ta seconde phrase? Utiliser des clients? C'est à dire?
[^] # Re: Félicitations
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 4.
C'est vrai que pouvoir sortir le prototype quand on appelle une fonction est quelque chose d'utile quand on utilise un IDE. Les IDEs ont leur lot d'avantages, je ne dis pas le contraire, vim aussi, grâce au fait qu'il soit possible de l'utiliser dans un terminal et donc d'en entrer/sortir rapidement, éventuellement après avoir greppé sur un terme, télécharger un fichier, remis en style (via astyle p. ex. ), commité, etc.
Bon, je sais, on peut faire pas mal de ces actions directement à partir de vim, mais je n'ai pas encore suffisamment l'habitude. N'empêche, à mon humble niveau, avec mon usage, je trouve bash+vim+cmake+git bien plus confortable à utiliser qu'un IDE avec un plugin pour git.
Question de goûts, je suppose.
[^] # Re: qwerty?
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 2.
Sinon, ALT.GR+SHIFT+é marche aussi. (J'ai lu ça sur linuxfr il y à pas bien longtemps, mais ça à changé ma vie, depuis j'utilise des majuscules accentuées…)
La touche au dessus de tab, et à gauche de & le fait sans combinaison en "azerty linux".
Par contre, j'avoue que pouvoir avoir les chiffres accessibles sans bloquer un doigt sur shift serait bien pratique.
[^] # Re: Clavier et normalisation.
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 2.
Ben, il y à au moins la traditionnelle F1, qui permets d'afficher l'aide sur 95% des soft que j'utilise. L'air de rien, c'est bien utile.
Par contre, j'ai beaucoup moins d'intérêt pour les touches multimédia, parce que je binde des raccourcis de mon window manager à mpc, par exemple (à une exception près: au boulot, car elles sont idéalement placées entre les touches fléchées et le pavé inser/supprs/pgup/pgdown/orig/end).
Conclusion: l'utilisateur qui configure son clavier n'en à de toute façon rien à foutre, mais alors strictement, de la dispo standard, et des contrôles par défaut des applications. Parce qu'il les à adapté à son comportement. Mais ce n'est pas une raison pour casser les habitudes qui ne font de mal à personne, genre F1 pour l'aide, F2 pour renommer, ESC pour annuler (ben oui, personne n'en à parlé de celle-là encore :p ).
Non, le problème (je parle de ce qui est imprimé sur les claviers, et qui répond tel que sous windows de mémoire), c'est plutôt le truc sur le alt.gr du $£ (je sais même pas ce que ça représente, ici ça tape un ê… utilité moyenne, e est plus simple amha), le ² qui est à côté du &, etc.
[^] # Re: Clavier et normalisation.
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 2.
Tu fais comment pour sélectionner du texte dans un terminal? Je veux dire, sans la souris. Merci pour les shift+pgup/down par contre!
Toujours dans mon terminal, les raccourcis pour copier/couper basés sur suppr ne marchent pas ici. Une combo de touches, ou un truc à paramétrer?
[^] # Re: Clavier et normalisation.
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 5.
Alors, pause ça sert quand tu dois mettre en pause un jeu, une vidéo, arrêt de défilement, certes c'est un peu ancien, mais quand on à un OS digne de ce nom qui ne nous cache pas les emmerdes, ça permets de prendre le temps de lire.
L'impression d'écran, crois-moi, plein de gens s'en servent, j'en veux pour prendre que les gens qui travaillent envoient des rapports de bugs avec des captures, plutôt qu'un copier/coller de l'erreur du navigateur.
La touche suppression, sert à plein de gens pour supprimer des fichiers ou du texte. Quand je dis plein de monde, c'est vraiment plein de monde hein, je parle bien sûr pas de Mme Michu qui travaille en usine, mais des gens qui travaillent sur un PC de bureau. Les barbus, eux, s'en servent également pour couper du texte, certes.
Quant aux 5 autres touches, origine, fin, défilement de page vers le haut ou le bas, elles peuvent, encore une fois, servir à toute personne qui travaille régulièrement sur écran, à aller plus vite là ou elle souhaite aller dans son texte. Oui, c'est plus rapide que CTRL+F dans bien des cas… L'insertion, elle, ok, elle est moins utilisée. Pour ta gouverne, elle permets de copier ou coller du texte, ainsi que de basculer entre les mode écrasement et insertion du texte. Les 2 premiers usages sont anciens et quelques peu obsolètes (et encore, ça m'arrive de m'en servir encore) mais le second est très utile quand, encore une fois, on travaille sur du texte et que l'on utilise pas vim (qui dispose d'un mode d'écrasement, qui rend donc cette touche moins utile).
Maintenant que je t'ai manifestement appris que ces touches sont utiles, et pas que pour les geek ou utilisateurs d'applications anciennes (qui existent encore en nombre, que tu apprécies ce fait ou non! Certains sont adeptes du: if it's not broken, don't fix it!).
Mais, plus important, il faut vraiment, mais alors vraiment, que tu comprennes que… hé bien… tiens-toi bien, tu es assis? Ces touches ne font pas partie de ce qui pose problème avec les disposition clavier, et quand tu regardes les différents claviers autour de toi, elles ne sont ni toujours présentes, ni toujours au même places.
Autrement dit: elles ne sont pas standard.
[^] # Re: Objectif réel du projet ?
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 2.
On fait comment sous linux? Bon, les majuscules accentuées, je sais, le œ aussi, mais le reste, du tout, alors je sais la balle pour apprendre :)
[^] # Re: Gné ?
Posté par freem . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 3.
Merci. Je ne savais pas comment exprimer tout ça sans y aller trop fort dans le sarcasme et le trash.
[^] # Re: Félicitations
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 3. Dernière modification le 13 novembre 2014 à 18:32.
Pas besoin, vim tourne sous windows aussi.
[edit]
oups, pas vu la réponse entre deux…
[^] # Re: Félicitations
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 3.
Il dit que ça lui évite de quitter la fenêtre de son émulateur de terminal pour modifier un texte.
Autrement dit, il est peut-être (comme moi dans ce cas?) le genre de personne qui à oublié que l'on peut faire les choses à la souris dans un explorateur de fichier graphique, préférant le faire à coup de commandes shell.
[^] # Re: Félicitations
Posté par freem . En réponse à la dépêche GNU Emacs 24.4. Évalué à 1.
Oui, dommage que la seule implem que j'en aie vu (notepad++, codeblocks, scite, et 2-3 autres basés sur scintilla) soit bugguée (un certain nombre d'actions n'ont pas le comportement attendu, par exemple, quand on veut coller un truc à des endroits différents, ou quand on veut insérer une ligne: ça n'affecte qu'un seul curseur, quand ça ne fait pas sauter les autres curseurs…) et inutilisable sans prendre en main la souris.
Accessoirement, pour du code, je trouve ça pas plus mal de ne pas l'avoir.
Avant, je m'en servais. Depuis, j'évite de dupliquer du code, même si c'est vrai que dans le cas des switch case ça évite des frappes… mais avec vi, '10o[\t]case :[ENTER]' génère mes 10 lignes de copié collé. Plus qu'à revenir à chaque fois mettre la bonne valeur dans le case… l'avantage contrairement aux pointeurs multiples que j'aie utilisés, c'est… qu'on peut générer des blocs de code de plusieurs lignes de cette façon. La dernière fois ça ne marchait pas avec n++.
Par contre, le seul truc qui me gêne vraiment avec les nouveaux éditeurs de texte, et qui m'a séduit avec vim (avec lequel je suis encore un grand débutant) c'est le fait de ne pas avoir besoin de la souris ou de raccourcis clavier multipliant les appuis simultanés (bien que vim aie un certain nombre d'actions que l'on déclenche ainsi…mais je ne m'en sers jamais, principalement parce que je ne les connais pas et/ou qu'il s'agisse de gestion de fenêtres, chose que je délègue à mon WM).
À l'origine, j'ai toujours utilisé des IDE, puis quand je suis passé à linux j'ai commencé à apprendre à utiliser vim. Je n'utilise plus d'IDE, et je ne suis pas persuadé d'y avoir perdu en productivité…
[^] # Re: prendre les choses dans l'ordre
Posté par freem . En réponse au message Comment installer Linux sur mon ordinateur? . Évalué à 3.
Petit points de détails…
Rolling release signifie que de nouvelles versions des logiciels sont intégrées régulièrement, qui ajoutent des fonctionnalités (et donc peut-être des bugs, tandis que les mises à jour de sécurité elles sont moins enclines à ce genre d'ajouts indésirables).
Debian Jessie, l'actuelle Testing, est sur le point (ou l'est-elle déjà?) d'un "freeze", ce qui signifie qu'elle ne recevra plus que des bugfixs jusqu'à devenir la version stable de Debian. Du coup, appeler Debian Testing une rolling release me gêne: ça dépend du moment.
Enfin, il y à une 3ème mouture de Debian, dite unstable, qui est elle réellement en rolling release. À noter quand même que les rolling release ont plus de risques à casser lors d'une MaJ.
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 2.
Je dis peut-être une connerie, mais il me semble qu'Ubuntu est sur du i486?
J'aurai du préciser: sur une machine de bureau :)
Je pense, notamment, aux navigateurs web, de loin l'application qui me bouffe le plus de RAM… quand je ne joue pas :)
Je n'essaierai même pas. Mais justement, une des dépendance qu'il gère est: "break". Du coup, il m'est arrivé de devoir passer plus de 5 minutes à sélectionner les bonnes versions sur N paquets. 5 minutes, c'est sûr, c'est pas la mort, mais pour un débutant, ça ne sera pas nécessairement si peu.
Et si l'OP installe des paquets de sources non officielles (genre, par exemple, les paquets wine-unstable, pour une raison où une autre, genre pour une appli pas encore supportée par wine-stable, qui est la seule présente dans les repo debian) il pourrait avoir ce genre de surprises.
Je pensais ici très précisément à AutoCAD. Vécu récemment (ça s'est fini dans une VMs avec windows 7). Bon, certes, il existe une version 32bits, je ne sais plus quels soucis j'avais dessus en essayant de l'installer, mais je n'ai pas télécharger 1.3Go puis 1.7Go juste pour le fun, tu peux me croire.
J'avais bien essayé de choper une version plus ancienne, mais introuvable sur le site officiel (pas trouvé comment, en tout cas) et pas la moindre motivation pour télécharger des trucs à la provenance douteuse pour le taf.
[^] # Re: KS
Posté par freem . En réponse au message Louer un machine sur le net. Évalué à 2.
En effet, j'avais pas pensé à cette petite bête…
[^] # Re: OVH VPS
Posté par freem . En réponse au message Louer un machine sur le net. Évalué à 2.
Merci pour ces précisions. C'est plus ou moins ce que je pensais, mais je voulais en avoir le cœur net :)
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 1. Dernière modification le 06 novembre 2014 à 18:26.
Faux. Il à dit:
ainsi que:
et
Hors, le X200 ne dispose, manifestement que de 2 Go de RAM… (améliorable à 4, à priori)
Bref, le hors sujet, c'est?
Mea culpa, j'aurai du dire que moins il y à de barettes de RAM installées, moins on tire sur la batterie, ce qui est en effet sensiblement différent.
Mais, personne n'à parlé de machine neuve. Mon netbook n'à que 3 ans, c'est vrai c'est pas tout récent, mais voila, c'est pas non plus super vieux. Et si je voulais jouer sur les mots, je parlerai de RPI, mais ce serait vraiment me moquer de toi.
Preuves? Non, parce que, comme je l'ai dis dans ce message, il y à 3-4 ans on trouvait encore des machines à 1Go sans souci, sous emballage neuf. Bon, après, c'est vrai, on peut parler de plusieurs années à partir de 2 ans…
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 1.
J'ai plusieurs machines qui disposent d'un seul Go.
Et qui t'as dit que l'OP utiliseras une machine récente?
D'ailleurs, sur une machine portable, moins on utilise la RAM, moins on tire sur la batterie, donc plus on à d'autonomie.
Bref, toi, tu t'en fous peut-être, mais ce n'est pas nécessairement le cas de tout le monde. Certains, comme toi manifestement, veulent juste du cutting edge. C'est leur droit, de changer de machine tous les 2 ans.
D'autres, comme moi, veulent pouvoir utiliser leur système dans la longueur, même quand mes machines ont 5, 6 ans, je continue à m'en servir.
Donc, on s'en fout de ta vulgarité, oui, c'est clair.
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 1.
Mouai. Si tu le dis. Moi, je dis que le 64 bouffe plus de RAM. Je peux l'expliquer, mais, comme toi, je ne vais faire qu'une simple assertion inutile, une sorte de demi-argument.
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 3.
Je n'ai même pas parlé d'espace disque… ou alors je veux bien que tu me cites l'endroit (je viens de faire un CTRL+F sur "disq" et il n'y à que 4 occurrences sur ce thread, dont 3 dans ton message, la dernière dans la réponse de Neox, mais rien à voir avec le multiarch) .
En fait, ça dépend des options d'optimisation utilisées. Ça dépend aussi de si l'appli génère un trafic important entre la RAM et les caches.
J'ai peut-être un peu trop raccourcis mon argument, je ne voulais pas dire que le 32 bits est moins performant que le 64 bits: ça dépend des usages.
Si tu utilises beaucoup de grosses valeurs numériques (sur plus de 32 bits) le 64 bit t'apporte quelque chose. Si ton applications en revanche n'utilise que des petites valeurs, c'est moins sûr, mais ça, le bench qui ne prend que des outils de compression/décompression/3D/stress test, il ne peux pas le montrer: ces applications sont très gourmandes en gros calculs, donc le 64 est clairement avantagé.
Un autre avantage du 64, c'est d'avoir un certain nombre de registres supplémentaires, dont on bénéficie en fonction du compilo et des options. Ça compense en partie le problème des pointeurs 2 fois plus gros, mais pas complètement.
Dommage que je ne parviennes pas à remettre la main sur les expérimentations que j'avais lues pour utiliser des pointeurs 32 bits en utilisant la puissance du proc 64… ils y expliquaient les choses bien mieux que moi.
Maintenant, je ne me souviens pas non plus avoir vu les spec de la machine que l'OP compte utiliser. J'ai cru comprendre que ça sera un PC portable, et s'il est un peux vieux, ce n'est pas déconnant d'imaginer qu'il n'y ait que 1Go de RAM. De nos jours, 1 Go ça pars vite, surtout sur internet, et quand tu commences à swapper, les perfs ne sont pas les mêmes.
Quand je regarde le bench que tu cites, et que je vois les spec de la machine, j'ai pas l'impression qu'il s'agisse d'une vieille bécane (8Go, core i7)… plutôt une bête de course! Et nulle part n'est indiqué combien de RAM est utilisé par les 2 systèmes.
Franchement, si je n'avais pas dû compiler sur mon netbook, j'y aurai peut-être installé du 32 bits, pour éviter de swapper quand je lançais le browser.
Après, je t'accorde une chose, je ne connais que la théorie à ce sujet, et comme je fais personnellement un usage plutôt intensif côté CPU de mes machines (la programmation, quand ça compile ça peut traîner, et d'ailleurs j'ai été très heureux de découvrir que clang avait une occupation mémoire de 20 bons % de moins que GCC en compilation… ça m'évitait de swapper quand j'utilisais tous les threads CPU.) je n'ai jamais fait de comparatif.
Ainsi que les libs dont wine dépends. Certaines pouvant être nécessitées par d'autres logiciels du système, et si, pour une raison ou une autre, on à un conflit entre la version de lib 32 et celle en 64 (bon, c'est indiqué par le gestionnaire de paquets, donc le système pètera pas…) on peut se poser des questions, quand on n'a jamais touché que du Windows.
Ah, et pour debian, il faut aussi activer manuellement l'architecture i386, avant d'installer wine.
Certes, c'est très simple, mais bon, un débutant imaginera-t-il qu'il faille mélanger les archi? Je pense qu'un débutant se dirait juste "bon, je fais comme d'hab, j'installe et voila" et ensuite se demandera pourquoi wine refuse d'exécuter telle ou telle appli, et risque d'imaginer que c'est de la faute au système.
Je ne parlerais pas non plus des applications windows compilées en 64 bits, dont le packageur est lui en 32 bits, il semble que wine ne gère pas encore ce genre de joyeusetés (expérience vécue récemment en tentant d'installer autocad, l'install foirait à cause de cette distinction).