flib joue à cache cache - Page 1

slt,
J'ai décidé de programmer avec flib pour completer le basic seulement je rencontre un problème très embêtant.
Je commence par transférer les progs (flib,flib2) sur ma calculatrice (v200). Jusque là tout va bien.
Je decide alors d'utiliser une commande de flib dans un programme, je l'exécute, aucun problème. J'essaye une deuxième et là damnation, il me dit que l'application est en cours d'utilisation où un truc du genre.
Je vais donc voir dans varlink si le prog est toujours là et je me rend compte qu'il ne reste plus que flib2 pourtant la memoire utilisée correspond à la taille de flib et flib2.
Je pars alors à la recherche de flib et finalement, le seul moyen pour le retrouver, c'est de reinitialiser toute la mémoire.
Et même après ça le programme est toujours là, seulement on peut le voir dans le menu varlink et le supprimer manuellement.

Est ce que c'est qu'à moi que ça arrive où chez vous aussi flib fait .....? Vous sauriez pas pourquoi?
NB: j'ai la rom 2.09
Merci.

ça arrive qd un prog asm est buggé, ça... essaye plutôt vertel3 de vertyos

Ça doit être la fonctionnalité SET_FILE_IN_USE_BIT de TIGCC qui ne fait pas la bonne chose.
Je vais analyser ce problème cet après-midi (après avoir bien dormi). Si je réussis à isoler le bogue (ce qui est probable), je te ferai parvenir des binaires corrigés de FLib aussitôt que possible.

Xehn
: Je decide alors d'utiliser une commande de flib dans un programme, je l'exécute, aucun problème. J'essaye une deuxième et là damnation, il me dit que l'application est en cours d'utilisation où un truc du genre.

Je ne peux pas reproduire ton problème... Quelle commande as-tu essayée? Et as-tu bien pris la dernière version? Sinon, reessaye avec celle-là.

J'ai bien la dernière version de flib. Je l'ai essayée sur vti et je rencontre le même problème mais il apparait mais rapidement. Pour la commande, je ne m'en souvient plus et je ne pense pas que ça ait de l'imortance mais j'ai surement entré un truc du genre clrscr ou pretty...

Et as-tu eu une erreur avec ton pretty? Parce que dans ce cas, c'est normal que ça foire. Ce n'est pas compilé avec ENABLE_ERROR_RETURN, donc à la première erreur, hop, le programme n'est plus utilisable (parce que le bit in-use n'est pas retiré correctement). Je vais te faire parvenir une version compilée avec ENABLE_ERROR_RETURN. À moins que tu ne veuilles la compiler toi-même...

En fait je me doutais que c'était une erreur de...du truc que t'as dit. Sérieusement, j'essaye encore de décrypter ce que tu m'as expliqué .
Mais bon, envoie moi quand même la version recompilée, que je vois ce que ça donne.
Thank you

flib.zip envoyée à l'adresse e-mail de ton profil.

Sur TI 89 j'avais aussi ce type de bug avec Flib.
Enfin pas exactement, mais il était inutilisable après une commande et Flib2 crashait immédiatement qd Flib avait disparu.
La dernière version a corrigé ce bug donc j'ai pas ralé...
Ah, je me demandais un truc sur Flib :
Pourquoi M LEIBER il a pas mis de commande de Buffer dans Flib?

nop, ça c'est une feature de Vertel

Ouais mais Vertel il fait pas les NVG, les Map et les Komp!!

Ouep, c'est vrai. J'ai viré les nvg vu qu'en statique je trouve que ça sert à rien (et puis c'est facile à reproduire avec des cyclepic), map se fait ac des listes, et komp y'a pas ça prend trop de place.

ué, mais bon, cyclepic... c pire que les 8 nvg sur HW2

Bah tu fais une alternance ac vertel alors, et en utilisant les buffers au besoin, justement

Les listes c'est plus lent que les map et les cyclepic c'est affreux, c pas sur tout l'écran, et en plus on peut pas faire les animations partielles sur nvg avec les listes, ce que map de M LEIBER permet de faire en gray...
Le truc c'est que 3 lib de 8 ko ça commence à faire beucoup !

bah... sinon, tu remplace Komp par XPack, tu prend Vertel et FLib1 (je crois que c elle qui contient map), ça te fait 2*8Ko+1 ou 2 Ko pour XPack.

Pourquoi pas PepZip?

c'set atrocement lent, pepzip

Kevin>pasque je connais pas

C'est si utile que ça map ? Faudra que je regarde ce que ça fait exactement

J'utilise map pour faire les animations sur un plan en NVG, c'est beau et rapide, et flib attend l'appuit sur une touche en animant un NVG : très utile pour les menus bien dessinés !
Sinon map je m'en sers aussi pour les fonds du RPG que je prépare (je vais peut-être remplacer ces commandes-là par des trucs du genre vertel("pict","#matrice",...) si c'est plus rapide et comme y'a le buffer en plus... ).

Sinon pour PepZip et Xpack:
est-ce que les ratio sont honnêtes ?

Et est-ce que c'est compatible 2.09 (je veux pas de pb de Kernel !!)
Et enfin si la compression est lente c'est pas très grave du moment qu'ils décompressent vite...
Euh aussi je veux bien les liens ou un site pr les DL.

Niveau compression, ça à rien à voir avec Komp
C plus ou moins du niveau du ppg (autour de 50, pour dl, ça doit probablement se trouver kkpart sur http://www.ticalc.org

Pour XPak, va plutôt sur mon site (cf signature), la dernière version n'est pas encore sur ticalc...

Merci beaucoup !
J'essaye et je vous dirai...

Me revoila!

Alors PepZip je ne l'ai pas essayé : il fait 8,7 ko ce qui est trop dans mon cas!

Et j'ai testé Xpack. Il va à la vitesse annoncé 3ko/s en compression ( assez lent) , mais 80 Ko/s en décompression (instantané!!!!).
Comme j'ai pas besoin de compresser fréquement c bon!
Et pour la taille, il fait 4,175 octets pour le logiciel qui compresse, et 1,435 octets pour celui qui décompresse.

Je vais dc passer à Xpack et ciao Flib2...

8.7Ko pour PepZip ???
Putain, je m'attendais pas à un truc du genre. Même si le compresseur et le décompresseur sont intégré.

Je ne l'ai pas mis sur TI c'est la taille du fichier pepzip 8,729 octets sur PC dans le Zip de pepzip (oh ça rime...).
Donc ptêt que ça fait moins après.
Pour xpack c les vrai taille mais y'a plein de (dé)compresseur différent suivant ce que tu veux faire... Et puis pepzip est apparement tout automatique : tu lui mets un nom et il se débrouille!!