G.bleu a écrit 186 commentaires

À ce sujet je te conseils l'article expliquant pourquoi Godot n'utilise pas ECS

tl;dr:

ECS c'est une approche plutôt bas niveau qui est surtout intéressante pour des questions de performances.

De son côté Godot expose une API haut niveau et orientée objet à l'utilisateur, et utilise dans ses systèmes internes (typiquement pour la physique, l'audio et le rendu) une architecture orientée donnée (comme ce que fait ECS) pour être performant.

Cette approche fonctionne bien pour la plupart des cas, sauf pour des types de jeux particulier devant gérer beaucoup de logique de jeu (mais genre beaucoup beaucoup, comme pour un open world ou un gros city builder).

À ce moment ajouter une approche ECS pour la logique de jeu devient justifiée (et dans le cas de Godot on peut écrire cette logique sous forme d'extension native pour un max de perf).

Vu que Zig n'a pas de notion de destructeur, t'es obligé de mettre ton defer (et le unlock) dans le main

Oui tout à fait, mais du coup on se retrouve avec une fonction qui retourne une ressource devant être impérativement nettoyée… mais rien pour garantir que ce sera fait ! (le fameux RTFM quoi ¯\(ツ)/¯ )

C'est le retour du bug classique façon:

int foo() {
  lock_mutex();
  if (a) {
    // fait plein de truc compliqués
    release_mutex();
    return x;
  } else if (b) {
    // encore d'autres trucs compliqués
    release_mutex();
    return y;
  } else if (c) {     // Hop ! une PR ajoute cette nouvelle condition
    // toujours plus de trucs compliqués...
    // ... et on a oublié de release le mutex, c'est vendredi la review est un peu molle, ça part en prod, Ariane 5 explose en vol
    return z;
  }
}

La solution qu'a choisi Zig pour contrer ce problème est un puissant système de vérification à la runtime quand on compile avec le profile de test (et aussi en mode release-safe).
C'est largement mieux que C, mais ça ne vaut pas une vérification exhaustive à la compilation (comme permet le RAII): on ne détectera le problème que si on passe dedans pendant notre phase de test.
Et donc c'est typiquement le code peu utilisé (ou galère à tester) genre gestion de cas d'erreur dans un cas aux limites qui se retrouve à contenir des bugs (comprendre: les bugs les plus horribles à reproduire)

Enfin, autant ce type de checks marche pour vérifier des erreurs d'allocations genre use-after-free, autant il n'est d'aucune utilité pour de la gestion de ressource comme dans mon exemple…

c'est pourquoi je réserverai Zig pour de l'embarqué, de la programmation système ou des librairies qui ont besoin d'être très optimisées

J'ai l'impression que Zig est très séduisant pour les devs C car on garde la philosophie une très forte compatibilité avec le C (Zig se vent comme étant capable de s'intégrer dans un projet C existant) tout en fournissant un langage avec tooling et écosystème au bas mot 20ans en avance par rapport au C99… Ho wait !

Mais là tu parles de garbage collector (dont une des implémentation est le compteur de références qui est mis en oeuvre dans les smartpointers C++)

Le garbage collector est utilisé uniquement pour les allocations dynamiques (si une allocation a lieu sur la stack, on sait que sa durée de vie est liée à l'appel de fonction l'ayant créé, donc pas besoin de check à la runtime pour savoir quand la libérer).

Le RAII est un concept orthogonal au garbage collector: si ton smartpointer est capable de décrémenter le compteur de référence et de faire la libération de mémoire quand celui-ci arrive à zéro, c'est bien que du code a été appelé automatiquement quand la variable contenant le smarpointer a été détruite. Et cela quelque soit l'endroit où se trouve la variable ne question (stack, dans une structure elle-même sur le tas etc.).
De plus le RAII peut servir a gérer autre chose que de la mémoire: fichier/socket ouvert, mutex etc.

(et Go n'utilise pas de compteur de référence pour son garbage collector, mais du mark and sweep)

J'en rajoute une couche avec ce post de l'auteur de Zig

RAII works fine in Zig

Il semble considérer que le defer fait office de RAII. Mais c'est oublier que le defer s'exécute quand on quitte la fonction dans laquelle il a été déclaré. Du coup on ne peut pas retourner des objets avec destructeur.

Par exemple:

const std = @import("std"); 

const LockGuard = struct {
    mutex: *std.Thread.Mutex,

    fn take(mutex: *std.Thread.Mutex) !LockGuard {
        std.debug.print("Lock!\n", .{});
        mutex.lock();
        return .{
            .mutex = mutex,
        };
    }

    fn release(lg: *LockGuard) void {
        std.debug.print("Unlock!\n", .{});
        lg.mutex.unlock();
    }
};

var m: std.Thread.Mutex = .{};
fn take_lock() !LockGuard {
    var lk = try LockGuard.take(&m);
    defer lk.release();

    return lk;
}

pub fn main() !void {
    std.debug.print("taking lock!\n", .{});
    var guard = try take_lock();
    std.debug.print("lock taken {}!\n", .{guard});
}

va retourner (vous pouvez aller sur https://zig-play.dev/ pour jouer avec):

taking lock!
Lock!
Unlock!
lock taken [...] !


alors qu'un langage supportant le RAII n'aurait libéré le lock que quand guard n'est effectivement plus référencé, c'est à dire à la fin de la fonction main !

Et puisque maintenant c'est Vendredi, je vous laisse avec la justification pour fermer l'issue pour faire du vrai RAII en Zig ;-)

Le RAII, c'est surtout de la performance processeur en moins […] c'est aussi une consommation mémoire non maîtrisé

Je pense que tu confonds RAII et garbage collector ;-)

RAII n'a strictement aucun impacte au runtime: c'est le compilo qui détermine où une variable n'est plus utilisée et met à cet endroit le code d'appel du destructeur.

Si tu ne fais pas de RAII tu devras mettre à la main l'appel au destructeur au même endroit (dans tous les cas faut bien faire un close sur le file descriptor ou un free sur le buffer !).

(et les smartpointers de C++ sont implémentés grâce au RAII)

Cette histoire de inline for m'a aussi encouragé à creuser, et il semblerait que le compilo fait parfois des choses inattendues.

Par exemple en Rust, il ne faut pas utiliser la variable d'incrément dans une boucle for.

En plus il faut prendre en compte le fait que chaque version du compilo peut changer l'heuristique, donc un code qui faisait du loop unrolling peut ne plus le faire.

J'imagine que c'est encore pire pour le C où il y a plein de compilos différents avec chacun leur heuristique pour faire le loop unfolding…

Bref ça semble légitime d'avoir un inline for pour s'assurer que le comportement est bien celui attendu, typiquement si on est sur une plateforme embarquée ou la place/puissance est comptée.

Merci beaucoup pour cette dépêche très sympa ;-)

Je trouve globalement Zig très rafraîchissant et bourré de bonnes idées.

Typiquement l'intégration d'un compilo C capable de cross-compilation dans quelques dizaines de Mo. Ça donne même des idées pour les logiciels ayant besoin d'embarquer un compilo pour faire du JIT.

Bref j'en arrive à ma question: mais pourquoi donc des gens aussi compétents refusent de mettre du RAII (c'est à dire des fonctions destructeur appelées automatiquement quand un objet se fait free ou bien est enlevé de la stack) ?

De ce que je comprends l'argument avancé c'est:
1 - c'est pour qu'il n'y ait rien de caché
2 - c'est plus lisible car c'est explicite

Pour le premier point on peut objecter que nos CPU modernes ne se privent pas pour faire toute sorte de magie noire avec notre code (out-of-order, processeur super-scalaires).
L'OS de sont côté décide arbitrairement du scheduling des threads, déclenches des interruptions quand ça lui chante et fait semblant d’allouer de la mémoire quand on fait un malloc pour finalement tuer notre process sur un out-of-memory quand il a été trop optimiste…
Bref des choses cachées quand on un impact sur notre programme c'est pas ça qui manque dans un ordinateur moderne !

Le second point me semble encore plus incompréhensible: on se retrouve avec un pattern consistant à systématiquement devoir écrire var foo = init(); defer foo.destroy();.
- Si on oublie le defer on a fait un bug
- Donc faut faire gaffe à ça en code review
- Et faut des outils pour détecter ce type d'erreurs
- Et ça peut être plein de classes de bug: memory leak, resource leak (e.g. on ne ferme pas un fichier), deadlock (e.g. la ressource représente la prise de mutex)

En règle générale avoir un langage qui permet d'exprimer des structures ne pouvant pas représenter un état invalide est un gain énorme (exemple typique: en Rust un mutex contient l'objet qu'il protège, de fait il est impossible d'accéder à ce dernier sans avoir pris le mutex).

Et si on veut pinailler, defer est déjà quelque de magique vu qu'on n'est pas explicite sur l'endroit où sera fait l'appel de fonction (j'imagine que personne n'est assez fou pour défendre l'utilisation de free sans defer ni RAII comme en C ^).
De fait plutôt qu'un defer, j'aurai plutôt vu un mot clé permettant d'indiquer qu'une fonction retournait un object avec destructor.
Quitte à devoir explicitement fournir le destructeur dans la fonction d'initialisation si on veut rester plus explicite, par exemple:

var foo = raii foo_factory() -> foo_destructor; // pseudo syntax,
On peut même obliger les variables raii à avoir un nom particulier (genre avec un symbole en préfixe) étant donné que la variable peut survivre à la fonction l'ayant créée (typiquement en la retournant à l'appelant), ce qui était moins utile pour le defer car il s'exécute uniquement dans la fonction d'où il est déclaré.

Bref, de ma fenêtre le RAII apporte des avantages monstrueux comparés à ses "inconvénients" théorique (et ça semble plutôt simple de faire un defer sous stéroïde qui garde le meilleurs des deux mondes). Et du coup je n'arrive à comprendre le raisonnement des devs de Zig (qui, je le rappelle sont des mecs sacrément brillants !)

Dernier point: on n'est pas vendredi, ce post n'est pas un troll (ni un flim sur le cyclimse). Il est bien possible que j'ai fait un homme de paille sans le vouloir avec les arguments pour l'absence de RAII, si c'est le cas merci de me corriger dans la joie et la bonne humeur ;-)

tl;dr: 1) Le PAAS c'est la vie 2) Scalingo c'est très cool

Ma boite utilise Scalingo depuis 2 ans, jamais eu de soucis et comme tu dis leur support client est super (il y a un chat intégré et c'est souvent Yann le CEO qui vient répondre !).

Par rapport à Heroku y'a moins d'extensions disponibles forcément, mais les indispensables sont là (PosttgreSQL/MySQL/Mongo/Redis etc.). Perso je trouve qu'il ne manque que une extension de gestion des logs pour faire des recherches facilement dedans (en l'état on a accès aux logs en directe dans la page web de son projet, et sinon il faut utiliser la cli ou bien télécharger les archives à la main)

A force de DIY, un peu peur de déléguer… Qu'en est-il ? Ca marche ? C'est fiable ? Ca soulage ? Ca soigne la déprime du vieil admin ? Ca rassure le décideur ?

De mon point de vu le développement et l’administration système sont deux métiers totalement différent. Du coup soit on a une équipe dédié à chaque métier, soit le travail sera mal fait.
À partir de là la question est : est-ce que tu as le budget pour avoir ta propre équipe admin sys en interne ? Perso je suis très content de déléguer ça à Scalingo/Heroku ;-)

Sous Windows, le nouveau certificat racine ISRG Root X1 (celui qui remplace DST Root CA X3) est ajouté à la liste des certificats de l'OS de manière lazy la première fois qu'il est utilisé.

Le soucis c'est que seul l'implémentation de TLS fourni par l'api Windows (cad CertVerifyCertificateChainPolicy ) déclenche cette récupération !

Concrètement ça veut dire que si tu utilises uniquement Firefox (qui embarque ses propres certificats racine et n'utilise pas l'api windows pour faire du TLS), et bien il y a toutes les chances que ton PC n'ait pas ISRG Root X1.
Et du coup quand tu utilises OpenSSL avec les certificats du système (c'est ce que fait Python par default) tu te retrouves avec une belle erreur SSL ! (Python récupèrant les certificats auprès du système avant de les charger dans OpenSSL)

Le plus beau étant que pour résoudre ça il suffit d'ailleurs sur n'importe quel site utilisant Let's Encrypt depuis Edge/IE/Chrome (ce qui va déclencher la récupération de ISRG Root X1).

plus d'info:
https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550
https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/
https://github.com/psf/requests/issues/2966#issuecomment-636750327

Et comme vous êtes gourmand, petit bonus:
Tous les certificats fournis par Let's Encrypt son signés par le certificat intermédiaire S3 qui est disponible signé par DST Root CA X3 et ISRG Root X1.
Si il se trouve que par hasard vous avez le certificat intermédiaire S3 signé par DST Root CA X3 sur votre machine, alors c'est celui-ci qui sera utilisé (d'ailleurs si vous avez une idée pourquoi je suis preneur ⁾ et provoquera une erreur:

$ python -c "from urllib.request import urlopen; print(urlopen('https://linuxfr.org').status)"
Traceback (most recent call last):
[...]
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1131)>

La solution ? Faire comme Firefox et embarquer ses propres certificats racines dans son application (mais du coup 1) incompatible avec ces "passerelles de sécurité" à moins de permettre un mécanisme de chargement de certifs additionnels et 2) obligé de mettre à jour l'application quand les certificats changent :'( )

Ben voyons. Je voit pas trop ce que ca a voir avec la choucroute.

On parle de l'expérience de développement sur une plateforme donnée, ça va de l'écriture du code à la distribution à l'utilisateur en passant par une myriade de détailles comme les tests ou même la compatibilité avec les autres plateformes (parce que tu commences rarement ton application de zéro).

Concrètement avec un PC sous linux je peux développer pour toutes les plateformes (Windows compris) SAUF pour iOS et macOS. Et avec un PC sous Windows c'est même histoire (et bien souvent même pas besoin de VM \o/).

Et je peut te la renvoyer a la figure "l'obligation de developer pour android sur Android Studio" (parce que oui, eviter android studio, c'est aussi pratique que d'éviter Xcode: c'est techniquement possible, mais c'est pas franchement réaliste).

Bah du coup c'est pas une obligation puisque t'es pas obligé.

Par exemple si tu as une application Python utilisant le framework Kivy tu peux build pour Android depuis la command line.

Ou sinon on peut citer toutes les applications mobiles qui sont un packaging d'une application web, là encore ton framework de packaging te crée un template de projet Graddle et tu le lances depuis la command line.

Un Mac mini a 500 dol et ca roule. Ca me parait pas plus prohibitif que ca. Et c'est le genre de machines qui se trouvent très facilement en récup a bien moins que 500 dols (voir gratuit).

"Un PC d'occasion à 500 dol et ça roule. Pourquoi tu héberges ton site web sur Heroku ?"

Le top 500 des applis du store fait des mises a jour en gros tous les 7 a 15 jours depuis des annees, et ne se fait pas rejeter.

Le truc, c'est que oui, ya des histoires assez vilaines d'updates rejetées, c'est clairement pas agréable cote developeur quand tu te fait broyer par la machine Apple. Ca reste extrêmement rares,

On est concrètement sur un déséquilibre entre le développeur d'application et le géant monopolistique contrôlant l'entièreté de la chaine (:surprised_pikachu:).
Remplace développeur d'application par créateur de contenu et Apple par Youtube et les problèmes sont strictement les mêmes: si t'es un gros ça marche pas trop mal, pour tous les autres tu dois te plier à des caprices abscons qui peuvent réduire à néant tes investissements sans raisons valables ni réel possibilité de correction.

Tu vois, c'est ce genre de pics qui te fait passer pour un guignol

T'as pas pu t'empecher d'en rajouter une tonne, et maintenant tu passes pour un mec qui sait pas de quoi il parle, ou un menteur, au choix.

Donc, oui, comme je disait plus haut, tu passes pour un guignol.

Insulter les gens ça te fais surtout passer pour une personne grossière avec qui on ne peut pas échanger, tu dois être charmant avec tes collègues.

un autre truc qui aide pas non plus est que les outils de dev et frameworks pour android sont honnêtement plutôt mauvais, et rendent les choses plus difficiles.

Obligation de développer pour iOS sur macOS, et interdiction d'avoir une machine virtuelle macOS ou un dual boot sur autre chose que du hardware Apple.

Il y a quelques années avoir macOS sur sa CI impliquait d'utiliser un service dédié avec des tarifs prohibitifs (heureusement Github action et Azure pipelines sont passés par là depuis, mais même comme ça les machines Apple sur la CI sont en nombre limité et ralentissent les builds).

Et la fameuse validation de l'app store au dernier niveau de l'arbitraire (on ne compte plus les cas de devs ayant fait une anodine mise à jour bugfix et s'étant vu refuser car la mise à jour ne respect pas les conditions de la plateforme, sans pour autant avoir le détail de ce qui leur est reproché… exemple typique: https://twitter.com/flicktype/status/1427292830523744257)

Vraiment niveau rendre les choses plus difficiles, ils sont très très fort chez Apple ;-)

Si j'en crois cette PR, on a le nom du professeur. De là on obtient très rapidement son adresse mail et son compte Twitter.

À partir de ça perso j'enverrai un mail/tweet à chaque fois qu'une PR abscons est ouverte, si la personne est de bonne fois elle devra bien se rendre à l'évidence que tu subis du harcèlement de la part de ses élèves. Si elle n'est pas de bonne fois, elle te bloquera et là il te reste à faire de même à un responsable de son département (ça se trouve bien sur le site).

Et perso je suis extrêmement curieux de savoir quel exercice a été donnée aux élèves pour en arrivé à un tel résultat, ça vaudrait de poser des questions à ce sujet sur les PRs (si elles ont été réalisées par des comptes d'élèves et non par des comptes de bots ça peut marcher ^).

Je parierai sur un exercice consistant à automatiser la création d'une PR:
- ça semble en rapport avec son centre d'intérêt de recherche "mining software repositories for open innovation in two-sided markets."
- la seule activité récente de son github était en rapport avec python et le covid et elle est sans doute francophone (elle était prof y Montréal). Du coup c'est possible qu'elle soit tombé sur ton repo par hasard et l'ai utilisé comme exemple de ce qu'elle attendait de ses élève, et beaucoup l'ont pris au pied de la lettre…

C'est la 3è plus grosse consommation d'électricité et plus gros producteur de CO2 depuis 1876

J'imagine que les deux premiers c'est les réseaux Bitcoin et Ethereum ;-p

Plus sérieusement, ton exemple est très bon pour illustrer le gain en lisibilité qu'apporte constexpr sur un cas concret.
Personnellement, l'utilisation de templates récursifs m'ont toujours paru à la limite de l'exploit et de l'exploit ;-)

https://www.youtube.com/watch?v=jpSU2Hff0Jc

L'intérêt provient justement des limitations de l'outil et de son côté tout en un ;-)

À mon avis c'est beaucoup plus gratifiant pour un enfant de pouvoir avoir un résultat le plus rapidement possible et à ce niveau pico8 est imbattable (typiquement avec des outils plus spécialisés comme ceux dont tu parles on va vite s'éparpiller, rien qu'en devant connecter les différents outils entre eux ou bien en pêchant par ambition)

Évidemment si l'enfant est motivé on peut par la suite très vite évoluer vers des choses plus complexe, genre au hasard Godot ^{^}

Je m’apprêtais à conseiller Godot (pour le côté super léger + facile à prendre en main + langage de script simple), mais en fait il est probablement trop puissant si tes neveux sont des débutants total.

À l'inverse Pico8 (https://www.lexaloffle.com/pico-8.php) est volontairement super limité tout en fournissant des éditeurs (sprites, map, et même musique ce qui est super cool car c'est bien souvent le parent pauvre quand on dev des jeux en amateur ⁾ intégrés ce qui permet de se focaliser sur les fondamentaux.
En plus tout le code tient dans un fichier de quelques ko donc même pas besoin de se prendre là tête avec git.
Et la cerise sur le gâteau c'est la possibilité de publier son jeu en un clique sur le site de pico8 ce qui permet à n'importe qui de pouvoir y jouer depuis son navigateur ;-)

Merci pour ces explication, et j'en profite pour te féliciter pour ton article qui a été un vrai plaisir à lire ;-)

De ce que j'ai compris, une fois cette attaque réussie on se retrouve avec une clé publique B apparaissant comme appartenant a Alice et certifiée par Charlie.

Par contre la clé B en question a été créée de façon spécifique à l'attaque (notamment le fait de devoir contenir un fichier JPEG valide ainsi que le user id de alice à sa fin).
Du coup on ne dispose pas de la partie privée de cette clé, et la retrouver revient à essayer de retrouver la vrai clé privée de Alice à partir de sa clé publique…

Bref je ne vois pas l'utilité pratique de cette attaque (mais c'est malgré tout du très beau travail hein ! ^), j'ai raté un truc ?

Tu as essayé de configurer le système de rendu pour utiliser OpenGL 2.1 ? (par défaut il est en OpenGL3 qui est prévu pour les machines plus haut de gamme, cf. https://docs.godotengine.org/en/3.2/tutorials/misc/gles2_gles3_differences.html)

Parce qu'utiliser un langage peu performant qui consomme des cycles CPU (donc de l'energie) pour rien, c'est pas très écolo.

À mon avis c'est surtout consommer des cycles CPU pour des applications qui servent à pas grand chose qui n'est pas très écolo ;-)

Sauf bibliothèque qui ferait exactement ce que tu veux en Python pour ton domaine précis, je ne vois aucun avantage compétitif à ce dernier en général.

Par rapport à du Go, Python propose une REPL (un shell interactif quoi) qui amène beaucoup de convivialité:
- Dès que tu as un doute sur une construction tu peux tester, ça rend plus aventureux ;-)
- Tu peux interagir avec une lib dont tu ne connais pas/mal l'api plutôt que d'avoir uniquement la doc. C'est incroyablement pratique quand on tâtonne pour faire un truc en particulier.
- Pareil pour le débug dans lequel tu as vraiment une puissance d'introspection énorme qui aide à comprendre ce qui se passe (voir à modifier/monkeypatch tout à la volée pour vérifier que ton intuition est la bonne)
- Pour une application interagissant avec une base de donnée, tu as quasiment gratuitement un shell avec une couche métier (en exposant les classes de ton ORM) qui te permet de manipuler les données facilement

J'adore les choix, en factorisant on se retrouve avec:

Are you Hispanic or Latino ?
- yes
- no
- I don't wish to answer

Probablement un problème de clavier qui se blo

Merci pour le journal et le projet, ça fait très plaisir de voir une approche audacieuse à un problème ancien ;-)

Dans mes souvenir un pauvre hello world en C++ se retrouve tout de suite avec des tonnes d'includes en cascade, dont beaucoup ne sont des bibliothèques standards fournies par le compilo (donc ne devant jamais changer en théorie…).
De plus ce travail est réalisé pour chaque fichier.

(Le comité C++ est d'ailleurs en train de travailler sur une feature de module pour justement résoudre ces soucis, il avait été annoncé un gain de 20% sur le temps de compile grâce à ça)

Du coup en te basant sur les appels systèmes pour déterminer les dépendances (et sans faire d'optimisations propre au langage pour rester agnostique) j'aurai tendance à croire à un gros overhead (aussi bien en temps qu'en taille de logs dans tes fichiers .smk.*).

Tu as des chiffres là dessus ? J'imagine que tu n'as pas pu résister à l'envie de compiler smk avec smk ;-)

Google ne va pas te défoncer la gueule au tonfa et te garder 24H parce que t'as remplacé ton Android par un Nokia 3310.

L'état non plus tu sais…