A propos des des"commentaires" nostub - Page 4

Kevin Kofler
:

Flanker
: 16o de signature

Plus la signature est longue, moins il y a de risques de faux positifs (programme qui commencent par cette signature par hasard).

tu crois franchement que 16o c'est pas trop ? y a combien de faux positif pour les prog kernel (alors que la signature est sur 4o)

numéro de révisions sur un longword

C'est pour une plus grande évolutivité. Je n'ai pas envie d'être obligé de remplacer complètement le standard parce qu'on a dépassé le nombre maximum de révisions prévues. Le standard de base ne changera plus, il peut juste y avoir ajout de nouveaux champs. Donc le versionnement doit être préparé pour une longue vie.

franchement, je veux pas te vexer, mais je crois pas qu'il y aura 4294967296 versions différentes de ce standard. A raison d'une par seconde, ça sera atteint dans 136 ans Déjà 255, ça me paraît bcp

Flanker
: mais par contre, ça risque d'être désagréable si on veut faire une fonction qui extrait de façon définitive un ppg (pour remettre les commentaires à leur place)

Tu ne remets pas les commentaires à leur place, ils seront de toute façon dans le programme décompressé aussi. (Copier les commentaires en compressant est implémentable, les virer du programme original, pas vraiment.)

chouette encore un gain de place avec un peu de chance, ça compensera le gain gané par la compression

Godzil :
Ce que je trouve restricitf ? -> 'l'authorité" qui en est en charge

Donc c'est bien par pur esprit de contradiction.

en même temps, je le comprends, vu que tu es incapable de reconnaître qu'il faut faire évoluer un standard. Un standard permet pas de faire un truc ? Bah on fait pas alors, hors de question de changer le standard

Godzil :
Heu franchement obliger le programmeur a avoir une feature dont il veux pas je deteste ce genre de politique

On ne t'oblige à rien, la touche "Suppr", ça existe.

ouééééé "M$" se fait condamner par l'UE pour avoir fait la même chose, je te signale

Vertyos
:

parce que ce serait idiot qu'un shell doive en gérer plusieurs

Mais non... Un shell peut gérer le standard si il le veut, si son auteur a envie de faire quelque chose qui soit totalement incompatible, il risque de ne pas avoir d'utilisateurs du tout et alors, tant qu'il fait ce qui lui plait, où est le problème ?

Que l'utilisateur se retrouve avec un programme pour lequel son shell n'affiche pas le commentaire, l'icône, ... pour la seule et unique raison que monsieur le programmeur de ce programme a refusé de respecter le standard existant et inventé son propre format que personne n'implémente.

bah de toute façon, vu l'utilisation qu'il y a de ce standard, on peut pas vraiment par ler de standard

Bah oui, pratiquement tous les programmes ne sont pas du tout incompatibles avec un anti-plantage (la preuve: TICTEX, PreOs Browser etc. peuvent les lancer sans problèmes), pour ceux qui le sont, mes TSRs et ceux de Samuel Stearley ont déjà été mis à jour pour inclure les flags d'incompatibilité, et pour les autres (qui ne doivent pas être beaucoup), je ferai un patcheur (mkcompat à la M$) pour permettre de rajouter un header de commentaires contenant les flags d'incompatibilité demandés et éditer la table de relogements en conséquence. (Rajouter des commentaires dans un binaire est moins dur que les supprimer parce qu'en rajoutant, on peut mettre les données où on veut, ils ne seront pas en plein milieu du fichier.)

comme d'hab, ça fait profondément chier l'utilisateur de devoir changer UN programme, par contre, le forcer à télécharger un programme pour patcher tous ses programmes, c'est

Godzil
:

Godzil> J'aimerais bien que tu dises en quoi tu trouves le standard actuel trop restrictif, et que tu indiques quelle a ta source d'inspiration pour ta super idée révolutionnaire, loin des jouets actuels...

J'aimerai aussi savoir ce que tu trouve trop restrictif dans le format actuel qui me semble assez efficace et évolutif pour le moment(pas forcement de nous dire ce que tu prévois).

Deja, combien de fois il faudra que je repete que mon projet n'a RIEN a voir avec ce truc

Alors pourquoi tu en as parlé ?

Ce que je trouve restricitf ?
-> 'l'authorité" qui en est en charge -> ce qui induit qu'on peut pas en faire ce qu'on veux

Faux, Kevin a répondu.
Et tu voudrais mettre quoi par exemple ?

-> fait que pour mettre des petites choses

Heu pourquoi ?

-> pas pratique a utiliser dans le programme en lui meme

Faux, Kevin a répondu également.

et le but de ce topic n'est PAS de parler de mon projet (dont j'avais deja un peu parlé il ya longtemps)

Et pourquoi tu ne veux pas en parler ?

Bon Godzil, j'ai l'impression que tu t'enfonces un peu plus à chaque post. Mon but n'est pas de te faire comprendre que tu as tort ou que tu n'es qu'un abruti, mais je commence à en avoir assez de te voir prendre les choses toujours de haut sans raison pertinente.
J'aimerais bien que tu arrêtes d'esquiver mes question et que tu me répondes, il n'y a que comme ça que la discussion avancera.
Parc que là, tu me fais vraiment penser à geogeo...

Pollux
:Mouais enfin même en se restreignant à des numéros "parlants", 256 versions x 256 révisions devraient largement suffire...

Pas sûr...

Pourquoi ne pas juste extraire les commentaires du ppg, s'ils sont au début du fichier ? Parce que sinon c'est pas le fait que ça prenne 2x plus de place qui va arranger les choses ^^

Parce que:
1. ça change tous les offsets, il faudrait recalculer la table des relogements, voire les tables de relogements si on utilise les tables personnalisées permises par TIGCC,
2. les commentaires peuvent être n'importe où dans le fichier, le header ne contient que des pointeurs,3. les commentaires peuvent aussi être en même temps des données (c'est le cas pour certains TSRs de Samuel Stearley ou de moi).

Pkoi ne pas les mettre dans des sections de startup ?

Parce que l'utilisateur peut les mettre où il veut, ça fonctionne avec presque les mêmes mécanismes du linker que les exports kernel. La différence se trouve dans ce qui est exporté uniquement (des métadonnées dans le premier cas, des fonctions ou données dans le deuxième, même si le standard _nostub est suffisamment puissant pour qu'on puisse exporter tout et n'importe quoi, même des fonctions, en utilisant les codes réservés à l'application, il faut juste me demander de réserver une plage de codes pour éviter les conflits). Les programmes en assembleur utiliseront forcément la méthode bas-niveau (Samuel Stearley définit même le header lui-même, moi, j'utilise les _nostub_data__0000 du linker; et comme déjà dit, on réutilise les chaînes de caractères si elles sont déjà dans le programme), et le système de compression automatique doit être compatible avec l'assembleur aussi.

Bah non, je fais pas ça en bas niveau comme vous, j'utilise les méthodes de haut-niveau pour le faire (COMMENT_BW_ICON, etc...)

Et tu définis COMMENT_BW_ICON comment? Tu utilises un symbole interne à GTC?

Flanker
:tu crois franchement que 16o c'est pas trop ? y a combien de faux positif pour les prog kernel (alors que la signature est sur 4o)

4 octets donnent toujours une probabilité assez grande de faux positifs, c'est une ou deux instructions, ou 4 caractères d'une chaîne de caractères, ou une ligne d'un sprite 32×32. A priori, on ne sait même pas s'il y a du code ou des données à cet endroit.

franchement, je veux pas te vexer, mais je crois pas qu'il y aura 4294967296 versions différentes de ce standard. A raison d'une par seconde, ça sera atteint dans 136 ans Déjà 255, ça me paraît bcp

255, c'est peu! On aurait peut-être pu s'en sortir avec 65536, mais c'est trop tard, le format est fixé! C'est tout l'intérêt d'avoir un standard avec des numéros de version et tout: le format ne change plus! Et le longword a été choisi parce que c'est le même format utilisé aussi pour les numéros de version des programmes dans le même standard, pour la consistence. Et pour les numéros de version des programmes, on a utilisé un longword pour pouvoir coder des numéros de version comme 0.94 Beta 18 r1 de manière lisible (0.94.18.1 - comme dit dans le standard, il est conseillé d'afficher les numéros de version numériques comme des adresses IP).

chouette encore un gain de place avec un peu de chance, ça compensera le gain gané par la compression

En échange, la taille du lanceur a été réduite de 546 octets, et il y a encore des optimisations en cours.

en même temps, je le comprends, vu que tu es incapable de reconnaître qu'il faut faire évoluer un standard. Un standard permet pas de faire un truc ? Bah on fait pas alors, hors de question de changer le standard

Le standard de commentaires _nostub a été conçu pour être évolutif.

Godzil :
Heu franchement obliger le programmeur a avoir une feature dont il veux pas je deteste ce genre de politique

On ne t'oblige à rien, la touche "Suppr", ça existe.

ouééééé "M$" se fait condamner par l'UE pour avoir fait la même chose, je te signale

Parce qu'ils sont un monopole. Les distributions Linux le font aussi et n'ont pas eu de problèmes. Et puis ce qu'on fait, nous, n'est pas tout à fait la même chose.

comme d'hab, ça fait profondément chier l'utilisateur de devoir changer UN programme, par contre, le forcer à télécharger un programme pour patcher tous ses programmes, c'est

1. Personne ne t'obligera à utiliser un kernel intégrant cet anticrash.
2. Tu n'as qu'à corriger tes TSRs, ça fera des programmes à patcher en moins. Les miens et ceux de Samuel Stearley sont déjà corrigés depuis longtemps.

Sinon, je suis assez d'accord avec le ./92 de Sasume, sauf pour la dernière phrase. Phrase qui n'a vraiment pas sa place dans ce topic, d'ailleurs.

Flanker> tes remarque sont plus ou moins justifiés mais la réponse c'est que maintenant que le format à été fixé, c'est un peu tard pour le changer.
Créer une incompatibilité pour gagner 10 octets pour des programmes qui dépassent de plus en plus souvent le Ko, c'est trop cher payé.

[cite]tu crois franchement que 16o c'est pas trop ? y a combien de faux positif pour les prog kernel (alors que la signature est sur 4o)
...
franchement, je veux pas te vexer, mais je crois pas qu'il y aura 4294967296 versions différentes de ce standard. A raison d'une par seconde, ça sera atteint dans 136 ans Déjà 255, ça me paraît bcp


chouette encore un gain de place avec un peu de chance, ça compensera le gain gané par la compression

en même temps, je le comprends, vu que tu es incapable de reconnaître qu'il faut faire évoluer un standard. Un standard permet pas de faire un truc ? Bah on fait pas alors, hors de question de changer le standard

Heu y'a 2 extrémistes la. un standard on peut le changer mais il faut avoir une raison suffisante et en essayant d'éviter au mieux les problèmes d'incompatibilité(un peu comme le passage du HTML au XHTML justement)

Et puis pour ce standard kevin n'est pas le seul a le gérer officiellement, il n'est pas sencé en être responsable officiel il me semble(à vérifier mais je crois que c'est à la TICT et Thibault seulement)
[cite]

Kevin:

On ne t'oblige à rien, la touche "Suppr", ça existe.

ouééééé "M$" se fait condamner par l'UE pour avoir fait la même chose, je te signale.

Certes c'est pas totalement faux.
Ceci dit l'UE c'était pour concurrence déloyale, or là il n'y a aucune concurence.

Flanker> tes remarque sont plus ou moins justifiés mais la réponse c'est que maintenant que le format à été fixé, c'est un peu tard pour le changer.
Créer une incompatibilité pour gagner 10 octets pour des programmes qui dépassent de plus en plus souvent le Ko, c'est trop cher payé.

oui, je sais bien

4 octets donnent toujours une probabilité assez grande de faux positifs, c'est une ou deux instructions, ou 4 caractères d'une chaîne de caractères, ou une ligne d'un sprite 32×32. A priori, on ne sait même pas s'il y a du code ou des données à cet endroit.

4 octets, c'est aussi 32 bits, c'est aussi un longword, c'est aussi la longueur d'un mot de 4 lettres, ...
je réitère ma question : y a eu combien de faux positifs pour la signature kernel ? pis en tête des programmes, c'est quand même plus souvent du code, surtout que la signature, c'est aussi move.l (a7),(a7) (ou un truc du genre, spa important) qui est forcément du code

255, c'est peu!

y a eu combien de révisions en un an ? 0. je vois pas pourquoi y en aurait tout d'un coup 10 par ans pendant 15 ans :/

En échange, la taille du lanceur a été réduite de 546 octets, et il y a encore des optimisations en cours.

c'est pas une raison pour bloater les programmes :/

2. Tu n'as qu'à corriger tes TSRs, ça fera des programmes à patcher en moins. Les miens et ceux de Samuel Stearley sont déjà corrigés depuis longtemps.

nan, le standard n'est pas pour les progs kernels ça aurait été avec plaisir, mais là c'est pas possible

Kevin Kofler
:

Pollux
: Mouais enfin même en se restreignant à des numéros "parlants", 256 versions x 256 révisions devraient largement suffire...

Pas sûr...

Oh, tiens, comme c'est étrange, tu as "oublié" de citer la phrase juste après (et d'y répondre)
Tiens, je te la remets au cas où tu voudrais te rattraper :

Rappelle-moi, y en a eu combien pour l'instant ?

Et tu définis COMMENT_BW_ICON comment? Tu utilises un symbole interne à GTC?

Oui ^^ (mais l'implémentation n'est pas terminée, vu le nb de progs qui utilisent ça c pas très haut sur ma todo list...)

Sasume:
Parc que là, tu me fais vraiment penser à geogeo...

Développe et explique moi ça par message privé, merci! (Franchement ce genre de reflexion ça me casse le ***).

1. De toute façon, pour les programmes kernel, tu as déjà les solutions de PpHd (HdKeep, RegisterHandler), donc tu dois déjà t'occuper du problème de l'anticrash, l'amélioration de l'anticrash _nostub que je propose ne te concerne pas (en tant que programmeur).
2. Dois-je en conclure que tous tes TSRs (même ceux qui étaient en _nostub) sont kernel maintenant? J'appelle ça une régression, moi...
3. C'est nul, les TSRs en kernel. Pourquoi? Ben, c'est simple:

I. Badly-designed RAM_CALLs - avoid these at all costs!
-------------------------------------------------------

The following RAM_CALLs are really badly designed. They don't quite serve their intended purpose,
so it is very unwise to use them. Don't.

+----------------+---------------------------------------------------+---------------------------+
| Name           | Badly designed because                            | Use instead               |
+----------------+---------------------------------------------------+---------------------------+
| RegisterVector | Kernel mode is not a good choice for TSRs. If you | _nostub mode              |
|                | use any "function RAM_CALLs" in your kernel-based |                           |
|                | TSRs, they will unavoidably either crash or get   |                           |
|                | forcefully uninstalled (leaking memory) when the  |                           |
|                | kernel gets uninstalled. This also affects the    |                           |
|                | conditional lib RAM_CALLs, so you can't use any   |                           |
|                | libraries. So why are you using kernel mode in    |                           |
|                | the first place?                                  |                           |
+----------------+---------------------------------------------------+---------------------------+

Cf. http://members.chello.at/gerhard.kofler/kevin/ti89prog/ramcalls.txt pour le document complet.

Pollux
:

Rappelle-moi, y en a eu combien pour l'instant ?

Ce n'est pas exclusivement de ma faute qu'il y en a eu si peu, le problème est que quand je demande du feedback (par exemple, on me demande de changer quelque chose, je le fais, je demande si c'est bon), ben le feedback n'arrive pas... Et je finis par oublier, à force d'attendre le feedback que j'ai demandé...

3. C'est nul, les TSRs en kernel. Pourquoi? Ben, c'est simple:

dis, tu n'espères quand même pas m'apprendre des trucs sur les tsr en kernel ? je pense que je connais mieux que toi ce sujet

./98>
Tu nous feras tjs autant rire Kevin
Et c'est quoi cette histoire de leak avec les RAM_CALLs ?

Sinon, trouvé dans ton document :

+-------------------------------------+--------------------------------------------------+
| Name(s)                             | Use the following ROM_CALLs instead              |
+-------------------------------------+--------------------------------------------------+
| font_medium, font_small, font_large | DrawStr, DrawChar, DrawClipChar, DrawStrWidth    |
+-------------------------------------+--------------------------------------------------+

Flanker
:

3. C'est nul, les TSRs en kernel. Pourquoi? Ben, c'est simple:

dis, tu n'espères quand même pas m'apprendre des trucs sur les tsr en kernel ? je pense que je connais mieux que toi ce sujet

Et le problème que j'ai décrit, tu y as pensé? Tu t'en fous que tes programmes plantent?

Kevin Kofler
:

Pollux
:

Rappelle-moi, y en a eu combien pour l'instant ?

Ce n'est pas exclusivement de ma faute qu'il y en a eu si peu, le problème est que quand je demande du feedback (par exemple, on me demande de changer quelque chose, je le fais, je demande si c'est bon), ben le feedback n'arrive pas... Et je finis par oublier, à force d'attendre le feedback que j'ai demandé...

Nan mais c'est pas le problème, juste que tu disais "pas sûr" comme si il aurait pu y avoir plus de 256x256 versions dans d'autres circonstances ^^

Pollux :
./98>
Tu nous feras tjs autant rire Kevin

Ce n'est pas drôle! C'est totalement sérieux comme problème. Déjà reporté à PpHd, il a avoué qu'il y a un problème, mais n'a pas changé le design pour le corriger.

Et c'est quoi cette histoire de leak avec les RAM_CALLs ?

Le TSR kernel appelle un "function RAM_CALL", c'est-à-dire une fonction qui est dans le kernel. Le kernel est désinstallé. Tu fais quoi?
a. Rien. => Plantage, parce que le pointeur de fonction vers lequel on saute n'est plus valide.
b. Tu restaures tous les vecteurs de AMS en désinstallant le kernel. => Leak de mémoire, le handle du TSR est perdu, plus rien ne pointe vers ce handle.

Kevin Kofler
:

Pollux :
./98>
Tu nous feras tjs autant rire Kevin

Ce n'est pas drôle! C'est totalement sérieux comme problème. Déjà reporté à PpHd, il a avoué qu'il y a un problème, mais n'a pas changé le design pour le corriger.

Non enfin c'est plutôt le fait que tu t'auto-cites comme ça et puis le reste du document qui est plutôt risible... Je n'étais pas au courant de ce pb technique en particulier, mais enfin c pas a priori insoluble, et puiq la "solution" que tu proposes est tjs aussi prévisible

Et c'est quoi cette histoire de leak avec les RAM_CALLs ?

Le TSR kernel appelle un "function RAM_CALL", c'est-à-dire une fonction qui est dans le kernel. Le kernel est désinstallé. Tu fais quoi?
a. Rien. => Plantage, parce que le pointeur de fonction vers lequel on saute n'est plus valide.
b. Tu restaures tous les vecteurs de AMS en désinstallant le kernel. => Leak de mémoire, le handle du TSR est perdu, plus rien ne pointe vers ce handle.

La lib de TSR de Flanker est pas censé éviter ça, genre en utilisant un hook dans le kernel qui serait appelé en cas de désinstallation d'un TSR ?

c'est pas encore complètement implémenté, le pb est pas mal complexe (les hooks, c'est simple à traiter, mais le reste ) mais évidemment ça fait longtemps que j'y pense et que j'y réfléchis

Et que moi j'attends comme un couillon que je sache quoi faire lorsqu'on demande la desinstallation de preos.
La 0.72 n'attend que ca.

Ca parle moyen du topic...
Again, en plus explicite: quelle est la faisabilité d'ajouter à TIGCC un moyen de mettre les commentaires AMS native à la fin du PPG (partie non compressée, après la fin des données compressées, juste avant les tags), au lieu de les inclure dans la partie compressée ? Cela donne directement l'intérêt du truc ou pas: si ça n'est pas supporté par TIGCC, aucun intérêt, on arrête d'en parler.

par contre, il faut penser au faitque les données peuvent être exploitées par le programme, ce qui complique pas mal les choses. Une solution serait de forcer à regrouper les données en un seul bloc qui serait "zappé" lors de la compression et rejeté à la fin du programme après les données compressées, avec une signature réduite au strict minimum.

> par contre, il faut penser au faitque les données peuvent être exploitées par le programme
Surtout avec le constant merging par exemple, en effet.

je pensais plutôt aux progs en asm, mais c'est vrai aussi

Lionel Debroux
: Again, en plus explicite: quelle est la faisabilité d'ajouter à TIGCC un moyen de mettre les commentaires AMS native à la fin du PPG (partie non compressée, après la fin des données compressées, juste avant les tags), au lieu de les inclure dans la partie compressée ? Cela donne directement l'intérêt du truc ou pas: si ça n'est pas supporté par TIGCC, aucun intérêt, on arrête d'en parler.

Mon idée est de lire et copier les commentaires lors de la compression. Pas déplacer, mais copier. C'est beaucoup plus simple.

Mon idée est de lire et copier les commentaires lors de la compression. Pas déplacer, mais copier. C'est beaucoup plus simple.

On ne peut pas les enlever du programme compressé? Ca compliquerait un peu mais ça ferait une économie de place non négligeable.
Surtout pour toi qui est fan de l'optimisation en taille.

Ce n'est pas vraiment implémentable, malheureusement.

C'est un défi ?

Toi, tu ne gères pas le standard complet, alors c'est facile pour toi...
Les commentaires peuvent se trouver n'importe où dans le programme.

#111: je pense également que c'est la solution la plus simple. Evidemment, ça gaspille de la place, mais on n'a rien sans rien.
Quand peut-on espérer l'implémenter dans TIGCC ?

Toi, tu ne gères pas le standard complet, alors c'est facile pour toi... Les commentaires peuvent se trouver n'importe où dans le programme.

J'ai rapidement lu la spécifiaction il y a longtemps.
Mais en pratique, les commentaire doivent presque toujours ce trouver au début ou à la fin non? Ca pourrait être utile de les sortir uniquement dans ce cas là et dans les autre les laisser

Lionel Debroux :
#111: je pense également que c'est la solution la plus simple. Evidemment, ça gaspille de la place, mais on n'a rien sans rien. Quand peut-on espérer l'implémenter dans TIGCC ?

Je ne sais pas. J'ai les updates de la doc à merger, GCC 4.0 à porter etc. Si tu fournis une spec de format, ça ira plus vite.

Pour le moment, je n'ai pas vraiment le temps.
Pour la spec de format, est-ce qu'on fait une extension à la spec actuelle, ou est-ce qu'on en fait une complètement nouvelle qui reprend une très grande partie de l'ancienne (copier-coller) ?