v3 - Page 6

petite suggestion pour la fonction text Vertyos:
pourquoi ne pas intégrer le clipping automatique pour cette fonction ?
-le problème se pause lorsqu'on affiche des chaines trop longues sur plusieurs colonnes à l'écran en utilisant les listes séquentielles.
-je sais pas si je me trompe mais en liste sequentielle on ne peut utiliser qu'une fonction de vertel à foison ne peut pas ecrire : vertel({"clip","text"}, {"#a","#b"},{"#c","#d"},"->",{"#e","#f"},{font,"#b"}) en espérant que le texte qui s'affiche soit clippé

; donc les chaines débordent des colonnes si elle sont plus longue!
-La solution TI consiste à les prétraiter avant l'affichage en utilisant seq(left(...)...); ce qui prend du temps si la liste est importante.
-mais si la fonction text de vertel avait un argument MaxLen (indiquant la longueur maxi du text en pixel) tu pourrais appliquer un clip automatique à chaque texte affiché, de sorte qu'il ne dépasse pas le rectangle de longueur maxlen et de largeur FontHeight

M'enfin je pense que ça correspond bien à un cas de figure générale du moment qu'on veut utiliser les listes sequentielles et afficher soit des images ou des chaines sur plusieurs colonnes sans rogner sur les autres colonnes quand les images ou les chaines ne sont pas au même format. Mais c'est surtout vrai pour les chaines ; en générale on utilise des images au format identiques !

Non, je ne pense pas que ses taux seront négatifs, s'il code correctement son RLE, mais ils seront rarement positifs
En tout cas pour compresser un texte, ils reisquent rarement d'être positifs. Quoique, un texte avec des jolis trucs de
| ===============

présentation du genre ===============
|    TITRE

ça, ça augmente le taux de compression

Par contre, pour les images et les progs, je doute que ce soit très efficace...

ben il peut etre negatif si il compresse en RLE quelque soit le nombre de repetition, sachant que sont code est :

TAG + CAR + NB -> 2 Octets

Si tu a dans le texte
00112233445566778899 -> 20 Octets

Compressé :
TAG+2+0 TAG+2+1 TAG+2+3 TAG+2+4 TAG+2+5 TAG+2+6 TAG+2+7 TAG+2+8 TAG+2+9 = 30 Octets

Donc taux de compression négatif...

Mais non...
Vu qu'il peut mélanger RLE et non RLE, bah ça fera 20 octets, vu que dans ce cas il n'utilisera pas RLE.
011111 ça fera 0 +TAG+1+5

voila, le rle c que du bonus
(et sans RLE ca doit pas faire bcp moins ? )
faudrait meme voir si tu ne pourais pas faire des repetitions de plusieurs chars pour que ca soit encore plus efficace

BiHi :
Mais non...
Vu qu'il peut mélanger RLE et non RLE, bah ça fera 20 octets, vu que dans ce cas il n'utilisera pas RLE. 011111 ça fera 0 +TAG+1+5

Bien sur qu'il peut mélanger RLE et /RLE

Mais le pbm c'est qu'il ne faut pas oublier le cas ou utiliser le RLE est moins efficace que si on compresse pas, et c'est ce cas justement que j'ai présenté, Si on compresse en RLE des qu'il y a une répétition sa peut mener a des gain négatif en prenant mon exemple

andoh_wilfried > Heu... Je n'ai comprit qu'à moitié ton post, en gros j'ai l'impression qu'il s'agit encore d'une suggestion de nouvelle option très spécifique à un problème d'utilisateur -> non.
Si je me suis trompé, alors c'est que je n'ai strictement rien comprit au texte. Essaye d'éviter les phrases à ralonge (la ponctuation ça aide à lire), et les fautes d'orthographe.

Godzil > C'est l'utilisateur qui "code" la séquence DATA, en aucun cas un programme qui la génere (enfin si, je ferais surement un exemple pour encoder une variable, mais passons). Donc au "pire", on ne gagne rien, mais il est impossible d'avoir un ratio négatif (à moins de le faire exprès, mais là c'est plus moi que ça regarde )
Ton exemple aurait été vrai dans le cas d'un "vrai" RLE (avec sacrifice d'un octet), mais ici ce n'est qu'une appellation empruntée.

il fqut utiliser le RLE seulement quand il y a au moins une repetition de 5 chars
la on gagne (au pire rien si c un char d'echapement)

Bah voui
Mais bon c'était prévu pour ça à l'origine. Je crois que je suis bon pour le convertisseur var -> vertel make :]

je veux bien le faire en basic
en C, heu avec CC, veux bien essayer mais ca va me lourder vite

Je suis en train de le faire en basic, mais te gene pas

[edit] Ça marche, mais c'est lent
Pas trop grave, vu que c'est pour utiliser une seule fois normalement.

----------------liste sequentielle :
je crois que tu as dit dans un post qu'on ne peut pas utiliser les liste sequentielles et les listes simultannées !
Alors comment fait-on pour afficher des chaines sur plusieurs colonnes, en utilisant les listes sequentielles si on ne pas en même temps utiliser la fonction clip pour empêcher le texte de déborder sans utiliser left() car ça ralenti le prog énormément ?
peut-être devrais-tu prévoir un clipping auto du text à partir d'un arg supplémentaire du genre longueurMaxi_de_chaine_en_pixel !
Sinon une autre proposition plus générale ; tu rajoute une fonction set (len$) qui défini la longueurMaxi_de_chaine_en_pixel ; ensuite tu l'utilises pour tronquer tous les appels e la fonction "text"
----------------- "retr"
exemple: vertel("list","","retr","fold",mode)
permet de retourner une liste, un nombre ou une chaine;
peut-être pourrais-tu nous laisser récupérer un élément quelconque de la liste et pas uniquement le 1er ou toute la liste (mode={0,1,2,3.....}
ça pourrait être très utile remplacer les fonctions left,right,mid du TIOS pour traiter les listes surtout lorsqu'elles sont longues ! En plus on aurait l'avantage de ne pas sortir de vertel !
ça donnerait un truc du genre
{"a","b","c","d","e","f","g","h","i","j"}->a
vertel("load","#a","","retr","#b",{5,6,7}) => donc b={"e","f","g"}

j'espère avoir été bref et clair !

putain, faut imperativement que je me mette a miam moi ça pourrait vraiment faire une association du tonnerre

andoh_wilfried :
----------------liste sequentielle : je crois que tu as dit dans un post qu'on ne peut pas utiliser les liste sequentielles et les listes simultannées !

Et j'ai dit dans un post plus récent que ça avait été implémenté. Donc si, c'est possible.

Alors comment fait-on pour afficher des chaines sur plusieurs colonnes, en utilisant les listes sequentielles si on ne pas en même temps utiliser la fonction clip pour empêcher le texte de déborder sans utiliser left() car ça ralenti le prog énormément ?
peut-être devrais-tu prévoir un clipping auto du text à partir d'un arg supplémentaire du genre longueurMaxi_de_chaine_en_pixel ! Sinon une autre proposition plus générale ; tu rajoute une fonction set (len$) qui défini la longueurMaxi_de_chaine_en_pixel ; ensuite tu l'utilises pour tronquer tous les appels e la fonction "text"

Rajouter la fonction -> non, j'ai déjà expliqué pourquoi.
Le problème exactement, c'est quoi, que "text" ne tient pas compte des parametres du clipping ? Si c'est le cas alors c'est qu'il doit y avoir un problème à corriger de ce coté là.

----------------- "retr"
exemple: vertel("list","","retr","fold",mode)
permet de retourner une liste, un nombre ou une chaine;
peut-être pourrais-tu nous laisser récupérer un élément quelconque de la liste et pas uniquement le 1er ou toute la liste (mode={0,1,2,3.....}
ça pourrait être très utile remplacer les fonctions left,right,mid du TIOS pour traiter les listes surtout lorsqu'elles sont longues ! En plus on aurait l'avantage de ne pas sortir de vertel !
ça donnerait un truc du genre
{"a","b","c","d","e","f","g","h","i","j"}->a vertel("load","#a","","retr","#b",{5,6,7}) => donc b={"e","f","g"}

Ça pose un problème majeur. Avant d'être "copiées" dans une variable LIST du TiOS, les valeurs sont traitées en interne avec la même structure. Et c'est une structure pas très pratique puisqu'elle est comparable à une liste chainée : on ne peut connaitre un élement qu'en ayant le précedent. D'ailleurs faudrait que je me représente ça mais suivant le sens ou c'est stoqué ça peut devenir carrément compliqué de récuperer une seule variable isolée.
Bon bref, c'est une bonne idée, mais je ne suis pas sûr que ça soit faisable simplement. Je verrais ce que ça donne

j'espère avoir été bref et clair !

Plus sur la fin du post que sur le début

Bon voilà c'est fait (arg )
En fait pour rester compatible avec l'ancien fonctionnement, ça marche comme ça :

vertel("load",{"str1","str2","str3"},"","retr","mystr",1)

Après la partie en vert, les 3 valeurs sont stoquées : la liste interne vaut {"str1","str2","str3"}. Le fait d'utiliser dans l'appel en violet l'argument '1', qui avant signifiait seulement "retourner seulement le dernier élement", veut dire maintenant "retourner l'element n°1 de la liste interne".
Dans cet exemple on a donc exactement le même résultat : mystr prend pour valeur "str1", c'est à dire la valeur n°1 de la liste interne. Par contre il est possible de faire "retr","mystr",2, et dans ce cas mystr contient "str2".
Attention, l'element retourné est effacé de la liste interne, qui vaut donc {"str1","str3"}. Pour récupérer l'element n°2 puis le n°3 il ne faudra donc pas faire "retr","mystr",2 puis "retr","mystr",3, mais deux fois "retr","mystr",2 (de toute façon, Vertel renverait une erreur expliquant que l'élement indiqué n'existe pas dans la liste interne).

Vala

C'est même beaucoup plus pratique que je l'espérait !
alors je peut donc à partir de ton exemple pour récupérer
mid(liste_interne_vertel,3,3) ={"str3","str4","str5"}
écrire ceci :
vertel("load",{"str1","str2","str3","str4","str5","str6"},"","retr","mystr",3+newlist(3))
C'est vraiment top ! Merci ; enfin adieu aux fonctions basic left() ; right() ; mid()
j'ai essayer de faire un explorateur basic mais ça ramait un peu lorsque je devait tronquer la liste des fichiers à afficher ! ça devrait s'améliorer avec cette nouvelle méthode.

Si j'ai une petite idée de ce genre ; je ne manquerai pas de te faire signe!

Bon je t'envoie ça par mini message, j'ai testé rapidement, mais il est possible qu'il y ait des bugs, tu verras. Garde l'ancienne version de coté à tout hazard.

(la notice ne mensionne pas encore ce fonctionnement de "retr" au fait).

Vertyos
marche pas ton lien pour la v3

Peut-être que je m'y prend mal pour utiliser les liste sequencielles et simultanée dans un même appel; je voudrait que tu m'explique comment faire :
J'ai fait un petit Editeur de matrice que je vais peut-être transformer pour modifier les liste et les data.
le problème c'est que je je veux utiliser les fonctions comme ceci:
vertel({ "clip" , "text" };{"#liste_limite_écran_inf_x" , "#matrice_de_chaine" }, { "#liste_limite_écran_inf_y" , "#liste_x" },"->",{ "#liste_limite_écran_sup_x" , "#liste_y" } , { "#liste_limite_écran_sup_y", font }, mode)
En fait je veux que le text à afficher ne dépasse pas limite_écran_sup_x[index] chaque fois que que le tag sequenciel fait varier cette liste.
Donc le tag sequenciel "->" devrait s'appliquer à chacune des 2 listes { "#liste_limite_écran_sup_x" , "#liste_y" }.
normalement en mode simultané les premiers arguments de chaque liste sont pour la fonction clip, et les 2nd pour text !
je pense que je me trompe surement dans la syntaxe ;

Ah oui pour le lien, je me suis planté. Je renvoie.

Bon sinon pour ton problème (illisible, au passage) : il y a une erreur dès la 1ere fonction : tu utilise {"clip","text"}, donc une liste de deux élements non-séquencielle et interruptible (pas de tag "->" ni "|"). En clair, la lecture des listes va s'arreter après avoir lu au maximum 2 élements, quelle que soit la longueur des autres listes.

Deuxième chose : {"#liste1","#liste2"} a exactement le même effet que augment(liste1,liste2) (en bien plus rapide) : ça ne fait que "coller" les listes bout à bout. C'est à dire que tu as d'abotd toutes tes coordonnées de limite d'écran, puis à la suite, le contenu des listes de données. En fait il est impossible "d'alterner" l'utilisation de deux fonctions en un seul appel (ce que tu cherche à faire c'est une grande série de clip / text répetée X fois). Tu n'as pas d'autre choix que de repasser la main au TiOS pour gérer ce cas, même si c'est plus lent

OK je l'ai ! C'est dommage que je puisse pas faire 'grande série de clip / text répetée X fois' !
tu peux me rappeller pourquoi la fonction text ne peut pas être automatiquement clippée !

Théoriquement elle devrait être affectée par "clip" comme toutes les fonctions graphiques à l'exeption de recp. Je vérifierais.

M'enfin vertyos je t'avait une fois demandé si tu pouvais pas ajouter un param à la fonction text pour tronquer le nombre de caractères à afficher de sorte à ne pas depasser une une limite de n caractères. Alors pourquoi c'est pas réalisable ?

J'ai pas dit que c'était pas réalisable, j'ai dit que je n'implémenterais pas ça. C'est trop spécifique à TON problème, donc ça va augmenter la taille de la lib pour rien.

Ah j'oubliais; j'avait une autre question à propos de la fonction 'stat' ; elle ramène un entier dont il faut tester les bits ;
mais pour nous ce qui serait interessant c'est que tu ramène directement la chaine correspondante aux status de la variable:
en gros pour chacun des cas de figures :
Archive => Tag archive
Locked => Tag Lock
Hide => Tag Hide
Hide+Archive => Tag archive & Tag Hide
Hide+Locked => Tag Lock & Tag Hide
variable visible de la ram => chaine vide
je sais pas si ça suffira pour rendre plus rapide un explorateur fait avec vertel; mais c'est vrai que si vertel à toutes les fonctions pour faire cela; avoir un shell de + de 20 Ko sur la calc; ça prend de la place en mémoire .
A propos dans ton exemple de shell avec la V3 commment tu fais pour afficher toutes les caractéristiques des variable d'un répertoire(Nom,Taille,Type,Status) sans sauver 2 fois la liste des fichiers du répertoire en cours :
-Une liste avec le nom du repertoire pour recuperer Taille,Type,Status
Une liste sans le nom du repertoire pour l'affichage du nom de la variable

Non, utiliser un entier dont il faut tester les bits est plus facile et adaptable qu'utiliser des chaînes de caractères.

Voilà, comme a dit BiHi. Sinon pour le "comment j'ai fait", les exemples sont dans le zip, non ?

andoh>lis la doc de FLib, FL explique comment récupérer ça trés facilement et trés rapidement.

Ah heu oui c'est pas bête ça comme remarque. Ça servira surement à certains d'expliquer comment tester un bit sur une valeur.

le problème c'est pas que ça gène de tester des byte ; c'est expliqué dans la notice de vertel ; ça rend le programme lent si on veut faire un explorateur ; je m'excuse vertel mais je ne vois pas beaucoup l'usage qu'on fait de ces flag à part tester leur état (ce qu'on peut tout aussi bienfaire avec une chaine) et les afficher dans un explorateur (pratique les chaines).
D'ailleur je trouve aussi que c'est le cas de la taille des fichiers; ça devrait être une chaine plutôt qu'un entier!
M'enfin à toi de voir lequel serait plus utile aux utilisateurs.