Vertel 3 - Page 2

Il y a aussi d'autres problème avec vertel 3 sur les codes des touches : les alpha + direction sont retournés à -65536 près... (dans vertel 2 c t pas les bons codes mais ils étaient positifs au moins lol!)
Euh aussi la compatibilité descendante ne marche pas par exemple pour les timers avec "sstime",-1,"/" qui n'est plus compris (fo virer le -1 et c bon).

pour le - je suis d'accord, mais les codes sont bons.

En effet, il y avait un problème avec paus, qui retournait un short signé (le type de retour de ngetchx() est "short", alors que ça devrait logiquement être "unsigned short"). Je viens de corriger le problème, la lib est uploadée, disponible au même endroit.

Je ne l'avais jamais recompilée avec TIGCC 0.95, elle a grossi de 2 octets, tant pis.

A propos de la compatibilité descendante, ça fait toujours plaisir de voir que les gens ne lisent jamais la notice, donc je cite :

Le changement du premier chiffre de la version indique un recodage complet de la librairie, qui s'accompagne malheureusement d'un lot d'incompatibilités. Cependant il n'est pas question ici de l'incompatibilité totale qui existait entre les versions 1.xx et 2.xx. Même si cette nouvelle édition n'a pas pour but d'être une simple mise à jour mais une nouvelle librairie, il est envisageable, moyennant quelques modifications, de convertir un programme de Vertel 2 à Vertel 3, voici la liste des incompatibilités à résoudre :

Et quelques lignes plus bas :

• Changement du fonctionnement de "time" (même raison que pour "apdt")

Donc réponse habituelle => RTFM.

Ok, c'est bon, j'ai plus de problèmes avec cette nouvelle version

Ok, tant mieux

En fait le truc c'est que garder un compatibilité partielle m'a semblé débile, parce que par exemple le gray saute, donc g du revenir à flib dans une dizaine de mes prgm perso pour cette fonction. Comme le prog était ouvert j'en ai profité avant de le recompiler de virer les "/" pour mettre des "" (moins d'octets...) et virer les préfixes d_, s_ , e_ et t_ (qques centaines de kilo par prog). Et c'est la que c'est débil car Vertel pourrait être plus rapide en enlevant cette compatibilité avec préfixe qui n'a pas lieu d'être puisque dans de très nombreux cas il faut réediter le prog, voire changer les indtructions complètement (gray et busy..)!

Bah ué, mais bon, la pluspart des prog n'utilisent pas gray ni busy. Et puis c plus rapide changer une fois txt_draw en text et 2-3 autres instructions courante que de tous changer. Par contre, ce qui pourrait être pas mal, c de faire en plus une version qui prend pas en compte la compatibilité.

Enix
: Comme le prog était ouvert j'en ai profité avant de le recompiler de virer les "/" pour mettre des "" (moins d'octets...) et virer les préfixes d_, s_ , e_ et t_ (qques centaines de kilo par prog).

Quelques centaines de kilos ? C'est vraiment des très gros progs alors

Et c'est la que c'est débil car Vertel pourrait être plus rapide en enlevant cette compatibilité avec préfixe qui n'a pas lieu d'être puisque dans de très nombreux cas il faut réediter le prog, voire changer les indtructions complètement (gray et busy..)!

La raison pour laquelle j'ai gardé ces compatiblités, outre le fait que ça peut rendre certains programmes compatibles v2 / v3 sans aucun changement, est que ça ne grossit / ralenti quasiment pas le code de la lib. Ça doit prendre à tout casser une 10aine d'octets, et franchement le gain éventuelle serait completement invisible dans un programme en C, alors je te laisse imaginer par rapport au basic...

manque 30 ou 40 octets pour que tu vires la compatibilité

Vertyos
: lol c'est énorme ! Si j'avais une astuce pour gagner 50 octets sur la lib, je l'utiliserais tout de suite... enfin bref...

En effet ce sont des très gros prog (par exemple g un logiciel de dessin de 12ko fait à la main nvg, noir&blanc avec toutes les options dont g eu besoin...; un bench , des jeux et des utilitaires).
Je pensais également à cette citation de MacIntoc pour le nombre d'octet!, mais je l'ai pas mise!
Enfin je croyais que le gain ne serait pas nédligeable mais comme je ne fais que du basic, c'était en comparant avec des lefts(chaîne de commande,4) pour virer les préfixes...
Sinon tant que t'es là Vertios, est-ce que tu mettras le "keylow" de flib ds Vertel (4...) ?

Mac > Ah ok
Mais quand je parlais d'astuces pour réduire la taille, c'est pas en supprimant des fonctionalités

Enix
: Enfin je croyais que le gain ne serait pas nédligeable mais comme je ne fais que du basic, c'était en comparant avec des lefts(chaîne de commande,4) pour virer les préfixes...

Non, en effet c'est pas tout à fait comme ça que ça marche ^^

Sinon tant que t'es là Vertios, est-ce que tu mettras le "keylow" de flib ds Vertel (4...) ?

Y'aura probablement pas de Vertel 4, ajouter le keylow dans v3, je sais pas... Ça prend pas mal de place et j'aime pas trop le procédé utilisé (redirection des interruptions, capture des touches, restauration), en plus ça affiche quand même les indicateurs 2nd et cie :/

Sauf si le breakoff est activé.

Bon bin je vais alors garder flib avec vertel tant qu'ils s'entendent si bien !
>bobt89 C vrai ! C comme ça que je faisais et c très cool!

Vertyos>Faudrat que tu rajoutes ça dans la liste des features de Vertel

> (Quant à la vitesse, je n'en à rien à battre.)


pas d'accord !!!!!!!!!!!!!!!!!!!!!!!!!!!! bon maintenant si c'est 3ns o lieu de 1ns .........

Vertyos :
Mac > Ah ok
Mais quand je parlais d'astuces pour réduire la taille, c'est pas en supprimant des fonctionalités

Et refuser d'économiser les piles, ce n'est pas "supprimer des fonctionnalités"???

Non, c'est "ne pas en ajouter", surement pas les supprimer (ou alors on a pas la même notion du mot supprimer). Mais bon, j'ai déjà expliqué pourquoi je préferais de loin un ngetchx() à l'autre méthode.

En fait, tu ne pourrais pas intégrer une fonction genre seq en basic, ca permettrait d'accélérer quelque appel à la lib.

Trop compliqué, seq, y'a besoin d'évaluer n'importe quel type d'expressions, comme je vais pas les recoder (je pense pas pouvoir recoder ams, de toutes façons ), faudrait appeller les fonctions basic, bref... lent.

Non, mais je ne pensais pas refaire exactement seq, mais un truc simplifié pour par exemple des {1,3,5,7,9,...}

Avec la valeur de départ, le nombre d'elements, et le pas ? Pourquoi pas après tout...

ce serait bien aussi de pouvoir le mettre directement en argument, et pas comme une autre fonction.

Hmm nan, là ça fait un cas particulier, trop de code à rajouter. En admettant que la fonction s'appelle "abcd" (si vous avez une idée de nom, allez-y), il suffira de faire vertel("abcd",1,3,10,"","retr","","pixl","#",10) par exemple pour tracer des pixels à x=1,4,7,10,... et y=10.

et ça éviterais la lenteur du seq, ué, c pas con ça.

Et quad t'as plusieurs listes ??

suffit de faire plusierus appels succesifs:]

Ah bah là, pas le choix, faudrait les génerer une par une dans des variables temporaires : vertel("abcd",1,2,10,"","retr","seq1","","abcd",1,3,10,"","retr","seq2","",... /* utilisation de #seq1 et #seq2 */,"","delt",{"seq1","seq2"})

Tiens, je c pas si ça prend beaucoup de place, mais ce serait pas mal de rajouté un argument à retr pour indiquer si on veut garder une var en ram ou si on veut la sortir sous forme de fichier.

Hmm c'est chiant après, à chaque fois que tu veux appeller une variable faut vérifier si c'est un "vrai" fichier ou juste une copie temporaire en ram :/