Fichiers liés séparés - Page 1

voila, mon programme atteint sa limite...65 ko donc je ne peux plus rien rajouter...
j'aimerai savoir comment faire pour séparer les choses...je m'explique...

Programme principal
Sous programme

Comment dire au programme d'acceder au sous programme? Que son acces soit indirect...
Qu'on est obligé d'avoir le programme principal pour lancer le sous prog...

est ce que ça a qqch à voir avec les lib?

c'est très très sombre et je sais pas du tout comment m'y prendre

puissiez vous m'éclairer merci

J'imagine que ce qui prend de la place c'est surtout des données nan?

Il est possible de stocker les données dans des variables externes, mais aussi de créer des librairies (que ce soit en nostub ou en kernel) pour contenir du code en externe...

en fait, j'aimerai séparer l'intro, le programme et licences(en 3 fichiers differents).

les étapes se déroulent comme cela:

programme()>lancer l'intro>lancer la fonction licence(vérifie si le serial de la calto est dans la base de donnée de "licence">retour au programme

car là, c'est tout en un bloc...
et je peux plus avancer sans faire d'ordre ca je dépasse les 65k

Ximoon :
J'imagine que ce qui prend de la place c'est surtout des données nan?

pr la licence, pas pour l'instant mais pour l'intro oui
mais c'set quand même le prog principal le + gros
l'intro comprend que des données pratiquement..

n'y a t il pas alors? de fonction comme

prgrm"nom du prog"

où cette commande lance un prog à partir d'un prog???

pas facile en C de lancer un autre programme...
et ça ne se passe pas comme en BASIC : les variables ne sont pas partagées, par exemple

En kernel, ça se fait assez facilement.

??? qu'est ce que le kernel??? un langage de prog?

Pardon, en mode kernel.
Le kernel est un programme qui s'exécute sur la TI et qui permet d'étendre les possibilités de tes programmes (utilisation de librairies dynamiques, RAM_CALL, ...) qui contient quelques routines qui simplifient la vie du programmeur.

DoorsOs est un exemple de kernel qui est très connu.
Le plus à jour et le plus performant est actuellement PreOs.

Je me permettrai d'ajouter (sans vouloir lancer un débat interminable) que le kernel souffre des casseroles d'utilisation ancienne de hacks extrêmement sales, qui sont cassés à chaque changement majeur dans les versions d'AMS, et que les utilisateurs disposant d'un kernel sur leur calculatrice sont minoritaires.

Peut-être qu'avant de splitter ton programme, tu devrais l'optimiser (à commencer par utiliser des options de compilation optimisée - voir à ce sujet un topic récent nommé "optimization" sur le Forum International de yAronet).

Et (au risque de me répéter) il devrait pouvoir suffire d'externaliser les données sans séparer le code lui-même en plusieurs exécutables, ce qui est infiniment plus simple à tout point de vue.

En plus, probablement.

Je me permettrai d'ajouter (sans vouloir lancer un débat interminable) que le kernel souffre des casseroles d'utilisation ancienne de hacks extrêmement sales, qui sont cassés à chaque changement majeur dans les versions d'AMS,

Je me permettrais de repondre (sans vouloir relancer un débat interminable) que les ttstart (Les lanceurs de programmes nostub) souffrent des memes problemes,a savoir des hacks extrêmement sales, qui sont cassés à chaque changement majeur dans les versions d'AMS (Au passage, je rappelle que tstart ne peut pas supporter les programmes kernel-based - encore une erreur de ta part- puisqu'il ne rajoute pas le twin dans la VAT, et c'est necessaire pour les faire fonctionner - meme si j'ai du rajouter du code pour que ca marche un peu - mais ce n'est pas garanti, et je peux faire des programmes kernels, 100% conformes, qui plantent dans ces cas la) : AMS 2.07 ou AMS 3.00 en sont de parfait exemples (D'ailleurs il a fallu recompiler ou patcher les programmes nostub, mais pas les programmes kernels - sauf rare exceptions).
Tous les programmes kernels un minimum recent n'utilise que des appels documentes, au contraire des _nostub (et ne me parle pas des programmes datant d'AMS 1.xx, merci) - je ne parle pas de tes ajouts, mais des startup code de tigcc, de ttstart, et j'en passe).

Ca serait mieux si tu répondais des choses vraies. Je veux dire, multiples fautes:
* ttpack != lanceurs de programmes "nostub" (on dit AMS native, et ces lanceurs s'appellent les pstaters / ttstart);
* ttstart est censé supporter également les programmes kernel-based (qui sont minoritaires, encore une fois).
* un changement AMS correspond en général à un changement HW (cf AMS 3.00 pour la Titanium), donc il n'y a pas que l'OS qui breake (le plus gros problème sur la Titanium est la disparition du ghost space).

Au moins, on ne réinvente pas la roue (filelib...), et on n'utilise que rarement les variables du système (il y a le cas particulier de la variable de l'APD - pour contourner un bug du système, contrairement à ce que font certains programmes kernel-based qui utilisent les variables systèmes n'importe comment sans bonne raison)...

On peut éviter le troll svp ?

Mal parti: l'edit du post de PpHd en rajoute. Je ne peux pas laisser passer des erreurs pareilles:
> D'ailleurs il a fallu recompiler ou patcher les programmes nostub, mais pas les programmes kernels
Grossièrement faux. En plus, tu te fous de moi, car je t'ai obligé à le faire savoir sur ticalc (Solar Striker, entre autres, utilise les fonts n'importe comment - comme d'habitude - et faisait n'importe quoi sur Titanium avant qu'il soit modifié). Tu connais la méthode sur laquelle on s'est mis d'accord, et qui est un des rares trucs spéciaux à marcher convenablement sur PedroM...
Certains programmes kernel-based ont des versions AMS 1.xx et AMS 2.xx bien séparées (ils ont dû être portés - modification du code, patch et recompilation - vers AMS 2.xx).

Pourquoi ttstart ne supporterait-il pas les programmer kernel-based ? A une époque, il a justement fallu changer la façon dont la mémoire est allouée, pour que les programmes kernel-based ne fassent pas n'importe quoi. Si ça ne marche pas et que personne ne me le dit, je ne peux pas le deviner.


> Tous les programmes kernels un minimum recent n'utilise que des appels documentes, au contraire des _nostub.
Si tu fais référence à mes ajouts (address / value hacks) à TIGCCLIB, sache que d'une, ils ne sont pas encore intégrés - ce sont les derniers pending updates - et que de deux, ils ne sont utilisés que sur des versions d'AMS qui n'évoluent plus, et où ils ont été testés.

Même remarque que #15, mais sans la question. Fin du troll, retour au sujet, si ça vous amuse encore le kernel/_nostub y'a d'autres topics pour ça (ou bien les mini-messages, vu que ça n'interesse quasiment plus personne).

Soit, on en restera donc là. J'aimerais juste savoir pourquoi il prétend que ttstart ne supporte pas les programmes kernel-based.

"On en restera donc là", encore heureux vu que t'as pas pu t'empecher de continuer à troller malgré le post de Ximoon... Pour tout ce qui manque, que ce soit savoir pourquoi il prétend que ttstart ne supporte pas je sais pas quoi ou autre chose, tu règles ça ailleurs.

Vertyos: PpHd a fait au moins un double edit de son post. Un après le post de Ximoon, qui a déclenché le mien (le timestamp est maintenant effacé). Un autre après mon post et le tien (voir le timestamp).

http://www.yntoo.com/posts.php?s=52004

Tiens jette un coup d'oeil la dessus pour les fichiers externes. (données externes plutot)

Puisqu'il y a un remontage, profitons-en pour signaler que PpHd a tort: Kevin a vérifié que ttstart fonctionnait avec les programmes kernel-based, sous différentes versions de PreOS.

...