1

Slt !
J'ai essayé AS92 => trop fort, je peux enfin programmer en un langage plus puissant que le BASIC on-calc ! (vu que je pars bientôt en vacances, c bien utile !), mais j'ai un pb : à chaque utilisation, il me fait perdre environ 8ko de RAM....
Il n'y a pas quelqu'un qui ait une version ne présentant pas de pb (j'ai essayé la verion sur le site de la dba, et celle sur TI-Calc...)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

2

oui, le reset pour libérer la RAM, c'est ce que je fais.... (vive la ROM2.05 qui récupère 100% des archives !)...
Mais faut dire que c un peu chiant....
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

3

BOn, ben, je crois qu'il va falloir faire avec pour l'instant..........
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

4

ExtendeD à fait un lanceur pour as92 qui libere la mem à la fin.
le topic doit etre encore par ici wink

5

houla... trop fort !
Faut que je retrouve le topic.
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

6

g trouvé le prog : merci.
Cpdt, un truc chiant : faut que le répertoire courrant soit main... M'enfin bon, j'ai corrigé ce truc pour mon usage perso...

Par contre, je sais pas pourquoi, mais les 4 ou 5 premières fois que j'utilise le prg, ça fait encore perdre de la mem (après, ça en perd plus...).
C'est pas du au fait de la création de outputb et asret.., car ça se produit plusieurs fois (ça vien tpas non plus du fait que ça passe dans l'historique de calculs....)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

7

en fait, je ne l'ai pas encore utilisé wink

8

ben, j'ai essayé pas mal de trucs pour corriger le pb que je disais :
Je perdais de la RAM les 3 ou 4 premières fdois que j'utilisais le patch... et plus après...
Alors, j'ai modifié ds le code du prog le nombre max de Handles... Extended l'avait mis à 2000... je l'ai monté à 2050...
=> maintenant, je perd quasiment plus de mem...
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

9

tu en perds encore ?
on peut pas monter le nombre de handles au-delà ?

10

j'ai essayé de le monter à 2200...
Ca me fait perdre en gros 1ko.
(Je tiens à préciser que, dans ce ko, il faut tenir compte du fait que la variable asret... tient 4 octets, et le programme une fois compilé en fait 200..) => environ 800o de perdu... mais seulement la première fois... plus ensuite.
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

11

asret : 4 octets : oui, mais as92 a un bug que j'avais découvert : il alloue toujours la même quantitié de mémoire pour asret, je crois que c'est 1000 octets.

12

Bon, j'ai refait le test, et je vais tout détailler, pour que ça soit bien clair :

TI-92+, HW1, ROM2.05, UniversalOS1.30, Maxmem.

* Reset de toute la mémoire (RAM et Archive), puis envoie d'un backup depuis le PC.
* Installation de UniversalOS, d'un TSR que je me suis fait pour mon usage perso, de AutoClBr (TSR de Kevin Kofler), et de Bestview (autre TSR, je sais plus de qui).
* Modifications des modes, pour les mettre à ce que j'ai l'habitude d'utiliser.
=> L'installation des progs et la mise à jour des modes ont été fait par un programme que j'ai moi-même programmé en C, et que je sais être non buggé.

Là, j'ai plusieurs répertoire :

AEFFACER : le répertoire qui contiendra les sources à compiler.
.... // d'autres répertoires, sans importance.
MAIN
... // d'autres répertoires sans importance.
ZZ__AS92 : le répertoire qui contient tout ce qui se rapporte à AS92 (le programme AS92, le patch de Extended modifié, les fichier textes des librairies, des exemples, ...).

Le répertoire courrant n'est pas MAIN, mais AEFFACER. Cela pourrait pose problème à la version officielle du patch de Extended qui suppose que le répertoire courrant est MAIN... Mais, suiste à des modifications que j'ai effectué dans le code du patch, cela ne pose plus de problèmes... En effet, à présent, au lieu de chercher et de travailler uniquement dans MAIN, le patch travaille dans tous les répertoires : il regarde dans quel répertoire sont les fichier as92ret et outputb, et travaille avec eux... (J'ai utilisé des fonctions recherche plus poussées que SymFindMain...).
Normalement, les fonctions que j'ai utilisé ici ne devraient pas bugger : ce sont des copies conformes de celles que j'ai utilisé dans mon explorer, qui est en période de bêta-test, et pour lequel on ne m'a pas encore fait de repport de bug... De plus, dans tous les cas que j'ai essayé, les variables ont été trouvé dans le bon répertoire, et la compilation et la création de l'exécutable se sont fait sans encombre de ce côté là...

Voici le contenu du fichier TEXT que j'ai utilisé comme source (il est nommé "hello") :
include zz__as92doorsos
include zz__as92userlib
include zz__as92graphlib

_main:
jsr graphlib::clr_scr

SetFont #1

WriteStr #20,#10,#4,maStr

jsr userlib::idle_loop
rts

_comment dc.b "Programme Hello World",0
maStr dc.b "Hello World !",0

Les fichier mis en include correspondent à des fichiers TEXT faisaint office de header pour le prog : ils contiennent les équivalences ROM_CALLs, ou fonctions de libs.
Les macros SetFont et WriteStr correspondent à celles de DoorsOS
(Il y a peut-être une ou deux faurtes de frappe qd j'ai recopié de ma TI au PC... Mais, sur la TI, ca marche !)

Ensuite, je tape dans l'écran HOME ceci, pour compiler le prog :
zz__as92aspatch("include aeffacerhello")
J'ai à ce moment là noté la mémoire RAM qu'il me restait de libre via l'écran MEM => j'ai obtenu 165716 octets.

J'appuie sur ENTER (logique :-))...
La compilation se fait sans problème...

Création des fichiers aeffaceroutpub (195 octets) et as92ret (4 octets)...
A ce moment là, j'efface la ligne qui s'est rajouté dans l'écran HOME (pour ne pas fausser les données de l'historique des entrées)... Et je vais dans l'écran mem => 164480 octets de libre...
(Précison : le programme créé fonctionne sans pb !)

J'ai donc perdu 1236 octets...
Dans ces 1236 octets, 199 ont servi pour les deux variables crées par AS92...
Rien n'a du servir pour l'écran HOME....

=> 1037 octets sont "parti" sans laisser de traces....

Si je relances la compilation, je n'ai plus aucune perte de mémoire....
=> Cette perte de mémoire ne se fait qu'à la première compilation...
Je n'ai pas pu reproduire ce truc sur VTI, mais il n'avait que 100ko de RAM libre, et non pas plus de 165ko....


=> Je vois pas trop d'où ça peut venir..........
Si jamais c'est un truc con auquel je n'ai pas pensé, ben, dites le moi... Comme ça, je me coucherai moins con ce soir :-)



Avant de changer le nbr max de HANDLEs dans le patch d'extended, j'avais plusieurs pertes de mémoire successives, pour les 3-4-ou 5 premières compilations... (Un des cas que j'ai noté est le suivant : 165698 => 158980 => 154350 => 150222 => 150222 : plus de pertes)...
Je sais pas si ça peut aider quelqu'un.... je l'espère...



PS: je précise que je ne suis pas fou : étant donné que je n'ai qu'un petit forfait internet, j'ai écrit tout ça hors-ligne, pour pouvoir prendre mon temps, et le faire du mieux possible...
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

13

Bon, j'ai refait le test, et je vais tout détailler, pour que ça soit bien clair :

TI-92+, HW1, ROM2.05, UniversalOS1.30, Maxmem.

* Reset de toute la mémoire (RAM et Archive), puis envoie d'un backup depuis le PC.
* Installation de UniversalOS, d'un TSR que je me suis fait pour mon usage perso, de AutoClBr (TSR de Kevin Kofler), et de Bestview (autre TSR, je sais plus de qui).
* Modifications des modes, pour les mettre à ce que j'ai l'habitude d'utiliser.
=> L'installation des progs et la mise à jour des modes ont été fait par un programme que j'ai moi-même programmé en C, et que je sais être non buggé.

Là, j'ai plusieurs répertoire :

AEFFACER : le répertoire qui contiendra les sources à compiler.
.... // d'autres répertoires, sans importance.
MAIN
... // d'autres répertoires sans importance.
ZZ__AS92 : le répertoire qui contient tout ce qui se rapporte à AS92 (le programme AS92, le patch de Extended modifié, les fichier textes des librairies, des exemples, ...).

Le répertoire courrant n'est pas MAIN, mais AEFFACER. Cela pourrait pose problème à la version officielle du patch de Extended qui suppose que le répertoire courrant est MAIN... Mais, suiste à des modifications que j'ai effectué dans le code du patch, cela ne pose plus de problèmes... En effet, à présent, au lieu de chercher et de travailler uniquement dans MAIN, le patch travaille dans tous les répertoires : il regarde dans quel répertoire sont les fichier as92ret et outputb, et travaille avec eux... (J'ai utilisé des fonctions recherche plus poussées que SymFindMain...).
Normalement, les fonctions que j'ai utilisé ici ne devraient pas bugger : ce sont des copies conformes de celles que j'ai utilisé dans mon explorer, qui est en période de bêta-test, et pour lequel on ne m'a pas encore fait de repport de bug... De plus, dans tous les cas que j'ai essayé, les variables ont été trouvé dans le bon répertoire, et la compilation et la création de l'exécutable se sont fait sans encombre de ce côté là...

Voici le contenu du fichier TEXT que j'ai utilisé comme source (il est nommé "hello") :
include zz__as92doorsos
include zz__as92userlib
include zz__as92graphlib

_main:
jsr graphlib::clr_scr

SetFont #1

WriteStr #20,#10,#4,maStr

jsr userlib::idle_loop
rts

_comment dc.b "Programme Hello World",0
maStr dc.b "Hello World !",0

Les fichier mis en include correspondent à des fichiers TEXT faisaint office de header pour le prog : ils contiennent les équivalences ROM_CALLs, ou fonctions de libs.
Les macros SetFont et WriteStr correspondent à celles de DoorsOS
(Il y a peut-être une ou deux faurtes de frappe qd j'ai recopié de ma TI au PC... Mais, sur la TI, ca marche !)

Ensuite, je tape dans l'écran HOME ceci, pour compiler le prog :
zz__as92aspatch("include aeffacerhello")
J'ai à ce moment là noté la mémoire RAM qu'il me restait de libre via l'écran MEM => j'ai obtenu 165716 octets.

J'appuie sur ENTER (logique :-))...
La compilation se fait sans problème...

Création des fichiers aeffaceroutpub (195 octets) et as92ret (4 octets)...
A ce moment là, j'efface la ligne qui s'est rajouté dans l'écran HOME (pour ne pas fausser les données de l'historique des entrées)... Et je vais dans l'écran mem => 164480 octets de libre...
(Précison : le programme créé fonctionne sans pb !)

J'ai donc perdu 1236 octets...
Dans ces 1236 octets, 199 ont servi pour les deux variables crées par AS92...
Rien n'a du servir pour l'écran HOME....

=> 1037 octets sont "parti" sans laisser de traces....

Si je relances la compilation, je n'ai plus aucune perte de mémoire....
=> Cette perte de mémoire ne se fait qu'à la première compilation...
Je n'ai pas pu reproduire ce truc sur VTI, mais il n'avait que 100ko de RAM libre, et non pas plus de 165ko....


=> Je vois pas trop d'où ça peut venir..........
Si jamais c'est un truc con auquel je n'ai pas pensé, ben, dites le moi... Comme ça, je me coucherai moins con ce soir :-)



Avant de changer le nbr max de HANDLEs dans le patch d'extended, j'avais plusieurs pertes de mémoire successives, pour les 3-4-ou 5 premières compilations... (Un des cas que j'ai noté est le suivant : 165698 => 158980 => 154350 => 150222 => 150222 : plus de pertes)...
Je sais pas si ça peut aider quelqu'un.... je l'espère...



PS: je précise que je ne suis pas fou : étant donné que je n'ai qu'un petit forfait internet, j'ai écrit tout ça hors-ligne, pour pouvoir prendre mon temps, et le faire du mieux possible...
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

14

il marche pas chez vous TeOS sur 2.05 ?
moi g fais tourner SMA dessus avec confus

15

Ah ?
Ce pb est connu est vient d'UniversalOS ?
Et bien.... non... je ne vais pas repasser à DoorsOS !

Vivement la future version UniverslOS...
(Au fait, y'a pas une bêta de la version 1.31 qui traine quelque part ?)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

16

ok smile

17

Pollux> OK...
Mais, dans la doc de UOS, JM dis qu'il n'a pas implémenté la libération auto des blocs mémoire, parce qu'i lne sait pas trop comment faire...
Il dit que l'algo de Doorsos est imparfait ....
JM : ça serait cool que tu implémete cette foncionnalité ...
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

18

ok...
Cela dit, il y a des cas où le programmeur oublie certains trucs con dans son prog (comme libérer la mem)...
Dans de tels cas, ça serait pas mal qu'une sécurité supplémentaire d'UOS s'en occupe...
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

19

oui squale y'en a une, tu veux, je l'ai....

20

Iceman> tu as la bêta de Uos ?
Si c'est pour 92+, ça m'interesse......
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

21

par contre, vu que le serveur mail de wanadoo est mort depuis ce soir, tu peux l'envoyer à master_sql@inorbit.com
(vive les "adresses de secrous" :-)
ou alors, ICQ....
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

22

rdv ce soir a 19heures sur icq squalou

23

19h pas possible : c l'heure à laquelle je bouffe...
par contre, vers 21h... ou maintenant, vu que tu y es :-)


PS: comme pseudo, je préfère squale :-)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

24

oki !!