anaseto a écrit 2229 commentaires

un mode "brouillard de guerre" (tilde?) pour trouver plus facilement les zones non explorées et donc les chemins restant.

Je teste du coup le caractère ░ pour les zones non explorées, ça donne pour une carte partiellement explorée :

Et pour une carte totalement explorée :

C'est un peu une combinaison des deux approches, ça a le mérite qu'on voit à la fois les points sur les cases explorées et clairement aussi quelles cases ne sont pas explorées.

En 5 min, mon envie de hacker s'est retrouvée réalisée, compilée et vérifiée : je préfère les gros blocs (ASCII 219) pour l'affichage des murs et un mode "brouillard de guerre" (tilde?) pour trouver plus facilement les zones non explorées et donc les chemins restant.

J'avais testé un peu les blocs, mais j'imagine que l'habitude des #, plus que ça fait un peut bizarre pour les diagonales, a fait que j'ai laissé ça finalement :) Par contre je suis un peu désorienté de ne pas voir les points ;)

Mais c'est vrai que ça serait pas très difficile de proposer deux styles différents, peut-être juste une option à passer en ligne de commande, à moins que je me décide à stocker une configuration.

Et je peux donc proposer mon idée en screenshots (qui manquaient)

C'est vrai qu'ils manquaient :) En voilà donc un avec le style par défaut (à option -s près), pour comparaison avec les tiens :

Il manque juste à mon avis une petite démo pour les débutants (montrer le principe et l'utilisation de chaque action disponible)

Peut-être une petite démo avec asciiscinema ?

un petit message "Using item %s" quand on s'équipe (pour confirmer notamment quand on échange avec un objet identique)

C'est fait !

Et l'option utile pour améliorer le pathfinding du joueur serait de colorer légèrement les bordures rencontrées du brouillard de guerre.

Je suis pas sûr de comprendre exactement. Colorer différemment les bordures qui viennent d'être rencontrées ?

Eh bien, j'ai choisi Go surtout parce que c'est un langage que je connais bien et avec lequel je suis assez productif. Après, j'aime bien la simplicité et les build rapides qui donnent un peu l'impression d'utiliser un langage dynamique (impression renforcée par l'intégration des tableaux dynamiques et maps dans le langage), mais avec un minimum de garanties de types statiques, un meilleur outillage pour les éditeurs comme vim et de meilleures performances.

Pour le choix d'utiliser le terminal avec la librairie termbox-go, il y a plusieurs raisons. Une première raison c'est que vu les objectifs assez précis que j'avais, je savais que c'était suffisant ; pour faire un jeu plus complexe, ça aurait pu être un peu limite, mais là avec un nombre limité de couleurs je peux transmettre toute l'information importante (est-ce qu'un monstre dort, se promène ou est en train de te chasser, par exemple). Une deuxième, c'est que c'est une librairie en pur go, donc ça simplifie les builds, ils sont plus rapides, plus simples d'un point de vue dépendance et la cross-compilation de projets écrits en pur go est aussi beaucoup plus facile. Pour des librairies graphiques, il faut actuellement passer par des bindings. Et, enfin, termbox-go est une librairie très facile à utiliser, en tout cas, j'ai trouvé que c'était le cas.

Mais ça n'empêche pas qu'un jour il serait possible faire une version graphique, même avec des tuiles : je n'ai pas beaucoup réfléchi en ce sens, mais la partie interface est plus ou moins abstraite du reste (à l'aide d'une interface go), donc avec de la motivation et un peu de temps, ça devrait être faisable sans trop de difficultés et sans tout chambouler.

C'est vrai, j'aurais dû le mentionner, il y a plusieurs variantes graphiques de Nethack (par contre pas forcément à jour sur la dernière version). Le wiki de Nethack est d'ailleurs une mine d'information :)

Je n'y avais pas pensé, vu que j'y mettais quelques opinions et ressentis personnels, mais pourquoi pas ! Edit : je le mets dans l'espace de rédaction ?

C’est plutôt récent, il y a encore quelques années, on contestait le réchauffement en soi.

Honnêtement, le problème avec le sujet du réchauffement, c'est qu'il s'agit d'un sujet scientifique dont tout le monde entend parler et, de façon surprenante, pas mal de monde s'improvise expert sur le sujet. Certains rigolos (je caricature peut-être un peu, et encore) iront jusqu'à dire qu'il n'y a pas eu de réchauffement le siècle dernier et que toutes les données sont truquées par je ne sais quelles folies, d'autres iront dire que oui, regardez, j'ai vu de la glace fondre dans les alpes, si c'est pas une preuve que les cyclones vont devenir dangereux et les ours blancs vont tous mourir, etc. Mais les scientifiques et les gens un peu sérieux ne font normalement ni l'un ni l'autre ; enfin, sans doute que dans le tas certains qui ont des intérêts économiques dans tel ou tels sens en fonction de qui les finance sont contents des déformations par les médias et la population de leurs propos dans un sens ou dans l'autre si ça peut assurer la pérennité de leurs financements, bien sûr.

Oui, mais pareil, ce « favorisées ou aggravées par le réchauffement » suivi d'une liste d'exemples n'est qu'un ajout journalistique, car, comme tu le dis, lier réchauffement à un phénomène particulier, aucun scientifique ne va se le permettre, car il ne le peut pas.

Et petit détail qui peut passer inaperçu, mais qui me semble avoir son importance : ils affirment qu'une tendance à l'accroissement de l'intensité est « likely » pour les tropicaux et « low » pour les extra-tropicaux, mais ils ne donnent pas d'estimation sur le fait que la cause de cette possible tendance soit précisément le réchauffement, juste sur le fait qu'il s'agisse d'une tendance solide ou non. D'où ma position qu'il me semble fragile de sous-entendre des liens de cause à effet qui visiblement ne sont peut-être pas forcément si évidents.

Effectivement, mea culpa sur ce point. Le paragraphe à citer est donc :

AR4 concluded that it was likely that an increasing trend had occurred in intense tropical cyclone activity since 1970 in some regions but that there was no clear trend in the annual numbers of tropical cyclones. Subsequent assessments, including SREX and more recent literature indicate that it is difficult to draw firm conclusions with respect to the confidence levels associated with observed trends prior to the satellite era and in ocean basins outside of the North Atlantic.

On est donc dans du « likely » à partir de 1970 pour une tendance à l'accroissement de l'intensité, et pas de données fiables avant 1970.

Je maintiens par contre que sous-entendre un lien entre précipitations à Harvey et réchauffement n'était pas très scientifique de ta part non plus :)

Oui, je conteste pas ces courbes, et j'ai exagéré avec mon « clairement erronée » pour le xkcd, elle est en fait juste un peu « grossière » ; mais c'était une remarque en passant, poussée par l'exaspération de voir des simplifications et des conclusions hâtives. Ce que je voulais contester c'est surtout la non-pertinence de poster cette courbe vis-à-vis du sujet qui était traité (les cyclones, précipitations, etc.), comme si ça apportait une quelconque lumière sur le sujet.

Pareil que plus haut, ça n'a absolument rien à voir avec le sujet traité. J'ai l'impression que tu réponds à quelqu'un d'autre. Edit : surtout qu'il ne me semble rien avoir dit sur le CO2, et que ta courbe de température ressemble à celle du document que j'ai donné en lien.

L'anomalie à ce jour est en effet proche de +1°C (enfin, ça varie un peu suivant les stations et les types de mesure et de l'intervalle de temps pris en compte, et je sais pas quelles données utilise le xkcd), c'est la forme de la courbe entre 2000 et 2013 qui me semble tracée à la va-vite, probablement dû à un choix simpliste des points, mais peu importe.

En effet, on s'égare, ma remarque portait sur les cyclones et les précipitations et le fait que des « low confidence » en science deviennent des « without any doubt » dans le monde du journalisme. Le xkcd n'a absolument rien à voir avec ceci, et n'était absolument pas pertinent dans le contexte. Ce n'est pas parce qu'il y a un réchauffement qu'il est forcément coupable de tous les maux qu'on veut par défaut : faut voir ce qu'en disent les scientifiques au cas par cas ; il n'y a pas de magic bullet qui répond à tout. En l'occurrence, pour les cyclones, eh bien, taper allègrement sur le réchauffement comme si tout était dit alors que les scientifiques sont à un niveau de « low confidence » sur une quelconque influence significative du réchauffement, c'est juste ridicule :)

Quoiqu'on pense, étant donné la hausse extrèmement soudaine de la moyenne des températures sur terre depuis le début du siècle comparé à l'évolution depuis la dernière ère glaciaire, autant prendre la question de réduction des émissions au sérieux:

Je suis d'accord qu'il faut le prendre au sérieux. C'est pour cela que, pour éviter de perdre sans faire exprès en crédibilité (ce qui ne sert pas bien la cause pour réduire les émissions et la pollution), il est mieux de se référer directement aux données officielles de l'IPCC (GIEC en français). Le chapitre 2 « Observations: atmosphère et surface » détaille l'état des observations tout en étant relativement accessible. En particulier, concernant les cyclones, on trouve :

In summary, confidence in large scale changes in the intensity of extreme extratropical cyclones since 1900 is low. There is also low con-fidence for a clear trend in storminess proxies over the last century due to inconsistencies between studies or lack of long-term data in some parts of the world (particularly in the SH). Likewise, confidence in trends in extreme winds is low, owing to quality and consistency issues with analysed data.

Les données officielles sur les températures (même chapitre) sont aussi plus raisonnables, mais non pour autant moins intéressantes, que la courbe clairement erronée sur la fin du xkcd ; je sais que l'objectif c'est de faire un truc amusant et marquant avec xkcd, mais j'ai peur que ça risque de décrédibiliser la cause plutôt que de l'aider et de donner des arguments faciles à ceux qui veulent polluer la planète…

On a tous vu les images d'Harvey qui a battu tous les records de pluviométrie aux USA.

Ton journal laisse penser que ceci est causé par le réchauffement climatique, mais probablement à tort et par simple effet journalistique. En tous cas, même des gens qui font de la recherche sur le sujet parmi ceux qui soutiennent la thèse du réchauffement anthropique le pensent. Tu trouveras dans l'article:

Global warming is a serious issue and mankind must deal with it, but hype and exaggeration of the current effects is counterproductive in the long term.

et

There is no evidence that global warming is influencing Texas coastal precipitation in the long term and little evidence that warmer than normal temperatures had any real impact on the precipitation intensity from this storm.

L'esprit du truc à l'air différent que pour Python3 : on dirait surtout un appel à ceux qui trouvent qu'il manque des choses dans ce langage à venir avec des vrais cas de problèmes pour illustrer, et pas juste des cas d'école qui restent dans l'abstrait.

Et puis, ça n'a pas l'air d'être pour demain, et il n'y aura peut-être même pas de changement non-compatibles:

Once all the backwards-compatible work is done, say in Go 1.20, then we can make the backwards-incompatible changes in Go 2.0. If there turn out to be no backwards-incompatible changes, maybe we just declare that Go 1.20 is Go 2.0.

Et j'imagine bien que, si changement incompatible il y a, un go fix au minimum sera fourni pour automatiser la transition.

mais il faudrait, oui :)

Voilà, j'ai du coup créé une liste de diffusion pour les utilisateurs de frundis chez tuxfamily. J'explique maintenant ici comment s'y inscrire.

Pour le reste, l'installation semble fonctionner. Je vais faire quelques tests. Pour ne pas polluer les commentaires, as-tu déjà l'idée de créer un canal IRC freenode dédié ? ou autre chose ?

Ayant juste, à ma connaissance, que quelques utilisateurs, je n'y ai pas trop réfléchi encore, à vrai dire, mais il faudrait, oui :) En attendant, il est possible de créer des tickets sur github ou juste m'envoyer un mail, les deux me vont, qu'il s'agisse d'un bug ou juste une question ou autre. D'ailleurs, quand on se pose une question, c'est souvent que quelque chose n'est pas suffisamment bien expliqué dans la doc, donc ça m'intéresse !

Pour anki il y a plus de cartes pré-faites disponibles en ligne, par exemple une recherche permet de trouver des trucs pour les régions (pas testé, par contre). A priori ça devrait pas être trop dur de les adapter pour Mnemosyne qui est plus adapté qu'anki pour les enfants, peut-être.

C'est effectivement lisible sans trop de difficulté. La seule chose qui me gène toujours (mais c'est sûrement parce que je suis pas développeur) c'est l'obligation d'un retour à la ligne à chaque emphase (par ex)… ça casse un peu la lecture pour moi.

Au tout début je m'étais fait la même remarque. Après, je me suis dit que si d'autres aimaient ceci, c'était qu'on s'y faisait. Je trouve après coup que c'est le cas, on s'y fait et, par rapport à LaTeX, on finit par apprécier le style plus épuré avec moins d'accolades et la distinction claire entre ce qui est balisage et le texte normal. Les deux styles ont leur plus et leur moins, je dirais, mais en pratique on s'y fait.

J'ai bien envie de m'y essayer sur un projet d'atelier d'écriture qui commence bientôt. Tu utilises quel éditeur pour gérer la coloration au mieux ? Cela dit, je resterai bien sous emacs pour le reste (tâches, notes, etc).

Dans les sources il y a un fichier de coloration syntaxique vim spécifique pour frundis, mais, honêtement, si tu connais emacs, reste sur emacs : le nroff-mode fait parfaitement l'affaire. Je connais pas très bien emacs, mais un commentaire du genre .\" -*-nroff-*- en haut d'un fichier devrait activer le mode (je suppose qu'il y a moyen de lui dire aussi que tout fichier avec l'extension .frundis doit utiliser le mode nroff).

Par ailleurs, j'ai installé Go via le package sous Fedora 25 (c'est la version 1.7 de Go)… tu aurais un tuto un peu plus détaillé pour savoir ce qu'il y a à faire ensuite ?

Alors, dans le .bashrc, tu écris :

export GOPATH="$HOME/go"
export PATH="$GOPATH/bin:$PATH"

Ça dit que tous les programmes go seront installés dans le répertoire $HOME/go, et après on ajuste la variable PATH pour que bash trouve les exécutables.

Et ensuite (après avoir fait source ~/.bashrc) juste lancer la commande : go get github.com/anaseto/gofrundis/bin/frundis. Il n'y a rien d'autre à faire, la commande frundis et alors disponible normalement.

Les pages de manuel, par contre, il faut les placer manuellement à un endroit où man les trouve (ou sinon, plus simple, juste les lire sur le site, ou bien lancer man ./frundis.1 en spécifiant le chemin).

assez simple

Enfin, il n'est pas si simple, parce qu'il inclut un fichier declarations.frundis commun à la plupart des autres livres, qui définit le style d'export de quelques éléments sémantiques et dans lequel sont utilisés aussi quelques variables ; pour un document simple, on peut faire beaucoup plus simple, ici c'est vraiment pour faire de la réutilisation entre divers documents pour un projet de plusieurs livres. Mais j'ai rien de mieux sous la main, donc j'espère que ça te donnera une idée des choses :)

Si j'ai bien suivi, Frundis n'est à ce stade utilisable qu'en ligne de commande avec un export pandoc ?

On peut exporter depuis la ligne de commande vers LaTeX, HTML, EPUB et, depuis plus récemment, vers markdown et groff mom. frundis, c'est juste un langage + l'outil en ligne de commande, il n'est pas lié à un éditeur ou interface particulière, n'importe quel éditeur de texte fait l'affaire, et la coloration syntaxique pour des documents roff (utilisé entre autre pour les pages de manuel sous linux) fait l'affaire pour frundis (la syntaxe de frundis étant un sous-ensemble simplifié).

À vrai, dire je serais assez preneur de voir un document un peu gros dans ce langage voir l'usage qui en est fait dans une vidéo.

Alors, des vidéos, j'ai pas ça sous la main. En exemples, il y a l'exemple sur la page du site et, en document plus gros, tu peux regarder les sources d'un des livres de kaoseto, celui-ci est assez simple (par contre, je sais pas si la version qui se trouve là est à jour totalement sur le langage, ça date d'il y a deux ans). Il permet de voir quand même dans le préambule qu'on peut inclure certains blocs uniquement pour l'export LaTeX (pour mettre en page plus joliment un poème dans la version LaTeX), tout en ayant un document qui permet d'exporter aussi vers les autres formats.

Bon, c'est pas troll mais une question sérieuse.

Pas de soucis :)

Je connais un peu org-mode aussi et c'est assez plein de fonctionnalités, en effet. Par contre, ça reste un langage de balisage léger très « dynamique » si on peut dire ça comme ça, pas très formel et qui protège peu des erreurs de balisage (pas prévu pour à la base, en même temps). Et, pour autant que je sache, il propose pas de moyen simple de faire du balisage sémantique flexible, même si j'imagine bien que, vu que c'est essentiellement lié à emacs (les équivalents sur d'autres éditeurs font pas le dixième et sont peut-être même pas compatibles), il doit peut-être y avoir moyen de l'étendre pour faire à peu près ce qu'on veut si on sait programmer en Emacs Lisp.

Donc, je dirais, pour résumer, que les fonctionnalités et les caractéristiques d'org sont plutôt différentes de celles que l'on trouve dans frundis : c'est du balisage léger, avec syntaxe plus complexe qui protège moins des erreurs, dépendances vis-à-vis d'Emacs et Emacs Lisp, des fonctionnalités initialement plus orientées vers TODO list et autres, et qui petit à petit s'étendent, donnant au final un langage assez complexe, mais qui pourtant ne fait pas facilement du balisage sémantique ; frundis, en comparaison, plus léger, a des objectifs plus ciblés et il est possible d'apprendre le langage dans sa totalité assez vite. Le seul point qui réduit peut-être l'accessibilité, c'est que la documentation est dans des pages de manuel et que j'ai l'impression que ça a tendance à faire un peu peur, peut-être (troll inside) un traumatisme de pages man d'outil gnu décrivant trente-six mille options en vitesse et renvoyant à la fin sans exemples vers la page info, je sais pas :)

Par contre, je suis en train de réfléchir à faire un « navigateur » pour trouver des cartes à éditer et, j'ai l'impression qu'un truc comme appuyer sur f (pour find), écrire un pattern, entrée, puis recevoir une liste numérotée de cartes qui correspondent et choisir alors la carte à éditer serait pas mal ; et, si disponible, lancer un fuzzy finder externe pour choisir la carte plus facilement.

Voilà, c'est fait et commité !

Est-ce qu'il y a, à votre connaissance, des projets collaboratifs pour construire et/ou capitaliser les fiches ?

Les logiciels anki et mnemosyne ont des reccueils assez conséquents de fiches, en particulier pour les langues, mais pas que. C'est souvent pas très difficile de les adapter pour morji, vu que anki et mnemosyne proposent des formats de sortie en fichiers textes TSV similaires à ce que peut prendre morji en entrée. Le seul hic, c'est si les cartes anki ou mnemosyne utilisent trop d'html, ça peut demander un peu d'efforts pour nettoyer et adapter au format plus simple de morji (pas de balisages imbriqués).

Perso, j'ai dû faire un peu ça pour importer ma base de données mnemosyne vers morji ; ça s'est fait assez facilement, mais c'est par contre difficile de faire une fonctionnalité d'import vraiment générique.

Pour les langues, c'est facile de récupérer des trucs de dictionnaires ou de collections de phrases avec traduction (par exemple Tatoeba).

Ceci dit, un truc à garder en mémoire, c'est que si utiliser des collections de fiches faites par d'autres peut s'avérer parfois pratique (je le fais des fois), ça peut être aussi assez piégeux. En effet, l'objectif de la répétition espacée est de permettre de ne pas oublier des choses que l'on a appris et d'être un complément à l'apprentissage. Le risque c'est de se retrouver à essayer de mémoriser du contenu que l'on a pas vraiment compris ou qui n'est pas organisé d'une façon adaptée à soi, mais adaptée à son créateur, qui parfois n'a peut-être pas inclus des choses qui lui semblaient évidentes et qu'il a appris par d'autres moyens. C'est pourquoi faire ses propres cartes, c'est souvent mieux, et je dirais surtout lorsqu'on débute, parce que ça motive et c'est didactique. Un ensemble de règles pour la création de cartes souvent mentionné est celui des 20 règles pour formuler la connaissance sur le site de supermemo.

bon ça suppose peut-être d'avoir un peu trop de données à vouloir se souvenir et ça dépasse le cadre de ce logiciel.

Je dirais que ça pourrait rentrer dans le cadre de morji, a priori, oui. Avec morji (ou anki ou mnemosyne), c'est largement possible de se débrouiller avec des dizaines de milliers de cartes.

si tu en as un certain nombre au lieu de le faire aléatoirement tu peux choisir ceux qui sont en relation

Je vois un peu ce que tu veux dire, mais l'idée avec morji (ou les logiciels de répétition espacée en général), c'est qu'en dehors de vacances ou autres interruptions, tu réussis normalement à réviser toutes les cartes (tous thèmes confondus) qui sont dues en un jour donné : la partie révision en pratique n'est pas trop longue (10 à 20 minutes si on est à un rythme de 15 nouvelles par jour), c'est la partie apprentissage de nouvelles cartes (et création) qui prend le plus de temps.

Par contre, je suis en train de réfléchir à faire un « navigateur » pour trouver des cartes à éditer et, j'ai l'impression qu'un truc comme appuyer sur f (pour find), écrire un pattern, entrée, puis recevoir une liste numérotée de cartes qui correspondent et choisir alors la carte à éditer serait pas mal ; et, si disponible, lancer un fuzzy finder externe pour choisir la carte plus facilement.

As-tu pensé à une version web ?

Pas vraiment. Pour ça, je pense que le plus pragmatique, c'est d'utiliser anki, qui a une version pour android. Mnemosyne aussi, il me semble. Après, vu que la base de données de morji est simple (pas de stockage de statistiques non essentielles), ça ne serait pas très difficile de faire une version web de morji qui s'occuppe au moins de la révision (donc sans édition de cartes et le reste, moins utiles en déplacement, je suppose), mais perso ça me motive un peu moins de le faire, vu que j'en ai pas trop l'usage.