pulkomandy a écrit 1970 commentaires

J'utilise de plus en plus YouCompleteMe, qui fonctionne sous forme d'un démon en arrière plan (lancé par vim de façon transparente) et fournit à la fois le soulignement des erreurs de syntaxe et autres problèmes, et la complétion automatique.

Je ne l'ai testé qu'en C et C++ pour l'instant, mais il sait faire ça pour plusieurs langages, dont Python.

Essaie d'installer Windows XP sur un PC moderne qu'on rigole un peu. Normalement il va te demander d'insérer la disquette avec les drivers de ton contrôleur SATA.

Faire du warmup avant de lancer l'interprétation, c'est un peu contradictoire avec vouloir faire du JIT, quand même.

L'idée du JIT, c'est de pouvoir profiler le code et prendre des décisions à la volée. Genre si y'a un if() qui n'est que très rarement exécuté, le remplacer par un traitement similaire à celui d'une exception.

Sinon, tu fait une bonne vieille étape de compilation au démarrage et on en parle plus.

De mémoire, la VM .net de microsoft a un cache disque du code compilé/optimisé par le JIT, donc c'est vraiment seulement le tout premier lancement de l'appli qui est lent.

Et d'autre part, je suis surpris qu'on trouve encore des garbage collectors "stop the world". On sait faire des trucs qui tournent en tâche de fond sans avoir besoin de geler complètement le programme, non?

Mais avoir un bon navigateur web, c'est pas évident non plus. Le port de WebKit sur Haiku nous a fait trouver plein de bugs et de limitations dans nos APIs, et c'est un travail conséquent juste de garder notre version à jour avec les nouveaux développement.

Le HTML5 change en permanence, donc il faut régulièrement ajouter de nouvelles fonctionnalités pour que la dernière web app à la mode puisse se lancer correctement. Actuellement on est en train de travailler sur Web Crypto pour pouvoir utiliser WhatsApp, par exemple.

Même après une pause de 17 ans, on peut toujours reprendre le code source d'un logiciel et le faire évoluer. C'est ce que fait le projet HaikuArchives et on a pu récupérer des centaines de logiciels de cette façon.

Il y en a encore plein d'autres dont nous n'avons pas pu récupérer les sources. Je pense par exemple à SynC Modular, qui est un logiciel de synthèse musicale dont on a pas encore réussi à contacter l'auteur pour obtenir une copie du code. Et là, ce sera difficile de faire quoi que ce soit, il faudra donc le remplacer…

On dit Haiku, pas HaikuOS :)
Sinon il faut dire aussi LinuxOS et WindowsOS, question de cohérence :p

Rien ne t'empêche d'avoir une couleur différente pour chaque caractère du nom de ta variable, avec une signification différente.

Mais pour moi, du code propre et bien rédigé doit pouvoir se lire sans coloration syntaxique. La coloration, c'est pratique pour essayer de démêler un code illisible.

On tourne en rond, quelqu'un a déjà donné ce lien.

La réponse reste la même: ce genre d'infos devrait être encodé dans le type de la variable, pas dans son nom. Pour reprendre l'exemple du blog, il faudrait une classe UnsafeString, et les chaînes non sûres devraient être stockées dans des variables de ce type.

Après, on peut, au choix, mettre un operator= (ou un opérateur de cast, ou…) qui va faire la conversion de façon transparente (mais il faut bien réfléchir), ou ajouter la méthode .Encode() pour que ce soit explicite.

Et du coup, ce n'est plus au développeur de vérifier ce genre de choses: le compilateur va faire le job tout seul. Le mauvais code fonctionnera quand même dans le premier cas (on va juste perdre en performance avec des conversions inutiles de partout), et ne compilera même pas dans le second.

Par contre, et c'est ce dont on débat ici, il n'est pas question d'avoir un type différent pour une variable locale et un membre d'une classe. Donc, dans ce cas, avoir un préfixe peut faire sense (encore que, utiliser systématiquement this-> n'est pas forcément une mauvaise idée, quoi qu'un peu verbeuse).

Ce n'est pas parce qu'un logiciel a commencé à être développé il y a 17 ans qu'il est obsolète. Je ne comprend pas cette manie de vouloir tout réécrire à partir de zéro tous les 5 ans.

Comme l'a dit devnewton plus bas, en 2003 on avait plein d'environnements de bureau sympa sous Linux, mais ils ont tous décidé de tout jeter et de recommencer. C'est pas comme ça qu'on arrivera à quoi que ce soit.

L'API de Haiku a pas mal changé par rapport à celle de BeOS, et les habitudes au niveau des interfaces utilisateur aussi. Mais ça reste quand même largement moins cher de mettre à jour une application existante que de refaire tout le dev.

Chez moi, les variables membres sont préfixées par un f (comme "field"), les statiques par un s, et les constantes par un k. Et les méthodes ont des noms qui commencent par une majuscule, donc pas de conflit possible lors de la complétion.

    struct Limit
    {
        int32_t fQuantity;
        double  fPrice;
        bool    fActive;
    };


    class MyClass
    {
         public:
             double  Volume() const;

         private:
             int32_t fQuantity;
             double  fPrice;
             bool    fAsActive;

             static const double kTaxes;
    };


    double MyClass::Volume() const
    {
         double volume = fPrice * fQuantity * (1 + kTaxes);
         return volume;
    }

Et puis franchement, y'a vraiment pas beaucoup de caractères réservés dans les noms des identifiers, pourquoi vouloir justement utiliser ceux-là? Pourquoi pas un ‿ par exemple?

En ce qui me concerne, Haiku est mon système principal depuis quelques années et j'ai vraiment du mal à utiliser Windows et même GNU/Linux (ou j'ai réussi à avoir un système qui fonctionne à peu près comme je veux après plusieurs années à ajuster des fichiers de configuration).

Même si on ne remplace pas Windows sur les PC de bureau, ça fonctionne au moins sur ma machine et c'est dans mon intérêt qu'il y aie plus d'utilisateurs et j'espère, plus de contributeurs. Même si les ambitions ne sont pas forcément gigantesques.

Le côté expérience est également un point important. J'ai appris plein de choses sur le C++ en travaillant dans Haiku, mais aussi sur la façon de gérer un projet libre avec des contributeurs bénévoles, un management sans chef de projet, ce qui a ses avantages et ses inconvénients. Et aussi l'encadrement d'étudiants dans le cadre du Google Summer of Code et du Google Code-In, qui nous oblige à réfléchir à la façon dont de nouveaux contributeurs peuvent aborder le projet.

Il y a aussi un peu un intérêt historique à découvrir le fonctionnement de ces applications BeOS, qui parfois ont essayé de faire des choix différents, en profitant d'être sur une plateforme toute nouvelle, qui pouvait se permettre de bousculer un peu les habitudes. On peut donc avoir un regard avec un peu de recul sur ce qui a marché ou pas.

Le projet HaikuArchives essaie de récupérer le code source d'un grand nombre d'applications pour BeOS. On assure la maintenance de ces applications mais pour les tenur vraiment à jour ce serait un travail beaucoup plus important, donc on fait le minimum pour l'instant…

En parallèle, on a des applications Qt qui sont portées avec une assez bonne intégration (c'est ce qui nous permet d'avoir LibreOffice, par exemple). Mais ces applications ne sont pas "natives", et ne s'intègrent jamais parfaitement dans l'environnement de Haiku, donc on les considère comme une étape de transition, ça permet de combler les trous quand une application native pour Haiku n'existe pas encore.

On pourrait faire la même chose avec GTK, mais pour l'instant on considère plus important le travail sur l'OS et les applications natives.

Je vais répondre en reprenant la description présente sur le site de Haiku:

Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.

L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).

Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.

Il y a donc toujours une place pour un système libre sur ce marché.

Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?

Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).

Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.

Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.

D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).

La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.

Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.

On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.

En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).

La version anglaise dit la même chose:

A registry hive is a group of keys, subkeys, and values in the registry that has a set of supporting files that contain backups of its data.

Donc ce n'est pas une traduction bizarre. La base de registre est découpée en plusieurs ruches.
Je ne connaissais pas ce terme, moi non plus.

Tu installes mupdf et tu pourras utiliser des commandes vim du type 42g pour aller à la page 42 ou /mot pour chercher un mot (puis n pour passer au résultat suivant). Je ne peux plus m'en passer pour naviguer dans des PDFs.

C'est assez peu mentionné, mais les "anciens" compteurs électroniques (la génération avant Linky) permettait de récupérer ces infos directement chez soit, via un port série situé directement sur le compteur. Pourquoi il faudrait envoyer cette information au fournisseur d'énergie puis… leur demander pour y avoir accès? (accès qu'ils pourraient très bien rendre payant, d'ailleurs).

Donc le côté éducation/information, ça existait déjà, mais ça n'intéressait pas grand monde.

L'intérêt du relevé heure par heure, c'est que le fournisseur d'énergie va pouvoir facturer ça comme il veut (par exemple Direct Energie propose des heures "super creuses" à certaines périodes). On est plus limité à un modèle heures pleines/heures creuses avec des horaires fixes imposés par le distributeur d'énergie.

Dans ce cas précis, on fait la liaison avec le nom de l'option, dès fois qu'il vienne l'idée de mettre une espace entre le - et l'option.

Pourquoi tu crois que ST Microelectronics est toujours vivant et présent en Europe?

Je ne suis pas certain que personne ne s'en soucie…

C'est rigolo 3 minutes mais pas terrible pour communiquer. J'aurais préféré un site plus classique, avec quelques images des années précédentes, ce genre de choses.

Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.

Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)

Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…

Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.

gcc sait le faire, avec la famille d'options qui commencent par -M. Je crois qu'il peut même te générer un Makefile.

C'est ce que cmake utilise pour gérer les dépendances, par exemple.

La vraie raison c'est qu'il y a des distributions Linux qui vont gérer la compilation et le packaging. Donc peu de projets ont besoin de le faire d'eux-même.

Non mais RMS plus personne en a grand chose à faire de ce qu'il raconte. Il y a plein d'autres organisations que la FSF qui font la promotion du libre plus efficacement et de façon pertinente. Va voir la SFC ou la FSFE par exemple.

Je vois les choses d'une façon un peu plus positive: le logiciel libre progresse plus vite que les notions d'éthique qui y étaient souvent associées. ça ne veut pas dire que la partie éthique régresse, au contraire.