rewind a écrit 3425 commentaires

Ça dépend. Moi, j'enregistre ce que je soumets (sauf quand ça passe par la tribune de rédaction). Et c'est vrai que je me suis déjà fait la même réflexion que celui qui a soumis le bug. L'export Markdown me va parfaitement ! Et même pour celui qui n'a pas sauvegardé son texte, ça lui permet de pouvoir le faire facilement.

Je vois d'ailleurs que ça a été déployé ce soir.

Je n'arrive pas à trouver la bonne page, je crois. Je pense que je ne cherche pas au bon endroit… Tu peux m'aider ?

Techniquement, comment tu fais ? Tu aurais un tutoriel ou un jeu qui fait comme tu le décris ?

Étant le premier développeur de Jyraphe, je suis très content de voir Jyraphe voler de ses propres ailes (même si une jyraphe n'a pas d'aile). C'est vrai que j'ai délaissé ce projet depuis bien longtemps, par manque de temps et surtout manque d'intérêt. Il y a eu quelques pics d'activités sporadiques sur la mailing-list ces dernières années mais je n'avais plus l'envie pour m'y investir autant qu'il aurait fallu. Et donc, la conséquence naturelle, c'est que pas mal de forks sont apparus. Ce qui est très bien !

Après, mon souhait serait de fermer définitivement le projet sur GNA (virtuellement), puisqu'il est évident qu'il ne reprendra plus et que les forks apportent tout ce qu'il faut. Et j'aimerais aussi pouvoir rediriger les personnes intéressées et qui arrivent sur la page GNA vers les bons forks, puisque, comme je le comprends, chacun de ces forks n'a pas les mêmes objectifs d'évolution. Est-ce que ceux qui trainent par ici et qui sont impliqués dans ces forks sont d'accord pour ça et aussi, est-ce que la description de jihele un peu plus haut dans les commentaires pourraient convenir ?

Soit 7 jours, 15 dépêches sur la première page (!?).

Pas très représentatif. Essayons avec plusieurs pages pour se faire une idée :

• page 1 : 25/02 - 18/02 : 7 jours
• page 2 : 18/02 - 13/02 : 5 jours
• page 3 : 13/02 - 11/02 : 2 jours
• page 4 : 11/02 - 07/02 : 4 jours
• page 5 : 07/02 - 02/02 : 5 jours
• page 6 : 02/02 - 27/01 : 6 jours
• page 7 : 27/01 - 20/01 : 7 jours
• page 8 : 19/01 - 14/01 : 5 jours

J'arrête là. On peut aussi regarder les statistiques de l'an dernier. Il y a eu 1035 dépêches, soit environ 2,84 dépêches par jour. Avec 15 dépêches par page, les dépêches restent donc en moyenne 5,29 jours. Et c'est une moyenne, on voit avec les chiffres au dessus que c'est très variable. Pour celui qui a écrit une longue dépêche qui est publiée le 11/02, et bien sa dépêche disparaît deux jours plus tard et c'est très frustrant. Et je le sais, parce qu'une de mes dépêches a été publié le 12/02.

Et je ne parle même pas des journaux. Parce que même s'ils n'apparaissent pas sur la page principale, pour ceux qui vont les lire et les commenter, ça prend du temps aussi, donc il faut les prendre en compte, parce que les journées n'ont que 24h et le temps de moulage sur linuxfr est probablement une durée fixe. Si je reprend le cas de ma dépêche, dans les 2h qui ont suivi sa publication, on a vu 3 journaux qui sont à plus de 100 commentaires dont 1 à plus de 200 (merci systemd). Bon, c'est un coup de pas de bol, mais voilà, il faut bien comprendre que ça freine l'écriture de dépêche de qualité : pourquoi se faire chier si tout ce travail disparaît en quelques jours dans les oubliettes de linuxfr ?

Actuellement, je suis en train d'écrire le prochain épisode de ma saga sur les jeux vidéos. À la louche, je dirais que j'y ai passé déjà une dizaine d'heures en cumulé (c'est vraiment un gros épisode, pour les autres, j'étais plus autour de 3-4h). S'il disparaît en quelques jours, je vais être un peu déçu. Bon, ça ne m'arrêtera pas, mais voilà, ça fait chier.

Écrire une dépêche avec du contenu intéressant, ça prend beaucoup de temps. Vraiment beaucoup de temps. Donc trouver une solution pour que ces dépêches puissent être plus visibles, c'est vital. Parce que quand on voit qu'on disparaît au profit d'une annonce de LUG ou de la revue de presse de l'APRIL qui reçoit très rarement plus de 1 commentaire, on se sent un peu rageux.

Ha mais on peut continuer à critiquer le goto. Je suis tout à fait d'accord que son usage se justifie dans quelques cas bien identifié (grosso modo, les codes au cheminement complexe, comme les cas d'erreur du journal ou encore les parseurs), mais dans tous les autres cas, on a inventé des structures pour cacher les goto et avoir une sûreté supplémentaire, généralement parce qu'on a une portée (scope) différente et donc, on a des garanties sur la durée de vie des variables et tout ce genre de chose.

Pour moi, on pourrait continuer à inventer des structures pour les cas restants. Le goto fait partie d'une ancienne boîte à outils qui n'est plus guère compatible avec les techniques modernes. Si on prend juste le fait de déclarer les variables au plus près de leur première utilisation, c'est compliqué avec des goto, parce qu'on n'a pas le droit de passer par dessus une déclaration de variable.

Pas break qui sert déjà à trop de choses (imagine que tu veuilles lancer une "exception locale" comme je décris au milieu d'une boucle, et bien ça ne marchera pas). Et goto, ben heu, voilà quoi.

Retrouver une syntaxe proche des exceptions ne me choquerait pas, mais ça ne serait pas possible pour ne pas casser la "compatibilité" entre C et C++. Si je devais vraiment me creuser la tête, je proposerais peut-être check (pour try), fail (pour catch), discard (pour throw).

Surtout que la gestion des exceptions en c++, c'est loin d'être gratuit.

Tout dépend de ce que tu appelles gratuit. Si c'est à l'exécution, si, c'est gratuit sur pas mal d'architecture. Si tu parles en terme de maintenance, c'est pas pire qu'autre chose et parfois, c'est plus simple (dans le cas de parser par exemple, où on peut arrêter à n'importe quel moment).

Sur la plupart des architectures, les exceptions sont gratuites au sens où il n'y a pas de code supplémentaire qui est exécuté si aucune exception n'est levée. Et pour les autres, ça utilise setjmp/longjmp donc je dirais plutôt que les exceptions sont imbattables en C++.

Je pense qu'il voulait dire -fno-exceptions qui supprime toute la gestion des exceptions. Le -fno-rtti empêche de faire des dynamic_cast (entre autre).

Perso, je n'ai quasiment jammais utilsié les exceptions en C++.

Moi non plus, mais dans le cas que je décris, c'est juste un goto déguisé, comme peuvent l'être les break et autre continue. Donc, pas d'exception (au sens normal du terme) à gérer. Mais c'est vrai qu'il faudrait peut-être une autre syntaxe pour différencier des vrais exceptions.

Pour reprendre l'exemple de CrEv :

try {

  // bla bla bla

  if (/* comportement pas glop */) {
    throw;
  }

  // bla bla

} catch {
  // traitement des cas en erreur
  return k_fail;
}

Et pour reprendre l'exemple du journal :

static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) {


OSStatus err;

// ...

try {

  if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) {
    throw;
  }

  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
    throw;
  }

  if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) {
    throw;
  }

} catch {
}

SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);

return err;
}

J'ai toujours rêvé d'avoir un truc genre try/catch mais local à une fonction, c'est-à-dire qu'on doit faire le catch au même endroit que le throw (donc pas de gestion d'exception). Je trouve que ça permettrait de se débarrasser presque définitivement des goto. Et en plus, ça serait plus simple à lire et à comprendre.

Le problème n'est pas dans la quantité… Depuis le début, on nous vend logind, journald et systemd (l'init, pas le projet complet) comme étant des trucs séparés qu'on peut remplacer par d'autres composants toussa toussa. Et là, paf, on met tout ensemble. Moi, je dis qu'il y a comme un problème, mais après, je veux pas être mauvaise langue. N'empêche que si on va relire tous les trolls sur la dépendance de GNOME à systemd, je pense qu'on va bien se marrer avec des arguments de l'époque qui viennent de voler en éclat d'un seul coup.

il lui manque juste un bon système d'init ;)

j'aurais plutôt dit qu'il manquait un éditeur de texte :P

We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login
and libsystemd-daemon into a a single libsystemd.so to reduce code
duplication and avoid cyclic dependencies (see below).

C'est marrant comme systemd peut être un vrai nid à trolls. Il faut dire que Lennart y met beaucoup d'entrain. Là, pour les non-anglophones, il annonce qu'il fusionne plusieurs bibliothèque en une seule. Et quand on voit la liste, on se dit que systemd devient de plus en plus un truc monolithique, loin de ce que ses défenseurs nous vendent depuis des lustres comme quoi tout est bien séparé. Bref, je constate que les pourfendeurs de Lennart avait vu juste sur ce point… et la suite alors ? Va falloir refaire du pop corn là !

D'un point de vue technique, Kanboard est une application web développée en PHP et utilise Sqlite pour enregistrer ses données

Oui, donc tu dis en fait qu'il faudra de toute façon passer par un panneau de configuration pour l'input. Mais sur le tuto, j'hésite encore. Dans FF12 par exemple, dans mon souvenir, au début, il y a un tuto pour prendre en main le jeu, ce n'est pas très long (et d'autres aspects du jeu sont mis en tuto plus loin dans le jeu) et ça permet de bien introduire les mécaniques du jeu je trouve. Je voulais ajouter la configuration des touches mais bon, peut-être que ça fait trop du coup. Je vais continuer à réfléchir.

OK, c'est plus générique que ce que je pensais. Du coup, j'ai une question subsidiaire ;) En fait, je me dis que je ne pourrai pas échapper à la configuration de l'input, quel qu'il soit. J'ai vu que tu avais un widget prédéfini pour ça d'ailleurs. Ma question est : penses-tu que ce soit possible de le faire de manière plus interactive ? En fait, pour mon jeu, j'aimerais que le joueur puisse configurer son input au fur et à mesure, genre au début "appuyer sur la touche OK". Et ensuite, "appuyer sur Avancer", etc. Puis je fais bouger le joueur. Puis "appuyer sur Annuler", et je le fais utiliser cette nouvelle touche en jeu. Et du coup, la configuration se fait au fur et à mesure en montrant à quoi sert quelle touche façon tutoriel. Bon, ça c'est mon rêve, maintenant, pour toi qui a déjà mis les mains dedans, est-ce que ça te semble faisable et/ou facile ?

Ton journal tombe bien parce que j'avais une question sur les interfaces que tu développes et tu y réponds en partie mais j'aimerais en être sûr.

Ici, comme je le comprends, tu unifies toutes les interfaces en considérant qu'elles partagent toutes un ensemble d'actions simples (déplacement, «ok», «annuler»), c'est bien ça ? Et donc, tu fais tout pour ne pas avoir d'interaction spécifique à une interface particulière. Ma question est : est-ce que ce n'est pas handicapant ? Parce qu'avec une souris, tu pourrais avoir une interface bien plus riche qu'avec une manette, ou différente disons. Est-ce qu'on ne se prive pas de modes d'action possible dans un jeu à cause de cette unification ? Jusqu'où peut-on pousser l'unification sans que ça ne paraisse trop artificiel ?

Dans mes réflexions préliminaires (en grande partie dû au fait que tu m'as dit vouloir jouer avec une manette au tout début, merci bien !), j'avais pensé à faire quelque chose dans ce genre là donc ça ne me paraît pas si dénué de bon sens. Mais je me demande vraiment si ça ne va pas être limitant en pratique.

Et du coup, tu conseillerais plutôt de ne pas prendre en compte VS ? Je me pose la question, j'ai suivi des débats sur la mailing liste de LLVM et c'était pas triste de trouver un sous-ensemble de C++11 qui soit acceptable pour le développement de LLVM, et le problème venait toujours de VS. Ils reconnaissaient que ça s'améliorait avec les dernières versions mais il y a encore tout un tas de VS qui sont mauvais niveau C++11.

Personnellement, je ne vais pas utiliser VS, même pour compiler pour Windows. Donc, j'en ai un peu rien à faire en vrai, mais j'aimerais avoir l'avis de quelqu'un qui a manifestement l'expérience du sujet.

les députés, élus sur des listes

Encore raté. En fait, tu ne sais pas du tout de quoi tu parles, tu penses qu'on vote pour un maire en uninominal et pour un député sur une liste alors que c'est exactement le contraire.

Tiens dans le genre de probabilités qui ne devraient jamais arriver, il y a l'Euromillion. La probabilité de gagner à l'Euromillion est bien plus faible que les probabilités que tu nous as annoncé pour le tirage au sort. Et pourtant, quasiment toutes les semaines, quelqu'un gagne, c'est dingue hein.

Il y a deux sortes de gens. Ceux qui comprennent les probabilités, et les autres ;)

Visiblement, tu comprends les probabilités mais pas les statistiques. Si la probabilité n'est pas nulle, c'est que ça peut arriver, et donc, ça arrivera si tu renouvelles l'expérience suffisamment de fois.

Le discours "l'essence de la démocratie c'est de choisir des représentants" je ne l'accepte pas.

Je n'ai jamais dit ça, justement. J'ai bien parlé de choix politiques, pas de choix de personnes. Dès qu'on vote pour des listes, les aspects personnels entrent moins en ligne de compte que le programme politique.

On vote des personnes, qui font ce qu'elles veulent, une fois arrivé au pouvoir.

Et qu'est-ce que ça change avec le tirage au sort ? Elles vont bien faire ce qu'elles veulent aussi, sauf qu'on n'aura pas su au départ ce qu'elles voulaient faire.

Le maire est le président du conseil municipal, il n'est pas seul, il est avec une majorité du conseil municipal, rien à voir avec le président de la république qui est bien élu tout seul lui.

Notre système actuel est très complexe puisqu'on ne peux pas voter à plus de deux élections dans la même année… Il y a régulièrement des reports !

Rien dans la loi n'impose à ce qu'il y ait au plus deux élections par an. Ce sont les députés qui décident de reporter les élections, mais ce n'est en aucun cas une obligation. Je me souviens une année d'avoir voté le même jour pour les municipales et les cantonales (c'était en 2008), on aurait pu avoir un autre scrutin plus tard dans l'année.