Le topic de la programmation: Et envoyez des sioux!

[Raplonu]

Je te conseille vivement de privilégier la première solution de Cwningen.

La seconde est valide mais ajoute une restriction inutile sur le type "ContainerType" -> être un template qui prend 1 argument.

[vectra]

BMDJ sur nunux: l'outil Remarkable


C'est tout con, mais jusqu'alors on m'envoyait vers retext pour l'édition de markdown, et franchement c'est une purge.
Alors ok, y'a aussi les plugins CLion, mais va lancer CLion pour retoucher viteuf un .md.

Pour le moment, je préfère encore rédiger mes .md en org-mode sous emacs, puis les exporter... J'envie d'ailleurs Github qui supporte le .org nativement.

[Frypolar]

Visual Studio Code ne fonctionne pas sous Linux ?

[Nattefrost]

Si, y a un paquet pour à peu près toutes les distribs (via un repo crosoft ou un download direct du RPM/deb). Après je sais pas si le visualiseur markdown de VSCode est équivalent à Remarkable, n'ayant pas essayé ce dernier.

[gros_bidule]

Pourquoi ne pas faire de l'asciidoc ? C'est supporté à peu près partout (dont gitlab) et c'est tellement plus sexy & puissant
Et le plugin IntelliJ fait des merveilles.

[vectra]

Quand on a org-mode, tout parait fade à côté!
Sinon, asciidoc est-il supporté par Bitbucket?

[BentheXIII]

Je te conseille vivement de privilégier la première solution de Cwningen.

La seconde est valide mais ajoute une restriction inutile sur le type "ContainerType" -> être un template qui prend 1 argument.

J'ai bien tenté mais la forward declaration

PointCloud.hpp
template <class ContainerType, class PointType = typename ContainerType::value_type>  class KDTree;

déplait au compilateur qui rétorque que "KDTree does not name a type". J'ai les flags c++14 activés.

[Cwningen]

Ça doit venir d'ailleurs parce que cette ligne seule, ça compile pour moi. Et comme on est en train de déclarer KDTree, c'est étrange de dire qu'il ne nomme pas un type.

[Tramb]

Vérifie un peu la cyclicité de tes includes et déclaration, aussi.

[vectra]

CLion: sympatoche, l'intégration d'Atlassian (Jira et Bitbucket).
Rien de fou, mais de quoi éviter des passages inutiles sur le navigateur.

[brundleti]

En regardant les posts de William, je suis alle faire un tour sur ioccc qui a eu lieu cette année a l'occasion des 25 ans de ce concours. On peut notamment voir que Fabrice Bellard a gagne une catégorie et que c'est la 3eme fois qu'il gagne Comme dirait un ancien ministre de l’éducation nationale de la culture : "Ce Bellard : quel bel homme !!!"

L’entrée de Mills est très impressionnante (émulateur de PDP-7/11) et le fichier hints a quelques détails historiques très sympas.

[Møgluglu]

So if I have a PDP-7 emulator, how do I run operating systems that expect a PDP-11? Simple… I emulate a PDP-11/40 on the PDP-7.

Cette classe.

[vectra]

Plop les coins,

J'ai une question pour les canards familiers de Doxygen.
Je commence à m'y mettre sérieusement maintenant que j'ai CLion, et que ce dernier propose une assistance raisonnable à la rédaction des blocs de commentaires. Mais je bute sur deux problèmes:

1) La balise @example (\example) qui orne une déclaration de fonctions. J'aimerais bien y mettre un exemple multi-ligne qui ne soit pas trop dégueu, mais je n'y arrive pas. Ca finit en une ligne dégueulasse...
2) Mes .h commencent à devenir particulièrement verbeux en doc, surtout pour les cartouches de fichiers et de fonctions: ça muscle les doigts de scroller dans tout ça. Je me demandais donc si ce n'était pas une bonne idée que de séparer la doc Doxygen aux petits oignons du code du .h, qui devrait rester lisible et compréhensible tel quel ou presque.

J'ai notamment vu cet exemple qui m'a pas mal plu:
https://www.stack.nl/~dimitri/doxyge...docblocks.html

Là, on déporte clairement la doc d'un côté, et les déclarations de l'autre.
Je ne trouve pas cela tellement plus lisible sur l'exemple, mais je me dis qu'il y a moyen de mettre la partie doc dans un fichier tiers, genre un module qui contiendrait un triptyque .cc/.h/.doc, le ".doc" étant au pire #-inlcus.
Au final, la doc serait bien générée par Doxygen, a priori bien parsée également par CLion, et on n'aurait pas de découragement à être verbeux dans les commentaires.

Je voulais confronter cette idée saugrenue aux bonnes pratiques en vigueur chez nos dieux du code. J'ai essayé de m'inspirer de code de référence que j'avais sous la main, mais franchement c'est soit spartiate, soit ils utilisent pas Doxygen comme je le comprends (VTK).

[Frypolar]

2) Mes .h commencent à devenir particulièrement verbeux en doc, surtout pour les cartouches de fichiers et de fonctions: ça muscle les doigts de scroller dans tout ça. Je me demandais donc si ce n'était pas une bonne idée que de séparer la doc Doxygen aux petits oignons du code du .h, qui devrait rester lisible et compréhensible tel quel ou presque.

Il existe peut-être un raccourci clavier qui permet de replier tous les commentaires ! Sinon dans le code C++ de mon équipe on a des interfaces pour toutes les classes qu’on partage publiquement. C’est là que se trouve la doc vraiment verbeuse et comme on y touche rarement ce n’est pas très gênant à l’usage.

Sinon je suis moyen chaud pour séparer totalement la doc du code. Si quelqu’un d’autre vient lire le code ça risque d’être pénible. Par contre si tu as moyen de garder un minimum de doc dans le code et de déporter les parties vraiment grosses, genre les exemples multi-lignes, je dis pourquoi pas.

[gros_bidule]

Sur nos projets on essaie de limiter les commentaires de classes/fonctions à 1 ou 2 lignes max. Si l'on ressent le besoin d'en écrire davantage, c'est généralement que c'est rattaché à une spec (donc on mentionne le n° de ladite spec) ou que ça mérite de rédiger une belle doc dans notre wiki Gitlab (ça a l'avantage de supporter markdown et asciicdoc, en plus de plugins sympas pour faire des diagrammes).
Du coup ça se passe relativement bien. Si ça peut donner des idées.

PS : un des avantages du wiki, c'est que l'on peut mettre à jour la doc rapidement, sans forcément passer par des merge request. L'info circule donc plus vite. Avant on avait intégré la doc dans le projet (laquelle se générait avec une tâche maven), donc la doc pourrissait souvent des semaines ou des mois en review, et bougeait finalement peu. Depuis le wiki, c'est le jour et la nuit, on l'alimente souvent et vite.

[William Vaurien]

De mon côté j'ai plutôt vu la doc moisir sur le wiki: au début il n'y a rien, un effort est fait pour faire la doc.
Ensuite la doc se périme petit à petit, mais personne ne prend la peine de mettre à jour.

[rOut]

Le mieux c'est restructuredtext, mais bon markdown a gagné la bataille visiblement.

[Frypolar]

PS : un des avantages du wiki, c'est que l'on peut mettre à jour la doc rapidement, sans forcément passer par des merge request. L'info circule donc plus vite. Avant on avait intégré la doc dans le projet (laquelle se générait avec une tâche maven), donc la doc pourrissait souvent des semaines ou des mois en review, et bougeait finalement peu. Depuis le wiki, c'est le jour et la nuit, on l'alimente souvent et vite.

Dans ce cas le problème n'est pas d'avoir la doc dans votre dépôt mais la façon de travailler ensemble

[TiNitro]

Il existe peut-être un raccourci clavier qui permet de replier tous les commentaires

ouais, sinon faut changer d'IDE, c'est le minimum

Sinon je suis moyen chaud pour séparer totalement la doc du code. Si quelqu’un d’autre vient lire le code ça risque d’être pénible. Par contre si tu as moyen de garder un minimum de doc dans le code et de déporter les parties vraiment grosses, genre les exemples multi-lignes, je dis pourquoi pas.

Pareil, si tu veux nourrir un espoir infime d'avoir une doc qui reste à jour, il faut qu'elle soit dans le code. Sinon, le Hotfix urgent sera dans le code, mais pas dans la doc.

[William Vaurien]

Je suis en train de migrer notre vieux projet en C de CVS () vers git.
Au passage le build sera simplifié: CVS était tellement lent que les étapes du builds avaient été saucissonnées en plein de sous étapes lors de l'automatisation avec Jenkins.
Avec git il n'y a plus cette contrainte: le checkout complet 'from scratch' passe de plus de 6mn à moins de 30 secondes

Maintenant je me demande si je ne vais pas complètement zapper la phase de packaging et remplacer par un stockage dans un autre repo.
Donc arrêter de faire un tgz avec les binaires et les ressources web, de l'uploader dans un repo nexus pour le descendre sur un serveur et le dépackager pour enfin faire une install, et à la place stocker les binaires dans git et poser un tag. L'avantage serait de simplifier tout un tas de scripts bash qui font ces manips et d'avoir un truc plus simple au final.

Je sais que normalement on est pas trop censé mettre des binaires dans un gestionnaire de versions, mais je crois que git gère ça très bien.
C'est une fausse bonne idée ?

[Tramb]

Très bien ça dépend. 100GB ouais, 5 TB, non.

[brundleti]

Je suis en train de migrer notre vieux projet en C de CVS () vers git.
Au passage le build sera simplifié: CVS était tellement lent que les étapes du builds avaient été saucissonnées en plein de sous étapes lors de l'automatisation avec Jenkins.
Avec git il n'y a plus cette contrainte: le checkout complet 'from scratch' passe de plus de 6mn à moins de 30 secondes

Maintenant je me demande si je ne vais pas complètement zapper la phase de packaging et remplacer par un stockage dans un autre repo.
Donc arrêter de faire un tgz avec les binaires et les ressources web, de l'uploader dans un repo nexus pour le descendre sur un serveur et le dépackager pour enfin faire une install, et à la place stocker les binaires dans git et poser un tag. L'avantage serait de simplifier tout un tas de scripts bash qui font ces manips et d'avoir un truc plus simple au final.

Je sais que normalement on est pas trop censé mettre des binaires dans un gestionnaire de versions, mais je crois que git gère ça très bien.
C'est une fausse bonne idée ?

Tu as le système de fichiers (opensource) pour git développé par MS qui est censé gerer ce cas-la si j'ai bien tout suivi : https://git-lfs.github.com/

[William Vaurien]

Très bien ça dépend. 100GB ouais, 5 TB, non.

ça tourne autour des 250MB de binaires... répartit en une centaine de petits executables.
Pour le lfs, j'ai l'impression que c'est un truc plus pour les très gros truc genre video, mais je vais quand même regarder...

Je m'en vais faire un pipeline de test pour valider cette idée et en parler aux admins de notre bitbucket aussi...

[brundleti]

ça tourne autour des 250MB de binaires... répartit en une centaine de petits executables.
Pour le lfs, j'ai l'impression que c'est un truc plus pour les très gros truc genre video, mais je vais quand même regarder...

Je m'en vais faire un pipeline de test pour valider cette idée et en parler aux admins de notre bitbucket aussi...

en plus apparemment lfs peut être utilise sur un repo git déjà existant et il se debrouille comme un grand pour la conversion mais bon je te conseille d'avoir des sauvegardes au cas ou

[Tramb]

ça tourne autour des 250MB de binaires... répartit en une centaine de petits executables.
Pour le lfs, j'ai l'impression que c'est un truc plus pour les très gros truc genre video, mais je vais quand même regarder...

Je m'en vais faire un pipeline de test pour valider cette idée et en parler aux admins de notre bitbucket aussi...

Ouais t'es tranquille pour un moment. Mais tu imposes un client git aux gens qui veulent récupérer les artefacts. C'est pas mieux de les servir en http, nfs et tutti quanti ?

[William Vaurien]

Nous sommes notre propre client: la prod appuie sur un bouton qui va appeler un de nos scripts via une plateforme de déploiement automatisé et lancer l'install sur des serveurs que nous administrons quasiment à 100%.

Je m'inquiétais plus de la taille du repo sur le disque, surtout avec les releases 'snapshots' qui peuvent se produire plusieurs fois par jour.

Pour le moment nous gardons les paquets de releases et nous sabrons les vieilles snapshots (soit trop nombreuse soit trop ancienne), j'imagine que je pourrais faire pareille en collant les versions intermédiaires sur des branches vouées à disparaître au fur et à mesure...

Je ne sais pas vraiment comment git gère les binaires, est-ce qu'il est capable de faire du calcul de delta ou pas sur ce genre de fichier.

[Tramb]

Si tu as l'intention d'"oublier" des builds de ton repo, tu vas juste te battre contre git.

[William Vaurien]

Quand on vire une branche les données restent ??? Si c'est le cas ce n'est pas la bonne solution.

[Tramb]

C'est assez subtil, ça dépend si les objets ont été packés, potentiellement par un gc automatique, ou sont encore loose.
Enfin ça serait trop long (enfin je suis trop flemmard) de voir tous les cas ici, il faut bien comprendre le modèle sous-jacent et la doc.

[newbie06]

En regardant les posts de William, je suis alle faire un tour sur ioccc qui a eu lieu cette année a l'occasion des 25 ans de ce concours. On peut notamment voir que Fabrice Bellard a gagne une catégorie et que c'est la 3eme fois qu'il gagne Comme dirait un ancien ministre de l’éducation nationale de la culture : "Ce Bellard : quel bel homme !!!"

Ce type est une brute, en plus très gentil et modeste. QEMU