uView 1.0, XPak 1.0 - Page 2

Si on n'a pas de kernel, c'est le troisième. Et en plus, il me semble que la version kernel ne soit pas compatible avec AMS 2.

Si on n'a pas de kernel, c'est le troisième

Y en a un sur toutes les plateformes, ne sois pas ridicule Par contre si c pas compatible AMS 2 l'argument est recevable.

Moi je vois une première adaptation et 3 repompes

Kevin Kofler
: Si on n'a pas de kernel, c'est le troisième. Et en plus, il me semble que la version kernel ne soit pas compatible avec AMS 2.

hmmm je t'ai déjà vu dire ce genre de trucs plusieurs fois, on dirait plutôt 'il me semble que la version kernel n'est pas compatible', ou 'il ne me semble pas que la version kernel soit compatible'

D'un autre coté si tu veux corriger des fautes, penche toi sur le cas croustx y'a déjà nettement plus de boulot

Hmmm je crois que ça n'est pas le bon topic pour te demander si tu veux qu'il poste encore plus, fier de sa nouvelle orthographe...

Tiens, comme c bizarre. C dommage que le moteur de recherche de ticalc soit mort, j'aurais bien voulus vérifier^^

bon g testé les 2, mes impressions
bah deja, j'adore uview et sa barre de defilement, ca plante bien moins que hibview, par contre une fenetre d'exploration du genre hibview/tictex serait amha un peu mieux
xpack compresse mieux que zlib, mais un explorateur pour compresser serait bien plus pratique, d'ailleurs ca serait pas mal qu'on puisse compresser à partir d'uview
j'ai remarqué un bug, sur ma ti92+ ams 2.09, si je compresse des fichiers archivés, bah xpack les compresse, mais 2 fichiers sur 3 font planté la calto avec uview et impossible de les decompresser (plantage aussi), mais sinon aucun bug.
Bref je trouve que la combinaison uview/xpack est bien plus performante que hibview/ziplib, bref, n'hésitez pas, changez

d3us
: xpack compresse mieux que xlib

j'ai la meme genre de bug qu'au ./38, mais avec une ti89 AMS 2.05 avec preos

Dans ce cas l'intégration du compresseur à mon shell attendra

J'ai paumé mon câble donc pour l'instant je peux pas tester. J'ai bien l'impression que le compresseur inclus dans les .89g est corrompu, mais normalement il y a (paraît-il) une version correcte dans le zip. Et tout a marché parfaitement pdt les concours (sur ma calc comme sur celles de plein de monde), sans que j'y retouche depuis.

d3us
: zlib (en plus ct re-marqué après)

bah p-ê que je suis pas revenu ici depuis ... nan !!!!

dans le même post :

Bref je trouve que la combinaison uview/xpack est bien plus performante que hibview/ziplib

pke zlib == ziplib ?

en effet, moi yen a avoir du mal il s'agissait de ziplib

je te le fais pas dire

Moi j'ai une 92+ et j'arrive quasiment pas à decompresser un seul fichier correctement .
Chaque fois le decompression me ramène des variable de type "EXPR" mais je pense que pour la taille du fichier ça doit être bon.
Un truc qui est pas normal aussi ; ça devrait pas ramener un fichier compressé plus grand que l'original.

Idem pour moi (avec une 89 et sans le "quasiment")!

en fait, xpak est plus que buggé (j'ai réussi à foutre en l'air tous les fichiers de ma calto avec ) et uview à qques problèmes pr lire les textes formattés, bref je reviens sur ce que j'ai dit, il vaut mieux utiliser hibview/ziplib

	crle=malloc(256*sizeof(int));
	if (!crle) ER_throwVar(ER_MEMORY);
...
	memset(crle,0,sizeof(crle));

->

	crle=malloc(256*sizeof(int));
	if (!crle) ER_throwVar(ER_MEMORY);
...
	memset(crle,0,256*sizeof(int));

En fait juste avant la release j'avais transformé crle qui était un tableau statique en tableau alloué dynamiquement (donc en pointeur), sans changer le code de réinitialisation Et pour la release, j'avais fait des tests sur VTI, avec une RAM resettée, donc le tableau était qd même à 0... J'ai aussi fait des tests dans des conditions plus réalistes, mais :
* ça ne bugge pas tjs, c'est en fait relativement probable que le fichier généré soit un fichier correct, mais prenant quelques octets en plus (< 10 octets) parce que la compression RLE n'est pas totalement optimale
* dans les cas où ça bugge, ça bugge de manière subtile : ça change juste quelques lettres doubles au milieu du fichier, mais ça ne change ni la taille ni, dans 99% des cas, le type Donc pour mes tests de compression de répertoires, j'ai regardé le début de qques fichiers, j'ai vérifié que c'étaient bien des fichiers texte avec la bonne taille (en principe ce critère est suffisant pour déterminer 80% des bugs de compression), mais je n'ai pas vérifié qu'ils étaient bien tous égaux bit à bit...

Vraiment désolé, j'avais déjà eu un ou deux bug report, mais je n'avais pas réussi à les reproduire jusque là (et pour cause) Et puis je m'étais déjà servi très intensivement de XPak sur ma calc, mais c'était avant que je fasse les qqs optimisations mineures pour la release...


Je vais releaser XPak 1.1, et si j'ai le courage de finir l'ajout du pretty print à uView, je vais releaser une nouvelle version de uView aussi... En attendant, je vous déconseille vivement d'utiliser la compression si vous tenez à vos fichiers

Eh ben ! il était vicieux ce bug !
Errare Humanum Es (orthographe trèèès aproximative )

et c pr quand la release?

C'est du Pollux, donc les temps d'attente se comptent en siècles.

Si y a des gens motivés pour planter leur calc, ils peuvent faire des tests (le multitâche préemptif que j'ai fait est assez casse-gueule, donc il y a peut-être des bugs)

bah après le 16 juin c possible , sinon avant, j'ai le bac qui arrive donc j'ai déjà assez d'hibview qui m'oblige a faire un reset toutes les 3 ou 4 lectures

!up

Si vous voulez tester uView 2.0 "release candidate " (avec prettyprint, gestion des images compressées, conversion ZIP->XPAK) --> mmsg

Pollux
: prettyprint, gestion des images compressées, conversion ZIP->XPAK

en fait le plus chiant ça a surtout été de faire un truc multitâche (enfin, bi-tâche plutôt ) pour permettre le rendu en tâche de fond des expressions... finalement ct pas forcément si utile que ça