Un tout nouveau shell pour TI: sh`L - Page 29

-

Pour la Final version t'aurai vpu l'appeler 1.0! Dommage pour les sources, ca aurait pu interesser du monde et si jamais on a besoin de faire un ajout interessant ,une corection de bug, une adaptation a un nouvel AMS/HW, ... après que tu aie disparu de la communauté les sources seraient indispensables (de toute facon c'est pas grave, tout le monde sera passé a TIM ). et pour les newbie il sufit de prevenir que le code n'est certainement pas optimal dans un commentaire en entete.

-

heu... p'tet pas la version finale.
j'ai trouvé des bugs dans ma lib complib
je sais pas celle que tu utilises : si c'est la premiere que je t'ai passé, y'a le pb d'archivage (que tu as du contourné je pense)
mais sur la version en ligne, y'a des trucs qui ont changé ce qui a fait que ca bug (un copier/collé qui s'est mal passé ) pour les fichiers ayant plus de deux fois le caractere '\0'...

mais bon, tu n'auras qu'a recompiler quand j'aurais fini de debugger

"c'est pas grave, tout le monde sera passé a TIM" t super sur de toi dit donc

y'avais un petit avec. C'était juste une petite provoc gratuite. Je serais flaté que tout le monde passe a TIM mais si j'arrive a le finir avant 2010 ca sera déja bien

Ça te fait combien de versions finales de shl, Orion ?

-

Y'a toujours les problèmes dûs à CompLib ?
(des fois, ca compresse et en décompressant, ca fait n'importe quoi ...)

Tu deverais en distribuer les sources !

Par contre hibou pour complib, il est dispo sur ton site? Et est-ce qu'il permet de compresser des handles? Et est-ce qu'il est très rapide pour décompresser et compresser 7ko?

Oui
Oui (enfin, me semble)
Relativement ... enfin, c'est surement le meilleur compromis vitesse/taille/compression/decompression

Dexter
a écrit : Tu deverais en distribuer les sources !

Entièrement d'accord.
Vive la TICT, qui sort toujours les sources de leurs programmes!

Kevin: Apres, c'est juste une affaire de gout, je suis aussi de cet avis là faut dire que : "Acheteriez vous une voiture avec le capot soudé ?" (RedHat powa)

Non franchement c'est mieux de diffuser les sources et il ne faut pas avoir peur de ceux qui modifie les sources pour mettre leurs nom à la place. Personnelement je trouve plus interessant de diffuser les sources avec le progs et tout le monde devrait en faire autant car cela permet de mettre à jours le programme si il y a une modifications de la ROM ou une corrections de librairies...

Encore sur calculatrice, ce n'est pas bien grave mais sur PC, je pense que c'est une vraie attitude à avoir !

geogeo>oui, la version "buggée" est dispo sur mon site, et elle permet de compresser des handle ou variable dans un handle ou variable (4 possibilités)
Et est-ce qu'il est très rapide pour décompresser et compresser 7ko? c'et du huffmann donc c'est asez rapide (7ko en environ 1/2 s je pense). Mais mon algo n'est pas optimisé, je recherche d'abord a ce que ca ne bugge pas

De toute facon, comme je disais plus haut, huffman est tres certainement le meilleur comprois possible sur une calculatrice

1/2, c'est bien pour ce que je veut faire, merci hibou. Mais quelles sont les fonctions buggés et c'est quoi ces bugs?

Je pense que c'est le bug que je soulevais #848

cf #844
ca me fais penser que j'ai des questions a poser pour les programmeurs... je vais crée un topic dans projet

nEUrOne a écrit :
faut dire que : "Acheteriez vous une voiture avec le capot soudé ?" (RedHat powa)

Nuance : Accepteriez-vous une voiture si on vous l'offrait avec le capot soudé ?
La réponse change, non ?

mais nan, ca doit revenir au même ... il le faut !

-

C'est marrant, avec Orion les bugs viennent toujours des programmes des autres

j'arrive pas a comprendre qd se passe ce bug dont il parle. C'est vraiment chiant les gens qui mettent des bouts de phrases bout a bout sans reelle transition

je suppose a priori que c'est le pb d'archivage... mais vu les infos, je peux pas vraiment dire
si il a utilisé les outils de hibview pour compresser, c'est sur que ca part en couille...

jackie>hibview est buggé, c'est un fait... mais les deux questions ne me concernent pas

-

1. Déjà si tu n'utilisais pas que le code des autres...
2.

Orion_ a écrit :
>- Il faudrait pouvoir faire un truc contre les fichiers temporaires ! je deteste ce 0001 !!! sa c parceque tu lance shL depuis un programme basic, c un bug d'ams , pas de shL

Kevin Kofler a écrit :
Alors là pas du tout! Ce n'est pas un bogue d'AMS! Si tu utilisais les fonctions d'AMS pour lire les répertoires, ces répertoires n'apparaîtraient pas! C'est ton code sale d'accès direct à la VAT qui bogue. Le TICT Explorer n'a pas ce bogue.

Orion_ a écrit :
ah ? alors les exemples de code fourni par la doc de TIGCC sont sale
interessant

Déjà tu utilises le code de TIGCC, et de plus, par la suite, tu as avoué t'être trompé dans les paramètres passés à SymFindFirst...

Orion_ a écrit :
> - La version téléchargeable a une fuite de mémoire (~2ko)
Alors la je vois pas, parceque je fait bien gaffe a toute les allocation et les déallocation sa viens pas de moi, (soit TinyX, soit complib) ...

erf, c'etait bien les tx_LoadFont qui merdait
la j'ai mis un simple tX_LoadFont(); et y'a plus de fuite de mémoire.

Orion_ a écrit :
mais, j'ai du tout abandonner, parcequ'il y a un hic complib ne permet pas de connaitre le type de fichier compressé :-/

hibou
a écrit : ben c'est ca qu'il fallait utiliser : get_type_initial_var(type)

Orion_ a écrit :
> - J'arrive pas à lancer un texte sur ma calculatrice (HW1), que ce soit un texte zippé ou non, j'ai bien HibText ...
la non plus je vois pas, c peut etre HibText qui n'est pas compatible HW1, (je vois que sa)

je crois que j'ai release shL v0.4 un peu vite
finalement sa a permit de mettre a jours des bug et des améliorations

sh`L 0.5 final: Public Release:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
-Modification du plugin de lecture de fichier texte avec l'utilisation de HibView.
(Lecture des fichiers TXT et maintenant ZIP contenant du texte compréssé !!)
-Correction d'un bug qui permettait de compresser un dossier. (n'importe koi )

En l'occurence, pour TinyX, le bug venait plus de l'utilisation du code, mais aussi du fait que les routines actuelles ne sont pas bien pour l'utilisateur ...

Oui, c'est vrai, j'avoue
Mais ça m'énerve quand même cette attitude de rejeter les bugs sur les prog des autres.