Vertel 3 - Page 3

Bah... sinon, tu peut jouer sur le nom de variable. Si le nom commence par une certaine lettre ou un truc du genre.

Je profite encore de ce topic, mais ne serait-il pas possible de faire une fonction qui renvoie la chaine binaire genre vertel("bin",145,"","retr","g") renverait {1,0,0,1,0,0,0,1} et si c'était une liste de les mettre bout-à-bout ?

ça, non
trop spécifique.

Ouais, mais ca permetrait de coder des informations en bits et non obligatoirement en octets

Voilà, je viens d'uploader la ß5, avec donc une nouvelle fonction "sequ". Un de ces jours faudra que je release la source aussi, je commence à avoir la flemme de mettre la librairie à jour...

J'en connais un qui va être content et qui va s'empressé de la foutre en l'air

Surement pas ^^

Je voudrais pas trop m'incruster ds cet éternel conflit entre Flib et vertel mais pour un souci de compatibilité, vous croyez que ca ralentirait bcp un prog si je faisais appel à une fonction (ou un otre prog) qui appellerait à son tour la librairie (que l'utilisateur avisé pourrait choisir si je fais deux versions de ce ss prog) ???
en gros :
prgm(a)
if a=1 then
main\flib("...:...")
ou (pr toi Vertyos)
main\vertel("...") (je connais pas trop vertel !)
....
endif
endprgm
PS: ya pas moyen de faire un label dynamique avec indirection ?

Pour vertyos : g regardé tes fonctions en vitesse (ya des trucs mieux que flib) mais g pas fais gaffe : ya un truc comme Komp et Hide ?
Pour Kevin (le povre tt le monde lui en veut y me fait penser à un gars de mon lycée (spé maths bien sur!)...) : je sais que faire des versions de Flib différentes serait contraire à la volonté de François Leiber mais faut avouer que la musique et les high-scores sont pas très utilisés dc si on pouvait les virer ds une version light ?!!

Bah dans ce cas, utilise vertel, c'est moins compliqué que de retoucher flib

Oui mais le truc c'est que Flib est bcp bcp plus répandu et plus utilisé (du moins de ce que j'ai vu) et g pas envie de me retaper tous les prgm que j'ai qui utilisent flib.
Par contre je voudrais que les gens qui ne veulent pas Flib puissent utiliser mon prog comme les otres !!

Il n'y a pas komp. En revanche, tu peut utilisé XPack ou PepZip qui sont bien plus efficace que Komp en compression (et bien plus rapide en décompression, je crois).

Hide existe.

Si c un explorateur que tu fait, je te conseil vivement Vertel. En un seul appel à Vertel, tu peut récupérer et afficher les dossiers, les fichiers, leur taille et leur type.

C'est pas un explorateur, c'est juste un prog classic cours/mini progs....
Pour la compression, je me doutais qu'il fallait utiliser qqch comme pepzip.
Sinon, pour la rapidité, c'est vraiment plus lent si je fais appel à un ss prog ????

a priori oui, mais le mieux c'est que tu fasses des essais toi même ^^

Si tu veux un prog rapide il vaut mieux utiliser vertel (qui en plus est toujours mis à jour) :

• plus rapide
• moins lourd (8Ko pour vertel et 16 Ko pour flib (2 libs))

le seul défaut de vertel (à mon avis) c'est la synthaxe (celle de flib est plus légère et plus simple)

tommybart2000
: ya un truc comme Komp et Hide ?

Il y a hide, mais pas komp : c'est une fonction qui prend énormément de place et qui est impossible à implémenter sans dépasser la limite des 8ko que je ne veux pas franchir

et c'est peut-être mieux : tu peux utiliser XPAK, qui va être également utilisable par les programmes kernel ^^

C'est facile de faire une version "light" de FLib! FLib est sous GPL maintenant, donc il suffit de virer (ou mettre entre #if 0 et #endif) quelques lignes de la source et de recompiler, et tu as parfaitement le droit de distribuer le résultat.

Attention, il s'agit d'une version FLib modifier par mes soins, veuillez absolument utilisé la version fournit

Kevin, je te rapel que c une lib DYNAMIQUE, pas statique, tu peut pas faire 50 versions différentes pour les 50 programmes qui l'utilise

Kevin Kofler
: C'est facile de faire une version "light" de FLib! FLib est sous GPL maintenant, donc il suffit de virer (ou mettre entre #if 0 et #endif) quelques lignes de la source et de recompiler, et tu as parfaitement le droit de distribuer le résultat.

Merci Kevin pour tes précisions mais je suis pas un pro de la recompilation.
Faudrait déja que je charge les outils de la TIGCC et que j'essaye de comprendre !
Je te disais ça pasque il me semble que tu maintenais cette lib à jour depuis que François nous a quitté (lol) !

bah si, comme il aura plein de conflits de version, et il pourra dire que les libs dynamique c'est de la merde

L'ennuie avec les versions personnalisés c'est que si chacun se ramène avec sa librairies c'est plus une lib dynamique
Si l'utilisateur a flib et flib2 (version lourde : 16 Ko) et qu'il veux utiliser son programme il devront rajouter en plus du prog la version "light" de flib

Donc il vaut mieux garder flib tel quel même si on n'utilise pas toutes les fonctions.
(Par contre il n'est pas interdit de rajouter des fonctions est de créé une nouvelle version de flib pour tous les progs )

tommybart2000
: Je te disais ça pasque il me semble que tu maintenais cette lib à jour depuis que François nous a quitté (lol) !

Je fais mon possible, mais j'ai été très occupé avec les projets de compatibilité TI-89 Titanium (cf. Ti-Gen).

./82 > exactement

Hors sujet : pour les labels avec indirections, ya pas moyen ?
Je suis obligé de me faire un if elseif..... ???

Si bien sur ca marche :

"ab"->nomlab
Goto #(nomlab)
...
Lbl ab
...

ah merci !
Il me semblait avoir essayé en vain ?!!
Arf fait bon se remettre un peu à la prog (au basic lol) !!!!!

Dommage que je n'ai pas participé au sujet ; j'aurai profité pour ramener sur le tapis la mis-à-jour de la fonction
'test' pour qu'elle prenne en compte tout les opérateurs de comparaison en particulier '<>' car à ma connaissance seul sont supportés '=' , '>' et '<'.

Vertyos -> C'est bien d'avoir crée une fonction "sequ" pour générer des listes.
Je l'ai pas encore testé mais puisque tu dit ça doit être forcément plus rapide qu'en basic.
Rassure moi :
Est plus rapide de générer une liste avec 'sequ' que de charger une liste identique déjà créee avec l'indirection interne ?
Parceque si ce n'est pas le cas , il serait peut-être plus intéressant de faire un autre type d'argument liste
c'est à dire une chaîne de caractère commençant par un Tag particulier suivi de ces arguments. Un truc du style "$1,3,5"

Bien sure cela ne serait envisageable que dans la mésure où l'on gagnerait en vitesse.

Vertyos > Comme je pense que ma première proposition va peut-être tomber à l'eau j'en fait une autre.
Vue que l'utilisation de la fonction 'sequ' est souvent suivie de 'load' ; pourquoi ne pas mettre un 4ème argument facultatif (par défaut ce serait la variable interne #) qui serait le nom de la variable où cette liste serait retournée ?
Parce que je pense que ça alourdirait moins la syntaxe du prog basic et le plus intéressant c'est qu'on pourrait générer en un appel plusieurs listes en faisant simplement :
Vertel("sequ",{0,10,20},{0,30,90},5,{"a","b","c"}) pour générer les 3 listes a, b, c