David Demelier a écrit 670 commentaires

En C/C++, la référence pour commenter en masse est le #if 0 … #endif. Ça permet de pallier le problème des commentaires intérieurs notamment :

#if 0
/*
 * Ce commentaire fonctionne
 */
if (true) {
}
#endif

git is great because linus did it, mercurial is better because he didn't

J'ai jamais compris pourquoi les gens faisaient 'grep pat file | wc -l' au lieu d'un simple 'grep -c pat file'.

git is great because linus did it, mercurial is better because he didn't

Oui ainsi que 3 boutons :

• Partager sur facebook
• Partager sur twitter
• Partager sur G+

git is great because linus did it, mercurial is better because he didn't

Moi je code toute fonction publique au format doxygen dans son .h, du coup la plupart de mes commentaires se situent dans mes .h et non dans mes .cpp.

En revanche, il m'arrive de commenter des parties difficiles ou des cas d'utilisation spéciaux.

git is great because linus did it, mercurial is better because he didn't

Oui, même le site a encore une apparence très … old-school on va dire :p

git is great because linus did it, mercurial is better because he didn't

Effectivement ça a du être fixé depuis. Par contre je vois que certains s'amusent avec la langue :p

git is great because linus did it, mercurial is better because he didn't

En lisant l'article, j'ai vu que la quasi totalité des applications sont écrites dans des langages différents. Une en Python 3, une en javascript, une en Vala et le reste de GNOME est souvent en C et Python 2.

Ça signifie que moi, si je souhaite installer GNOME 3 je suis obligé d'installer une palanquée de langages de script à côtés juste parce que chaque développeur a décidé d'utiliser son préféré.

Si un jour je souhaite développer un correctif pour une de ces applications je vais être obligé d'apprendre un nouveau langage. Pourquoi personne ne décide de dire chez GNOME : C/Gtk (éventuellement Vala) ou Python (car très utilisé chez GNOME) puis rien d'autre.

Après, je suis d'accord que cela "ouvre" plus de possibilités vers d'autres développeurs qui connaissent pas forcément ceux cités juste au dessus mais ça fragmente encore plus l'écosystème de GNOME. Sans parler des performances bien sûr. Je suis assez d'accord pour faire des bindings des bibliothèques GNOME afin de faire des plugins du GNOME-Shell dans son langage favori, mais pas les applications principales.

Sinon, bravo pour l'article il est vraiment complet et intéressant. Cela me donne tout de même envie de tester GNOME 3 une fois :)

git is great because linus did it, mercurial is better because he didn't

Ça commence mal, la démo ne fonctionne pas sur le site /o.

git is great because linus did it, mercurial is better because he didn't

Bonjour,

Je pensais avoir trouvé mon bonheur avec sleepybot mais j'ai hâte de tester ce projet, ce sera lundi première heure :-)

Mis à part le langage de programmation (C++/Lua vs Java/Sleep), quels sont, selon vous, les avantages ou différences fonctionnelles de votre bot par rapport à SleepyBot/PircBot ?

Hello,

J'ai regardé rapidement SleepyBot et ses fonctionnalités. Ce dernier a le support du DCC, qui n'est pas encore présent dans irccd mais sera peut-être rajouté dans la version 1.1. Il a l'air de posséder plus de fonctionnalités qu'irccd mais sa documentation est légèrement plus basique.

Irccd a la possibilité de se connecter à plusieurs serveurs en même temps, ce qui -à priori- n'est pas disponible avec SleepyBot. Par contre, en utilisant Java, je pense que SleepyBot est encore plus portable.

git is great because linus did it, mercurial is better because he didn't

Merci pour ce projet très intéressant !

Qu'est-ce qui a motivé le choix de Lua pour les scripts ?

Merci pour ton message ! Tout d'abord Lua est un langage de script connu pour être facilement intégrable dans du C/C++ (et même d'autres). C'est presque sa fonctionnalité première finalement, beaucoup de logiciels / jeux s'en servent afin d'étendre une application avec un langage de script performant et simple.

Lua est très léger, sa bibliothèque (sans le compilateur et l'interpréteur) n'excède pas 14000 lignes de code, il est très haut niveau et permet donc d'étendre irccd avec seulement quelques lignes.

Il a notamment été utilisé pour l'interface graphique de World of Warcraft, nmap, la suite logiciel Adobe Lightroom, ou bien le populaire gestionnaire de fenêtres awesome

Par exemple, un simple plugin qui permet de répéter tout ce qui se dit sur un canal pourrait s'écrire :

function onMessage(server, channel, nickname, message)
    server:say(channel, message)
end

git is great because linus did it, mercurial is better because he didn't

Encore un projet en C++, on le sait c'est un très mauvais langage, qui à surtout beaucoup de défauts et une relative simplicité. Donc encore une fois pourquoi du C++ ?? Si on veut saccager tout les projets libres, on est sur la bonne voie.

Oui, quand on ne sait pas coder le C++ est forcément un très mauvais langage.

git is great because linus did it, mercurial is better because he didn't

Ruby n'est pas plus lent que les autres (notamment Python)

d'accord

git is great because linus did it, mercurial is better because he didn't

Ruby c'est lent et puant. Honnêtement, ils aurait du passer au C++ ou PyQT, mais ruby….

git is great because linus did it, mercurial is better because he didn't

Complètement faux. Moi j'utilise le clic du milieu depuis des années et j'ai pas encore 30 ans

git is great because linus did it, mercurial is better because he didn't

Je veux pas être trop méchant, mais le nom est vraiment merdique. Il me fait penser à une erreur de frappe.

git is great because linus did it, mercurial is better because he didn't

 elseif (UNIX)

-  target_link_libraries(liblogicalaccess logicalaccess-cryptolib crypto boost_filesystem boost_date_time boost_system dl)
+  target_link_libraries(liblogicalaccess logicalaccess-cryptolib crypto boost_filesystem boost_date_time boost_system)
 endif()

Es-tu sûr que ça continue de compiler avec Linux en enlevant la bibliothèque dl ? Il me semble que sur Linux contrairement aux *BSD les fonctions dl* ne sont pas directement exportés dans la libc

git is great because linus did it, mercurial is better because he didn't

Ahaha, j'ai bien ri, merci.

git is great because linus did it, mercurial is better because he didn't

Qu'est-ce que Qt a de si merveilleux ? GTK+ 3 est-il si pourri que ça ?

Oui, QT est propre, plus rapide et plus performant. Gtk c'est une horreur en C voulant simuler de l'orienté objet avec un langage qui ne le prévoit pas. Du coup ça donne du code dégueu et incompréhensible.

Il n'y a qu'à regarder comment faire un GObject, ça fait vomir.

Et puis, gtk_widget_create_full_parameter_c_est_vraiment_relou_a_ecrire_cette_function();

git is great because linus did it, mercurial is better because he didn't

Pour ma part c'est epdfview, même s'il ne gère malheureusement pas le défilement continu il est convivial et rapide.

git is great because linus did it, mercurial is better because he didn't

Moi j'ai bien peur de la suite.

git is great because linus did it, mercurial is better because he didn't