encore une chtite question - Page 19

Ce débat dans mon topic ne me dérange pas

ok

tellement j'aimerais que tout le monde s'entende pour une meilleure compatibilité !!!

pareil... sauf que j'aurai tendance à prendre les fonctionnalités en compte... préfére plus de fonctionnalitas (utiles !) qu'une compatibilité abusive

>Et l'histoire des flags linker que tu définis dans ton header et qui ne sont pas les bons pour notre linker? Je compte au moins:
> _ti89ti
> _mistub
> _readonly
> _install_preos
Raison de plus de penser que votre linkeur est "has-been".
Surtout que ca ne vous couterait rien de le gerer.

><SARCASM>Merci de traîter TIGCCLIB en entier d'"obsolète et dépassé", c'est très sympa pour Zeljko et tous les autres (y compris moi) qui ont travaillé dessus.</SARCASM>
Pas de probleme. Tu peux compter sur moi.

>Bizarre. Et pourtant AMS 1 est dépassé depuis nettement plus longtemps que les kernels que tu veux jeter. AMS 2.03: décembre 1999. PreOs 0.54: février 2002. Il y a plus de 2 ans de différence.
Ben si tu as AMS 1.0x et que ton programme est un KV3, je ne vois aucune raison (a part la stabilite) de ne pas utiliser DoorsOs.
Si un programmeur utilise les nouveaux ram-calls, c'est qu'il en a besoin. C'est tout. Faut pas chercher plus loin.

>J'ai autre chose à faire. Et puis pour moi, "mettre à jour" != "rajouter les RAM_CALLs que tu as rajoutés au format sans demander rien à personne".
Sauf que je demande avant de faire des ajouts.
Les auteurs de Teos, DoorsOs, UniOs m'ont dit de faire ce que je voulais.
Alors je poste des topics ou je parle des extensions que je compte faire suite aux demandes des utilisateurs.

> Le format kernel aurait dû être freezé après DoorsOS II. Tous tes ajouts ne créent que des problèmes de compatibilité.
Lesquels ?

>Parce que tu patches les programmes sans rien demander à personne.
C'est bien l'avantage du kernel : assurer la compatibilite sans rien demander a personne

> Tu sais, je pourrais faire ça avec le _nostub aussi (trap 11 fonction 15).
Sauf que les programmes _nostub sont bien plus sales que les programmes kernels

>Si je ne fais pas d'autopatcheur (même dans Iceberg), c'est parce que je trouve que c'est une très mauvaise idée de patcher les programmes à chaque exécution.
Trop lent

>C'est beaucoup plus simple si l'utilisateur a le choix de patcher ses programmes si et quand il a envie, et GhostBuster fait ça très bien.
Marche pas facilement sur les Pack Archive, sur les libraries.
L'utilisateur moyen est pas capable de le faire.

>(Au passage, ton autopatcheur rate pas mal des corrections faites par GhostBuster!)
Il ne fait que ce qui est SUFFISANT pour les Programmes Kernels.

>Arrête de raconter n'importe quoi... Tu as fait quoi pour la compatibilité? Rajouter des RAM_CALLs pour que les programmes ne tournent plus qu'avec PreOs?
Faire fonctionner les programmes sur Titanium ou sur V200
Faire une compatibilite anterieure.
Assurer une ABI stable.

>Par exemples, tu te permets de donner une valeur négative à CALCULATOR sur Titanium alors que:
>* CALCULATOR a toujours été documenté comme une valeur unsigned.
Pas dans kernel.h

>* CALCULATOR a été documenté comme valant 0 sur Titanium par TIGCC dès la sortie de la première bêta compatible Titanium.
Et c'est moi qui impose mes vues alors que VOUS AVEZ IMPOSE cette valeur arbitrairement.
Vous m'avez montre votre INCAPACITE a communiquer et a discuter. Donc je ne vous ecoute plus.
Vous faites ce que vous voulez, je m'en fous

>* TitaniK et Iceberg suivent la convention de TIGCC.
TitaniK et Iceberg sont totalement obsoletes, depasses. Ils plantent la TI des que tu tentes des systemes de libraries poussees.

>Donc tu te fous complètement de ce que font les autres kernels et ce que documente TIGCC,
Pas des autres kernels, mais de TIGCC totalement.

>tu donnes la valeur que tu veux sans rien demander à personne.
L'hopital que se fout de la charite ? Tres peu pour moi.

>Et quand j'ai eu la nouvelle (un peu par hasard, comme d'habitude chez toi),
Non. J'ai fait expres. Tu me crois stupide ?

> je t'ai même dit explicitement bien avant la sortie de PreOs 0.70 de ne pas le faire, tu l'as fait quand-même.
Vous ecoutez pas. J'ecoute pas. Ou est le probleme ? Les dialogues unidirectionnels, tres peu pour moi.

>Pour distinguer une Titanium d'une 89 normale, c'est simple, HW_VERSION est là exactement pour ça!
Rappelle moi la valeur de hardwareID sur Titanium

> Et utiliser HW_VERSION plutôt que CALCULATOR pour détecter le HW3 est certainement une idée meilleure,
>parce que ça donne des programmes qui marcheront sur la V200 HW3 qui va sans doûte sortir à un moment.
Forcement. Si tu veux detecter le HW3, tu utilises HW_VERSION et pas CALCULATOR !
Faire l'idiot ne te convient pas.

><SARCASM>Vive tes efforts de compatibilité!</SARCASM>
C'est mon letimotif. (c) and TM

>Ce débat dans mon topic ne me dérange pas, tellement j'aimerais que tout le monde s'entende pour une meilleure compatibilité !!!
Le seul probleme a ce niveau la est la definition de "compatibilite".

Oue.

ils portent pas le même nom

tios.h est pour l'asm, kernel.h pour le C. Et doorsos.h est Has Been.

je savais que ma réponse allait bcp t'aider

PpHd :
>Et l'histoire des flags linker que tu définis dans ton header et qui ne sont pas les bons pour notre linker? Je compte au moins:
> _ti89ti
> _mistub
> _readonly
> _install_preos
Raison de plus de penser que votre linkeur est "has-been". Surtout que ca ne vous couterait rien de le gerer.

Monsieur "j'utilise le non-linkeur obsolète du kernel le plus obsolète existant sur TI-89/92+ et je lui apporte quelques quick hacks" traîte notre linker puissant et évolué de "has been". Tu n'en as pas d'autres?

Si un programmeur utilise les nouveaux ram-calls, c'est qu'il en a besoin. C'est tout. Faut pas chercher plus loin.

Et si un programmeur utilise les nouveaux ROM_CALLs, c'est qu'il en a besoin. C'est tout. Faut pas chercher plus loin.

Sauf que je demande avant de faire des ajouts. Les auteurs de Teos, DoorsOs, UniOs m'ont dit de faire ce que je voulais.

Bon, c'est vrai qu'ils s'en foutaient.
Mais là, pour PreOs 0.70, tu n'as pas du tout demandé l'avis de l'auteur de Iceberg (moi) avant de rajouter tes trucs... Tu as même mis des trucs que j'ai explicitement rejetés (GHOST_SPACE).

> Le format kernel aurait dû être freezé après DoorsOS II. Tous tes ajouts ne créent que des problèmes de compatibilité.
Lesquels ?

Compatibilité des nouveaux programmes avec les anciens kernels. Sous TeOS, ils planteront même s'ils utilisent tes RAM_CALLs!

>Parce que tu patches les programmes sans rien demander à personne.
C'est bien l'avantage du kernel : assurer la compatibilite sans rien demander a personne

> Tu sais, je pourrais faire ça avec le _nostub aussi (trap 11 fonction 15).
Sauf que les programmes _nostub sont bien plus sales que les programmes kernels

N'importe quoi, pratiquement tout ce que patche GhostBuster peut aussi se trouver dans un programme kernel. Notamment, le bogue de ROM_base avec 0x600000 se trouve dans tous les programmes kernel en C avec niveaux de gris compilés avec une vieille release de TIGCC.

>Si je ne fais pas d'autopatcheur (même dans Iceberg), c'est parce que je trouve que c'est une très mauvaise idée de patcher les programmes à chaque exécution.
Trop lent

C'est une des raisons (mais pas la seule).

>C'est beaucoup plus simple si l'utilisateur a le choix de patcher ses programmes si et quand il a envie, et GhostBuster fait ça très bien. Marche pas facilement sur les Pack Archive,

zunpack est livré avec GhostBuster pour une raison.
Et puis tu montres là un désavantage des packs archive, pas de GhostBuster.

sur les libraries.

GhostBuster patche parfaitement les librairies.

L'utilisateur moyen est pas capable de le faire.

Oh que si... Depuis quand tu prend les utilisateurs pour des idiots? S'il est capable d'installer un kernel, il est aussi capable d'utiliser un patcheur, ce n'est pas plus compliqué. Avec mon entrée de FAQ, ça passe très bien.

>(Au passage, ton autopatcheur rate pas mal des corrections faites par GhostBuster!) Il ne fait que ce qui est SUFFISANT pour les Programmes Kernels.

Pas pour tous les programmes kernel...

>Arrête de raconter n'importe quoi... Tu as fait quoi pour la compatibilité? Rajouter des RAM_CALLs pour que les programmes ne tournent plus qu'avec PreOs?
Faire fonctionner les programmes sur Titanium ou sur V200

Sur V200, c'était une adaptation minime de PreOs, plus une fonction "lie about CALCULATOR" pour les programmes qui utilisaient des trucs débiles comme CALCULATOR*30. Pas dur, franchement.

Sur Titanium, ben je l'ai fait avant toi.

Faire une compatibilite anterieure. Assurer une ABI stable.

Là, c'est vraiment le strict minimum...

>Par exemples, tu te permets de donner une valeur négative à CALCULATOR sur Titanium alors que:
>* CALCULATOR a toujours été documenté comme une valeur unsigned.
Pas dans kernel.h

Je n'y peux rien si ton header ne suit pas la documentation de TIGCC.

>* CALCULATOR a été documenté comme valant 0 sur Titanium par TIGCC dès la sortie de la première bêta compatible Titanium. Et c'est moi qui impose mes vues alors que VOUS AVEZ IMPOSE cette valeur arbitrairement.

On n'avait pas de choix. Comme je viens de le dire sur ticalc.org:

As far as TIGCC is concerned, the Titanium is just a TI-89 HW3.

Rationale: There will be no other TI-89 HW3 (TI has discontinued production of the "classic" 89), so it's a unique identifier (we have a HW_VERSION pseudoconstant even in _nostub mode for quite some time now), and we can't give a non-0 value to CALCULATOR on an 89-family calculator because this would break source compatibility with the tons of programs writing CALCULATOR?foo:bar. Also, the keyboard layout is practically the same between the 89 and the Titanium (the Titanium keyboard has just been distorted by a curve freak, but other than that it's the same), so there is no reason for the typical game or utility to conditionalize on Titanium or not. Launchers or shells will indeed need to conditionalize on HW3, but they should conditionalize on the hardware version, not on the calculator model, in order to accomodate for future HW3 V200-family models.

En plus, cette valeur a été prise en concertation avec les kernels existants (TitaniK et Iceberg), et elle a été discutée sur le forum de la TICT aussi, donc je pensais que tu étais au courant.

Vous m'avez montre votre INCAPACITE a communiquer et a discuter. Donc je ne vous ecoute plus.

Notre incapacité à communiquer et à discuter??? Je n'ai appris de ton intention de mettre CALCULATOR==-1 que par pur hasard, en parlant de complètement autre chose, et ce n'était que bien après que la décision de TIGCC avait été prise. Il était trop tard de changer, et de toute façon, même au départ, on n'avait pas le choix pour les raisons de compatibilité source évoquées. C'est aussi pour ça que je ne t'ai pas contacté pour te demander ton avis: je savais qu'on n'avait pas le choix pour TIGCC quoi qui se passe et je pensais donc même qu'il était évident que CALCULATOR allait valoir 0 sur Titanium, j'ai été évitré quand j'ai appris que tu allais mettre -1.

Vous faites ce que vous voulez, je m'en fous

Bah, et nous on se fout de ce que tu fais maintenant... De toute façon, pour nous, le flag Titanium n'existe pas (pour nous, la Titanium est une TI-89), donc ce sera couvert par ton système "lie about CALCULATOR" que tu appelles prétentieusement "émulation". Tant pis si PreOs ruine les programmes en les patchant, la solution sera "utilisez Iceberg qui ne patche pas les programmes sans vous demander votre avis".

>* TitaniK et Iceberg suivent la convention de TIGCC. TitaniK et Iceberg sont totalement obsoletes, depasses. Ils plantent la TI des que tu tentes des systemes de libraries poussees.

Je peux aussi faire un Iceberg 2.00 basé sur PreOs 0.70, mais en supprimant ou réversant tous les changements néfastes que tu y as apportés (autopatcheur, flag Titanium, CALCULATOR==-1, peut-être aussi le RAM_CALL GHOST_SPACE qui ne devrait vraiment pas exister, peut-être même les RAM_CALLs de TSRs) et rajoutant à nouveau les changements de Iceberg 1.00 (sauvegarde de l'écran, compatibilité TitaniK, correction du stack leak dans l'anticrash _nostub dont je me suis plaint il y a des années et que tu as refusé de corriger, méthode propre de gérer le problème des fontes, en prenant compte du derelogement contrairement à ton autopatchage foireux) et peut-être d'autres (meilleur anticrash pour les programmes _nostub, ...). C'est une option que je suis en train de pondérer.

>Donc tu te fous complètement de ce que font les autres kernels et ce que documente TIGCC, Pas des autres kernels,

Bah si, tu t'es foutu complètement de ce qu'a fait Iceberg pour CALCULATOR.

mais de TIGCC totalement.

<SARCASM>Très intelligent.</SARCASM> Sous quels termes veux-tu qu'on discute encore avec toi si tu nous parles comme ça? Et penses-tu vraiment que ce soit bien pour la communauté si le principal kernel (enfin, peut-être plus longtemps si je fais Iceberg 2.00 ) est en conflit avec le principal outil de développement??? Pourquoi ne peux-tu pas discuter avec nous avant de changer des valeurs en commun entre nos projets comme CALCULATOR?!

>Et quand j'ai eu la nouvelle (un peu par hasard, comme d'habitude chez toi), Non. J'ai fait expres. Tu me crois stupide ?

Exprès de ne pas nous notifier à temps??? Ou alors tu veux dire "exprès de nous notifier"? Mais alors le problème était que c'était beaucoup trop tard pour changer quoi que ce soit dans TIGCC! Il aurait fallu y penser avant. (Et en plus, il y a aussi le problème de compatibilité source dont je parle plus haut.)

>Pour distinguer une Titanium d'une 89 normale, c'est simple, HW_VERSION est là exactement pour ça!
Rappelle moi la valeur de hardwareID sur Titanium

gateArray==3. C'est la valeur testée par AMS quand on lui demande la version matérielle, donc c'est ça que doit contenir HW_VERSION.

> Et utiliser HW_VERSION plutôt que CALCULATOR pour détecter le HW3 est certainement une idée meilleure,
>parce que ça donne des programmes qui marcheront sur la V200 HW3 qui va sans doûte sortir à un moment.
Forcement. Si tu veux detecter le HW3, tu utilises HW_VERSION et pas CALCULATOR ! Faire l'idiot ne te convient pas.

"Faire l'idiot"??? Tu deviens de plus en plus arrogant et insolent!
Pourquoi veux tu pouvoir faire un if (TI89_TITANIUM)?
a. Touches, écrans? -> Pas besoin, la TI-89 est identique.
b. Protection, ghost spaces, USB, matériel horloge? -> C'est lié à HW_VERSION.
Bref, il n'y a aucune raison valable de distinguer la Titanium d'une non-Titanium si ce n'est la version matérielle, donc HW_VERSION est le seul identifiant qui a besoin de changer.

Martial Demolins :
Euh, pour revenir au sujet, j'aurais voulu savoir si cet exemple de RamCalls.txt:

\wait		jsr	kernel::Idle		; Idle the calc (Saves batt).
		tst.w	KEY_PRESSED_FLAG		; Wait for a key
		beq.s	\wait
		move.w	GETKEY_CODE,d0		; Read the key value

peut être utilisé avec les grays (ie: pas de problème avec l'Int 1)?
Parceque sinon, c'est super commode pour la lecture du clavier, ya presque rien à faire

Cette méthode de lecture de claviers est la plus sale qui existe! Tu vas fouiller directement dans les variables globales privées de AMS au lieu d'appeler les ROM_CALLs faits pour. Beurk! Voilà exactement pourquoi je trouve que le système de RAM_CALLs des kernels est néfaste, il encourage ce genre de programmation sale en mettant ces variables privées à disposition des programmes.

PpHd :
Et doorsos.h est Has Been.

"Has Been", "Has Been", "Has Been", tu n'en as pas d'autres?
C'est surtout PreOs qui sera "Has Been" si je sors Iceberg 2.00.

Bon, c'est vrai qu'ils s'en foutaient.

pas sûr

zunpack est livré avec GhostBuster pour une raison. Et puis tu montres là un désavantage des packs archive, pas de GhostBuster.

oué, mais les programmes patchés ne marchent plus sur les calc standard

Oh que si... Depuis quand tu prend les utilisateurs pour des idiots? S'il est capable d'installer un kernel, il est aussi capable d'utiliser un patcheur, ce n'est pas plus compliqué. Avec mon entrée de FAQ, ça passe très bien.

changer un seul fichier est beaucoup plus simple que patcher 50 ou plus fichiers ...

En plus, cette valeur a été prise en concertation avec les kernels existants (TitaniK et Iceberg),

t'as réussi à te mettre d'accord avec toi-même ? ça n'a pas été trop dur ?

Notre incapacité à communiquer et à discuter???

la tienne est légendaire

Je peux aussi faire un Iceberg 2.00 basé sur PreOs 0.70, mais en supprimant ou réversant tous les changements néfastes que tu y as apportés (autopatcheur, flag Titanium, CALCULATOR==-1, peut-être aussi le RAM_CALL GHOST_SPACE qui ne devrait vraiment pas exister, peut-être même les RAM_CALLs de TSRs) et rajoutant à nouveau les changements de Iceberg 1.00 (sauvegarde de l'écran, compatibilité TitaniK, correction du stack leak dans l'anticrash _nostub dont je me suis plaint il y a des années et que tu as refusé de corriger, méthode propre de gérer le problème des fontes, en prenant compte du derelogement contrairement à ton autopatchage foireux) et peut-être d'autres (meilleur anticrash pour les programmes _nostub, ...). C'est une option que je suis en train de pondérer.

Je ne vois pas trop l'intérêt de faire un kernel pour toi

C'est surtout PreOs qui sera "Has Been" si je sors Iceberg 2.00.

oué, enfin ça ne sera qu'un PreOS 0.70 sans les trucs nouveaux :/

Je pense que vous devirez arrêter de vous disputer tous les deux.Moi, je suis surtout pour la compatibilité antérieur, donc:

Flanker:

zunpack est livré avec GhostBuster pour une raison. Et puis tu montres là un désavantage des packs archive, pas de GhostBuster.

oué, mais les programmes patchés ne marchent plus sur les calc standard

Est-ce que c'est vrai?

---

we can't give a non-0 value to CALCULATOR on an 89-family calculator because this would break source compatibility with the tons of programs writing CALCULATOR?foo:bar

Là, je suis plutot d'accord avec Kevin...

Vous devriez vous mettre d'accord, et éviter de mettre volontairement des incompatibilités les uns envers les autres par pur esprit d' "incommunicabilité" ou de contradiction.... Franchement ce serait cool d'avoir un bon kernel compatible avec toutes les TI, et sur lequel on peut programmer avec TI-GCC sans utiliser des programmes auxiliaires... Mais je pense que TIGCC et son linker devraient prendre en compte le kernel.h de PhHd, et accepter que preOS reste le kernel principal, titanik et iceberg ayant été, je crois, faits seulement pour la titanium, non?

Je pense que PpHd devrait accepter les problèmes de compatibilité de preOS (graphlib, CALCULATOR) et que Kevin devrait accepter d'utiliser les fonctions kernels de PpHd et faciliter la compilation de programmes l'utilisant... Et ne plus rouspèter sur la compatibilité avec les anciens kernels... que PreOS soit LE kernel, et qu'il n'y ait plus de concurrence de kernels stupides dues à une fierté mal placée!
Pour les RAM_CALL, je ne connais pas assez les kernels pour avoir un avis dessus. Mais les formats Kernel ne sont pas obsolètes, alors arrêtez de vous disputer avec les "tel format ne devrait pas exister", etc.

PS: Quand je le dis, ça parait tellement simple... Mais je sais qu'il n'est pas facile de s'entendre.. Mais je voudrais bien que ces disputent cessent...
Link, Ange de Francis de Grade 0.

>Bon, c'est vrai qu'ils s'en foutaient.
>Mais là, pour PreOs 0.70, tu n'as pas du tout demandé l'avis de l'auteur de Iceberg (moi) avant de rajouter tes trucs... Tu as même mis des trucs que j'ai explicitement rejetés (GHOST_SPACE).

Iceberg est un fork de PreOs, c'est toi qui t'écarte du tronc, pas lui

>Compatibilité des nouveaux programmes avec les anciens kernels. Sous TeOS, ils planteront même s'ils utilisent tes RAM_CALLs!

Quelle idée d'utilier TeOs... La meilleure solution est de laisser tomber ce kernel obsolète.

J'avoue que je ne comprends pas trop pourquoi PpHd a choisi -1 comme valeur de CALCULATOR pour TI-89 Titanium

Ce qui est important au niveau de la compatibilité, c'est que les vieux programmes puissent tourner sur des kernels récents, pas l'inverse...

>Oh que si... Depuis quand tu prend les utilisateurs pour des idiots? S'il est capable d'installer un kernel, il est aussi capable d'utiliser un patcheur, ce n'est pas plus compliqué. Avec mon entrée de FAQ, ça passe très bien.

bon ça c'est la meilleure: tu passes ton temps à dire que l'utilisateur moyen n'est pas assez intelligent pour:
1- envoyer sur sa calc les fichiers nécessaires à un prog kernel
2- installer un kernel
Et maintenant tu renverses leurs capacités intellectuelle... un peu de cohérence que diable !


edit:
>Sur Titanium, ben je l'ai fait avant toi.

Si tu as eu des beta-testeurs et un ams 3.00 à disposition avant lui c'était pas dur

Kevin Kofler
:

Sauf que je demande avant de faire des ajouts. Les auteurs de Teos, DoorsOs, UniOs m'ont dit de faire ce que je voulais.

Bon, c'est vrai qu'ils s'en foutaient. Mais là, pour PreOs 0.70, tu n'as pas du tout demandé l'avis de l'auteur de Iceberg (moi) avant de rajouter tes trucs... Tu as même mis des trucs que j'ai explicitement rejetés (GHOST_SPACE).

Mdr, donc forker un kernel te donne le droit de limiter les évolutions du kernel ?


Sinon, pour CALCULATOR = -1, je suis pas sûr que ça soit une bonne idée non plus... Surtout qu'il n'y a absolument aucune différence niveau écran ou clavier.

Et la solution, ça aurait été quoi selon toi ?

Il n'a pas complètement tort, mais le problème doit être solutionné quand même.
Cependant l'exemple donné par Kevin est un hack à partir du moment où CALCULATOR n'est pas défini comme un booléen, et a fortiori appelé à avoir d'autres valeur au fur et à mesure que de nouvelles TI68k apparaissent.

Nan nan mais le pb c'est pas de "se servir d'un entier comme un booléen" (ça c'est très propre, ça teste juste si on a une 89 ou pas), c'est qu'aucun des aspects de la calc n'a été séparé de CALCULATOR et que si une nouvelle calc apparaissait, il n'y avait aucun moyen de savoir quelles propriétés elle avait : il aurait fallu définir des pseudo-constantes SCREEN89, KEYBOARD89, ROMADDR89, etc... Au pire, même si un programme supposait effectivement que l'écran a une résolution de 89 ou de 92 et que la TI-95 sortait avec un écran de 256 pixels de haut, il aurait suffi de voir où SCREEN89 était utilisé...