Adrien Dorsaz a écrit 958 commentaires

Hello,

Il me semble que GCC ne "cache" pas les constantes string dans le binaire.

Tu dois pouvoir vérifier avec ton éditeur de texte favoris ou avec la commande strings ton_binaire.

cf: https://github.com/linuxfrorg/linuxfr.org/pull/263

Simplement parce que je pensais que les scripts Ansible seraient bientôt disponibles ^^

Mais vu comme le temps passe vite, je vais faire un rebase et un PR. Merci pour le relancement du sujet.

Hello,

Pour t'aider dans la mise en place de ton environnement, j'ai écris un fichier "INSTALL.md" qui explique comment installer LinuxFr sur Debian Stretch.

Pour la piste du template, ça à l'aire juste, je commencerais par là aussi :)

Tu verras, Rails est sympa, il définit un environnement de travail assez chouette avec un ORM qui se base sur les models pour gérer la base de donnée et sur une approche MVC classique gérée par le serveur bin/rails.

Avec Rails, pas mal de choses sont définies de manières implicites. Pour ce bug, ça ne devrait pas être nécessaire, mais, si tu veux mieux comprendre le fonctionnement de Rails, leur tutoriel est un très bon début :)

Tu peux faire des PRs pour tout ce que tu veux et dans ce cas, ça semble pertinent comme ajout.

Il me semble que, même sans entrée dans le suivi, tu peux faire des PRs. L'entrée dans le suivi permet d'avoir les avis des autres et voir si c'est pertinent pour le site. Je pense que des corrections du style, une mise à jour du Readme, n'a pas forcément besoin d'une entrée de suivi.

Bonne découverte !

Hello,

Si je me souviens bien des longs débats Snap vs Flatpak vs Appimage, Canonical a choisi par design de ne permettre d'utiliser qu'une seule source de snaps (snapcraft.io).

Et c'est justement un des points qui différencie Flatpak. Flatpak a décidé par design le contraire: n'importe qui peut créer son propre serveur flatpak et l'utiliser.

Maintenant Canonical vient de casser le système de miroir de Debian par ce package qui dépend de snapcraft.io (c'est le cas depuis 1 ou 2 versions je crois).

Je pense que le plus simple pour continuer d'utiliser les mirroirs, c'est d'utiliser Debian. En effet, Debian n'a pas d'intérêt à imposer Snap via ses paquets .deb.

PS: pour plus d'informations, notamment l'avis de Linux Mint: https://linuxfr.org/users/ps12r/journaux/canonical-refait-cavalier-seul-et-annonce-une-nouvelle-boutique-logicielle-centree-sur-snap

Wow, c'est effectivement étonnant, je ne pensais pas que LibreOffice faisait des PDFs non-standards avec cette option.

Je trouve aussi que l'argumentation de l'utilisateur kurt.pfeifle est vraiment mauvaise: avec ce genre de discours, on ne corrige jamais aucun bug… genre "pas vu, pas pris".

Par contre, je pense que ça serait intéressant d'ajouter un commentaire pour expliquer que, si LibreOffice corrige ce bug, ça sera utile pour pouvoir inclure facilement des factur-x.

Hello,

Au sommet denode.rb, il y a une note qui dit que le user peut être NULL:

class Node < ActiveRecord::Base
  belongs_to :user     # can be NULL

J'imagine que ça peut être pareille pour les commentaires.

C'est peut-être des votes sur des contenus/commentaires de comptes supprimés ?

Une piste pour comprendre la production serait de lancer des requêtes SQL du style:

select count(1), DATE(created_at) as creation_date
from nodes
where user_id is NULL
and score <> 0
and creation_date > DATE_SUB(CUR_DATE(),INTERVAL 1 MONTH)
order by creation_date desc;

select count(1), DATE(created_at)
from comments
where user_id is NULL
and score <> 0
and creation_date > DATE_SUB(CUR_DATE(),INTERVAL 1 MONTH)
order by creation_date desc;

Dans le where, on peut ajuster la condition sur la date de création pour l'analyse.

Pour éviter d'avoir ces clés bizarres, on pourrait ajouter une condition à la fin des lignes que tu as trouvés (dans node.rb et comment.rb, ça devrait suffir):

unless self.user_id.nil?

Je ne sais pas si on est dans le même cas, mais LibreOffice est déjà capable d'inclure le fichier odt dans le PDF. C'est accessible via une option à cocher quand on utilise la fenêtre d'export

Il faudrait voir si l'odt est une pièce jointe du PDF, je ne sais pas…

Je me demande s'il parle de l'historique qui est en RAM et n'est pas encore enregistré sur le disque ?

Si je me souviens bien, l'historique de la session en cours s'enregistre par défaut à la fin de la session. D'ailleurs c'est un peu ennuyeux comme comportement quand on a plusieurs terminaux ouverts en même temps: l'historique n'est pas partagé directement entre eux.

D'une part si tu édites encore des fichiers de conf directement sur les serveurs en 2019 c'est que t'as déjà tout faux et pas ta place dans l'industrie

Merci pour ce chaleureux message, j'avais peur de ne pas savoir où est ma place…

Je peux te rassurer: je ne suis pas administrateur système en industrie :-)

d'autre part tu n'as pas besoin d'utiliser l'éditeur présent sur le serveur pour y éditer un fichier (hello points de montages ssh)

Ok, c'est quand même un échec pour un fichier de configuration : pour pouvoir bien l'éditer, tu dois sortir une autre machine.

pour finir avoir de la coloration syntaxique et du linting n'est qu'à un jet de pierre pip/gem/yum/dnf/gem.

Le problème pour un utilisateur normal, c'est qu'il va casser sa configuration puis se rendre compte après qu'il a besoin d'un linter.

Pour du code, ça ne me pose pas de problème, mais pour un simple ajustement de configuration, c'est hyper lourd.

Je pense que la grande différence est le contexte: quand je travaille sur un code python, j'utilise généralement un IDE, car je sais qu'il y a beaucoup de conventions à respecter. J'espère que tout le monde se rend compte que modifier un code, n'est pas du tout un acte anodin et qu'il y a beaucoup de règles à respecter.

Les tabulations / espaces, c'est un des premiers trucs que l'on apprend en lisant des tutos sur python.

Par contre, quand je modifie un fichier de configuration, ça doit être un acte anodin. Il doit être possible de le faire sans IDE (emacs, vim ne sont pas toujours installés sur tous les postes/serveurs).

Un exemple typique, est que je vois un comportement par défaut que je veux changer. J'ouvre le fichier de configuration, je voit que c'est du texte et je l'adaptes selon le reste du fichier. Je le fais avec un simple éditeur de texte (qui ouvrirait un fichier de config avec un IDE ?) et je ne vois pas la différence entre espace/tabulation. Maintenant, avec un fichier .ini tout se passe sans problèmes, avec un fichier .yml, il y a 9 chances sur 10 que je vienne de casser mon service/programme.

Je pense que le contexte fait vraiment la différence pour l'édition: pour un code, les gens savent qu'il faut suivre une formation, mais pour une configuration, des administrateurs systèmes, des utilisateurs doivent pouvoir les modifier.

Maintenant, dans le cas de reqman, je comprends l'utilisation de yaml: c'est un outil destiné à des développeurs / testeurs, ça ne me choque pas :)

L'article est très intéressant : le développeur semble conquis par Rust et il présente quelques qualités du langage.

En fait, il ne soulève quasiment pas de points négatifs ! Le point négatif le plus important est l'intégration de Cargo (le système de build/test/…) dans d'autres système de build.

Merci beaucoup pour ce retour, c'est intéressant.

Mon objectif était d'apprendre le C++-17 avec la création de ce nouveau projet. Comme j'avais déjà pas mal jouer avec Glib/Gtk récemment, je voulais l'utiliser pour la Gui simplement.

Si j'ai bien compris, un des grands intérêts d'utiliser Gtk 3, c'est que cette version implémente Gobject Introspection. Cet outil devrait permettre de ne plus avoir besoin de faire manuellement les binding dans le langage cible (comme tu expliquais que c'était le cas pour le C++ gtkmm, glibmm…).

En fait, ça définit la syntaxe d'un fichier .gir qui expose l'interface de manière abstraite du langage d'implémentation (C en l'occurrence pour Gtk). Ce fichier est généré directement par le projet source (donc Gtk).

En lisant ce fichier avec un programme (cppgir pour le C++), il serait possible de générer de manière automatique les interfaces dans le langage cible (ici, C++).

Donc, en théorie, cppgir devait résoudre mon problème, mais je n'ai pas réussi à l'utiliser :-) Peut-être qu'on ne peut pas faire de C++-17 avec, je ne sais pas.

De rien :)

Pour LinuxFr, c'est agréable d'être entouré d'une bonne équipe: Mathieu trouve de bonnes idées d'améliorations et de test et Bruno réagit vite aux demandes de fusion et donne de bons conseils.

Ça prend un peu de temps à écrire les comptes rendus, mais c'est assez chouette pour moi aussi de voir ce qui s'est passé.

Ah ben voilà, je me disais bien que c'était inhumain d'utiliser Emacs avec 2 mains ! Ils devraient ajouter dans leur documentation que pour pouvoir l'employer correctement, il faut utiliser ses pieds :)

A ce sujet, on avait eu un journal très intéressant l'année dernière :-)

Pour les titres, oui, je me suis souvenu, c'est ce que je suis en train d'ajouter avec l'image d'illustration.

Il y avait déjà eu pas mal de boulot à faire pour le panneau latéral et les barre d'outils, alors j'avais laissé ça de côté, mea culpa.

Ahahah, vu la discussion, je crois que j'avais compris tout de travers :)

Quand tu as dit:

J'en profite pour t'informer que de moins en moins de dépêches utilisent la deuxième partie (c'est très casse-pied en modération).

Est-ce que ce qui est pénible, c'est que les rédacteurs n'utilisent plus la deuxième partie ?

Moi, j'avais compris ce matin quelque chose du genre "L'équipe de modération trouve la deuxième partie très casse-pied"… Autant te dire que j'étais un peu surpris :-)

Si je me suis bien trompé, tout va bien, car, justement, la suite des évolutions de l'espace de rédaction va être de mieux agencer tout ça avec l'image d'illustration qui permettra de bien séparé les notions de "chapeau", "illustration" et "contenu" (je dois justement mettre plusieurs titres dans ce contenu).

J'en profite pour t'informer que de moins en moins de dépêches utilisent la deuxième partie (c'est très casse-pied en modération).

Mmhh, c'est embêtant ça, parce que le nouveau design a une autre vision: l'idée c'est que la première partie soit un texte d'accroche très court (genre, 1-2 phrases) qui sera associée à une image d'illustration.

Ceci permet de supprimer ces ciseaux pour la rédaction collaborative pour rendre plus simple l'interface et aussi de faire des jolies vignettes dans la liste des dépêches.

L'idée que mjourdan avait donné:

Un essai d'implémentation pour une dépêche en cours d'édition:

Hello,

On avait perdu le lien vers la page wiki d'aide à l'édition, on l'a rétabli.

Tu peux donc ajouter cette documentation directement dans le wiki :-)

Sinon, je ne suis pas sûr d'avoir bien compris le code, mais j'ai l'impression qu'il faut écrire [[en:Programming]] pour avoir un lien vers une page wikipédia anglaise: Programming

Hello,

Merci pour le retour !

C'est bien vu pour le lien, on l'a effectivement perdu. J'ai fait une demande de fusion pour l'ajouter à nouveau.

Pour le second point, si je comprends bien, tu parles de la 2ème partie quand on est en mode "réorganisation" ?

Si c'est bien ça, la situation va s'améliorer quand les liens seront déplacés après la seconde partie (c'est en cours avec l'ajout d'image d'illustration).

Ok, il semble que tu connaisses déjà des différences. Du coup, tu pourrais préciser la question ?

Là elle est très large, c'est pour ça que je t'ai donné le lien de la FAQ de Matrix 😉

Non, ça n'est pas pareil.

Hello,

J'ai proposé le patch ici pour régler ce problème: https://github.com/linuxfrorg/linuxfr.org/pull/259

Le seul soucis, c'est que pour pouvoir utilisé la propriété table-layout des tableaux, je suis obligé de définir la taille width: 100%. Je pense que c'est pas si mal, mais ça va changer un peu le rendu des tableaux qui sont dans des contenus (les statistiques ne sont pas affectées :)).

Pour voir les cas que j'ai testé, c'est à la fin de cet article et dans le premier commentaire.

Hello,

Si je ne m'abuse, actuellement, toutes les tribunes (/board, celle de modération, celle des rédacteurs, celles pour chaque dépêche) est limité à 100 messages:

# encoding: utf-8

# It's the famous board, from DaCode (then templeet)
#
class Board
  include ActiveModel::Model
  include Canable::Ables

  NB_MSG_PER_CHAN = 100

### Constructors and attributes ###

  attr_accessor :id, :user_name, :user_url, :user_agent, :object_type, :object_id, :message, :created_at

Rendre le contenu illimité et sauvé en tout temps, ça me semble un peu exagéré, car chaque dépêche a sa propre tribune et car elles ne sont pas vidées à la publication d'une dépêche (la modération a toujours accès à cette tribune).

Personnellement, je comprends que la tribune dans une dépêche comme un lieu de discussion rapide et informelle pour les personnes qui sont en train de collaborer ensemble. De ce point de vue, je ne vois pas l'intérêt de conserver un nombre illimité de messages.

Par contre, on pourrait imaginer augmenter la limite à quelque chose de plus adapté ?

Sinon, pour les messages et prises de décisions les plus importantes pour la collaboration en rédaction, autant écrire leur résumé directement dans la dépêche: ça permet de s'assurer que tout participant à la dépêche voie ce texte puisqu'il est dans le corps de la dépêche.

Finalement, je serais donc plutôt pour augmenter la limite un peu, mais ne pas la supprimer pour éviter de surcharger les disques dures de LinuxFr (et le service Redis). A voir si Bruno est aussi de cet avis.