David Demelier a écrit 670 commentaires

Le client et le serveur sont développés sous GNU/Linux, puis empaquetés automatiquement pour MacOSX et Windows.

Est-ce que tu cross compile pour macOS ? Si oui je souhaite vraiment savoir comment tu fais :)

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

Ah ouais bien joué pour le sudo faire installer :D

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

C'est à la mode malheureusement. Surtout dans l'univers nodelol.js ou toutes les applications en http://omyapp.io.

• https://www.meteor.com/install
• https://docs.chef.io/install_omnibus.html
• https://sandstorm.io/install

Il y en a tellement encore… :)

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

J'avoue qu'avoir accès root indique une faille plutôt énorme. Il est vraiment important de faire des backups tous les jours et surtout de les dupliquer sur d'autres disques / serveurs.

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

Microsoft me surprend de + en +.

Je n'aime pas powershell mais j'apprécie le geste, sous licence MIT en plus :)

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

Si on est obligé de faire en C, il y a e4c qui n'est pas trop mal.

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

Tu as des mesures réelles ?

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

https://isocpp.org/wiki/faq/exceptions#why-exceptions

“But exceptions are expensive!” Not really. Modern C++ implementations reduce the overhead of using exceptions to a few percent (say, 3%) and that’s compared to no error handling. Writing code with error-return codes and tests is not free either. As a rule of thumb, exception handling is extremely cheap when you don’t throw an exception. It costs nothing on some implementations. All the cost is incurred when you throw an exception: that is, “normal code” is faster than code using error-return codes and tests. You incur cost only when you have an error.

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

assert c'est pour des erreurs de développement. Pas des erreurs au runtime.

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

si c'est pas très loin, utiliser une exception ne sert à rien par rapport à un code de retour ou un booléen pour gérer un truc immédiat; si c'est très loin, alors tu ne peux rien faire de vraiment très sérieux à part quitter le programme.

Donc tu préfère ce genre de code ?

int c()
{
   if (!some_failure)
       return -1;
   return 123;
}

int b()
{
    int result_c;

    if ((result_c = c()) < 0)
        return result_c;

    return result_c * 456;
}

int main()
{
    int value = b();

    if (value < 0)
        // code d'erreur, je suis obligé d'utiliser une seconde fonction pour récupérer une erreur "humaine"
        std::cout << "code d'erreur: " << value << std::endl;
    else
        std::cout << value << std::endl;
}

Plutôt que :

int c()
{
    if (a_failure)
        throw std::runtime_error("error...");

    return 123;
}

int b()
{
    return c() * 456;
}

int main()
{
    try {
        std::cout << b() << std::endl;
    } catch (const std::exception &ex) {
        std::cerr << ex.what() << std::endl;
    }
}

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

Ça, ça ne va pas changer, je déteste les exceptions en C++. Et je ne vois pas bien où je pourrais en mettre.

Bienvenue en 1989 :/

En interne, il y a quelques classes qui utilisent RAII. Maintenant, où est-ce que tu en verrais dans l'API publique ?

Je déteste vraiment avoir ce genre de code :

Music m;
if (!m.loadFromFile("foo")) {
    // gestion de l'erreur 
}

Cela signifie que toutes tes fonctions membres vont devoir vérifier que l'état de l'objet Music est bien ouvert et fonctionnel. Alors qu'un constructeur qui throw rend tout simplement impossible d'utiliser l'objet. Certains vont dire que c'est une hérésie de lever une exception dans un constructeur, mais c'est tout simplement la bonne méthode.

Avec un constructeur qui throw je sais que mon objet sera valide tout au long de sa vie.

Music m("foo.ogg");

// Par buffer (vector, array), etc
Music m(buffer.begin(), buffer.end());

// Stream?
std::istream customstream
Music m(customstream);

J'ai regardé rapidement ton projet, pour le ResourcesManager, tu pourrais retourner des std::unique_ptr plutôt que des pointeurs bruts. Ça marquera complètement l'ownership et tu pourras toujours retourner un std::unique_ptr null si l'objet n'est pas trouvé :)

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

Moui, la SFML 2.0 est une grosse réecriture il me semble, autant tout casser et passer à du moderne :)

Son changelog était assez marrant d'ailleurs.

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

Très bon choix pour SDL.

Je n'aime pas la SFML pour plusieurs raisons :

1. Le développeur utilise du C++ d'un autre âge, pas d'exception, pas de RAII, pas de C++11. Portabilité ? Non merci, C++11 a déjà 5 ans.

2. J'ai eu un souci de rendu sur FreeBSD (sur Windows ça fonctionnait), tout ce que l'auteur a su me répondre était "aucune idée".

3. Je suis l'auteur du support du joystick dans SFML, lorsque j'ai proposé le patch, j'ai bien précisé qu'il s'agissait de FreeBSD mais l'auteur a vraiment voulu merger le code avec Linux. Heureusement après plusieurs mails, il a finalement bien voulu ne pas mélanger le code FreeBSD et Linux.

Hâte de voir ton framework du coup :)

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

Bah alors il a gagné depuis l'apparition de Visual Studio Code, au moins.

En même temps ce n'est rien d'autre qu'un fork de atom alors bon :)

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

Je ne sais pas pourquoi tu préfixes toutes tes structures par un _. En C++ c'est même réservé par la norme, je ne sais pas ce qu'il en est C.

Mais aussi, je trouve ça moche.

Sinon dans l'ensemble je trouve que le code est propre et bien documenté.

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

Wine etait en licence MIT avant de subir l'abus d'une societe qui a forke et ferme le code, rendu payant le logiciel et fait pleins de correctifs (et le tout parfaitement legalement). Wine est finalement passe en GPL pour ces raisons (et aussi parce que beaucoup de contributeurs se rendaient compte qu'il travaillait presque directement pour l'autre entreprise qui cherry pickait tous les nouveaux fixes de Wine).

Effectivement pour le coup je pense que c'est bien pour Wine. Je n'ai rien contre la GPL lorsqu'il s'agit de frontends (exécutables finaux).

Cela protège largement le logiciel et c'est très bien comme ça.

C'est plutôt pour les bibliothèques, j'ai toujours pesté et fuis celles sous licence GPL. Je comprends pas l'intérêt de forcer un utilisateur de ta bibliothèque à faire du code open-source uniquement. C'est là que je trouve que la vision est vraiment orientée fanatique. Heureusement un bon nombre de personnes choisissent néanmoins la LGPL qui est bien mieux pour les bibliothèques.

Tiled (mapeditor.org) est bien fait pour ça. Son exécutable est sous GPL ce qui contraint tous les changements à être libre aussi et sa bibliothèque est sous LGPL. Au moins, normalement tout le monde est content :)

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

Lors d'une discussion autour de la licence BSD de Redox (OS écrit en langage Rust) un argument m'a semble convaincant. Il disait que ce qui est dommage avec les licences permissive c'est qu'elles n'incitent en rien les gens qui l'utilisent (PS3/PS4 et autres) a contribuer en upstream. Ce qui explique pourquoi FreeBSD est un projet quasi vide cote driver, parce qu'aucun inde ne souhaite contribuer (car son travail peut être réutilisé permissivement) et qu'aucune boite n'est pousse a le faire (car rien ne l'y oblige).

C'est une vision un poil extrémiste quand même.

Nvidia a bien fait un driver non libre pour Linux et aussi pour FreeBSD, je vois pas en quoi cet argument de licence permissive va fait fuir les entreprises.

De plus, rien ne t'empêche d'écrire un driver pour FreeBSD sous licence GPL. Personne ne t'interdira de faire cela.

FreeBSD a déjà reçu des contributions extérieures. Si le projet évolue plus lentement c'est pour bien d'autres raisons. Déjà parce que le projet s'est largement focalisé sur les serveurs. C'est venu après Linux et le modèle de développement est largement plus stricte. De plus les *BSD ont fait moins de communication.

Du coup je me demandais ce qu'en pensais les gens de FreeBSD car les arguments (la page n'est plus dispo) de la page Redox sur le choix de licence ne m'ont pas vraiment convaincu (ou bien je ne comprends pas).

En gros, c'est quoi l’intérêt de FreeBSD pour le libre ? :) C'est pas un troll, c'est une vraie question.

Si j'ai bien compris, pour toi c'est "use GPL or die" ? :)

Chez FreeBSD (et autres BSD même) on aime la liberté. Utiliser la GPL et contraindre les gens pour moi c'est une vision de fanatiques qui détestent les entreprises et voient le mal partout.

Je me souviens Theo de Raadt (OpenBSD) avoir dit quelque chose comme "Les gens font Linux parce qu'ils détestent Windows, nous faisons OpenBSD parce que nous aimons Unix".

Personnellement je fais que du libre (license ISC) et si on contribue à mes projets tant mieux, sinon c'est pas grave.

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

1. Les utilisateurs de Linux sont de base peu nombreux,
2. Les Linuxiens gamers sont encore moins nombreux,
3. Certains comme moi ne souhaitent pas installer Steam car c'est un logiciel privateur,
4. Les jeux sous Steam sont très loin d'être tous compatible Linux.

J'ai tout de même testé une fois, c'était plutôt bon et bien intégré. Je pense que ça reste une bonne chose.

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

Enfin, depuis le temps qu'on attend ça. Je trouvais ça tellement ridicule. Je trouve que Debian n'est pas assez transparent et modifie beaucoup trop les paquets qui sont fournis.

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

Aaah CMake <3 toujours aussi fan :)

/me est tellement content d'avoir changé le build-system vers CMake à $JOB

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

Celui qui m'a donné envie de me lancer dans le BMX il y a plus de 10 ans. Quel chagrin de voir son décès aujourd'hui même s'il a arrêté le BMX depuis plusieurs années. Pour moi ça a toujours été le meilleur. Décidement cette année…

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

Le départ de Matt n'a aucun impact sur la popularité de Mercurial. Mercurial a toujours été largement moins répandu que Git déjà parce que Git a eu un succès populaire avec GitHub et parce que son système de branche est efficace. Qu'il soit fait par Linus Torvalds lui donne probablement une étiquette supplémentaire.

Je suis fan de Mercurial, je m'en sers depuis environ 2008 et je m'en sers toujours, c'est mon DVCS au quotidien. Mercurial a des défauts mais il a aussi tellement d'avantages.

• TortoiseHg, le workbench, juste magnifique et exactement la même interface sur chaque plateforme !
• La portabilité est importante,
• Simplicité, les commandes sont courtes avec une documentation claire net et précise,
• Mise en place d'un serveur de dépôts, avec hgweb.cgi environ 5 lignes de configuration,
• Léger, le core fait la plupart des choses, les extensions fournies avec peuvent compléter,
• KISS, hg revert | update | branch vs git checkout,
• Un seul langage, Python. Git : bash, perl, C, …
• hg incoming | outgoing,
• hg serve,
• hg heads,
• hg summary.

Malgré tout, j'avoue que GitHub est particulièrement pratique pour collaborer.

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

Le bluetooth a été retiré il y a quelques versions de cela, j'espère que ça reviendra un jour.

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

Entre faire tourner un logiciel propriétaire local sur sa machine et utiliser un service web il y a une large différence. Sinon, on peut aussi enlever le support de l'imap/facebook/skype et autre conneries dans empathy et les compte en ligne.

De plus, si tu as pas de compte google, tu ne rajoute pas de compte en ligne et tu n'a aucune intégration. C'est pas parce que tu as le driver nvidia, le paquet flash player dans les dépôts de ta distribution que tu es obligé de les installer.

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

Tu le teste avec quelle distribution ?

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