Grâce à ce commentaire à propos des boutons de download, je me rend compte qu'avant de se lancer dans l'implémentation du nouveau design, il faut d'abord choisir quels navigateurs on souhaite supporter.
Pour Chrome, c'est difficile de retrouver les anciennes versions, Google force les mises à jour et ne supporte que la dernière version. Je propose de supporter la version Chromium de Debian oldstable (soit la version 57): https://packages.debian.org/search?keywords=chromium
J'avais déjà prévu une correction pour IE, il devrait aussi corriger l'affichage de ces anciens navigateurs: à la place d'utiliser les grid de CSS, je joue simplement avec la désactivation du float que l'on utilisait avant.
Pour Android, le "navigateur par défaut/de base" n'existe pas par exemple sur les smartphones Samsung, c'est un navigateur spécial fait par Samsung (qui est sûrement crée au-dessus du WebView d'Android, mais ça ne change pas grand chose à mon problème: je ne peux pas tester, je n'ai pas le matériel).
En plus, ce genre de navigateur pose des problèmes de sécurité à cause de certains algorithmes indisponibles (par exemple, certains algorithmes de TLS) ou des failles de sécurité jamais corrigées. D'ailleurs, Google a décidé de ne plus lier le "navigateur par défaut" à Android, mais de livrer "Chrome pour Android" pour que les mises à jours du navigateurs ne doivent plus attendre les mises à jours Android des constructeurs (qui sont quasiment inexistantes).
Est ce que les version ESR de Firefox fonctionnent toutes ? voilà ce qu'il faut trouver le temps de tester.
Qu'est-ce que tu entends par "les versions ESR de Firefox fonctionnent toutes" ?
Par exemple, pour Firefox ESR 45, cette version est sortie en 2016 et n'est plus supportée par Mozilla depuis la version ESR 52.2 sortie en juin 2017. Cette version est elle-même remplacée par le support de la version ESR 60.2 sortie en septembre 2018. Cette version actuelle ESR perd son support cet automne.
Si tu veux vraiment les supporter "toutes", la première version ESR est sortie en janvier 2012 ;-)
PS: tu peux cliquer aussi sur le tritre des éléments pour lire la suite.
pas compris
Pour lire les articles au complet, je voulais dire que le titre des dépĉhes/journaux/liens/entrées de forum est aussi un lien cliquable pour voir l'article complet.
Eh ben, c'est hyper intéressant de lire ces deux billets :-)
Ils ont eu de très bon commentaires sur leurs choix techniques avant même de les implémenter !
Je pense que ça a été très bénéfique pour eux cette transparence des choix techniques avant même leur mise en place: ils ont en tout cas évités des frais inutiles.
Tiens, il y a aussi un autre usage: le tir sportif.
J'y pense parce que je vais devoir bientôt voter pour durcir la loi sur les armes à feu en Suisse.
Et justement, un des arguments du comité contre cette mise à jour de la loi est que les tireurs sportifs ne pourraient plus utiliser d'arme (mais il me semble que leur argumentation est douteuse).
J'avais aussi l'habitude de "plus petit multiple commun" à l'école obligatoire, puis à l'uni on a parlé de "plus petit commun multiple". Comme en français les adjectifs peuvent être placés n'importe où (à peu près), tous les deux sont justes et expriment la même idée :)
Merci Kantien, ça me semble plus clairement posé que mon résumé :)
Quand tu écris ceci:
type patch
type state
val commit : patch -> state -> state
val merge : state -> state -> state
J'ai juste un doute sur les deux dernières lignes: commit et merge sont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?
Pour essayer d'exprimer avec les conventions mathématiques dont j'ai un peu plus l'habitude (style f(x,y) = z avec les préfixes des arguments leur type):
commit(patch: x, state: A) = state: B
merge(state: A, state: B) = state: C
L'idée d'illustrer avec des opérations simples (multiplication et ppcm) sur les nombres est très bonne aussi.
Pour la phrase suivante:
La solution est de prendre un type plus riche que les liste pour les sommets du graphe : à savoir des graphes de lignes (dont les listes sont un cas particuliers).
Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).
Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
Le patch dépend d'un fichier source
Le patch travaille ligne par ligne (et non pas mot par mot)
Un patch peut ajouter des lignes, mais ne pas les modifier
Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
Ecrire les graggles de A et B l'un à côté de l'autre
Quand une ligne de A et de B partagent le même parent, fusionnez les parents en une seule ligne.
A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
… mais quand même tous les algos qui marchent, pour la première fois !
Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
Bravo !
Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles…
PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.
Ah pardon, c'est moi qui avait mal installé le système, il faut bien sûr installer le paquet ruby-rack pour faire fonctionner correctement board-linuxfr. Il faut que je mette à jour mon fichier d'installation :)
Merci pour la confirmation, je me doutais que la page de rédaction n'était pas complète à cause du manque des événements :)
Je suis un peu bloqué, je n'arrive pas à lancer board-linuxfr avec Ruby 2.3.
J'ai vu que Goliath a besoin de Ruby 1.9.2, j'ai donc suivi leur tutoriel d'installation, mais je n'arrive pas à l'installer. Il semble qu'il y ait un problème de versions nécessaire de ruby entre rack et goliath (j'ai dû même changer la version de rubygems pour réussir à lancer l'installation, c'est pas évident :/).
Du coup, je suis un peu bloqué pour continuer le travail sur l'espace de rédaction. Tu aurais une piste pour me sortir de ce sac de nœud de versions des différents composants ?
Je suis en train d'essayer de faire du dev sur l'espace de rédaction et je vois que mon navigateur essaie de joindre la route "/b/un_identifiant_a_rallonge". Cette route n'est pas enregistrée dans rails et du coup je reçois un 404.
Dans ton ansible, j'ai vu que tu demandais à Nginx de rediriger "/b/" vers un socket unix "board.sock". Est-ce que tu te souviens de ce que c'est ? J'ai l'impression d'avoir raté quelque chose.
Edit:
Ah ben je viens de voir le lien the board-daemon dans le Readme :)
Par rapport à HTML, les syntaxes comme Markdown / BBCode sont utiles pour empêcher l'injection de code malicieux dans ton site.
Pour les sites, c'est donc bien plus simple de valider le texte reçu de l'utilisateur:
il vire tout le code HTML qui pourrait y être présent
il lit le reste avec la syntaxe qu'il a choisi
il fait un rendu pour l'utilisateur et demande la confirmation à l'utilisateur.
Il serait également possible de définir un sous-ensemble des tags et attributs HTML et faire le même travail en théorie. Mais ça demande plus d'investissement: il faut utiliser une représentation XML et l'utiliser pour enlever tout ce qui n'est pas dans ta liste blanche de balises et attributs HTML.
Ok et avais-tu déjà choisi de les stocker en base de donnée ou sur le système de fichier ? Je ne sais pas trop ce qui est envisageable comme je ne connais pas l'architecture système actuelle…
Pour cette série, je me pose des plusieurs questions:
Si on commence à faire intégrer une image par article, est-ce qu'il faut commencer à proposer le stockage des images directement sur le serveur de LinuxFr ? L'idée, c'est qu'avec ce nouveau design, l'image fait vraiment partie de l'article, du coup, faudrait-il un stockage pérenne ou on continue d'accepter des liens qui peuvent casser ?
Pour la citation de l'auteur de l'image en Markdown, il ne semble pas y avoir de manière standard. Est-ce que l'on ajoute une nouvelle notation spécifique à LinuxFr ? Ou est-ce que l'on met toujours la citation dans le texte alternatif de l'image ? J'ai vu aussi sur Stack Overflow une solution proposant d'utiliser le tag HTML <cite> pour les bloques de citation.
Pour l'instant, je vais faire des tests où on continue de ne pas stocker d'images sur LinuxFr. Dans ce cas, j'ai juste besoin d'ajouter un champ aux articles qui contient le lien Markdown avec la citation.
Merci pour la mise à jour de la maquette, j'aime bien cette proposition qui permet de retrouver la source sans avoir à toujours afficher le bouton pour le Markdown.
Si je me souviens bien, la fonctionnalité de télécharger le fichier "Epub" est arrivée il y a 4-5 ans dans la vie du site. En fait, c'est vraiment plus pratique pour la plupart des lecteurs et je trouve que c'est une bonne idée de mettre en avant uniquement ce média hors-ligne.
Le bouton "Afficher la source" est aussi pratique pour pouvoir exporter son article vers d'autres plateformes qui comprennent le Markdown (comme des blogs personnels, par exemple).
Pour l'instant, je propose de laisser le pied de page tel qu'il est actuellement et de reprendre les modifications selon le plan que Bruno a mis dans les commentaires ci-dessus. Ça vous convient ?
Il y a peut-etre une solution plus simple: garder le fonctionnement actuel, mais désactiver le float en mobilité. Cette solution permettrait de rester compatible avec IE.
Le résultat en mobile donne sur Firefox Desktop avec gabarit pour Galaxy S9/S9+:
J'ai testé sous Interne Explorer 10 et cette solution casse un peu l'affichage du lien "Lire la suite" (les boutons de téléchargements débordent un peu par dessus).
PS: J'ai ré-ouvert l'entrée de suivi pour ce fil de commentaire.
En effet, j'ai remarqué que sur mobile les liens Markdown et Epub apparaissent bizarrement. J'ai vérifié et c'était déjà le cas avant d'ajouter ces images.
Pour améliorer ça, il faudrait repenser la CSS du site pour éviter d'utiliser des float et préférer les CSS Grids. Apparemment, beaucoup de navigateurs supportent les CSS Grid maintenant, je vais voir ce que je peux faire.
Merci pour la fusion, la réactivité est appréciée :)
C'est très intéressant la liste proposée par Matthieu, je vais la découper et faire une entrée de suivi par partie. Ça permettra de montrer à tout le monde où on en est et ce qu'il y a encore à faire.
Pour ma part cette demande est très étrange : habitué à lire toutes mes nouvelles du jour sur mon propre lecteur RSS, je peste d'habitude contre les sites qui m'imposent des résumés d'articles pour me forcer à visiter leur site.
Du coup, je suis vraiment surpris par cette demande et je serai bien intéressé à comprendre un peu mieux comment tu utilises tiny rss ? Est-ce que tu l'utilises comme point centrale de notification ? Est-ce que tu consultes uniquement des sites web qui ont un design qui s'adapte à la taille de ton écran ?
Si on essaie d'imaginer cette fonctionnalité, quelle taille de texte voudrais-tu retrouver dans ton lecteur RSS ? Uniquement les titres ? Ou le titre avec les 20 premiers mots ? Ou au moins 150 caractères ?
# Quelles limitations technologiques ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 2 (+0/-0).
Hello,
Grâce à ce commentaire à propos des boutons de download, je me rend compte qu'avant de se lancer dans l'implémentation du nouveau design, il faut d'abord choisir quels navigateurs on souhaite supporter.
Pour Chrome, c'est difficile de retrouver les anciennes versions, Google force les mises à jour et ne supporte que la dernière version. Je propose de supporter la version Chromium de Debian oldstable (soit la version 57): https://packages.debian.org/search?keywords=chromium
Pour Firefox, je propose de faire la même chose puisque Debian utilise déjà les version ESR, on peut utiliser la version ESR de Debian oldstable (soit la version 60): https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=firefox-esr
Pour Android c'est beaucoup plus compliqué, car le navigateur par défaut dépend des mises à jour des constructeurs (jusqu'à la version Lolipop). Si les utilisateurs ont la version L et le Google Play Store, alors leur webview suit les mises à jour de Chrome. Pour les autres, il faudrait soit installer "Chrome pour Android", soit "Firefox".
Pour iOS, je ne pourrais même pas tester et du coup, je ne sais même pas ce que je pourrais imaginer comme "version minimale" :/
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
J'avais déjà prévu une correction pour IE, il devrait aussi corriger l'affichage de ces anciens navigateurs: à la place d'utiliser les
gridde CSS, je joue simplement avec la désactivation dufloatque l'on utilisait avant.Le pull request est disponible ici: https://github.com/linuxfrorg/linuxfr.org/pull/235
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).
Pour Android, le "navigateur par défaut/de base" n'existe pas par exemple sur les smartphones Samsung, c'est un navigateur spécial fait par Samsung (qui est sûrement crée au-dessus du WebView d'Android, mais ça ne change pas grand chose à mon problème: je ne peux pas tester, je n'ai pas le matériel).
En plus, ce genre de navigateur pose des problèmes de sécurité à cause de certains algorithmes indisponibles (par exemple, certains algorithmes de TLS) ou des failles de sécurité jamais corrigées. D'ailleurs, Google a décidé de ne plus lier le "navigateur par défaut" à Android, mais de livrer "Chrome pour Android" pour que les mises à jours du navigateurs ne doivent plus attendre les mises à jours Android des constructeurs (qui sont quasiment inexistantes).
Qu'est-ce que tu entends par "les versions ESR de Firefox fonctionnent toutes" ?
Il n'y en a qu'une seule (voire 2 pendant quelques semaines de chevauchement): https://wiki.mozilla.org/Release_Management/Calendar.
Par exemple, pour Firefox ESR 45, cette version est sortie en 2016 et n'est plus supportée par Mozilla depuis la version ESR 52.2 sortie en juin 2017. Cette version est elle-même remplacée par le support de la version ESR 60.2 sortie en septembre 2018. Cette version actuelle ESR perd son support cet automne.
Si tu veux vraiment les supporter "toutes", la première version ESR est sortie en janvier 2012 ;-)
Pour lire les articles au complet, je voulais dire que le titre des dépĉhes/journaux/liens/entrées de forum est aussi un lien cliquable pour voir l'article complet.
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0). Dernière modification le 17 mai 2019 à 17:28.
Pour Android, je n'ai pas de version 4 ou 5 sous la main et il dépend du constructeur si je me souviens bien.
Pour Debian Jessie, je veux bien regarder, mais bon, Stretch est disponible depuis 2 ans et Buster sera bientôt dispo…
PS: tu peux cliquer aussi sur le tritre des éléments pour lire la suite.
[^] # Re: lxqt
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Quel DE pour des débutants?. Évalué à 2.
Oui, il est chouette :)
J'avais besoin d'un DE léger pour une machine virtuelle et il fonctionne vraiment bien !
[^] # Re: previously, in "gitlab migrations"
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Gitlab migre de Azure vers GCP et explique pourquoi (spoil : azure sucks). Évalué à 4.
Eh ben, c'est hyper intéressant de lire ces deux billets :-)
Ils ont eu de très bon commentaires sur leurs choix techniques avant même de les implémenter !
Je pense que ça a été très bénéfique pour eux cette transparence des choix techniques avant même leur mise en place: ils ont en tout cas évités des frais inutiles.
# Il vaut mieux attendre encore un peu...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Mise à jour logo Red Hat. Évalué à 3 (+0/-0).
… on pourra directement intégré le futur logo ;-)
[^] # Re: le web dans sa fange
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Firefox ne peut plus utiliser d'extension. Évalué à 3. Dernière modification le 07 mai 2019 à 06:54.
Tiens, il y a aussi un autre usage: le tir sportif.
J'y pense parce que je vais devoir bientôt voter pour durcir la loi sur les armes à feu en Suisse.
Et justement, un des arguments du comité contre cette mise à jour de la loi est que les tireurs sportifs ne pourraient plus utiliser d'arme (mais il me semble que leur argumentation est douteuse).
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
J'avais aussi l'habitude de "plus petit multiple commun" à l'école obligatoire, puis à l'uni on a parlé de "plus petit commun multiple". Comme en français les adjectifs peuvent être placés n'importe où (à peu près), tous les deux sont justes et expriment la même idée :)
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Merci Kantien, ça me semble plus clairement posé que mon résumé :)
Quand tu écris ceci:
J'ai juste un doute sur les deux dernières lignes:
commitetmergesont bien des fonctions prenant les 2 premiers éléments en paramètre et faisant un résultat du type du dernier élément ?Pour essayer d'exprimer avec les conventions mathématiques dont j'ai un peu plus l'habitude (style
f(x,y) = zavec les préfixes des arguments leur type):L'idée d'illustrer avec des opérations simples (multiplication et ppcm) sur les nombres est très bonne aussi.
Pour la phrase suivante:
Je trouve qu'elle explique mieux l'astuce de l'utilisation des graphes et elle n'utilise même pas le terme de
graggle, bravo :) (quand je parlais de simplification de la représentation du fichier, c'est exactement ça, mais plus clairement exprimé en partant de la richesse du graphe au lieu de la "simplification/relaxation" de la liste).[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
Il a écrit dans un commentaire plus bas:
Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
Bravo !
Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles…
PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 7.
J'ai regardé les anciens contenus linuxfr tagués pijul, je suis tombé sur Hacker News, puis sur ce lien: https://jneem.github.io/archive/
Il y a quatre postes de blog assez long, mais qui m'ont l'air mieux formaté et plus concret :)
[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0).
Ah pardon, c'est moi qui avait mal installé le système, il faut bien sûr installer le paquet
ruby-rackpour faire fonctionner correctementboard-linuxfr. Il faut que je mette à jour mon fichier d'installation :)[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0).
Merci pour la confirmation, je me doutais que la page de rédaction n'était pas complète à cause du manque des événements :)
Je suis un peu bloqué, je n'arrive pas à lancer board-linuxfr avec Ruby 2.3.
J'ai vu que Goliath a besoin de Ruby 1.9.2, j'ai donc suivi leur tutoriel d'installation, mais je n'arrive pas à l'installer. Il semble qu'il y ait un problème de versions nécessaire de ruby entre rack et goliath (j'ai dû même changer la version de rubygems pour réussir à lancer l'installation, c'est pas évident :/).
Du coup, je suis un peu bloqué pour continuer le travail sur l'espace de rédaction. Tu aurais une piste pour me sortir de ce sac de nœud de versions des différents composants ?
[^] # Re: Version ansible
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Fichier INSTALL.md détaillé pour guider les nouveaux contributeurs. Évalué à 2 (+0/-0). Dernière modification le 20 avril 2019 à 22:09.
Je suis en train d'essayer de faire du dev sur l'espace de rédaction et je vois que mon navigateur essaie de joindre la route "/b/un_identifiant_a_rallonge". Cette route n'est pas enregistrée dans rails et du coup je reçois un 404.
Dans ton ansible, j'ai vu que tu demandais à Nginx de rediriger "/b/" vers un socket unix "board.sock". Est-ce que tu te souviens de ce que c'est ? J'ai l'impression d'avoir raté quelque chose.
Edit:
Ah ben je viens de voir le lien the board-daemon dans le Readme :)
[^] # Re: Intérêt réel du Markdown ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Saletés de codes différents et tutoriel wiki. Évalué à 6.
Par rapport à HTML, les syntaxes comme Markdown / BBCode sont utiles pour empêcher l'injection de code malicieux dans ton site.
Pour les sites, c'est donc bien plus simple de valider le texte reçu de l'utilisateur:
Il serait également possible de définir un sous-ensemble des tags et attributs HTML et faire le même travail en théorie. Mais ça demande plus d'investissement: il faut utiliser une représentation XML et l'utiliser pour enlever tout ce qui n'est pas dans ta liste blanche de balises et attributs HTML.
[^] # Re: 1ère série - préparer le terrain dans l'espace de rédaction
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 2 (+0/-0).
Ok et avais-tu déjà choisi de les stocker en base de donnée ou sur le système de fichier ? Je ne sais pas trop ce qui est envisageable comme je ne connais pas l'architecture système actuelle…
# 1ère série - préparer le terrain dans l'espace de rédaction
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Implémenter le nouveau design de LinuxFR. Évalué à 3 (+0/-0). Dernière modification le 15 avril 2019 à 09:50.
Pour cette série, je me pose des plusieurs questions:
Si on commence à faire intégrer une image par article, est-ce qu'il faut commencer à proposer le stockage des images directement sur le serveur de LinuxFr ? L'idée, c'est qu'avec ce nouveau design, l'image fait vraiment partie de l'article, du coup, faudrait-il un stockage pérenne ou on continue d'accepter des liens qui peuvent casser ?
Pour la citation de l'auteur de l'image en Markdown, il ne semble pas y avoir de manière standard. Est-ce que l'on ajoute une nouvelle notation spécifique à LinuxFr ? Ou est-ce que l'on met toujours la citation dans le texte alternatif de l'image ? J'ai vu aussi sur Stack Overflow une solution proposant d'utiliser le tag HTML
<cite>pour les bloques de citation.Ah ben, je vois qu'il y avait déjà une proposition ici pour la citation: https://linuxfr.org/suivi/ajouter-le-texte-alternatif-en-bas-des-images Cette proposition utilise en plus les nouveaux tags HTML5, c'est le bon moment pour commencer à les utiliser :)
Pour l'instant, je vais faire des tests où on continue de ne pas stocker d'images sur LinuxFr. Dans ce cas, j'ai juste besoin d'ajouter un champ aux articles qui contient le lien Markdown avec la citation.
[^] # Re: Cas d'usage pour le téléchargement en markdown ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
Salut Matthieu,
Merci pour la mise à jour de la maquette, j'aime bien cette proposition qui permet de retrouver la source sans avoir à toujours afficher le bouton pour le Markdown.
Si je me souviens bien, la fonctionnalité de télécharger le fichier "Epub" est arrivée il y a 4-5 ans dans la vie du site. En fait, c'est vraiment plus pratique pour la plupart des lecteurs et je trouve que c'est une bonne idée de mettre en avant uniquement ce média hors-ligne.
Le bouton "Afficher la source" est aussi pratique pour pouvoir exporter son article vers d'autres plateformes qui comprennent le Markdown (comme des blogs personnels, par exemple).
Pour l'instant, je propose de laisser le pied de page tel qu'il est actuellement et de reprendre les modifications selon le plan que Bruno a mis dans les commentaires ci-dessus. Ça vous convient ?
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
Chouette, merci pour la fusion :)
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
Il y a peut-etre une solution plus simple: garder le fonctionnement actuel, mais désactiver le float en mobilité. Cette solution permettrait de rester compatible avec IE.
Il faut que je teste d'abord.
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0). Dernière modification le 08 avril 2019 à 22:13.
Re,
J'ai regardé cette piste et en effet les CSS Grids fonctionnent mieux que
floatpour faire du responsive design.J'ai posté l'évolution ici: https://github.com/linuxfrorg/linuxfr.org/pull/234
Le résultat en mobile donne sur Firefox Desktop avec gabarit pour Galaxy S9/S9+:
J'ai testé sous Interne Explorer 10 et cette solution casse un peu l'affichage du lien "Lire la suite" (les boutons de téléchargements débordent un peu par dessus).
PS: J'ai ré-ouvert l'entrée de suivi pour ce fil de commentaire.
[^] # Re: CSS à ajuster ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 2 (+0/-0).
En effet, j'ai remarqué que sur mobile les liens Markdown et Epub apparaissent bizarrement. J'ai vérifié et c'était déjà le cas avant d'ajouter ces images.
Pour améliorer ça, il faudrait repenser la CSS du site pour éviter d'utiliser des float et préférer les CSS Grids. Apparemment, beaucoup de navigateurs supportent les CSS Grid maintenant, je vais voir ce que je peux faire.
[^] # Re: Merci pour le patch
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Design: ajouter une icône de téléchargement à côté des liens Markdown et Epub. Évalué à 3 (+0/-0).
Hello,
Merci pour la fusion, la réactivité est appréciée :)
C'est très intéressant la liste proposée par Matthieu, je vais la découper et faire une entrée de suivi par partie. Ça permettra de montrer à tout le monde où on en est et ce qu'il y a encore à faire.
# Comment utilises-tu les RSS ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Limiter la taille des articles dans les flux RSS. Évalué à 6 (+0/-0).
Hello,
Pour ma part cette demande est très étrange : habitué à lire toutes mes nouvelles du jour sur mon propre lecteur RSS, je peste d'habitude contre les sites qui m'imposent des résumés d'articles pour me forcer à visiter leur site.
Du coup, je suis vraiment surpris par cette demande et je serai bien intéressé à comprendre un peu mieux comment tu utilises tiny rss ? Est-ce que tu l'utilises comme point centrale de notification ? Est-ce que tu consultes uniquement des sites web qui ont un design qui s'adapte à la taille de ton écran ?
Si on essaie d'imaginer cette fonctionnalité, quelle taille de texte voudrais-tu retrouver dans ton lecteur RSS ? Uniquement les titres ? Ou le titre avec les 20 premiers mots ? Ou au moins 150 caractères ?