internal error - Page 4

Tu te fous de ma gueule ? On parle de meilleure lib, la vitesse en fait partie. Si tu ne peux pas t'empecher d'accuser de détournement de sujet chaque fois que tu ne peux plus répondre, on va le clore ça reglera tous les problèmes.

Je ne parle pas de la MEILLEURE lib en soi, mais de la meilleure lib pour un débutant. Clib est bien, mais pour un débutant -> poubelle! Le gars aura beaucoup de peine à s'en sortir du au fait qu'il n'y a pas de noms de fonctions, mais des numéros. Si j'ai mis des numéros, c'était pour la taille du code (BASIC) et pour la vitesse. On notera tout de même le petit prog 'clib' qui demande comme argument le numéro de fonction et affiche un panneau d'infos plus un nom associé à la fonction.
Flib est bien, mais il devient très rapidement compliqué avec des structures du style:
flib("drawstr:0,"&string(y*10)&",4,"&chaine)
Vertel est bien aussi mais il m'a planté dès que j'ai essayé deux trois trucs... C'est pour ça que je ne trouve pas cette librairie optimale, c'est tout. Mes critères lorsque je juge un prog sont simples:
-Stabilité
-Simplicité
-Qualité
-Taille
-(Vitesse)
Or Vertel n'est pas stable donc je l'ai mise tout de suite à la poubelle. C'est un fait, pas un reproche!

(je ne sais pas j'ai pas vraiment poussé l'utilisation de clib),

J'avoue que clib est stable car les seules fonctions dangereuses sont séparées dans APR (Scrolling, aggrandissement, remplissage, ...)

Là encore tu vas m'expliquer où je t'ai "traité comme de la merde"

Heu... Tes posts n'ont pas un ton franchement sympathique alors que j'essaie de faire des efforts! J'ai mes défauts, j'essaie de les corriger, maintenant c'est pas une raison pour me coller une étiquette et penser que ça ne va pas changer. De plus, je n'ai rien dit de mal!

Là encore tu vas m'expliquer où je t'ai "traité comme de la merde"

Ben excuse, c'était plutôt adressé à Neuro vu son super-post

1. super comme comportement
2. comme a ton habitude tu parle sans savoir 3. ta gueulle

Neuro > 1. Tu crois que le tien est mieux? J'ai aussi lu TES posts et tu es loin d'être un ange mon cher
2. Je SAIS de quoi je parle vu que j'ai lu la doc.

Là encore tu vas m'expliquer où je t'ai "traité comme de la merde" en citant clairement le post, ou bien tu vas simplement admettre que tu t'es emporté.

Bah je me suis emporté, mais c'était face aux autres topics aussi. C'était la goutte d'eau qui a fait déborder le vase. C'est tout.

Toujours les sujets qui blaisse. Quant on parle de nostub, kernel ou encore de librairies graphique là les topics partent en live. Il y a beaucoup de topics sur ce sujet, en date optimsation vitesse de jackiechan.... Donc arrêter de vous prendre la tête ici, ce n'est pas le sujet du topic.

clib est ptet bien (je ne l'ai pas essayée), mais tu dis qu'elle n'est pas adaptée pour un débutant
or tu trouves flib("drawstr:0,"&string(y*10)&",4,"&chaine) est aussi compliqué (alors que ca c du B.A.ba (comment ca s'ecrit c'te connerie ?) si tu veux voir des trucs vraiment compliqués (mais vraiment performants) je peux t'en faire avec vertel, et là tu verras que ca sera tres comliqué )
faudrait savoir alors ce que tu entend par simple ...
clib ne l'est pas (n° pour les fonctions ->ok)
flib non plus (alors que l'exemple que tu as filé est vraiment un truc de base (meme si c'est un exemple volontairement simplifié, je le suppose, tout ce que tu peux faire avec flib dans ce genre restera assez simple comparé à ce que tu peux faire avec vertel )
et puis pour simplifier tu pouvais faire flib("drawstr:0, y*10,4,"&chaine)
(avec un espace devant le y*10)

azerty83 :
or tu trouves flib("drawstr:0,"&string(y*10)&",4,"&chaine) est aussi compliqué (alors que ca c du B.A.ba (comment ca s'ecrit c'te connerie ?)

D'ailleurs, cet exemple est incorrect. Il faut mettre:
flib("drawstr:0,"&string(exact(y*10))&",4,"&chaine)

Toujours les sujets qui blaisse. Quant on parle de nostub, kernel ou encore de librairies graphique là les topics partent en live. Il y a beaucoup de topics sur ce sujet, en date optimsation vitesse de jackiechan.... Donc arrêter de vous prendre la tête ici, ce n'est pas le sujet du topic.

Bah je propose que chacun utilise la libe qu'il trouve le mieux et qu'il nous fasse de bons progs avec. Et surtout que LUI, soit satisfait. Le reste, que ce soit vertel, clib, flib, basic_lib ou n'importe quoi ça n'est pas important. Le principal est d'avoir réussi à faire quelque chose de bien. Or ses programmes (donc de l'auteur du topic) sont déjà très bien même s'il n'a pas utilisé de lib! Alors s'il veut en utiliser une, il va les essayer et choisir lui-même celle qu'il trouvera le mieux. (Manque de bol j'espère que ce sera aucune des trois )

flib("drawstr:0,"&string(exact(y*10))&",4,"&chaine)

Avec flib il n'y a pas besoin que les nombres soient exacts (en revanche clib le requiert, d'où ma demande pour NG_aproxesi dans l'autre topic)

Ecoute mon cher M. TrouDuc ... déjà, on se renseigne avant de parler, la doc est une chose, pis si tu savais lire, tu saurais qu'elle n'est absolument pas actualisée !
Alors tes critères de séléction, tu te les gardes pke c de la merde

Bon vu la tournure que prend le topic je pense qu'il va être locké si le ton et/ou le sujet ne changent pas...

Kevin> Lorsque tu fais ESI_approx ou je saiis plus trop quoi... Après tu es obligé de faire GetFloatArg? N'y a-t-il pas un moyen plus rapide (et plus optimisé) d'obtenir un entier depuis le top_estack?

brunni > flib a besoin d'avoir des args exacts tout comme vertel et comme je pense toutes les libs basics
(faudrait etre pour tenter une gestion des floats )

quant au exact(), c'est du kevin
on peut aussi faire un setmode au debut et à la fin, avec tous les avantages (gain de vitesse par raport à un appel à une fonction basic récurrente) et les inconvenient (compatibilité à 100.00000000000% impossible avec toutes les version d'ams de localisation, de hw, de couleur de la touche on et de peinture du slide case des ti de la galaxie et de Navarre)

Pourquoi tu dis que c'est du Kevin? Si ça doit être exact, il a tout à fait raison non?
[Edit] En revanche, le mode exact n'a pas que des avantages... On aura plutôt des trucs du style 3/8 et ça c'est tout aussi dur de gérer que les float...[fin Edit]
A part ça, peut-être qu'il y a quelque chose... Serait-ce GetValue? C'est lent ou bien ça va Kevin?
Donc en gros:
-NG_approxtoEsi
-Puis GetValue(0,239)
Et hop! On a le bon argument! Chouette

Pourquoi tu mets ce smile? Ca ne marchera pas?

Ecoute mon cher M. TrouDuc ... déjà, on se renseigne avant de parler, la doc est une chose, pis si tu savais lire, tu saurais qu'elle n'est absolument pas actualisée !

Si môssieur avait un cerveau, il pourrait éventuellement envisager d'apprendre à lire... Tiens, commence par cette phrase, ça te fera un bon entraînement:

Bon vu la tournure que prend le topic je pense qu'il va être locké si le ton et/ou le sujet ne changent pas...

Pour te répondre Vertyos, c'est mon dernier mot sur le sujet. Ce serait dommage que tu fermes le topic. A la limite tu peux me kicker...

Si on pouvait reprendre les choses sérieuses SVP? (ev. post #100)

l'est serieux mon post ?

oops, m'en va l'editer !

flib("drawstr:0,"&string(exact(y*10))&",4,"&chaine)


On peut faire mieux maintenant :

flib("drawstr:0, exact(y*10),4"&chaine)

Depuis la version 3.0 (il me semble), FLib supporte les expression, plus besoins de passer par string.

Quand à la stabilité de Vertel, il me semble que ce soit du à la ROM.
Je tourne avec la 2.07, Vertel n'a jamais planté, mais mon frère a eu des problèmes avec la 2.08 pour afficher des sprites (crash).
Je ne sais pas si Vertyos a rebossé là-dessus, mais ça ne devrait pas poser trop de difficulté. Le seul truc que je reprocherais à Vertel, c'est la complexité du nom des fonctions, contrairement à celles de FLib, elles ne sont vraiement pas intuitives.

au risque de me repeter on peu eviter de mettre un exact( ) dans chaque appel à une lib

et pour vertel, verifie bien avec la derniere vesrion, car tous les bugs graves signaléz ont été corrigé il me semble

arf ma version a 6 mois, ce que j'ai dit est ptet faux du coup

nounoun :
Quand à la stabilité de Vertel, il me semble que ce soit du à la ROM.
Je tourne avec la 2.07, Vertel n'a jamais planté, mais mon frère a eu des problèmes avec la 2.08 pour afficher des sprites (crash). Je ne sais pas si Vertyos a rebossé là-dessus, mais ça ne devrait pas poser trop de difficulté.

Hmm étrange. Quand j'ai releasé Vertel 2, la rom 2.08 n'existait pas donc je n'ai pas pu tester dessus, mais je ne vois pas trop ce qui pourrait poser problème. Quelle version tu utilise ?

Brunni
: Kevin> Lorsque tu fais ESI_approx ou je saiis plus trop quoi... Après tu es obligé de faire GetFloatArg? N'y a-t-il pas un moyen plus rapide (et plus optimisé) d'obtenir un entier depuis le top_estack?

NG_rationalESI.

azerty83 :
quant au exact(), c'est du kevin on peut aussi faire un setmode au debut et à la fin, avec tous les avantages (gain de vitesse par raport à un appel à une fonction basic récurrente) et les inconvenient (compatibilité à 100.00000000000% impossible avec toutes les version d'ams de localisation, de hw, de couleur de la touche on et de peinture du slide case des ti de la galaxie et de Navarre)

On peut aussi faire du setMode compatible avec la localisation, mais exact() est beaucoup plus simple. Et ça ne prend que 2 octets (tokénisés) par appel, setMode prend une place énorme pour les chaînes. Et enfin, ce n'est pas propre de changer les modes quand ce n'est pas absolument nécessaire.

nounoun :
flib("drawstr:0,"&string(exact(y*10))&",4,"&chaine)


On peut faire mieux maintenant :
flib("drawstr:0, exact(y*10),4"&chaine)

Ce que tu fais là est idiot:
1. exact change selon la langue, donc ça n'a rien à faire dans une chaîne de caractères.
2. FLib est suffisamment intelligente pour utiliser NG_rationalESI quand elle évalue une expression (j'ai vérifié dans les sources), donc quand tu utilises l'évaluation d'expressions (l'argument qui commence par un espace), c'est déjà évalué en exact, donc pas besoin de mettre exact dans ce cas.

Brunni :
Si môssieur avait un cerveau, il pourrait éventuellement envisager d'apprendre à lire... Tiens, commence par cette phrase, ça te fera un bon entraînement [...]

T'es trop con ... c'est toi qui refout la merde là !
Si le topic est locké ce sera donc de ta faute

Puis, un petit conseil, ne reprend jamais les arguments de l'autre, ça fait vraiment sous merde ... bref, je retire ce que j'ai dit, reprend les arguments des autres, ca te changera pas trop !

Hmm étrange. Quand j'ai releasé Vertel 2, la rom 2.08 n'existait pas donc je n'ai pas pu tester dessus, mais je ne vois pas trop ce qui pourrait poser problème. Quelle version tu utilise ?

Qu'est-ce qui a tant changé dans cette ROM pour qu'il y ait tant de problèmes de compatibilité?

1. exact change selon la langue, donc ça n'a rien à faire dans une chaîne de caractères.

Le problème est que flib est très lent à gérer les expressions avec des espaces vu qu'il doit tokeniser l'expression... Tu vois le temps qu'il te faut pour exécuter un prog la première fois... eh ben flib prend ce temps-là rien que pour évaluer ton expression.

c'est déjà évalué en exact, donc pas besoin de mettre exact dans ce cas.

heu mais c'est toi qui a écrit qu'il fallait le mettre en exact

Kevin Kofler :
On peut aussi faire du setMode compatible avec la localisation, mais exact() est beaucoup plus simple. Et ça ne prend que 2 octets (tokénisés) par appel, setMode prend une place énorme pour les chaînes. Et enfin, ce n'est pas propre de changer les modes quand ce n'est pas absolument nécessaire.

encore une fois ca depend : si tu as un seul peu d'appels à flib, ok vaut mieux appeler exact(),
mais bon là c'est un peu filer de la confiture auc cochons
souvent dans un prog basic tu as bcp d'appels à la lib et meme des appels enormes (plein d'args)
et là ben un exact() à chaque fois va allourdir bien plus le prog que l'utilisation des setmodes, et surtout le ralentir !
encore une fois, on utilise les libs en partie pour accélérer le programme, c'est pas la peine de compliquer inutilement les appels
et pour la compatibilité, c'est vrai, on peu faire tres simple
(ca va pas te plaire par contre )

Brunni
:

c'est déjà évalué en exact, donc pas besoin de mettre exact dans ce cas.

heu mais c'est toi qui a écrit qu'il fallait le mettre en exact

Si tu utilises la syntaxe sans évaluation (sans l'espace), il faut mettre en exact. Avec la syntaxe avec évaluation (avec l'espace), c'est fait automatiquement.

azerty83 :
et pour la compatibilité, c'est vrai, on peu faire tres simple
(ca va pas te plaire par contre )

Ce n'est pas de la compatibilité alors. Ne détourne pas les termes.

La manière compatible de faire des setMode est:
:Try
:setMode("12","34")
:Else
:ClrErr
:setMode("FOO","Bar")
:EndTry
Les modes numériques pour AMS 2 localisé, et les modes anglais pour AMS 1.

rah, j'ai essayé de retrouver ca, mais je lui donnais des nombres au lieu de nombres dans des strings...

mais sinon, dis moi, n'oublirais tu pas de sauvegarder le mode courrant ?
c'est tres sale ca de ne pas restituer la calculatrice dans le meme etat de propreté que celui trouvé en entrant...
tu te laisses aller, faut de ressaisir

Y'a t-il encore des gens qui utilisent AMS 1.xx? Enfin, y'a t-il un avantage qu'on pourrait trouver à utiliser cette ROM plutôt que la 2.xx?

azerty83
: rah, j'ai essayé de retrouver ca, mais je lui donnais des nombres au lieu de nombres dans des strings...

Tout ce qui est nombres ne marchera pas avec AMS 1.
Et les nombres sans les chaînes ne sont pas acceptés par AMS 2 non plus.

mais sinon, dis moi, n'oublirais tu pas de sauvegarder le mode courrant ? c'est tres sale ca de ne pas restituer la calculatrice dans le meme etat de propreté que celui trouvé en entrant...

C'est évident.
C'était juste un exemple. Le mode qui s'appelle "FOO", je veux le voir.