HibText est mort, Vive HibVew - Page 2

comme si pointeur n'étais pas bon, ca affiche n'importe quoi, ca peut prendre tout l'ecran, ou rien afficher

mais j'ai pas de bonnes nouvelles...
j'ai fais tout mes test sur vti sur 92, 89, rom 2.05, 2.08. ca marche bien. pensant que ca suffirait
je viens de tester avec ma vrai 89, ca plante royalement...
je comprend pas
pas tout du tout
faut que je refasse tout mes tests et debuggage sur ma vrai Ti.... #snif#
le hibview que je fournis n'est donc absolument pas stable....

heu ... quel pointeur ? tu as un pointeur charwidth de déclaré ? ou un handle hDl ?

je pensait au pointeur de la chaine de caractere

j'ai ni charwidth, ni hdl..., il faut ?

c quoi ces pointeurs ???

pke c utilisé par TinyX en interne ...

bon, j'ai essayé de tester hibview hier sur ma 92+ HW2 AMS 2.08 PreOS 0.64 et ca a crashé direct, pas de message d'erreur, rien. Tellement violent que esc+on ne marche pas (pas plus que 2nd+hand+< )

Je vais télécharger les sources pour voir.

pourquoi y'a t-il une si grande différence entre vti et les real Ti ?
ca fait ***** qd meme

perso, je fais les petits tests sur vti et quand j'ai fais suffisamment de modifs, je teste sur real ti

edit: faudrait que tu mettes à jour les parties de ton site qui font référence à Hibtext et à Textrider.

moi c'est l'inverse j'ai des progs qui marchent très bien sur real TI et mal sur VTI

pourquoi y'a t-il une si grande différence entre vti et les real Ti ? ca fait ***** qd meme

VTI emule une HW1 et donc il peut y avoir de incompatibilité avec HW2. c'est en général le principal problème de VTI mais il y en a d'autres

Moi, il marche inpec sur ma TI89

Pas de probleme d'affichage, de lancement, de compression/decompression....

De plus, je me suis amusé a le recompiler en l'optimisant un peu, gain 10Ko!!!!!!!!

Je passe de 51588 octets (environ) a 41509 octets... Et sans toucher à une seule fonctionnalitée

Avez-vous pensé à la protection de la RAM par l'interruption 7? Car le programme doit être alloué autre part et donc ça plante essaye de rajouter EXECUTE_IN_GHOST_SPACE on c'est jamais.

Pour hibou:

Pour optimiser ton code, quand tu fait des (CALCULATOR? xxx1: xxx2), remplace par:

#if (TI89)
xxx2
#else
xxx1
#endif

car ca le calcul a la compile et non a l'execution

Regarde key.h ou texts.h, tu peut gagner facile 4Ko

De plus, avec certains paramètres de compile, j'en gagne 5 Ko de plus

Jarode a écrit :
Pour optimiser ton code, quand tu fait des (CALCULATOR? xxx1: xxx2), remplace par:

#if (TI89)
xxx2
#else
xxx1
#endif
car ca le calcul a la compile et non a l'execution

Il me semble qu'il suffit de ne compiler que pour un modèle pour que même les expressions du type (CALCULATOR?xxx1:xxx2) soient optimisées.

j'ai fais le test et c comme ca qu'il faut faire
le gain est enorme

Et c'est quoi, sinon, les paramètres de compilation que tu as passés pour avoir ce gain en taille ?

passage de o3 en os

oui en effet hibview est le genre de programme qu'il vaut mieux compiler en Os.

Tout compte fais, je ne compile que en Os mais l'executable fais 47129 octets au final. Ce qui est deja pas mal.

De plus, g recompilé complib est j'ai gagné un peu...


A savoir, j'utilise GCC 3.3, c ce qui me permet d'avoir une compilation meilleur

il n'est pas compatible on-calc ?
(c juste une question, pas un reproche ni rien : je n'en sais absolument rien (et g la flemme de lire le readme ))

arf c'est vrai que ca m'arrangerai que ce soit compatible on-calc vu que tish devrait l'être

GCC 3.3 faisait des executables plus gros d'apres Vertyos ...

Ben ça dépend des sources en fait.
Mais GCC 3.3 comportait quelques bugs. Kevin les a corrigés, mais peut-être qu'il y en encore quelques-un.

j'ai une version assez recente de GCC 3.3. Car je me souviens l'avoir telechargé plusieurs fois (du a des mises a jours)

De plus, Hibtext marche tres bien donc GCC 3.3 travail bien je pense

Excellent travail, hibou. Personnellement, ce qui m'intéresse le plus est CompLib.
Pour la taille énorme, je vous avais tous avertis qu'il vaut mieux utiliser DrawStr plutôt que de tout recoder comme le fait TinyX.
Quant à Uther et sa version kernel, il commence à me saouler. Uther, si ton shell est en mode kernel, l'anti-crash kernel de PreOs sera de toute façon actif, que le viewer utilisé soit en mode kernel ou pas. Ça ne change strictement rien pour toi.

geogeo
a écrit : Avez-vous pensé à la protection de la RAM par l'interruption 7? Car le programme doit être alloué autre part et donc ça plante essaye de rajouter EXECUTE_IN_GHOST_SPACE on c'est jamais.

Aucun rapport. Déjà, l'auto-int 7 n'a aucun rapport avec EXECUTE_IN_GHOST_SPACE, et puis les plantages dus à un EXECUTE_IN_GHOST_SPACE manquant sont bien particuliers (barre noire sans texte). S'il y a un #define à rajouter, ça serait plutôt SET_FILE_IN_USE_BIT.

jackiechan
a écrit : Mais GCC 3.3 comportait quelques bugs. Kevin les a corrigés, mais peut-être qu'il y en encore quelques-un.

Mais il y en a pas mal qui concernent aussi GCC 3.2.1, et je n'ai corrigé que GCC 3.3, donc il vaut mieux utiliser GCC 3.3.

A je pensais pouvoir aider merci Kevin de cette précision mais je trouve génial complib car le nostub c'est mieux des fois quand même.

Pour une fois je suis d'accord avec Kevin: un shell en mode Kernel c'est un peu paradoxal je trouve...

Je suis d'accord avec toi même le principal repproche que je ferait au nostub c'est les librairie dynamique car c'est très utile mais cela le kernel peut les gérer de façon correcte.

mmm, chsui obligé de la faire celle là :
[provocation]C'est aussi possible en _nostub : il suffit d'utiliser les DLL [/provocation]

Enfin, hors mis cela, Ximoon -> je vois vraiment pas pourquoi un shell en mode kernel serait paradoxal...le but du shell n'est pas uniquement la protection anti-crash, mais aussi (et surtout il me semble) la gestion de fichiers...

Tu me diras, pour moi, un shell c'est déjà inutile par définition
Mais honnêtement qu'est-ce qui peut justifier qu'un shell soit en kernel? A la base je suis plutôt pro-kernel mais là je ne vois pas... Enfn il fait comme il veut en fait...

Ce que je veux dire, c'est que kernel ou _nostub, c'est a peu près pareil... Je comprends pas pourquoi tu dis que ce serait une abération en kernel... il me semble que ça n'a rien de genant (et je serais plutot pro _nostub... )

En ce qui concerne l'utilité du shell, ben perso, je l'utilise très souvent : compression, exécution de programmes, cachage de fichiers, vérouillage calc, etc...