Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 61 sur 66 PremièrePremière ... 11515354555657585960616263646566 DernièreDernière
Affichage des résultats 1 801 à 1 830 sur 1951
  1. #1801
    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.

  2. #1802
    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.

  3. #1803
    Visual Studio Code ne fonctionne pas sous Linux ?

  4. #1804
    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.

  5. #1805
    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.
    nique la police

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

  7. #1807
    Citation Envoyé par Raplonu Voir le message
    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

    Code:
    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.
    Citation Envoyé par Colargol Voir le message
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  8. #1808
    Ç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.

  9. #1809
    Vérifie un peu la cyclicité de tes includes et déclaration, aussi.
    Because you're young, sharp as a knife
    You need that buzz to come alive

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

  11. #1811
    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.
    We all know Linux is great... it does infinite loops in 5 seconds.
    Linus Torvalds

  12. #1812
    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.

  13. #1813
    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).

  14. #1814
    Citation Envoyé par vectra Voir le message
    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.

  15. #1815
    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.

  16. #1816
    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.

  17. #1817
    Le mieux c'est restructuredtext, mais bon markdown a gagné la bataille visiblement.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  18. #1818
    Citation Envoyé par gros_bidule Voir le message
    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

  19. #1819
    Figure paternelle de substitution Avatar de TiNitro
    Ville
    Capitale eud'chwal
    Citation Envoyé par Frypolar Voir le message
    Il existe peut-être un raccourci clavier qui permet de replier tous les commentaires
    ouais, sinon faut changer d'IDE, c'est le minimum

    Citation Envoyé par Frypolar Voir le message
    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.

  20. #1820
    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 ?

  21. #1821
    Très bien ça dépend. 100GB ouais, 5 TB, non.
    Because you're young, sharp as a knife
    You need that buzz to come alive

  22. #1822
    Citation Envoyé par William Vaurien Voir le message
    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/
    We all know Linux is great... it does infinite loops in 5 seconds.
    Linus Torvalds

  23. #1823
    Citation Envoyé par Tramb Voir le message
    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...

  24. #1824
    Citation Envoyé par William Vaurien Voir le message
    ç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
    We all know Linux is great... it does infinite loops in 5 seconds.
    Linus Torvalds

  25. #1825
    Citation Envoyé par William Vaurien Voir le message
    ç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 ?
    Because you're young, sharp as a knife
    You need that buzz to come alive

  26. #1826
    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.

  27. #1827
    Si tu as l'intention d'"oublier" des builds de ton repo, tu vas juste te battre contre git.
    Because you're young, sharp as a knife
    You need that buzz to come alive

  28. #1828
    Quand on vire une branche les données restent ??? Si c'est le cas ce n'est pas la bonne solution.
    Dernière modification par William Vaurien ; 11/10/2018 à 21h06.

  29. #1829
    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.
    Because you're young, sharp as a knife
    You need that buzz to come alive

  30. #1830
    Citation Envoyé par brundleti Voir le message
    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

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •