Gof a écrit 2226 commentaires

Personnellement j'ai bien aimé ce film de lui: http://vimeo.com/32146368/
Une mise en abîme assez amusante.

autant ne jamais gérer les problèmes d'allocation et laisser le fichier etre corrompu dans tous les cas ?

Tu m'a mal compris.

Je voulais dire que vu qu'il est toujours possible que ça crash, il faut faire en sorte que les conséquences soient minimes en cas de crash. Merci autosave.

Et que vu que ce n'est pas si grave si ça crash, alors autant laisser crasher dans le cas de OOM.
En effet, gérer proprement toutes les situation de OOM est un travail énorme.

les softs qui n'ont pas d'auto-save

Je préfère des soft qui ont l'auto-save et pas de gestion d'OOM que l'inverse

le soft pourrait planter au milieu de l'auto-save

C'est pourquoi l'enregistrement doit se faire de façon atomique, pour que la sauvegarde précédente soit toujours là.
Pareil pour la configuration.

Et si il y a une coupure de courent, ou que te femme débranche la mauvaise prise pour brancher l'aspirateur alors que tu met la dernière touche ?
Comme on est jamais à l'abri des bugs, il faut toujours gérer les crash proprement. Autosave, et modification atomiques des fichier (enregistrer une copie, et atomiquement remplacer l'original).
Et donc tu ne perds pas plus de quelque minutes de travail.

Désolé, mais c'est pas déjà le cas ?
Qu'est-ce qui se passe d'après toi, quand il n'y a plus de mémoire avec firefox ?

En tous cas, aucun programme utilisant GLib ou GTK+ http://jeffreystedfast.blogspot.be/2008/02/worse-is-better-in-form-of-autosave.html

Peut être pour un serveur ou une application critique. Mais pour un programme avec une interface graphique, ça n'en vaux pas la peine.

Ça demande énormément de travail pour aucun gain.

Ce qu'il faut faire pour voir pourquoi ton programme prends autant de mémoire:

• T'assurer que c'est bien le tas (heap) qui prends la mémoire, et pas un fichier mapper (par exemple, le code des bibliothèques, ou un fichier de polices)

• valgrind --tool=massif, et regarder le résultat avec massif-visualizer

Pour donner un autre exemple sur un serveur ou dans une bibliothèque c'est vraiment pas ce qu'il y a de mieux à faire. Il faut tester et respectivement renvoyer une erreur au client (par ex indiquant de réessayer après un temps d'attente exponentiel en fonction du nombre d'erreurs)

Pas si simple. Il faut aussi s'assurer que tout ce passe comme prévu : de ne pas garder de mutex ver ouillé par erreur, de bien libérer toutes les ressources qui ont été allouée par la fonction. De garder l'état du programme dans un état correcte, sans structure de donnée à moitié initialisées.

En plus l'utilisateur de la bibliothèque devra faire pareil et ajouter du code pour gérer cette erreur.

Et tout ça pour pas grand chose au final. Le plus simple est de terminer le programme immédiatement. Et de bien récupérer en cas de crash.

Les programmes qui ont vraiment besoin de gérer les cas d'OOM sont plutôt rares. Et il vaux mieux ne pas gaspiller de temps et de ressources à le faire.

Ne le fait pas.

Dans un programme utilisateur ça n'a aucun intérêt.

Le mieux que tu puisse faire c'est un truc du style
C
assert(src_dup);

Si tu veux éviter les éventuelles faille de sécurités. Mais pour un 'bête' programme utilisateur du style concky, il n'y a pas grands risque. Tout ce que tu fais c'est perdre des cycles à tester et rajoute du code qui prends de la place en cache.

Gérer les "OOM" (Out Of Memory) est inutile pour deux raison:

1 - C'est impossible de tester tout les cas possible d'échec de realloc. Et du code non testé à de forte chance de ne pas fonctionner

2 - Les systèmes d'exploitation moderne "overcommit" la mémoire. Ça veux dire que même si il n'y a plus de mémoire, réalloc va quand même fonctionner. Et c'est au moment ou cette mémoire va être utilisée que le noyaux va devoir récupérer de la mémoire en tuant un processus (OOM killer) (en utilisant des heuristique, mais pas forcément celui qui demande la mémoire).

Bien sûr il y a des cas ou c'est nécessaire de gérer ça correctement (en embarqué par exemple). Mais pas ici.

C'est le syndrome SDS
(Syndrome du Disque SSD)

Aussi appelé le syndrome PNS (PIN Number Syndrome)
Voir aussi RAS syndrome

C'est triste ton avis sur les running gag

Il n'y a pas vraiment de graphismes : ce sont les pièces d'échecs unicode: ♔♕♖♗♘♙♚♛♜♝♞♟
Il fallait bien que ça serve.

Sinon, il y a aussi le Chessboxing

https://linuxfr.org/users/booga/journaux/burn-berlin-burn

On était deux.

Par contre, cette semaine ça va pas pour moi,

La Npresentation

Oui.

En particulier dans l'embarqué.
(Saviez vous par exemple que la Freebox était implémentée avec Qt ? {url} )

Pour ceux qui n'auraient pas compris: « Est mort » ça veux simplement dire qu'il est bronsonisé.

Celle de l'époque, selon les panthéon on a zoophilie, inceste, tromperie, lucre…

Mais est-ce que ces chose là étaient vraiment considérées comme immorales à l'époque ?

Quand on est en prison, c'est peut-être aussi qu'on a une morale douteuse :)

C'est quoi une morale douteuse ?
Une morale qui n'est pas compatible avec la morale de la moralité des gens ?
Personelement je pense qu'il n'y a pas de morale universelle ou absolue. Ce qui est bien pour certains est peut être mal pour d'autres, et inversément.

C'est pas Melbourne, c'est Brisbane.

En réalité, d'après l'annonce, c'est maximum 125 employés, et non l'ensemble comme le dit la dépêche.

En particulier, les ~50 employés Nokia qui bossaient a Brisbane (les développeurs de QtQuick) ce sont déjà fait officiellement virer
Il faut croire que Digia n'avais pas envie d'avoir des problèmes avec les fuseaux horaires.

Super tu réponds à l'une d'entre elle. Et les autres ?

Une seule suffit pour contredire tes propos (qui disent que QtQuick ne réponds à aucune des problématiques).
Bref, j'ai raison et tu as tort :-)

À toi maintenant de dire en quoi Qt ne réponds pas au problématiques que tu cite comparé a ses concurrents.

Ca ne répond à aucune des problématiques que j'ai cité.

Si. Ça réponds à au moins une des problématiques citées :-)

(Par exemple QtQuick2 utilise mieux le GPU. Et pour les autres, soit Qt y réponds, soit les concurrents n'y répondent pas)

QtQuick/QML c'est quelque chose de neuf qui est sensé répondre aux problématique actuelles.
Oui, ça garde les bases solides de Qt derrière. Au final c'est un nouveau langage et un nouveau paradigme.
Ça remplace toute la partie Widget de Qt en quelque sorte.

Si j'ai bien compris l'interview du CEO de Digia, les contributions de Digia sont minimes parce que Nokia ne voulait pas les intégrer.

Ce n'est pas Nokia qui veux ou ne veux pas intégrer les modifications, ce sont les « reviewer » (composé principalement de dev Nokia, mais pas que)
Et si les contributions ne sont pas acceptés c'est peut être car elle ne sont pas de bonne qualité.

PErsonnellement, je trouve que le dialogue d'enregistrement de fichier de qt est suffisamment meilleure pour qu'on se plaigne quand on enregistre des fichiers dans un logiciel gtk.

Quelle boite de dialogue de Qt ?
Celle par défaut basé sur celle de Windows 95 ? http://qt-project.org/doc/qt-5.0/images/filedialogurls.png

Le truc c'est que Qt s'intègre dans l'environnement dans lequel le programme est lancé. Si on ouvre un programme Qt dans Gnome, on aura la boite de dialogue GTK, si on ouvre dans KDE on aura celle de KDE, sous mac on a celle de mac, …
Celle "builtin" Qt n'est visible que pour les système sans boite de dialogues (embarqué) ou si le développeur customize la boite de dialogue avec des widget additionnels.