Progz - Page 3

!new_page

Je me demande pourquoi Kevin n'a toujours pas décidé de laisser PpHd tranquille.

très bonne question !!

Santi > oué !!!

iceman : tu nous montre voir s'il est aussi beau que celu que tu prépares ?

PpHd :
>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 ?

Quelle partie de "s'il y a assez de RAM libre" ne comprends-tu pas???
Le programme demande 64 KO de RAM libre, et alors?

>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 ?

"The maximum size of a single block is 65520 bytes, and the minimum size is 8 bytes." (http://tigcc.ticalc.org/doc/alloc.html#HeapAlloc, et c'est aussi dans la doc SDK).
Pour le reste, il est forcément documenté quelque part vu que je le sais et que ce n'est pas moi qui ai trouvé ça.

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

memcpy est là pour ça (cf. sources de mon task switcher ).

>Quelle partie de "s'il y a assez de RAM libre" ne comprends-tu pas???
>Le programme demande 64 KO de RAM libre, et alors?
Il est buggue

>Pour le reste, il est forcément documenté quelque part vu que je le sais et que ce n'est pas moi qui ai trouvé ça.
Documentation officieuse.

PpHd :
>Quelle partie de "s'il y a assez de RAM libre" ne comprends-tu pas???
>Le programme demande 64 KO de RAM libre, et alors?
Il est buggue

Alors SMA est très bogué parce qu'il demande bien plus que ça.

>Pour le reste, il est forcément documenté quelque part vu que je le sais et que ce n'est pas moi qui ai trouvé ça. Documentation officieuse.

Mais que tu es quand-même censé consulter, vu que tu es en mesure de le faire.
Plus ton implémentation est proche à celle de AMS, moins il y aura de problèmes de compatibilité. Le seul facteur limitant est le respect des droits d'auteur, mais tu n'es même pas obligé de regarder les sources de AMS pour implémenter la gestion mémoire à peu près de la même manière, donc tu peux très bien le faire sans violer les droits d'auteur de TI.

Pour "16 octets réservés au système devant chaque bloc", je suis sceptique. Il me semble que ça n'est le cas pour aucun handle. Déjà, ça n'est clairement pas le cas pour les handles 1 à 4 "Heap Markers", qui sont stockés tous à la suite sans blanc; c'est pareil pour les ACBs.
La fenêtre qui affiche les adresses des handles dans VTI (du moins celle modifiée par JM, je sais que cette fenêtre fonctionne dans cette VTI modifiée) le montre clairement, tout comme tthdex.
"les 2 octets précédant le bloc contiennent le flag lock et la taille divisée par 2": en revanche, ça, c'est vrai à peu de chose près (ça n'est pas exactement la taille divisée par 2). C'est très facile à voir en désassemblant HeapLock, HeapGetLock, HeapSize...

Thibaut a écrit:

!new_page
Je me demande pourquoi Kevin n'a toujours pas décidé de laisser PpHd tranquille.

Et nous, on se demande pourquoi tu n'arrêtes pas de poster ce genre de choses qui n'apportent ABSOLUMENT RIEN au débat. Les deux parties de ton post sont aussi inutiles l'une que l'autre. Accessoirement, elles sont ridicules en utilité (c'est dire...) par rapport à ta signature qui est trop longue, qui rend encore plus ridicule en taille ton post.
Kevin et PpHd ont des choses à propos desquelles débattre, ils n'ont pas besoin de toi qui fais ce genre de posts.


Note: je suis resté très longtemps offline, je n'ai lu que jusqu'à #65.

XDanger
: "les 2 octets précédant le bloc contiennent le flag lock et la taille divisée par 2": en revanche, ça, c'est vrai à peu de chose près (ça n'est pas exactement la taille divisée par 2).

C'est la taille interne divisée par 2. La taille interne est la taille arrondie par excès au prochain multiple d'une puissance de 2 (2, 4 ou 8, je ne sais pas exactement).
Et à cette taille interne divisée par 2 peut être rajouté 32768 (flag locked).

Et pour les octets réservés au système, ils ont peut-être été réduits dans AMS 2 par rapport à AMS 1.

> (...) par rapport à ta signature qui est trop longue, qui rend encore plus ridicule en taille ton post.
Waaa quel argument Je suis cassé
Tu es trop fort


> Kevin et PpHd ont des choses à propos desquelles débattre, ils n'ont pas besoin de toi qui fais ce genre de posts.
Nan y'a aucun débat. Kevin donne des ordres à PpHd. Comme si j'allais ordonner à Kevin ou à toi de programmer vos utilitaires d'une façon qui me plaît... Vous vous prenez un peu pour des chefs et vous laisserez PpHd tranquille quand vous l'aurez compris, d'où ma question.

Kevin: Moi je parlais d'un programme qui verifie si la memoire est bien allouee. C'est bugguee et je n'y peux rien. Reflechis encore.

> Nan y'a aucun débat.
Je pense que tu as malgré tout très bien compris ce que je veux dire (quand PpHd et Kevin débattent, en général de kernel/_nostub, PedroM/AMS, ils n'ont pas besoin de toi pour poster ce genre de trucs), mais tu fais semblant de n'avoir rien compris.

XDanger :

Kevin et PpHd ont des choses à propos desquelles débattre, ils n'ont pas besoin de toi qui fais ce genre de posts.

si pour une fois c thibaut qui a raison : que kevin et pphd veuillent débattre, soit, mais qu'il le fasse en un lieu approprié.

Poster des HS (ce qu'il font pour leur dialogue de sourds) dans un topic c'est du flood et le flood c'est contre la charte, donc Ximoon a bien fait de te locker une première fois, et je pense qu'une seconde couche ne serait pas de trop parcqu'à priori, antant Kevin que PpHd et que toi n'ont toujours pas compris que ce débat n'a pas sa place ici !!!

si vous n'y arrivez pas je vous aide :
Forum TI>Programmation ASM>Kernel vs Nostub et pas ailleurs

Bon évidemment si tous les débats Kernels/nostub/pedrom (et autres) pouvaient avoir lieu dans des topics dédiés ça serait l'idéal, mais ça n'est pas possible de locker tous les posts hors sujet d'un topic non plus... Ceci dit ici le mot "PedRom" a été introduit par l'auteur du topic, et je ne sais pas s'il avait envie de lancer un débat, mais il peut toujours se manifester, et tant que les posts sont constructifs, il n'y a pas vraiment de raison de les locker... contrairement aux petites engueulades purement personnelles du début du topic... qui n'apportaient rien à aucun débat On peut toujours demander d'aller continuer le débat ailleurs mais il est trop tard pour transformer le topic en zone lockée.

PedROM a été cité en premier par l'auteur du topic, mais il ne voulait sûrement pas de "débat". Y'a un de ces trois qui n'a pas pû se retenir de faire une remarque provocante, et le bordel a commencé : PpHd, Kevin, XDanger ?

Et y'en a toujours pour en rajouter sans contribuer au débat, fut-il hors sujet (Thibaut, TiMad ?)
Alors pas besoin de poster si c'est pour dire des trucs aussi polluants que ledit débat mais complètement inutile et provoquant.
Alors on se calme (j'ai comme l'impression de me répéter... pas besoin de pourrir ce topic plus qu'il ne l'est déjà...), je n'ai pas envie de locker qui que ce soit, ne m'y pousse pas...

lol, ca me fait rire tout ca .....des joutes enfantines !

Ximoon : J'ai cru comprendre que tu déchargeais éventuellement la responsabilité de ce bordel sur l'auteur du topic, sous prétexte que c'est lui qui a cité PedROM.
J'ai juste voulu te répondre que ce n'était sûrement pas l'intention de l'auteur, que c'est un des fanatiques habituels (je m'inclus) qui a provoqué le "partage en couilles" avec une première remarque provocatrice de l'un ou de l'autre camp, comme à chaque fois.

J'arrête ma pollution ici

un topic est fait pour débattre, sur un sujet précis, mais il se peux que le sujet se détourne, je vous emprie allez-y, parler de PedroM/AMS, ca regarde tout le monde, et PedroM est inclut dans mon topic....alors si vous voulez en parlez, vous pouvez !

Mais cordialement

Ok, le trio peut continuer son engueulade stérile

C'est cool au lieu d'avoir un topic floodé par un débat énervant a la longue on a un débat sur le role du modérateur

mais non c'est dans l'ordre des choses:
sujet initial -> kernel/PedroM vs nostub/AMS -> Attaques personnelles -> Modérateurs
C'est le courant que suit chaque topic dans la partie TI, et il faut avouer que c'est assez désagréable et redondant...

Si l'auteur ne voulait vraiment pas que l'on fasse cela, il aurait fait:





et l'affaire aurait ete reglee !

Bah moa je relance le débat, et vu l'état de ce topic, ça ne peut pas être pire . Mais il y a surtout que je suis excédé par les posts de XDanger à chaque fois que je passe qq minutes sur ce forum.

XDanger> Tu es en train de venir dans dans un topic dédié à quelque chose que tu n'aimes pas, alors à quoi tu t'attends ? C'est du flood pur et simple et il est arrivé ce qu'il devait arriver. Va sur un forum du PSG pour écrire "Vive l'OM", et on verra après.

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. Pas tous les programmeurs de gros programmes ne laisseront complètement tomber AMS. Et je trouve qu'il faut être bête pour programmer pour une petite minorité - c'est pourtant ce que font quelques-uns depuis des années...

Le standard AMS. Ca c'est la réponse à tout. A quoi bon refaire une rom si c'est pour refaire exactement AMS ? Médite la dessus et nous fait pas chier avec le standard AMS surtout quand tu places où tu veux la limite entre ce qui est standard et ce qui ne l'est pas.
Car le problème relatif à HeapMax n'est pas dû à pedrom mais à la documentation et au programme mentionné (CalcRogue ?). Il faut bien faire la distinction entre "documenté" et "non documenté" pour éviter des problèmes d'évolutivité.
HeapMax est une fonction qui renvoie la taille du plus grand bloc allouable, et la documentation aurait dû s'arrêter là. Les informations supplémentaires auraient dû être mentionnées à titre indicatif. Le programmeur, lui, aurait du écrire qqch du style HeapAlloc (min (HeapMax (), 65520)).

Mais que tu es quand-même censé consulter, vu que tu es en mesure de le faire. Plus ton implémentation est proche à celle de AMS, moins il y aura de problèmes de compatibilité. Le seul facteur limitant est le respect des droits d'auteur, mais tu n'es même pas obligé de regarder les sources de AMS pour implémenter la gestion mémoire à peu près de la même manière, donc tu peux très bien le faire sans violer les droits d'auteur de TI.

Et elle a été faite comment la documentation de TIGCC ?? Vous l'avez reçu de papa noël TI plusieurs années avant qu'ils se fasse chier à sortir la doc de TIFS ?


En fait, il n'a jamais été question de pub pour le nostub contre le kernel, mais de pub pour AMS, Le AMS, le plus grand OS de tout les temps qui bat Linux et NT à plat de couture et qui exploite à 100% les capacités de la TI. On a vraiment l'impression que certains sont payés par TI ici...
Du coup, les arguments qui ont circulé en faveur de AMS/nostub/libs statiques tombent à l'eau. Si vraiment c'est si bien, pourquoi faire du matraquage et imposer une manière unique de programmer sur la TI alors qu'il ne s'agit en plus que d'un simple loisir.

Néanmoins, je taperai pas davantage sur AMS/nostub/libs statiques. Cette philosophie a effectivement des avantages, tout dépend ensuite de ce en quoi on veut transformer nos TI68k.
Pour beaucoup d'autres, les TI68k sont suffisamment intéressantes d'un point de vue hardware pour être plus ambitieux et préférer une modification d'AMS (kernel) ou carrément un abandon (pedrom), le tout avec des libs dynamiques.
Alors un peu de respect bon sang.

Courage PpHd !
Quant à moi, j'avais un peu de temps à perdre et y a rien de plus amusant qu'un bon topic kernel/nostub.

> Mais il y a surtout que je suis excédé par les posts de XDanger à chaque fois que je passe qq minutes sur ce forum.
Sache que celui qui m'a envoyé chier quand je lui ai demandé d'où venaient des noms d'origine inconnue de ROM_CALLs inconnus, qu'il a mis dans un truc bien utile mais fait sans l'accord de l'auteur original, m'a excédé...
J'espère simplement qu'ils ne viennent pas d'un endroit tel que ça puisse causer des ennuis à quiconque, et je précise que je n'ai pas insulté cette personne de quelque manière que ce soit, je peux poster les mails...


> A quoi bon refaire une rom si c'est pour refaire exactement AMS ?
Combien de fois faudra-t-il que je répète que ce que je reproche à PedroM, c'est de faire semblant d'être compatible avec AMS ? Soit on refait exactement la même chose, ce qui n'a en effet que peu d'intérêt, soit on refait un truc complètement incompatible ! Là, on a un hybride des deux, qui est compatible sur certains trucs, mais ne réimplémente pas pSymPG, réimplémente mal les fonctions d'allocation dynamique... et qui accessoirement exporte une table de ROM_CALLs dépassée depuis plus de quatre ans. Il est vrai qu'AMS 1.xx était l'âge d'or du mode kernel...


> Médite la dessus et nous fait pas chier avec le standard AMS surtout quand tu places où tu veux la limite entre ce qui est standard et ce qui ne l'est pas.
Bien. Alors argumente: quand, à quelle occasion ai-je fait ça, qu'ai-je écrit, sur quoi ai-je varié ? Sinon, cette phrase est cacaniveau et c'est direction la poubelle...


> Le programmeur, lui, aurait du écrire qqch du style HeapAlloc (min (HeapMax (), 65520)).
Et pourquoi faire ? Pour avoir le plaisir d'alourdir le code alors que la doc de TIGCC et la doc officielle de TI elle-même marquent qu'un handle fait au maximum 65520 octets ?


> Et elle a été faite comment la documentation de TIGCC ?? Vous l'avez reçu de papa noël TI plusieurs années avant qu'ils se fasse chier à sortir la doc de TIFS ?
Une question qui ne répond pas à la tienne: as-tu participé de façon significative à cette documentation ?


> Le AMS, le plus grand OS de tout les temps qui bat Linux et NT à plat de couture
Quand est-ce que tout le monde va arrêter de mettre des arguments du monde des PC qui n'ont rien à faire dans un sujet traitant des TI ?


> Alors un peu de respect bon sang.
En disant "On a vraiment l'impression que certains sont payés par TI ici..." (de tels propos pourraient être qualifiés de diffamatoires), tu ne respectes pas ceux qui sont visés par cette phrase, et tu demandes qu'il y ait du respect ? Tu baisses dans mon estime...


[EDIT: merci fabetal_].