Elfir3 a écrit 1164 commentaires

Je trouve l'idée très sympa, je suis étonné qu'il n'y ait pas déjà des format d'archive proposant ce genre de fonctionnalités.

Par contre, je trouve l'impossibilité de faire de modification sur les fichiers, ou d'ajouter des fichiers, assez limitante. En tout cas, il ne me semble pas avoir vu d'indication comme quoi c'était possible.

Même dans le cadre de la distribution d'une application, il n'est pas rare d'avoir quelques fichiers écrits sur le système de fichier, certains font ça proprement en fonction de l'OS sur lequel ils tournent, d'autres font ça juste à côté du binaire, ce qui a des avantages et inconvénients.

J'imaginais aussi pouvoir faire packager un projet musical, tout en ayant la possibilité d'aller le modifier une fois monté. L'essentiel des accès sont en lecture, mais quelques modification pourraient encore être faites niveau métadonnées par exemple.

Est-ce que cette limitation est d'ordre technique sur le format de fichier choisi ? ou une contrainte choisie pour optimiser ?

Bon boulot en tout cas :-)

Pire, ils t'envoient un message avec un code pour s'assurer que le numéro est bien utilisé…

On pourrait ajouter C++ ou java …

De toute façon, go est lent. Donc quelques soient les raisons…

Qu'on me corrige au besoin (j'ai à peine touché à l'embarqué en jouant avec de l'arduino), mais l'OS n'est pas vraiment certifié, seul le micro kernel (Sel4) l'est, et l'était déjà avant l'arrivée de google avec Rust.

De mon point de vue, cet OS est plutôt un framework qui inclus un lib pour communiquer avec le kernel et qui vient avec quelques fonctions supplémentaires utiles (loggers, custom allocators, ..). Mais j'imagine que c'est ce qu'on appelle un OS à ce niveau :-)

Pas con l'histoire du controleur Midi… Faut voir si des messages Midi seraient suffisant à le création d'un patch (sans trop de bricolage non plus). Je suis pas encore assez documenté pour ça, merci pour l'idée.

Normalement avec les sysex tu peux faire un peu ce que tu veux. Par exemple juste envoyer un patch que tu désérialise côté synthé. Ou lancer une sauvegarde des paramètres en cours sur un emplacement mémoire.

J'ai trouvé la doc sysex du Korg Kronos pas mal faite si tu cherches des exemples de ce que tu peux faire avec.

Tu n'en parle pas, mais je suppose que tu risques sans doute tôt ou tard de vouloir l'intégrer dans une DAW. Commencer par une version plugin (ou du moins échafauder une version plugin dès le début), aidera a avoir la bonne archi pour que ce soit facilement pluggable par la suite.

Il y a 2 types de plugins que je te conseillerais à l'heure actuelle :
- lv2, qui est compatible avec la plupart des softs sous linux.
- clap, nouveau, mieux techniquement et poussé par BitWig. Mais nouveau… donc encore peu supporté.

Je me trompe peut être, mais j'ai pas souvenir d'y avoir déjà vu du python, même si c'est juste pour la partie GUI. En général, c'est du C ou C++ de ce côté là, avec Juce, Gtk, Qt ou des framework graphiques un peu plus exotiques. Encore une fois, je regarderais le code d'autre plugins pour me faire une idée.

Je sais que Juce est très utilisé à ce sujet avec pas mal d'outils pour la partie synthétiseur (oscillateurs, filtres…). Mais jamais testé.

Note que Lv2 et Clap viennent avec des "facilités" pour te donner des points de contrôle sur les paramètres du synthé, et que tu peux potentiellement reporter la développement de l'interface à plus tard.

--

Note, il me semble que python n'est pas vraiment fait pour être utilisé depuis un autre langage. Ca a déjà été fait, mais on préconise plus souvent d'appeler du C depuis python.
Surtout que, dans le cas d'un logiciel de traitement audio, j'éviterais de mettre du python dans la boucle pour des questions de perfs.

Autre idée si tu t'attaches au python, utiliser le midi pour contrôler les paramètres et faire de ton GUI un contrôleur midi.

Le soucis c'est qu'on ne de référence qu'au niveau du consommateur.
Si tout le monde diminue sa consommation de vidéo, le nombre de routeurs utilisés pourra diminuer. On aura moins vite tendance à remplacer le routeur gigabit par du 10 gigabit parce qu'on arrive à saturation.

Donc oui, c'est faux si on regarde la consommation d'un équipement réseau. Mais en terme de consommation répartie sur l'ensemble des machines mises en parallèle pour servir une région, il y a aura un impact.

Edit: j'avais raté un passage du blog .. ;)

Donc le premier points qui tu évoques est déjà interdit; tu veux des radars capable de détecter si des mineurs sont dans la voiture d'un fumeur?

Je remarque que la loi a aussi changé chez nous en 2020. Bonne chose ! Donc oui. Et a défaut d'une solution technique pour le radar, je propose un détecteur de fumée dans la voiture avec lecteur d'empreinte à utiliser par chaque occupant de la voiture dès qu'il y a détection. Couplé potentiellement sur une balance pour évaluer le poids des occupants de la voiture.

les parents devraient demander de manger plusieurs fois AVEC les élèves

On parle d'une école d'enseignement spécialisé, où les parents d'une bonne proportion d'élèves donnent des friandises en guise de repas à leurs enfants quand ils n'aiment pas ce qu'il y a à la cantine… et ce n'était pas qualité des repas qu'il fallait remettre en cause. L'éducation se fait, malheureusement pour certains, aussi à la maison.

Alcool, tabac, malbouffe, c'est d'abord un problème personnel (quoique avec l'alcool on aussi du collatéral)

Dis ça aux gosses qui sont obligés de subir la cigarette du parent dans la voiture, ou au personnel d'une école spécialisée qui doit fermer sa cantine parce que les enfants veulent manger comme à la maison (burger, frites…). Deux cas vécus..

En pratique, un radar qui lit une plaque, ça se voit.

L'infrarouge pourrait faire des miracles ;)

Sinon, les technologies a base de camera qui pourraient être incluse dans un boitier ne pourraient pas être assez performantes pour enregistrer les images et, sur base de plusieurs images, décoder la plaque ? Quand on voit la taille que ça prend..

J'ajouterai que ça reste une très mauvaise excuse, une limitation de vitesse n'est pas une consigne de vitesse; lorsque je conduis la logan des parents (aucun équipement moderne), j'ai pas de PV pour excès de vitesse, et j'ai pas les yeux rivés sur le compteur.

Moi non plus, mais ça n'a pas toujours été le cas. Ca demande un peu d'expérience pour jauger correcter sa vitesse en agglomération quand tu sors d'une autoroute. Je préfère savoir que mes enfants regardent la route plutôt que leur compteur quand ils sont en voiture.

Oui en absence de cas pratique où c'est utilisé, je veux bien qu'on me montre.

Ceux qui en avaient besoin ont migré vers d'autres langages où tu peux gérer finement la mémoire a force de se faire dire qu'ils n'en avaient pas besoin :-)

Ta façon de répéter continuellement comme s'il s'agissait d'une joute que tu souhaiterais gagner plutôt que comme un échange de comment parvenir à un objectif est extrêmement irritant.

J'essaie juste de recentrer sur le sujet initial qui a mené à cette échange de threads…

On est bien d'accord, mais là on parle du GC.

Je vois pas de cas où ça serait utile, cette gestion a un coût et peu être facilement source de bug.

Oui, ça a un coût, ça peut être source de bug (tout comme n'importe quel code), mais tu maîtrises avec précision quand tu veux que ce coût t'impacte et tu peux l'étaler à ta convenance en fonction du contexte d'exécution.

Je vais arrêter là par contre, j'ai exposé, il me semble, des points précis sur comment faire.

Non. Tu t'es contenté d'essayer d'adapter le cas de départ pour qu'il puisse fonctionner avec les différentes solutions à base de GC que tu avais en mains, ce qu'on ferait si on était contraint d'en utiliser un, ou de dire que tu ne vois pas où ça serait utile.

Bref, toujours pas de solution à base de GC pour garantir une frame, donc de la stabilité…

Tu peux dimensionner les générations et spécifier des configurations pour que les étapes du gc s'exécutent au moment opportun (ça n'est pas programmatique et impératif avec System.gc())

Donc, tu ne peux pas dire "il me reste 14ms pour cette frame-ci, gc pendant ce temps" et à la frame suivante lui demander de le faire pendant 5ms parce que tu as du faire du calcul un peu plus intensif.

Ta young gen est dimensionnée pour une seule de tes frame et le gc s'exécutera une fois par frame systématiquement et jamais plus que le temps que tu lui as donné

Mais rien de tout ça n'est dynamique vu ce que tu as écrit plus haut.

mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.

C'est bien beau, mais quand ça dépend de l'utilisateur on est loin d'un truc qui scale automagiquement

Désolé je suis un peu fleuve c'est pour rentrer un peu dans le détail et montrer l'approche. Il est bien sûr possible de faire mieux en faisant tout à la main, mais tu troque un contrôle plus simple (au sens KISS) pour un outillage très riche qui t'aide énormément à comprendre ce qui se passe.

On est d'accord que l'utilisation d'une VM avec ses propres types te permet plus de possibilité au niveau de l'auscultation de ta mémoire. Mais si tu te retrouves dans le cas ci-dessus avec les garbage collector actuels, t'as rien d'autre à faire que tortiller tes données et virer des features pour pouvoir éviter d'avoir à nettoyer quand une gestion manuelle aurait pu t'éviter ce soucis.

Je ne dis pas qu'il n'est pas possible d'avoir un GC qui fonctionne sur ce principe, mais visiblement ça court pas les rues..

Dans ce cas, je faisais référence au contenu du lien plus haut :D

Il y a sans doute plus de jeux écrit en Java qu'en Python :-)

En même temps, vu le matraquage des évangélistes dès qu'on parle de java c'est pas étonnant que beaucoup n'aient pas osé chercher plus loin ;)

Mais entre Python, C#, Java, Lua et Javascript, ça fait un paquet de jeux qui utilisent un ramasse miette sans souci.

Oui, et c'est pas pour rien que le jeux qui ont besoin de beaucoup de données se passent de ces langages. Ou alors tu vois apparaître des bugs report avec GC dedans une fois que le jeu commence à avoir une taille conséquente de données à gérer.

C'est le lien que j'ai posté plus haut :-)

Résumé, si tu dois allouer tout en ayant des perfs stables, mieux vaut virer les GC..

Note, ceci dit, que python fait vachement mieux que java dans ce domaine.

Après je connais peu de gens qui s'assurent que leur soft ne soient pas préempté par le noyau.

Pareil, mais ici on est pas du tout à ce niveau. Je reprends le cas de jeux parce que c'est ma seule expérience avec ce genre de soucis. Dans un cas standard avec un ordonnanceur qui fait bien son travail, le GC peut plomber les performance simplement parce que la désallocation se fait quand il l'a décidé, sans se soucier du temps qu'il a de disponible. C'est le cas avec le GC par défaut, les GC alternatifs proposés, et je n'ai pas vu d'alternative dédiée au respect du temps d'une frame quand j'ai fait mes maigres recherches à ce sujet. Mais je ne doute pas qu'il doit exister des GC exotiques que tu peux utiliser en patchant la jvm…

Et, en particulier dans le cas d'un jeu, avoir des performances généralement moins bonnes, ou d'avoir un gros drop de fps à cause d'une désallocation massive à un moment précis, ben ça fait la différence entre un jeu qui reste jouable ou non. Et c'est au développeur de trouver une parade.

Bref, pour en revenir sujet du thread, les GC peuvent être un soucis simplement quand le but est d'avoir un minimum de garantie de performances stables et sans que ce soit dans le contexte d'un driver.

Ensuite toujours pour java, tu as du tweak de jvm par rapport à ton code.

Veux-tu dire par qu'il est possible de s'assurer que le GC n'interrompe pas ou ne ralentisse pas l’exécution d'une portion de code a un moment inopiné ?

On est d'accord que rien n'est simple, mais tu as au moins des outils pour te permettre de jouer finement avec les désallocation pour rester dans une frame de temps spécifique. Ce qui, après une rapide recherche sur les les garbage collectors de java, js et (à moindre mesure ?) python, ne me semble pas être le cas.

Quand la mémoire ne bouge pas et que le GC n'a rien à nettoyer, ça se passe bien.

je vois qu'on en arrive à la même conclusion :)

C'est le soucis, ça simplifie la vie du développeur dans certains cas. Et ça la rend plus pénible dans d'autres.

Avec une gestion manuelle tu peux facilement prendre des mesures pour l'évacuer petit à petit, et choisir ce qui est primordial d'évacuer en fonction du contexte, et avoir une garantie de stabilité dans les performances.

Enfin bon, je sais que je ne t'apprends rien :-)

Mais je suppose qu'il existe une obscure classe java qui permet de choisir quels types d'objets tu peux libérer et pendant combien de temps, exécuté à la demande.. ?

Tu dois être dans une dimension parallèle parce que je remarque que même des boites qui ont du goulot dans l'utilisation de java on eu récemment des soucis avec. Trois jeux en java que j'ai en tête :
Minecraft
Project Zomboid
Star sector