reno a écrit 3886 commentaires

Je ne parlais de la vérification du range de l'index mais du type de l'index: si tu as un tableau indexé par un nombre de Choux, le compilateur ne te laisse pas l'indexer par un nombre de Carottes.
En C++, tout est indexé par des entiers, pareil en Rust je crois mais en Ada tu peux choisir simplement un type fort comme Index.

Il y a les effets de mode qui expliquent pourquoi Ada est si peu utilisé (même ses concepts comme les tableaux qui vérifie le type fe l'index ne sont pas repris par d'autres langages :-( ).

Mais il y a aussi que certaines choses courante dans d'autres langages comme les string de taille variable, en Ada ça pique les yeux, ça n'aide pas..

J'utilise principalement VSCode+grep pour travailler.

Pourquoi VSCode? Parce qu'il démarre assez rapidement et que la navigation entre ~20 fichiers est assez bonne la "plupart" du temps.

Pourquoi grep? Car souvent l'indexation de VSCode est pourrie (en C++): incapable de trouver un fichier sous un #include, ou il met + de temps que grep pour me trouver la définition d'une fonction(!) ou pire il me donne la mauvaise définition d'une fonction (dans le mauvais working tree).

Mais j'étais resté confiant en l'indexation de CLion (que je n'utilise pas car trop lent), sauf que cette semaine en faisant un find usage d'une méthode j'ai découvert que CLion avait manqué l'appel a la méthode a certains endroits..

Ma conclusion : un bon éditeur de texte plus grep/ag/ripgrep >> aux IDE pour les gros projets C++

Dommage que je n'ai pas le temps d'apprendre a configurer correctement VSCode pour qu'il appelle grep ou find pour moi, plutôt que de le faire moi même dans un terminal et de lui dire ensuite d'ouvrir le fichier que j'ai trouvé (ce qui est totalement absurde quand on y réfléchit bien)

Bon j'avoue ne pas vraiment comprendre l'analyse des performances sous Linux, il y a perf, SystemTap, bpftrace, ça fait beaucoup..

Mais pour ceux qui comprennent mieux, LWN vient de faire un article sur le sujet: Comparing SystemTap and bpftrace: je me permets d'envoyer un subscriber link (à ne pas diffuser inconsidérément merci):
https://lwn.net/SubscriberLink/852112/8a228aa8184dabc9/

Windows utilise \ comme séparateur de chemin car ils avaient peur de se prendre un procès s'ils réutilisaient /

SDL kezako?

Bah à peine GTK4 sorti qu'ils planifie GTK5 (cf le lien du dessous), qu'ils planifient GTK4.1 ça serait normal mais GTK5 .. ça montre bien qu'ils n'en 9nt rien a faire de la compatibilité..

Dommage que les dev d'Haiku ont préféré faire joujou avec leur propre noyau plutôt que d'utiliser Linux comme base car au contraire leur force a eux c'est la stabilité au niveau API..

Y a-t-il un desktop sur Linux qui vise la stabilité (retrocompatibilité) au niveau API?

Sur le long terme, ça pourrait être une stratégie gagnante..

Dommage on n'est pas Vendredi autrement j'aurais rappeler le coup de KDE4.0 mis par défaut sur Fedora alors que côté projet KDE on voyait ça comme une version expérimentale..
/S

Je ne suis pas un pro de gerrit mais pour moi au contraire gerrit est la source de la perte d'historique: je me fais mes petits commit local donc tout va bien pour git mais pour pouvoir les pousser sur gerrit je suis obligé de les squasher en un seul commit..

Salut,

j'utilise actuellement VSCode pour développer en C++, mais bon j'en suis moyennement satisfait, alors j'ai essayé SpaceVim et non seulement il y avait des bugs au démarrage en plus SpaceVim s'ouvrait plus lentement que VSCode (à vide) --> poubelle.

D'ou ma question, ça donne quoi coté réactivité ta configuration?

Effectivement ça semble intéressant les clone partiels d'un point de vue scalabilité.

Je ne suis pas très optimiste: il y a plein de choses qui pourraient être amélioré dans un DVCS par rapport à git: la gestion des sous-modules, la gestion de l'historique (je considère que "squasher des commit" est une hérésie, on devrait pouvoir "compresser" l'historique mais de manière réversible pas de manière irréversible), la cohérence des commandes, la scalabilité, la gestion des gros fichiers binaires, un système de ticket/doc intégré..

Mais un meilleur merge est-il une killer feature contre git?
Personnellement je n'en suis pas sûr, car c'est rarement un problème pour moi, mais je souhaite quand même du succès à Pijul,

Bah, il y a des irrationalitées 'à la mode' dont on parle plus OK, mais bon comme vieille irrationalitée il n'y a pas que les religions : l'homéopathie est pas mal dans le genre..

Certaines peuvent baisser aussi : j'entends beaucoup moins parler des sourciers, du spiritisme..

Bref tout cela montre que l'homme n'est pas particulièrement rationnel a la base et que ceux qui ont des intérêts financiers (les prêtres, les rois, les vendeurs de bonne aventure, les homéopathes.) utilisent ça a leur avantage : rien de nouveau sous le soleil..

Si tu pars d'un truc faux ou presque, tu vas t'enfoncer dans le faux de plus en plus, car c'est ce qui t'interesse et ton cerveau va te persuader que c'est vrai …
Et la les dégats sont catastrophiques, des gens sont persuadés que la terre est plate !
au 21e siècle

Franchement, je ne vois pas trop la différence entre croire à une religion quelconque et croire que la terre est plate: les 2 sont irrationnels.
Donc je ne vois pas trop en quoi la situation actuelle est pire qu'avant: au contraire le nombre de gens "raisonnable" (athées ou agnostique "sceptiques") est en constante augmentation (en valeur absolue).

Bon OK en pourcentage, ça n'est pas sûr par contre mais ce pourcentage n'a jamais été très élevé..

C'est que la conception de Gnome (ou de KDE) n'essaie pas particulièrement d'être robuste, il y a arcan https://arcan-fe.com/about/ qui montre qu'il est possible d'être robuste au dessus de Wayland, maid par défaut ça n'est pas le cas..

Prompt indiquant le worktree(repo) git utilisé + la branche utilisée + le répertoire utilisée en "compressant" pour que ça ne prenne pas de place.
Avec un mode "vidéo inversé" quand je suis dans un worktree qui ne correspond pas a celui configuré dans les variables d’environnement du terminal: ça m'a pris du temps a développer mais je ne me suis plus jamais trompé de worktree..

Le problème est que les optimisations du compilateur fonctionne dans un monde 'statique', alors que l'utilisation de ton cache va dépendre des applications qui tournent sur le CPU: le compilateur va bien marcher pour les HPC ou il n'y a qu'une seule application qui tourne a la fois.
Sur tout le reste, à mon avis le compilateur ne peut pas être compétitif par rapport a l'OoO et aux caches "dynamiques".

Il faut être trèèèsss patient pour utiliser CLion sur le projet sur lequel je suis..
Après il y a un collègue qui m'a dit que ça allait en changeant la configuration pour que CLion utilise la RAM plutot que des fichiers, sans le COVID je l'aurais déjà torturé pour en savoir +

Aujourd'hui j'ai pingé la collègue avec laquelle je partage une machine son VSCode (enfin le plugin C++) utilisait 39GO de mémoire résidente.
Le serveur est un monstre mais ça se remarquait quand-même !
Elle ne l'utilisait même pas, elle avait juste laisser la fenêtre ouverte depuis Lundi..

Après il n'y a pas de bon IDE pour les projets C++ de grande taille..

Je suis quasiment sur que dans les extensions 16bit de ARM ou MIPS, les instructions 32 bits sont alignées sur 32bits pas sur 16bits comme le RISC V.
Et ça n'est pas une petite différence, sur le RISC Vl peut y avoir un défaut de page pour accéder à la moitié d'une instruction, le prefetching est + compliqué aussi, après l'icache est + efficace..

Merci, je sais pourquoi ça a été fait, mais pour moi c'est privilégié les microcontrôleurs qui ont très peu de RAM au dépend de CPU 'normal' après c'est clair que le RISC V va être cantonné au monde des microcontrôleurs pendant une longue période..

Il y a quand même un point qui me choque particulièrement sur le RISC-V: la possibilité d'avoir des instructions 32bit non-alignées avec l'extension C.
C'est un RISC ça?? Bonjour la complexité de l'extension..
J'aurais bien aimé avoir un compte rendu de la discussion sur ce point car je trouve la décision vraiment surprenante.

Je ne comprends pas ton argument : que tu repartes 'from scratch' ou que tu sois au dessus de Linux, si tu vises la récréation fidèle de BeOS, il faut créer un système de fichiers, ça ne change rien..

Pas terrible l'attitude de Barret..

Une des particularité de BeOS était une excellente gestion de processus en multi-CPU (le multi-cœur n’existait pas encore), bien meilleurs que Windows ou Linux de l’époque

Pas si sûr que c'était une force du kernel de BeOS: pour moi, c'était plutôt les API qui poussaient les développeurs a utilisé le multithreading + que sous les autres OS.
Et même si c'était oe cas: qu'est-ce qui est plus facile : adapter le scheduler de Linux pour ses besoins (en espérant l'intégrer au noyau à (long) terme) ou réécrire un OS?

Sinon d'accord avec toi qu'il aurait fallu avoir l'équivalent de Wine pour Be.

Amusant que Haiku soit le seul survivant: quand BeOS est mort, l'idée naturelle était de faire un clone de BeOS au dessus de Linux ou d'un BSD, mais le seul clone de BeOS qui reste part d'un "nouveau" noyau.

Plusieurs explications possible, soit:
1) seul le fait de repartir du début est assez motivant pour fidéliser des développeur.
Même si d'un point de vue technique c'est sous-optimal (20 ans pour recréer BeOS..).

2) l'utilisation de Linux/*BSD induit beaucoup de choix possible sur la réutilisation ou non de l'existant (au dessus de X11? sans X11?) qui fragmente et donc fragilise cette option.

3) la faute a pas de chance.

Je me souviens d'un projet de ré-implémentation au dessus de Linux qui avait commencé a prendre puis est mort: le nombre de développeur ayant le temps et les capacités pour travailler sur un projet de ce type étant très faible, un seul projet mort a peut-être suffit à tuer l'option BeOS/Linux.
Après cette explication est peu satisfaisante car rien n’empêchait de forker le projet pour le continuer.