2.05.rom - Page 4

même si j'exagérre un peu...
ça s'en rapproche...

bah... pourquois voulez vous que ça rame
au lieu de faire une ligne de goto de ouf à la Bob64, j'ai fait un exit

MacIntoc
a osé écrire : au lieu de faire une ligne de goto de ouf à la Bob64, [...]

Bof... Je compare pour trouver ce qui est le plus rapide. Si c'est le GOTO qui s'avere être la meilleure solution, je laisse le GOTO...
Par contre les meilleurs lignes c'est rarement avec des GOTO... Souvent avec des augment, par exemple j'aime bien celle là (toujours interum...) :

augment(augment(left(#l_tmp,4),mid(#l_tmp,s_chx,1)),augment(mid(#l_tmp,5,s_chx-5),mid(#l_tmp,s_chx+1)))»#l_tmp

augment + left + mid + indirections + variables incompéhensibles rulezzzzzzzzzz

C justement le genre de ligne que j'essaye d'éviter

J'ai fait pire, mais j'utilisait pas des fonctions aussi variées!

Et il en est fière

crono > oui justement moi aussi mais quand y'a que des when ou que des augment c pas marrant... J'aime bien les lignes comme ça, j'en avait une sympa mais je la retrouve plus


macintoc > C justement le genre de ligne que j'essaye d'éviter
> Alors je comprends pourquoi tes programmes sont lents... Le moindre découpage que tu tenteras sur cette ligne la ralentira.

Nan, je fait juste en sorte qu'on ne puissent pas faire de ligne comme ça. C entre autre pour ça que je programme aussi lentement.

Bah t'es marrant toi... Moi je m'en fous d'avoir des lignes comme ça du moment que c'est rapide. L'optimisation mémoire c'est pas mon truc, en basic je cherche à avoir le résultat le plus rapide possible.

Là par exemple 2 lignes (dont celle-là) suffisent à faire ce que je veux, je ne vois pas comment faire plus rapide. C'est peut-être possible mais alors c'est au dessus de mon niveau.

je sais pas moi non plus, c pas tous le temps possible, mais y a surement quelque part dans ton prog un algo qui fait ça en partis et que tu passe à coté pour atteindre cette autre algo.

Bob> si c l'optimisation rapidité que tu recherche, arrête de coder en BASIC !!!

oué, exit ça peut être plus rapide...
mais en C, exit, ça fait quitter le programme
(je reconnais que je ne me souviens plus du tout du basic)

MacIntoc > Je connais mon prog, et je commence aussi à connaitre un peu le Ti-Basic
Voilà le sous-programme complet si ça t'amuse :
Define  p_mntfil(s_chx,s_pth)=Prgm Local  l_tmp s_pth[dim(s_pth)]»l_tmp augment(augment(left(#l_tmp,4),mid(#l_tmp,s_chx,1)),augment(mid(#l_tmp,5,s_chx-5),mid(#l_tmp,s_chx+1)))»#l_tmp EndPrgm

Si t'arrive à optimiser ça...

Squale92 > si c l'optimisation rapidité que tu recherche, arrête de coder en BASIC !!!
> Faut-il vraiment que je réponde ?

Bob> tu n'es pas obligé de répondre.
ce que j'ai dit est une vérité, tu ne peux pas le nier

Alors je dois vraiment être tordu pour apprendre le C tout en continuant le basic...
Le fait que mes progs soient principalement des libs pour le basic c'est pas pour rien, je les utilise après dans des programmes plus gros et plus importants que je fais en basic. Ce language suffit largement pour des utilitaires, il ne plante pas, il est utilisable oncalc, et si qqchose dans le programme devient vraiment trop lent je le fais en C.

Il ne plante pas...
Les progs en C de plantent quasiment jamais sur ma TI...
(enfin, ça dépend de comment ils sont codées... mais je n'envoie jamais de programme que je sais planter)

utilisable on-calc...
Ben, je code parfois on-calc, et jamais en BASIC...
(pas en C on-calc : les fichiers de 64ko au max sont pas bon pour moi... mes sources font plus que ça)
=> ASM powa

si quelque chose dans le prog devient vraiment trop lent, je l'optimise. pas besoin de changer de language, en général

les goto ne sont jamais trop optimisé

Les progs en C de plantent quasiment jamais sur ma TI...

> Bah peut-être qu'avec l'experience ça ne t'arrive plus, mais quand je programme en C il y a toujours des bugs aux premiers essais. Et des bugs 'graves', barre noire, qui font perdre toute la RAM. Donc coder en C pour l'instant ça m'est impossible.

Alors que le basic ne plantera jamais quelque soit l'erreur (sauf si c'est une erreur dans une lib en C evidement).

pour tester tes progs en C, utilise VTI !
j'ai pas dit que j'avais plus debugs... mais je les supprime sous VTI, et non on-real-TI.

mais, des bugs, j'en ai moins, voire même bcp moins qu'au début.
il y a peu de temps, j'ai passé une journée entière à coder, sans pouvoir tester ce que je codais (toutes les portions de code étaient inter-dépendantes... donc, il fallait que tout soit implémenté pr que je puisse tester).
A 22h j'ai enfin pu tester... j'avais deux bigs
du à des connenies.
(un y à la place d'un x pour le premier. je sais plus pr le second)



basic ne plantera jamais...
faudrait que j'essaye de refaire ma barre noire en basic...
pb, c que ça va bientôt faire deux ans... alors, je sais plus trop ce que j'avais foutu exactement

oué j'aimerais bien voir ce big bug en basic

j'aimerai bien réussir à le reproduire.
je sais que je voulais lancer l'éditeur de txt en basic...
=> en mode 2 écran (un en haut un en bas), et un switch entre les 2 écrans à un moment...
mais je sais plus trop les détails.

il me semble que, à l'époque, j'avais une ROM2.03

La 2.03 est buggée à mort... Moi aussi j'ai réussi a faire bugger des roms, surtout la 2.01. Mais jamais la 2.05, elle a l'air d'être assez stable.

Et puis pour le C, bah voilà c exactement ce que je voulais dire : non seulement tu est obligé d'avoir un programme assez stable pour commencer à l'éditer oncalc, et en plus tu as toujours peur de le lancer pour tester, parceque si il plante tu perd tout.
En basic tu peux commencer, continuer et finir un programme 100% oncalc, en le testant toutes les 5 minutes si ça t'amuse : tu ne cours aucun risque

si il plante tu perd tout...
bof bof...
je suis pas imprudent à ce point.
qd je code en ASM on-calc, j'ai toujours une copie de sauvegarde de mon source.

et puis, ma fois, courir des risques (mesurés) ne me gènene tpas qd je vois la puissance de ce que le C me permet de faire

Erf... Tu avances lentement du coup...
Je ne cours aucun risque en programmant en basic (+ vertel mais bon je ne l'ai encore jamais faite bugger), donc ça avance au pas de course, en très peu de temps un programme tout à fait fonctionnel est terminé, oncalc

Paour faire planter la calc avec du basic, tu peut faire un mix entre un getcalc (enfin, l'instruction de communication HW2->HW2) dans une try suivit d'un stop. Là, ça plante à chaque fois.

Pour l'optimisation, je commence par virer ce sous-programme

Pour l'optimisation, je commence par virer ce sous-programme
> Ouais d'accord t'es gentil

y changera jamais

Link a écrit :
squale:>Justement un GOTO dans une boucle y'a rien de plus c'est comme les sauts dans les if il faut faire:
if condition then
...
endif
if condition
goto label

et non pas:
if condition then
...
goto label
endif La, sur casio, tu te fais jeter, quelque chose de bien!!

Dur à faire sur les autres TI ...en particulier les TI z80, c pas super comme syntaxe celle que tu considères la bonne...même si c ce qui se fait de mieux nivo lisibilité, coté place c pas pareil.....eh oui c limité en mémoire les 83+


Mais comme dit Bob 64#98, ca dépend ce qu'on cherche, opti mémoire ou vitesse...y'a des micros programmes qui sont super longs à exécuter

microbug#115> ben il a raison c toujours le bordel les sous-programmes...

Justement, c'est sur TI-Z80 qu'il faut éviter les Goto dans un If:Then...End à tout prix parce que ça crée des leaks de mémoire!!!
Sur TI-89/92+, il n'y a aucun problème à utiliser un Goto dans un If ... Then ... EndIf.

oué ça va pour les codes simples mais les boucles If plus complexes, ca passe pus et on s'embrouille

moi je suis pour les sous programmes, mais uniquement pour les très gros programmes.
Comme ça on s'y retrouve mieux