Maxime a écrit 2334 commentaires

Alors oui tu peux jouer avec des C-r, c-R, c-o, c-O… mais déjà tu es obligé de jouer avec du ctrl ou alt, tu n'as pas d'accès direct

Je préfère Ctrl-r que F5 par exemple car F5 nécessite de bouger tout le bras alors que pour Ctrl-r, je ne décolle même pas le poignet.

Je pense qu'on parle ici d'un clavier spécialement dédié aux besoins de Mme Michu. Et Mme Michu elle n'utilise pas la touche Insert et lorsqu'elle appuie dessus par erreur, elle pense que l'ordi bug.

Personnellement j'utilise souvent Ctrl+Maj+C et Ctrl+Maj+V et ça ne me pose pas de problème, cela ne tord pas ma main dans tous les sens.

La touche insert n'a d'utilité que pour les raccourcis claviers qui l'utilisent car la touche était là et fallait bien lui trouver une utilité. On pourrait très bien remplacer cette touche par "Copier" par exemple.

Copier => copie la sélection
Maj+Copier => Colle (comme maj+insert)

Ainsi, on remplacerait un comportement rarement utilisé (passer en mode remplacement…) à un comportement très utilisé : copier.

Est-ce que vous avez un planning des conférences avec les salles ? Tout ce que j'ai trouvé sur le site c'est le planning par salle, c'est vraiment pénible d'essayer de se constituer un planning pour la journée vu que les confs ne sont pas synchronisées entre les différentes salles.

Personnellement, je suis en qwerty-us intl et je le trouve plus pratique pour écrire en Français que l'azerty (la plupart du temps).

J'ai les caractères accentués avec AltGr + la touche pour faire l'accent aigu. J'ai le ç avec AltGr + virgule. Pour les accents graves, c'est AltGr + ` suivi de la lettre à accentuer. Et tout cela marche aussi avec la touche majuscule. Ainsi, pour écrire É, je fais seulement AltGr + Maj + e, c'est plus rapide que Caps lock suivi de e suivi de Caps lock. J'ai les « » au niveau de [] et {}. J'ai aussi œ directement accessible avec AltGr.

En bonus j'ai tous les chiffres accessibles sans appuyer sur maj, et ne pas avoir de touches dédiées pour é, ç, ù, è et à permet d'accéder à plus de caractères. La disposition des caractères [], {}, (), <> est plus agréable.

Je ne connais pas le clavier Canadien. Est-ce qu'il est mieux que le qwerty-us intl ?

Non mais moi aussi je l'utilise (surtout le shift+insert pour coller ce que j'ai sélectionné). Mais je pourrais m'en passer. Ctrl+C, Ctrl+X et Ctrl+V est plus utilisé.

"pause" => Oui, qu'on le supprime.
"arrêt defil" => Idem.
"orig" => Je m'en sers tous les jours, comment tu fais pour aller en début de ligne ? Tu laisses appuyer la touche gauche ou tu utilises la souris ? Pense un peu aux utilisateurs de traitement de texte…
"fin" => Idem que orig.
"insert" => Ok pour supprimer, l'intérêt est limité.
"suppr" => Je dois être un vieux con mais j'utilise suppr très très souvent.
"page up/down" => Ok pour faire un raccourci genre Ctrl+Up et Ctrl+Down à la place ou utiliser une touche fonction. Par contre ça va casser un paquet de raccourcis clavier :/.
Les touches de fonction => ok pour supprimer, mais idem ça va casser un paquet de raccourcis ! Donc il faut les rendre accessible avec une touche Fn.

Bref, derrière ce troll vraiment moche, il y a quand même des choses intéressantes. Nous pourrions ajouter une touche Fn (genre à la place de la touche windows de droite comme sur mon clavier ?) et supprimer certaines touches physiques. Ceci peut se faire facilement au niveau du clavier.

Merci, effectivement le timeout est très long et sans aucun message pour me dire ce qu'il fait je pensais que samba n'était pas le problème.

Donc je pense que le problème est résolu sur l'une de mes machines. L'autre qui s'éteint très rapidement j'imagine que c'est le miracle systemd + SSD…

Je me réponds : il faut créer un dossier /var/log/journal si on veut que les logs soient persistants…

Merci mais je n'ai les logs que depuis le dernier démarrage. J'imagine que ça se configure ?

Je tourne sur toutes mes machines en Debian Jessie (pour le desktop), certains pensent que je suis fou car une mise à jour pourrait tout casser…

Alors oui ça arrive (très rare) et donc je ne peux pas le conseiller à un débutant qui fait tout seul ses mises à jour (car parfois il faut downgrader le package et c'est pas toujours évident). Je préfère également ne pas automatiser les mises à jour au cas où. Et je ne lance pas une mise à jour si je n'ai pas le temps de corriger une éventuelle erreur.

J'ai l'impression d'utiliser une distro en Rolling Release. Et je me demande donc : est-ce qu'une arch est vraiment plus stable qu'une debian testing ?

J'imagine qu'on doit aussi pouvoir faire une bdd de toutes les pubs existantes (on sort un hash à partir de l'audio/vidéo). Cela doit pouvoir se faire collaborativement et le logiciel doit aussi être capable de deviner que s'il y a une séquence de moins de 30s entre deux pubs, alors c'est certainement une pub et il peut éventuellement demander confirmation. Après, suffit donc de passer les pubs reconnues.

En 11pt, sur du fullhd, je passe de 212 colonnes à 239. Par contre en 11pt, le texte est plus lisible avec PragmataPro, donc je devrais passer à 12pt pour avoir le même confort. Et là je chute à 191 contre toujours 239 même si je passe à 12pt. Bref, 239 c'est presque 3 fois 80 colonnes ou 2 fois 120 colonnes, c'est pas mal. Bien sûr ça divise pas par deux la largeur, c'est pas magique.

Antoine a très bien répondu à cette question ici : http://linuxfr.org/news/microalg-langage-et-environnements-pour-l-algorithmique#comment-1569901

C'est donc l'arrondi à l'entier inférieur du résultat de la division. Je suis désolé d'avoir utilisé le terme division entière qui est un mauvais terme, je voulais dire par abus de langage : partie entière de la division.

Pour le terminal je suis en PragmataPro 11. http://www.fsd.it/fonts/pragmatapro.htm

Au début ça fait un peu bizarre mais on s'y fait très rapidement ! Et là on peut afficher plein de colonnes avec une taille de police raisonnable.

Dans ce cas, on peut dire que // c'est la division qui ne garde en résultat que la partie entière.

Il y avait une faiblesse dans Python2 qui a été corrigée. Cela donne donc :

>>> a = 2/3
>>> b = 2//3
>>> c = 2.0/3
>>> d = 2.0//3
>>> print(a, b, c, d)
0.6666666666666666 0 0.6666666666666666 0.0

Il faut donc juste retenir que / c'est la division et // c'est la division entière. Était-ce si difficile ?

Ici j'enseigne l'Ada à Bac+1 (première année école d'ingé en 5 ans). Je n'ai pas beaucoup d'expérience avec le Pascal mais pour moi c'est très proche (pour les bases en tout cas).

Je ne fais que des TD et TP, je n'ai aucun pouvoir décisionnel sur le choix du langage et la façon dont c'est enseigné. Mais ce n'est pas trop mal comme choix. Il y a tout ce qu'il faut pour enseigner les bases sans avoir à parler de pointeur ou d'objet trop rapidement.

Pour moi les inconvénients sont :
- Le langage n'est pas beaucoup utilisé donc les étudiants sont frustrés et ont le sentiment d'apprendre un truc qui sert à rien. En plus de toute façon on doit leur apprendre le C et le Java peu après (pour ceux qui se spécialisent dans l'info), ils aimeraient passer au Java plus rapidement.
- C'est un peu verbeux, surtout si on veut faire les choses proprement.
- Pas beaucoup de tutos sur internet pour ceux qui veulent approfondir.
- Pas toujours évident de trouver des encadrants qui connaissent bien l'Ada (on a une vingtaine d'encadrants ici pour les étudiants de première année). Heureusement que ce qui est enseigné est trivial (le public ne continue pas dans l'informatique pour 80% d'entre eux).

Mais si je devais choisir un langage pour enseigner, ce serait vraiment pas évident à choisir. Je pense choisir le Python mais ce qui me dérange c'est qu'on ne se rend pas toujours bien compte de la complexité algorithmique de ce qu'on fait. Mais au moins le code serait correctement indenté et les bons seraient davantage motivés pour approfondir.

En dehors de l'usage du Français, est-ce vraiment plus simple que de l'Ada ou du Pascal? Je cite ces langages car en lisant les exemples, j'ai vraiment l'impression de lire de l'Ada traduit en Français.

algorithme fonction connexite : entier
      parametres locaux
           t_graphe_s       G
      parametres globaux
           t_vect_entiers      cc
      Variables
           entier       i, no
debut
      pour i <- 1 jusque G.ordre faire
           cc[i] <- 0
      fin pour
      no <- 0
      pour i <- 1 jusque G.ordre faire
           si cc[i] = 0 alors
                 no <- no+1
                 prof_rec (G, i, no, cc)
           fin si
      fin pour
      retourne (no)
fin algorithme fonction connexite

En Ada :

function connexite(G : t_graphe_s) return Integer is
      i, no : Integer;
begin
      for i in 1..G.ordre loop
           cc(i) := 0;
      end loop;
      no := 0;
      for i in 1..G.ordre loop
           if cc(i) = 0 the
                 no := no+1;
                 prof_rec (G, i, no, cc);
           end if;
      end loop;
      return no;
end connexite;

Il n'y a vraiment pas en grande différence… Donc est-ce vraiment la peine de s'embêter à utiliser une copie traduite et avec encore moins d'outils à disposition ?

Est-ce que pour un gamin, la différence entre "tant que" et "jusqu'à" est très nette?

Je crois que tu sous-estimes trop les enfants.

Nous ne parlons pas du tout de la même chose. Ce que je n'aime pas c'est permettre à un étudiant de réutiliser des variables pour faire des choses qui n'ont rien en commun :

>>> a = 42
>>> type(a)
<type 'int'>
>>> a = "hello"
>>> type(a)
<type 'str'>

C'est l'une des restrictions de RPython par exemple.

En quoi le typage statique permet d'améliorer les choses ? Par exemple en Python tu n'as pas besoin de déclarer explicitement les types mais il y a quand même un type associé :

>>> a = "4"
>>> b = 4
>>> a + b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects

D'un point de vue pédagogique, le message reste le même : « on peut pas additionner une chaîne de caractère avec un entier, on ne mélange pas torchon et serviette ».

Ce qui me dérange c'est plutôt la possibilité pour une variable de changer de type en cours de route. Là ça devrait pas être possible.

Pour abonder en ton sens : j'ai personnellement appris la programmation avec le basic avant d'apprendre l'anglais. Et ce n'était pas un vrai problème. Alors bien sûr, ça donnait par exemple phonétiquement "elzé" pour "else" et je ne savais pas que c'était simplement le mot anglais pour "sinon", mais en dehors de ça, pas de problème pour l'utiliser.

Tout au plus ça peut jouer sur la facilité pour retenir certains mots clefs. Mais lorsqu'il n'y a pas 10 mots clefs différents à retenir, ça reste raisonnable.

J'ai collaboré avec Achraf le webmaster de qbworld et j'étais avec Élisée (Polyprogr@m's) l'un des initiateur de progboards avant que ça ne soit rapidement confié à Neliger.

Oui ça date… J'ai crée ce site il y a environ 15 ans !

Lorsque je parle d'ajout de sucre syntaxique c'est justement pour répondre à la critique que tu fais maintenant.

Tu dis : « il y a les touches √, x, ² ». Oui. Donc suffit de faire en sorte que √ soit une autre syntaxe possible de sqrt(). Idem la puissance, suffit d'avoir un symbole pour ça qui s'interprète comme un **. Et les utilisateurs comprennent bien le sens de "sin(45)", je pense qu'en l'espace de 1mn ils peuvent comprendre le sens de "sqrt(45)"… Mais encore une fois, on peut ajouter du sucre pour éviter ça.

Sur la remarque sur l'indentation, deux choses :
- je reconnais ce problème, je l'ai dit plus haut;
- lorsqu'on parle d'utiliser le Python, j'ai en tête une calculatrice dotée de plus de 15 colonnes évidemment.

Sur ce dernier point, je pense que nous n'avons pas tous la même chose en tête. Je ne parle pas de mettre Python sur l'équivalent d'une CASIO GRAPH 35 ou équivalent. Je parle de mettre Python sur du matos plus puissant (vu qu'on a souligné que c'était de très vieux processeurs actuellement utilisés). Par exemple si on fait un super environnement de calculatrice pour smartphone, je préfère avoir accès à du Python que du Basic.

Ça dépend de si ce Python-like permet de réutiliser du code Python standard et ne fait qu'apporter du sucre syntaxique et un ensemble de fonctions pour les I/O. Exemple : si je veux utiliser numpy, l'ajout de fonctions pour les I/O n'empêche rien.

Après pour répondre à ta question : l'intérêt c'est dès que ce qu'on cherche à faire devient un peu plus complexe…