Standard pour commentaires et autres données statiques exportées en _nostub - Page 2

>Est-ce que toutes ces données sont obligatoires?
Non. Lis le standard avant de poser des questions! Je pense que tout y est clairement expliqué (contrairement aux docs de PpHd).

Désolé j'ai lu la doc en coup de vent j'ai du passer a coté.

In order to allow programs to save size by not providing both a black&white icon and a grayscale icon unless it is really needed:
- grayscale shells should draw black&white icons by drawing the same icon in both planes if (and only if) no grayscale icon is available. - black&white shells should draw grayscale icons by drawing only the dark plane (the first one) if (and only if) no black&white icon is available.

C'est bien ce que je comptais implémenter mais si l'on fait des icones en niveau de gris complexes, ca risque de rendre très mal je pense qu'il aurait été pratique d'imposer une icone N&B si l'on veut une icone en gris. Je ne sais pas si c'est fait mais conseille dans la doc de réaliser une icone en N&B si l'on veut en réaliser une gris.

On (Thibaut et moi) en a parlé ici dans le topic sur Einstein. J'estime que ça suffit. Là, j'annonce la sortie du standard finalisé.

Moi ca m'aurait intéréssé mais je ne suivait pas du tout le topic d'einstein qui n'a pas grand chose a voir avec cette extension du nostub.

C'est vrai que c'est dommage de n'avoir parlé de ce standart que dans le topic sur Einstein...

Sinon, ça ne sert à rien, je pense, de dire qu'AMS utilise des icones 22x22 parce qu'elle ne pourra pas les exploiter vu qu'elle n'est pas prévue pour. À la limite, il n'y a qu'ID, qui ensubissant des modifications, pourrait les exploiter.

personellement je pense que le 16x16 est le plus adapté vu la taille de l'écran TI d'ailleur je trouve dommage de TI ait réalisé son meneu en 22x22 quant au icone 32x32 de einstein c'est tellement c'est trop gros

question conne: comment on sait si un programme utilise se standart ou non?

il me semble que la spécif du format définit certains flags qui permettent de savoir

(je l'ai pas relue depuis longtemps, mais il me semble (et ça serait logique))

Vais-je me mettre à programmer Kernel ....

TiMad
a écrit : question conne: comment on sait si un programme utilise se standart ou non?

C da,s le topic d'Einstein, voyon

> question conne: comment on sait si un programme utilise se standart ou non?
Question conne, en effet... Va voir le standard, triple buse !


Je trouve le comportement de certains dans ce sujet, pitoyable. Pour être informés, il faut fréquenter les forums de référence où se prennent les décisions, pas les forums comme celui-ci... Les liens ont été donnés, vous n'avez qu'à aller les consulter. Tant pis pour vous si vous ne le faites pas. Ca fait des mois que le topic existe sur le forum de TIGCC/TICT. Peut-être préférez-vous les décisions autoritaires de PpHd pour les nouveautés de PreOS... Pas nous, en tout cas.
Prétexter que les popups sont ch**** pour ne pas aller sur le forum de TIGCC/TICT, de meilleure qualité au niveau des discussions que celui-ci, est lamentable. Ce forum est beaucoup plus lamentable que l'autre par bien des aspects (ici, l'irrespect règne en maître...).

Peut-être préférez-vous les décisions autoritaires de PpHd pour les nouveautés de PreOS...

Pour pas mal de monde ici (je ne parle pas pour moi, vu que j'avais lu les spécif sur le forum tict, mais pour pas mal d'otres), ça revient au même

de meilleure qualité au niveau des discussions

en termes de discutions "sérieuses", oui.
mais peut-être est-ce justement pr cela que celui-ci (yaronet) est plus interessant...

Ce forum est beaucoup plus lamentable que l'autre par bien des aspects

Ne confond pas le contenant (le forum, qui est absolument génial !) et le contenu (les contenus des posts) !!!!!!!!!
Ce n'est PAS DU TOUT la même chose !

(ici, l'irrespect règne en maître...).

c un peu dommage, c vrai...

Les liens ont été donnés, vous n'avez qu'à aller les consulter

dans un sujet totalement off-topic...
quel irrespect pr les utilisateur du forum qui ne s'interessent pas à Einstein

Ouai mais ceci etant dit.. je vais pas aller sur ce frm ou l'on m'a insulté parce que j'avais sortit une version dll de XLIB...
Alors bon je pense que la bas c'est de la sensure plus qu'autre chose, un regroupement de personne bornées ...
Et puis sur le frm de la tict, ya rien de bien interessant d'ailleur.. tout comme cette norme qui n'est une fois de plus qu'un simple recopiage d'idees kernel...

Il est sûr qu'il aurait fallu au moins faire un topic donnant le lien de manière transparente ici histoire de réellement internationaliser la chose, parceque tenir la communauté francophone à l'écart, même si ce n'est pas voulu, n'est pas très sport.

Quant à ce qui est du forum de la tict lui-même, j'y ai très rarement été, et ce que j'y ai vu était un modèle d'intolérence envers les programmeurs français et les programmeurs kernel. peut-être que je suis mal tombé mais ça ne me donne pas envie de pousser plus avant...

XDanger
a écrit : Prétexter que les popups sont ch**** pour ne pas aller sur le forum de TIGCC/TICT

Et puis y'a le BoardReader pour ça

We selected 16×16 because:
* they are a good compromise between detail level and required byte space.

Bof, je trouve que les icônes 16x16 sont minuscules sur un écran de 92+, sur un écran de 89 je ne me rend pas compte. Et j'avais lutté pour faire de belles icônes en 22x22, dans lesquelles on voit encore quelque chose, alors des 16x16 ça doit être l'enfer à dessiner.
ID centrera les icônes, il n'y aura pas de zoom qui les abîmeraient.

MacIntoc a écrit :
Bon, d'accord, ça fait 2 programme

3:

Orion_ a écrit :
cool ce standard, c vraiment top le commentaire et les icones,
va falloir que j'integre tout sa a shL moi

ID n'est pas le seul, AMS aussi l'utilise.

AMS n'affiche pas du tout d'icônes pour les programmes en RAM sans ID.

Et le zoom, ou l'icone conteneur ne résoud pas tous les prbms. C toujours plus agréable d'avoir des icones du même type, que d'avoir des mix douteux.

Mais t'imagines-tu le bazar qu'il y aurait s'il y avait 15 formats d'icônes différents, et si chaque programme en définirait au maximum 4 ou 5 arbitrairement (parce que je vois mal un programme être livré avec 15 icônes)? Il a bien un choix à faire quelque part!

1.Ce n'est pas parceque c optionnelle que ce n'est pas de la place perdu. A partir du moment ou c utiliser, c de la place perdu.

Si la version numérique donne le même résultat, ben on ne met pas la chaîne.

2.et c pas possible de faire ça en utilisant la version numérique, peut-être ????

Mais "0.94.18.5" est différent de "0.94 beta 18 r5"!

Donc si je comprend bien, le champs commentaire, c pour les programmeurs parresseux ???

C'est aussi parce que ça permet de contrôler exactement ce qui est affiché. Par exemple:
* AutoClBr 2.21 by Kevin Kofler
* Kevin Kofler's AutoClBr 2.21
* AutoClBr version 2.21
* Kevin Kofler's great AutoClBr
* Bracket auto-closing TSR
etc.

Le nom du programme, lui, est AutoClBr et pas autre chose. (Et évidemment, ce n'est pas nécessairement le nom de l'exécutable. Par exemple, le nom du programme peut avoir plus de 8 lettres.)

1.C à dire dans un topic HS

Désolé. Ça concerne avant tout les auteurs des shells, et je pensais que les auteurs des shells allait quand-même regarder dans le topic de Einstein pour voir ce que fait leur "concurrence".

2.Ca ne concerne pas l'utilisateur lambda, mais les programmes tournant avec PreOS et leur programmeur (qui sont minoritaire, n'est-ce pas). Tandis que là, ça concerne tous le monde qui utilise le format _nostub. Du programmeur aux utilisateurs.

Ça concerne avant tout les auteurs des shells et de TIGCC. Les programmeurs _nostub utiliseront ce qui est proposé par TIGCC et affiché par les shells.

bah.. faut dire que dans ce topic, le truc qui était interressant, ct Einstein. Le standart était une dérivation comme il en arrive beaucoup dans les topics. Sur tous que ça parlait plus d'une signature pour éviter les plantages au cas ou certaine données était absentes ou un truc du genre...

Pas du tout. Le but numéro 1 du standard, c'étaient les commentaires. Tout le reste n'est qu'un produit collatéral. Et ça concerne directement Einstein. C'est d'ailleurs Thibaut qui a lancé la proposition en premier. (C'était aussi dans la liste todo du TICT Explorer depuis longtemps, mais Thomas ne le considérait pas comme très important, donc Thibaut a été plus rapide pour lancer la proposition.)

squale92 a écrit :
22x22 est AUSSI un standard d'AMS, puisque c'est ce qui est utilisé sur 2.08

Pour les FlashApps dans le menu à icônes, pas pour autre chose.

C'est aussi ce qui est fait ici : on nous impose quelque chose, sans nous demander notre avis avant !
(je parle des français qui vont pas sur le forum de la TICT... gens dont je ne fais parti qu'à moitié, puisque j'ai déjà lu plusieurs fois dans le passé le contenu de ce topic... je v sur le forum de la tict, mais c'est rès rarement)

ben, qd c dans un topic qui ne nous interesse pas... si le topic d'einstein m'interesse pas, je v as le lire pr savoir si on y parle d'autre chose !!!

Comme j'ai déjà dit, je pensais que ça allait intéresser avant tout les auteurs des shells, et que ceux-ci allaient lire le topic en question.
Et puis, sinon, on allait encore me gueuler dessus parce que j'ouvre trop de topics (n'est-ce pas oXman? ).

erf
oserai-je dire que c du nostub ? (arf, non, après tout, c vrai que le nostub c pour les UTILISATEURS paresseux... ceux qui ne lisent pas les readme, ou qui ont la flemme d'installer un kernel...)

...
Ça se passe de commentaire normalement, mais bon: ce n'est pas seulement pour ceux qui ont la "flemme" d'installer un kernel, mais aussi pour ceux qui n'ont pas envie de gaspiller leur RAM pour un kernel.

gaspiller

Uther Lightbringer a écrit :
C'est bien ce que je comptais implémenter mais si l'on fait des icones en niveau de gris complexes, ca risque de rendre très mal je pense qu'il aurait été pratique d'imposer une icone N&B si l'on veut une icone en gris. Je ne sais pas si c'est fait mais conseille dans la doc de réaliser une icone en N&B si l'on veut en réaliser une gris.

Non, je ne conseillerai pas le gaspillage de place. On met 2 icônes différentes si besoin est, et une seule quand ça suffit.

Moi ca m'aurait intéréssé mais je ne suivait pas du tout le topic d'einstein qui n'a pas grand chose a voir avec cette extension du nostub.

jackiechan
a écrit : C'est vrai que c'est dommage de n'avoir parlé de ce standart que dans le topic sur Einstein...

Désolé.

Sinon, ça ne sert à rien, je pense, de dire qu'AMS utilise des icones 22x22 parce qu'elle ne pourra pas les exploiter vu qu'elle n'est pas prévue pour. À la limite, il n'y a qu'ID, qui ensubissant des modifications, pourrait les exploiter.

En effet.

Uther Lightbringer a écrit :
personellement je pense que le 16x16 est le plus adapté vu la taille de l'écran TI d'ailleur je trouve dommage de TI ait réalisé son meneu en 22x22 quant au icone 32x32 de einstein c'est tellement c'est trop gros

Bon voilà. Merci de me soutenir, pour une fois.

TiMad
a écrit : question conne: comment on sait si un programme utilise se standart ou non?

On vérifie qu'il commence par un move.l (a7),(a7), un bra.w, et 12 octets de signature composés d'instructions illégales. Et comme le dit XDanger, c'est écrit dans le standard.

ExtendeD a écrit :
We selected 16×16 because:
* they are a good compromise between detail level and required byte space.
Bof, je trouve que les icônes 16x16 sont minuscules sur un écran de 92+, sur un écran de 89 je ne me rend pas compte. Et j'avais lutté pour faire de belles icônes en 22x22, dans lesquelles on voit encore quelque chose, alors des 16x16 ça doit être l'enfer à dessiner.

Mais le format que AMS utilise pour les FlashApps (BITMAP 22×22) prend 70 octets au lieu de 32. C'est plus que le double. Et puis c'est vraiment un format exotique, qui n'était pas en considération sérieuse. Ça aurait arrangé ID, évidemment, mais les autres shells se seraient retrouvé avec un format qu'aucune routine de sprites à part BitmapPut ne peut afficher et qui est pratiquement inzoomable vers des tailles standard (16×16, 32×32), par manque de routines comme par problèmes de divisibilité (à cause desquels je pense que tu as probablement fait le bon choix pour ID d'ailleurs), ...

> 1.C à dire dans un topic HS Désolé. Ça concerne avant tout les auteurs des shells, et je pensais que les auteurs des shells allait quand-même regarder dans le topic de Einstein pour voir ce que fait leur "concurrence".

Certes mais je ne lisait plus le topic Einstein car il ne corespond pas du tout au type de shell que je compte réaliser.

Non, je ne conseillerai pas le gaspillage de place. On met 2 icônes différentes si besoin est, et une seule quand ça suffit.

Si on compte faire des icone en niv de gris c'est qu'on a déja pris le parti de perdre de la place a mon avis

Bon voilà. Merci de me soutenir, pour une fois.

Mais mon but n'est pas d'être toujours contre toi

>2. Tu préfères ce que fait PpHd? Il impose ses "standards" (numéros de version des librairies, format pack archive, ...) sans consulter personne avant.
Si vous etes pas content contactez-moi. J'impose rarement. Surtout si vous avez des arguments. Oui, XDanger, tu vas encore me parler de ces ramcalls. Mais elles implictement pointaient vers les fonts du boot (Le francais est bien plus implicite et noble que l'anglais).
Les numeros de version des libs, c'etait une contrainte technique: y'avait quasiment pas le choix. Et qu'est ce qui manque dans les Pack Archive ? Je peux aisement rajouter les champs auteur, commentaire objectif, commentaire subjectif. Numero de version, etc. Et ca supporte les icones variables. A si, la chaine d'identification fait 6 octets au lieu de 18.

>Peut-être préférez-vous les décisions autoritaires de PpHd pour les nouveautés de PreOS...
Quelles decisions autoritaires absolument scandaleuses ai-je pu commettre ? Lorsque je sens que ca peut etre mal pris, j'en parle en vaproware dans 2,3 topics, et Kevin me balances ces arguments comme quoi c'est une abomination. Une fois ces arguments assimiles, je regarde si je continue ou pas.

>Ça se passe de commentaire normalement, mais bon: ce n'est pas seulement pour ceux qui ont la "flemme" d'installer un kernel, mais aussi pour ceux qui n'ont pas envie de gaspiller leur RAM pour un kernel.
Et qu'ils la gaspillent a nouveau avec ces commentaires dont ils n'avaient pas besoin.
C'est marrant la vie.

Et je precise que les autres auteurs de kernels m'ont donne carte blanche pour faire evoluer ce format (Je leur ai demande).

Bonne chance pour la suite.

PpHd
a écrit : A si, la chaine d'identification fait 6 octets au lieu de 18.

On a pris une chaîne d'identification longue pour éviter les faux positifs.

> parceque tenir la communauté francophone à l'écart, même si ce n'est pas voulu, n'est pas très sport.
Sans doute, il est sport d'insulter la communauté non francophone (je ne te vise pas toi, mais d'autres) pour des motifs parfois faux...

> et ce que j'y ai vu était un modèle d'intolérence envers les programmeurs français et les programmeurs kernel.
Non. Un modèle d'intolérance contre les kernels eux-mêmes, oui. Un modèle d'intolérance contre certains programmeurs français qui insultent, oui. Un modèle d'intolérance contre les programmeurs kernels, pas trop je trouve. Et ceux d'ici n'ont pas vraiment de leçons à donner à propos de l'intolérance aux programmeurs qui programment dans le mode opposé... Avec une nuance: les programmeurs _nostub sont majoritaires, les programmeurs kernel sont minoritaires... Qui est fermé d'esprit ?

> Désolé. Ça concerne avant tout les auteurs des shells, et je pensais que les auteurs des shells allait quand-même regarder dans le topic de Einstein pour voir ce que fait leur "concurrence".
En effet. Il faut s'informer de ce que fait la concurrence, ça aide à améliorer ses propres programmes...

> Mais elles implictement pointaient vers les fonts du boot
Mais voyons, l'implicite n'est pas bon du tout pour un standard...

> Et je precise que les autres auteurs de kernels m'ont donne carte blanche pour faire evoluer ce format (Je leur ai demande).
Et alors ? Ca n'est pas une raison valable pour ne pas faire de consultation publiques sur des forums très fréquentés (tu n'en a jamais fait sur le forum de TIGCC/TICT, évidemment; mais je ne t'en ai jamais vu faire sur les forums TI de ce forum ou ailleurs (même sur le site de la Time To Team)...

Pourtant, il faut saluer le travail de PpHd, qui essaie de maintenir à flot un format dépassé et de moins en moins utilisé... Il prend des décisions, certes de façon autoritaire, mais il prend les décisions qui s'imposent (décisions qui auraient d'ailleurs dû être prises il y a déjà longtemps, si le format kernel avait été standardisé autrement que par l'usage...). Il est vrai qu'à la grande époque des kernels, les fonctions d'AMS étaient mal connues...

PpHd a écrit :
Et je precise que les autres auteurs de kernels m'ont donne carte blanche pour faire evoluer ce format (Je leur ai demande).

Tu a reussi a joindre Xav ??
j'aimerait bien savoir se qu'il est devenu..
Tu pourrait nous faire un "interviewn" de Xav sur se qu'il pense de TIGCC, des kernel et des nostubs now ? (apres lui avoir raconté comment sa se passe, comment c géré etc...)

Si vraiment on devait avoir un "dieu" des TI, je croit qu'il faudrait mettre Xav dans la plus haute chaire

Je ne l'ai pas connu

Vous pouvez essayer Xavier@tigcc.ticalc.org . Mais je ne sais pas si l'adresse vers laquelle c'est redirigé est encore valable. Il est théoriquement toujours membre de l'équipe de TIGCC, mais on n'a plus de contact avec lui depuis très longtemps.

C dommage.. C'est l'un des seul a avoir montré la puissance de TIGCC, a avoir ecrit un shell (sont fameux DoorsOS) 99% en C

DoorsOS est plus maintenu, mais ne doit quand meme etre oublié, il s'agit surement du meilleur programme qu'on ai pu avoir sur TI.

godzil
a écrit : C dommage.. C'est l'un des seul a avoir montré la puissance de TIGCC, a avoir ecrit un shell (sont fameux DoorsOS) 99% en C

Tu trouves que DoorsOS montre la puissance de TIGCC??? Je ne suis pas d'accord. Il n'utilise rien de spécial. Il y a des programmes qui la montrent bien mieux. TI-Chess, pour n'en citer qu'un.

Ti-Chess n'est qu'un portage, non?

Je suis pas sur, mais je croit (je veux pas trop m'avancer non plus) mais que Xav ct plus ou moins lancé dans se projet pour pouvoir justement ecrire sont kernel en C.

Et puis a mon avis TI-Chess est surement une bonne preuve de la puissance de "calcul brute" des TIs mais montre pas a quel point on peu "bidouiller" les TIs simplement en C. Que je sache PreOS est ecrit en ASM, et pas en C ! (PpHd, me tape pas si g tord, g jamais regarder les sources de preos.)

Programmer sur les TI est plus du bidouillage qu'autre chose (pour moi) il est donc génial de montrer a quel point on peu implementer des truc "complexes" comme un kernel en C alors que pendant 2 ans auparevent, on ne pouvait le faire que en ASM!

Selon Thomas, il y a bien plus de code de lui que des auteurs d'origine du moteur. Le moteur d'origine était beaucoup trop lent pour une calculatrice.

Kevin Kofler
a écrit : Selon Thomas, il y a bien plus de code de lui que des auteurs d'origine du moteur. Le moteur d'origine était beaucoup trop lent pour une calculatrice.

sa m'étonne pas du tt

Et je suis toujours de l'avis que le simple fait qu'on puisse écrire un kernel avec ne montre pas du tout la puissance de TIGCC. Regarde plutôt: TI-Chess, FAT Engine, ... Et aussi les programmes mathématiques. Comme celui-là.