Progz - Page 2

XDanger
: Pen²: non, je ne le connais pas. Simplement, vu ses posts ici, il ne connaît pas forcément grand chose à la programmation de nos TI-68k.

[EDIT : raah balise [cite], ]

XDanger
: Rendre 200 KB accessibles en un bloc à tous les programmes, ça ne me paraît pas bien. Si un programme veut prendre en compte cette possibilité, il faut qu'il soit développé spécifiquement pour PedroM, c'est à dire que le programmeur doit s'emmerder avec le truc pas standard.

En quoi ça gêne exactement, pourrais-tu donner un exemple ? (ou le reposter, je suis peut-être passé à côté)
Le seul programme que j'ai rencontré ayant posé un problème est CalcRogue qui utilise quelque chose de pas propre du tout (d'ailleurs je crois que PpHd n'a finalement pas fait de workaround dans PedroM pour ça puisque c'est la faute du programme).
Mais la lecture de la taille du bloc juste avant le bloc ne suit *pas* le standard de l'AMS. Ce n'est pas un standard ça, c'est une implémentation interne.

pSymPG n'est pas isolé non plus. Si je lui demande de l'implémenter maintenant, c'est pour rendre PedroM moins incompatible avec AMS.

C'est quand même un point isolé par rapport au reste de PedroM.

XDanger :
pSymPG n'est pas isolé non plus. Si je lui demande de l'implémenter maintenant, c'est pour rendre PedroM moins incompatible avec AMS.
Et quid de PedroM 2.xx, si ça existe un jour ? Sous PedroM 2.xx, s'il veut l'exporter, eh bien il faudra qu'il recode beaucoup de routines de la VAT. Autrement dit, double perte de temps: faire un truc pas correctement et ensuite le faire correctement... Malheureusement, j'ai un peu l'impression qu'il y a un certain nombre de points sur lesquels PpHd est un peu bourrique.

C'est d'ailleurs la même chose avec OSModKeyStatus. Il n'y a qu'à regarder les horreurs de compilation conditionnelle qu'il a mis dans SIDE (qui a accès à l'équivalent PedroM de OSModKeyStatus parce qu'il est intégré à PedroM) parce qu'il n'est pas fichu mettre les bits dans le même ordre!

ExtendeD
:

XDanger
: Rendre 200 KB accessibles en un bloc à tous les programmes, ça ne me paraît pas bien. Si un programme veut prendre en compte cette possibilité, il faut qu'il soit développé spécifiquement pour PedroM, c'est à dire que le programmeur doit s'emmerder avec le truc pas standard.

En quoi ça gêne exactement, pourrais-tu donner un exemple ? (ou le reposter, je suis peut-être passé à côté)

char *p=HeapAlloc(HeapMax());
if (!p) fatal("erreur");
char *q=HeapAlloc(1);
if (!q) fatal("erreur");
=> Erreur.

unsigned short i;
for (i=0;i<2000;i++) {
if (HeapDeref(i)) {
unsigned short s=HeapSize(i);
printf("bloc %u: %u octets",i,s);
}
}
=> valeurs incorrectes

etc.

Le seul programme que j'ai rencontré ayant posé un problème est CalcRogue qui utilise quelque chose de pas propre du tout (d'ailleurs je crois que PpHd n'a finalement pas fait de workaround dans PedroM pour ça puisque c'est la faute du programme).

Ce n'est pas la faute du programme, PedroM est censée utiliser la même implémentation dans la mesure du possible. (Évidemment, il ne s'agit pas de copier-coller le code, ce qui serait illégal, mais de suivre les détails d'implémentation documentés.) L'implémentation du système de heap est documentée en détail (même dans la documentation de TIGCC), donc il n'y a aucune excuse de ne pas la suivre.

Mais la lecture de la taille du bloc juste avant le bloc ne suit *pas* le standard de l'AMS. Ce n'est pas un standard ça, c'est une implémentation interne.

Il est quand-même plus compatible

pSymPG n'est pas isolé non plus. Si je lui demande de l'implémenter maintenant, c'est pour rendre PedroM moins incompatible avec AMS.

C'est quand même un point isolé par rapport au reste de PedroM.

Non, c'est la base de toutes les fonctions de la VAT si elles sont implémentées correctement.

Et pour le problème de CalcRogue, c'est bel et bien un bogue de PedroM: il est censé lancer les PPGs dans l'espace fantôme comme le font tous les lanceurs PPG à part le sien. Il suffit d'une instruction, donc je ne vois vraiment pas de raison de ne pas le faire.

Kevin Kofler :
Et pour le problème de CalcRogue, c'est bel et bien un bogue de PedroM: il est censé lancer les PPGs dans l'espace fantôme comme le font tous les lanceurs PPG à part le sien. Il suffit d'une instruction, donc je ne vois vraiment pas de raison de ne pas le faire.

Oui, je suis d'accord là-dessus.

Je parlais de l'autre bug de CalcRogue venant de l'utilisation de HeapAlloc(HeapMax()) de ton exemple.

Ça, c'est un problème de PedroM...
HeapMax est documenté comme ne pas dépassant 65520:
1. cf. http://tigcc.ticalc.org/doc/alloc.html#HeapMax.
2. La documentation officielle de TI (TIFS) dit: "This will be in the range 0 . . . 65520."
Donc en dépassant 65520, il ne respecte pas la documentation de la fonction.

XDanger> non pas que le post était particulièrement agressif, mais je l'ai locké pour éviter que ce topic ne soit encore plus pourris par des batailles qui n'ont pas leur place ici. Donc pour tout le monde allez guerroyer dans un topic dédié dans une autre partie ou pas du tout

--- AUTO Post locked ---

comme un grand...

Ximoon :
XDanger> non pas que le post était particulièrement agressif, mais je l'ai locké pour éviter que ce topic ne soit encore plus pourris par des batailles qui n'ont pas leur place ici. Donc pour tout le monde allez guerroyer dans un topic dédié dans une autre partie ou pas du tout

Donc maintenant, on locke des posts utiles dont le ton est parfaitement correct? Tu te prends pour qui???
En tout cas, pour "éviter que ce topic ne soit encore plus pourris par des batailles qui n'ont pas leur place ici", là c'est raté...

Kevin Kofler :
Tu te prends pour qui???

C'est le role d'un admin Kevin ...

Le rôle d'un admin est de locker les messages impolis (c'est-à-dire contraires à la netiquette) ou contraires à la charte (messages illégaux, flood etc.; les messages impolis en font d'ailleurs partie si la charte est complète). Celui de XDanger n'était ni l'un ni l'autre.

Il évite les conflits en les tronquant a la source ... j'ai vu pire !

Tu te fous du monde Kevin, je locke une 'attaque personnelle' contre une certaine personne, quelque chose qui n'avait rien à voir avec le débat, complètement hors sujet et qui promettait de faire dévier le topic vers une engueulade qui n'avait rien à voir avec les TIs et toi tu en rajoutes une couche? Quand je pense que tu disais qu'ici on ne respectais pas assez les modos tu ne donnes pas un bon exemple. Maintenant di le topic est foutu on saura à qui la faute. Si tu a quelquechose à rajouter fais-le par mini messages histoire de ne pas pourrir ici un peu plus, mais je t'avoue que je ne te félicite pas ...

mon topic est parti en couille, vous voulez pas aller sur le chat pour vous embrouiller, avant que ce topic soit fermer ?!

C'est une triste habitude ces temps ci dès qu'on parle de Kernel, PedroM ou de lib dynamique

iceman: l'auteur d'un topic peut le fermer s'il y a quelque chose qui ne lui plaît pas... Vas-y, on t'en prie.
Et je ne vais jamais sur le chat, je ne compte pas y aller.

il peut tjrs taper

!kick XDanger
--- Kick : vous n'etes pas l'auteur du sujet ni modérateur !

pour résoudre le pb sans fermer le topic

Tu veux dire kick JackosKing plutôt?
C'est lui qui a commencé!

XDanger :
> Mais PedroM me fait vraiement trippéJe trouve qu'il n'y a pas de quoi en être content à ce point-là. Fonctions mal réimplémentées ou non réimplémentées, mépris du standard AMS... Je ne pense pas qu'il y a de quoi "vraiment tripper"...

c le ./11, relis bien, c XDanger qui a lancé une critique HS qui n'avait pas lieu d'être ds ce topic ...

Ce n'est pas hors sujet parce que ça répond au message n°7 de l'auteur du topic.

même impliciterment je ne vois pas où iceman a demandé l'avis de quelqu'un sur pedrom (pedrom qui n'est pas le sujet du topic je le rappelle) ...

Lequel de vous deux est le plus de mauvaise foi ?

>C'est d'ailleurs la même chose avec OSModKeyStatus. Il n'y a qu'à regarder les horreurs de compilation conditionnelle qu'il a mis dans SIDE (qui a accès à l'équivalent PedroM de OSModKeyStatus parce qu'il est intégré à PedroM) parce qu'il n'est pas fichu mettre les bits dans le même ordre!
C'est pas des horreurs. Juste des define differents. Et je peux encore changer cela puisque c'est interne. J'y peux rien si leur ordre de bits est bizarre. Enfin, bon, je peux pas changer leur ordre, mais le mien si.

char *p=HeapAlloc(HeapMax());
if (!p) fatal("erreur");
char *q=HeapAlloc(1);
if (!q) fatal("erreur");
=> Erreur.

Oué mais ca peut faire la meme chose sous AMS !
C'est ton programme qui est buggue, pas PedroM.

>Donc en dépassant 65520, il ne respecte pas la documentation de la fonction.
Oué et je l'assume sans probleme tant que tu ne me montres pas un exemple ou ca merde pour de bon sans bug de la part du programme

unsigned short i;
for (i=0;i<2000;i++) {
if (HeapDeref(i)) {
unsigned short s=HeapSize(i);
printf("bloc %u: %u octets",i,s);
}
}
=> valeurs incorrectes

HeapSize retourne un unsigned long. C'est le programme qui est buggue.

[A propos de la taille/2]
>Il est quand-même plus compatible
Le seul programme que je connais, qui le fait est Preos...
Et lorsqu'il y a HeapSize, on peut se poser des questions sur le programmeur.

>Non, c'est la base de toutes les fonctions de la VAT si elles sont implémentées correctement.
Elles sont implantees correctement.
D'ailleurs je ne vois pas pkoi on a cree une structure pour pSymPG... Difficile de l'utiliser plusieurs fois.

halal.. on aprend des choses aujourd'hui. tiens il fait beau

PpHd
:

char *p=HeapAlloc(HeapMax());
if (!p) fatal("erreur");
char *q=HeapAlloc(1);
if (!q) fatal("erreur");
=> Erreur.

Oué mais ca peut faire la meme chose sous AMS !

Pas s'il y a assez de RAM libre!
Mais bon, je te l'accorde, autant utiliser 65520 directement si c'est l'effet voulu. Ça serait aussi plus optimisé. Tu peux signaler ça à TRgenius (l'auteur du programme réel qui utilise HeapAlloc(HeapMax())).
Cela dit, ça reste un bogue de PedroM!

>Donc en dépassant 65520, il ne respecte pas la documentation de la fonction.
Oué et je l'assume sans probleme tant que tu ne me montres pas un exemple ou ca merde pour de bon sans bug de la part du programme

Ce n'est pas un bogue du programme. Il demande 64 KO de mémoire libre (65520+sizeof(SYM_ENTRY)), mais c'est son droit! Tu fais donc bien boguer un programme valide.

unsigned short i;
for (i=0;i<2000;i++) {
if (HeapDeref(i)) {
unsigned short s=HeapSize(i);
printf("bloc %u: %u octets",i,s);
}
}
=> valeurs incorrectes

HeapSize retourne un unsigned long. C'est le programme qui est buggue.

Non, le programme n'est pas bogué, parce que HeapSize est censé retourner un chiffre parmi les tailles de bloc valides, donc entre 0 et 65520, donc dans la rangée valide pour un unsigned short. Et HeapSize a même été déclaré en unsigned short dans TIGCC au départ. On l'a mis en unsigned long parce que la fonction retourne un longword entier et parce que c'est la taille d'un size_t, mais ce n'est pas nécessaire.

>Non, c'est la base de toutes les fonctions de la VAT si elles sont implémentées correctement. Elles sont implantees correctement.

Non, elles ne suivent pas l'implémentation documentée, qui est:
* blocs de taille >=8 (peut-être même obligatoirement multiple de 8?) et <=65520
* 16 octets réservés au système devant chaque bloc
* les 2 octets précédant le bloc contiennent le flag lock et la taille divisée par 2

D'ailleurs je ne vois pas pkoi on a cree une structure pour pSymPG... Difficile de l'utiliser plusieurs fois.

Tu veux dire quoi par "l'utiliser plusieurs fois"?

>Pas s'il y a assez de RAM libre!
Mais si ! Il se peut tres bien qu'il n'y est plus qu'un seul bloc de taille HeapMax de libre dans la heap. C'est meme probable ! Et c'est un bug du programme !
Je dois te faire un exemple ?

>Non, le programme n'est pas bogué, parce que HeapSize est censé retourner un chiffre parmi les tailles de bloc valides, donc entre 0 et 65520, donc dans la rangée valide pour un unsigned short. Et HeapSize a même été déclaré en unsigned short dans TIGCC au départ. On l'a mis en unsigned long parce que la fonction retourne un longword entier et parce que c'est la taille d'un size_t, mais ce n'est pas nécessaire.
A l'extreme rigueur...

>Non, elles ne suivent pas l'implémentation documentée, qui est:
* blocs de taille >=8 (peut-être même obligatoirement multiple de 8?) et <=65520
* 16 octets réservés au système devant chaque bloc
* les 2 octets précédant le bloc contiennent le flag lock et la taille divisée par 2
C'est documente ou ca ?

>Tu veux dire quoi par "l'utiliser plusieurs fois"?
Il n'y a qu'une seule structure de ce type dans le systeme.

pour en revenir au sujet : iceman, metal slug c'était pas pour ti à l'origine que tu le programmais, paraît que tu l'as même finis d'après tes dires, t'as des nouvelles ? (et stf2 et bigdyna au fait)