Analyse d'un programme source .bas

Non car j'ignore tout les caracteres tant que j'ai pas vu le 2eme <"> (bascule)...

Tu n'as plus qu'à faire du pas à pas sur la ligne en question pour voir ce qui cloche, bizarre sur 2 lignes si semblables que ça ne marche pas pareil...

C'est corrigé !

Tu avais raison JL35:
en effet c'était le <'> qui perturbait le prog : il prenait la suite pour un commentaire....
Reine de saba 26 est de nouveau en lice...

Suite de notre haletante course hippique :
Les deux chevaux sont fringants et prêts à en découdre.
Ah, cette fois, c'est l'arbitre qui vient de faire une chute,
(à mon tour de faire une révision de mon comparateur
qui n'avait pas prévu les variables tableaux à 2 dimensions).

Ca y est, l'arbitre est sur pied et la course peut commencer :
Reine de saba 26 (nouvelle casaque marbrée et tunique luisante),
ainsi que Belle de nuit 35 (casaque écossaise et tunique blanche)
prennent le départ et courent col à col, et ah, catastrophe !
A la première haie, Reine de saba 26 chute sur le sol
et la voilà les quatre fers en l'air,
tandis que Belle de nuit 35 (qui a vu toute la scène et qui jubile)
se déchaîne en direction de la ligne d'arrivée.
Aïe, aïe, aïe, cette pauvre Reine de saba si élégante...!


En bref, j'ai testé les deux programmes avec le petit programme suivant, tout simple :

Code:

dim t , i
for i=0 to 25
 t=t-int(t/10)*10+1
 print t
next i

et catastrophe, alors que le programme de JL35 le supporte parfaitement,
celui de Nardo26 se plante dès le chargement et affiche l'erreur suivante :
List index out of bounds (0)

Je suppose que c'est lié au fait qu'il n'y a pas d'objet dans ce programme.
Mais au fait, pourquoi le programme de Nardo26 cherche automatiquement
le nombre d'objets alors qu'on ne le lui demande pas ?

Mais finalement, Belle de nuit avait bien tort de jubiler comme ça,
car la voilà à terre, elle aussi ! Ah, décidément, que de péripéties dans cette course !

Dans le même genre, avec un petit programme qui n'a pas de variable,
le programme de JL35 plante lorsqu'on lui demande d'afficher les variables.
(bon, d'accord, dans un sens, c'est vicieux, mais pourquoi pas ?)
il affiche l'erreur suivante :
Not correct string expression. Fonction call with negative or zero value
à la ligne 360 :
var$(i%) = LEFT$(var$(i%), LEN(var$(i%))-5) + " [" + TRIM$(RIGHT$(var$(i%),5)) + "]"

Et voilà la course encore à remettre,
ah, quel feuilleton à palpitants épisodes, c'est pire que Dallas !

Bizarre...
Je viens de tester ton bout de code et ça plante pas !...

Chez moi, ça plante et dès qu'un programme est sans objet, ça plante.


PS : Ah, non, non, non, autant pour moi !
c'est la modification que j'ai apportée à ton programme
pour faire fonctionner mon comparateur,
qui plante... Bon, alors je n'ai rien dit !!!

Oui, bon, tu vas nous avoir à l'usure.

Un programme qui n'a pas de variables, quelle idée saugrenue !
Et tu oses demander l'affichage des variables d'un programme qui n'en a pas, quel culot !
Et puis après ce sera un programme qui n'aura pas de lignes...

Je vais m'adresser à mon syndicat des analyseurs de programmes, le SAP, (dont Nardo est le secrétaire général élu à mon unanimité) pour harcèlement moral.

Taratata, j'ai plusieurs programmes qui ne possèdent aucune variable,
ce n'est pas farfelu du tout !
Quant à un analyseur de variable, il devrait être capable de dire
qu'il n'y tout simplement pas de variable, pourquoi pas ?

Heu... on peut pas changer le nom 'SAP' ?

Ça me rappelle le boulot...
on travaille avec cette grosse daube/bouse qui est censée nous aider...

Bon j'arrête là les commentaires, sinon ma direction risque de me virer !

Ah, ce n'est pas possible, hein,
c'est moi qui suis déjà le secrétaire général de ce syndicat,
élu à l'unanimité de tout le monde !

Le programme est corrigé selon tes désirs, il peut n'y avoir ni variables, ni objets, ni labels, ni même de programme du tout, ça marche.

@Nardo au lieu de SAP si ça te gêne on peut mettre à l'anglo-saxonne SPA, et puis pour des bourrins comme nous traite jjn4 ça sera peut-être plus approprié !

Va pour SPA !
Bon et cette course? on attend la suite de ces palpitants episodes !!!

Je piaffe des quatre fers...

Citation :

Bon j'arrête là les commentaires, sinon ma direction risque de me virer !

Oui, déjà que le sujet est brulant en ce moment sur facebook :/

Et la course délirante reprend de plus belle !
Reine de saba 26, plus élégante que jamais en casaque carmin et tunique jade,
Belle de nuit 35 (casaque bleu nuit, tunique orange) qui piaffe d'envie de vaincre,
et le signal de départ est donné, les deux chevaux partent comme des flèches
et courent à la même vitesse, aucun n'arrivant à dépasser l'autre,
cette fois, ils sautent les haies en s'envolant littéralement,
c'est vraiment une course formidable,
ils ont déjà fait plusieurs tours d'hippodrome,
on se dit qu'on s'achemine vers la victoire,
est-ce qu'un cheval va prendre un peu d'avance et gagner sur l'autre ?
Et catastrophe, oh là, là, là, là, catastrophe !
Belle de nuit se prend les pieds dans une barre de haie et chute
juste devant Reine de saba qu'elle entraîne dans sa culbute,
les deux chevaux roulent sur le sol jusqu'en bas de la pente,
et semblent ne plus bouger, ou alors une patte pour l'un, une oreille pour l'autre,
Les infirmiers se précipitent et doivent juger l'état des juments sérieux,
car les deux pauvres bêtes sont montées en brancard
dans des camions à bestiaux du SAMU qui les emmènent
et partent en faisant fonctionner la sirène...

Bon, j'arrête, car JL35 et Nardo 26 doivent être inquiets ( )
Alors voilà, tout allait bien et il semblait que tous les programmes que j'essayais
allaient ne pas poser de problème jusqu'au bout,
et montrer que le programme de JL35 et celui de Nardo26 étaient devenus parfaits,
lorsque qu'un long programme a fait planter les deux programmes,
et je ne sais pas trop pourquoi :

Pour JL35, il y a un message d'erreur (function call with negative or zero value)
sur la ligne 149 :
FILE_WRITELN 2, STRING$(4-LEN(STR$(nl%)), " ") + STR$(nl%) + ": " + a$
et je ne sais trop pas à quoi le label opn: sert
tout ce que je peut dire, c'est qu'un essai montre que :
LEN(STR$(nl%)) = 4, ce qui aboutit donc à 0 et fait logiquement planter,
mais alors qu'est-ce que nl% ?

Pour Nardo26, le programme plante à la fin de l'analyse des variables,
affiche un message d'erreur qui disparaît aussitôt, et plante tout l'éditeur,
si bien que je ne sais pas de quoi il s'agit,
et je me demande si c'est le programme de Nardo qui plante
ou la modification que j'y ai apporté qui est précisément à cet endroit...
A suivre, donc, mais on verra demain...

(j'espère que les chevaux ne vont pas finir à l'équarrissage)

Citation :

Bon, j'arrête, car JL35 et Nardo 26 doivent être inquiets

LOL

Les chevaux ont finis par se battre entre eux au lieu de courir
Je suis crevé là ça se voit

A plus.

Je viens d'essayer ce long programme avec la version originelle de Nardo26,
donc dénuée de toute modification de ma part,
et effectivement, ça fait la même chose, ça plante et ça plante bien,
car il faut ensuite virer l'éditeur qui ne fonctionne plus et le réouvrir.
et comme le message d'erreur disparaît aussitôt apparu,
je ne sais pas ce qui se passe.

Aïe, aïe, aïe, Reine de saba 26 a l'air en très mauvais état !

Tu es dans le sous-programme d'ouverture d'un fichier source: mise en forme dans un fichier auxiliaire pour ajouter en tête des lignes le numéro de ligne (nl% est le numéro de la ligne lue).
J'en conclus que tu as chargé un programme qui fait plus de 999 lignes.
Et dans ce cas le STRING$(4-LEN(STR$(nl%)), " ") coince, il est incapable de générer une chaîne vide dans le cas où LEN(STR$(nl%)) est égal à 4 (ce qui à mon avis n'est pas normal, les Basics classiques ne font pas d'erreur dans ce cas, et du coup je me suis fait piéger, j'avais compté jusqu'à 9999 lignes sans erreur).
Pour moi le String$ devrait savoir générer une chaîne de 0 espace, c'est à dire vide.

Bon, je vais tester ce cas...


PS c'est corrigé !
Maintenant tu n'as plus qu'à tester un programme de plus de 9999 lignes, et là je suis sûr que ça va coincer !
Autres petites modifs:
- amélioration de la présentation des résultats dans l'affichage des variables et labels: séparation plus nette et alignée des libellés et des numéros de lignes.
- dans la présentation des IFs, mise en évidence des RETURN (aucune structure IF/End_If ne doit chevaucher un return.

C'est bon, ça marche, c'est vrai que le programme faisait 1615 lignes.
Je ne crois pas avoir de programmes faisant plus de 9999 lignes, donc ça ira.
Merci aussi pour la nouvelle adaptation à la taille des écrans.
Par contre, le cas où il n'y a pas de variable ne marche toujours pas.
(là, je sens que j'exagère, et que JL, le propriétaire du cheval Belle de nuit 35,
va sûrement aller se plaindre au syndicat national des chevaux fourbus,
le SNCF... )

Euuuuhh... JL35, il y a une petite erreur dans la nouvelle version du programme,
quand il affiche l'utilisation des variables (et qu'elles sont nombreuses),
il s'arrête de les afficher à partir de la 75° utilisation,
ou peut-être faut-il compter en terme de nombre de caractères,
car il en affiche une partie, comme ci dessous :

Citation :

a$ [3],97,98,99,124,125,126,127,138,139,140,141,
151,152,153,154,181,182,183,184,354,355,372,373,
403,404,405,406,410,412,877,878,879,880,883,885,
901,902,903,904,913,914,915,916,917,918,919,920,
921,922,923,924,925,926,927,928,929,930,931,932,
933,934,935,936,937,938,939,940,941,942,944,945,
946,947,948,94
p [17],24,79,84,390,391,392,423,430,446,461,463,
538,539,540,541,542,544,545,547,548,551,554,555,
557,558,560,561,562,564,565,567,570,571,573,574,
576,577,580,583,584,586,587,589,590,591,593,594,
596,607,608,609,610,611,613,614,616,617,620,623,
624,626,627,629,630,631,633,634,636,639,640,642,
643,645,646,6

alors qu'il y a une suite (résultats de Nardo26) :

Citation :

a$ déclarée en ligne 3 utilisée 98 fois en 3,97,98,99,124,125,126,127,138,139,140,
141,151,152,153,154,181,182,183,184,354,355,372,373,403,404,405,406,410,
412,877,878,879,880,883,885,901,902,903,904,913,914,915,916,917,918,919,
920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,
938,939,940,941,942,944,945,946,947,948,949,950,951,952,953,954,955,956,
957,958,959,960,961,962,963,964,965,966,967,968,969,970,972
p déclarée en ligne 17 utilisée 124 fois en 17,24,79,84,390,391,392,423,430,446,461,
463,538,539,540,541,542,544,545,547,548,551,554,555,557,558,560,561,562,
564,565,567,570,571,573,574,576,577,580,583,584,586,587,589,590,591,593,
594,596,607,608,609,610,611,613,614,616,617,620,623,624,626,627,629,630,
631,633,634,636,639,640,642,643,645,646,649,652,653,655,656,658,659,660,
662,663,665,685,694,699,700,702,706,708,709,712,713,716,720,721,723,727,
729,730,733,734,737,741,742,744,748,750,751,754,755,758,762,763,765,769,
771,772,775,776,779

et cette erreur n'existait pas avant...
Aïe, aïe, aïe, que de péripéties !

@JL35:
Il y a un truc que je ne comprends pas:

Citation :

- dans la présentation des IFs, mise en évidence des RETURN (aucune structure IF/End_If ne doit chevaucher un return.

Pourqui ? Ne peut-on pas écrire ceci:

Code:

label test
dim i%

i% = 3
gosub test
i% = 9
gosub test
i% = 11
gosub test

end

Test:
if i%<10
    print "OK"
    return
else
i% = 0
Print "Zéro"
end_if
return

Ce programme doit afficher:

Citation :

OK
OK
Zéro

Euh Klaus, je crois bien que tu as raison, on peut fort bien mettre un return en plein milieu d'un sous-programme.
Dans mon esprit je voyais plutôt un return dans ce cas dans une ligne comme:
IF nb = 0 THEN RETURN
et d'ailleurs dans ce cas je ne prends pas le return en compte, seulement s'il est en début de ligne.
Effectivement, dans l'exemple que tu donnes il est en début de ligne et ça marche.
Donc disons que j'ai dit un truc pas tout à fait exact, mais que le soulignage des Return attire l'attention sur la structure.

@jjn4, tu m'étonnes pour le cas sans variables, j'ai modifié et ça marche chez moi après essai..., il affiche 0 tout simplement...

Pour l'affichage des numéros de lignes d'une variable, il y a manifestement une troncature, j'ai une petite idée là-dessus (ça doit être suite à une astuce que m'avait donné cosmos concernant le MID$, je regarde tout de suite).

Problème de troncature du résultat:
Effectivement, pour la troncature c'était bien ça.
Je m'explique (ça peut servir):
Quand on veut obtenir le restant d'une chaîne a$ à partir d'un index donné k, on doit écrire:

Code:

b$ = MID$(a$, k, LEN(a$) - k + 1)

mais on ne sait jamais trop si on doit rajouter 1 ou pas, suivant les cas, alors cosmos m'avait donné une astuce, on écrit:

Code:

b$ = MID$(a$, k, 300)

et là Panoramic prend tout simplement le restant de la chaîne de quelque longueur qu'elle soit.
Et moi bêtement j'ai mis 300 partout sans penser que ça pouvait dépasser ça, auquel cas ça ne marche plus, ça tronque, et c'est ce qui m'est arrivé !

Alors je préconise:

Code:

a$ = MID$(a$, k, LEN(a$))

comme ça on est sûr que ça marche à tous les coups.

Deuxième problème:
cas où il n'y a aucune variable.
Je n'avais pas testé avec suffisamment d'attention, mais il y avait bien une erreur.
J'ai encore été trompé par ceci:

Code:

FOR i% = 1 TO nvar%
.....
NEXT i%

C'est bon à savoir, mais si nvar% = 0, eh bien la boucle est exécutée une fois avec i% = 1.
Je ne sais pas si c'est normal, mais c'est comme ça.

PS tout ça est corrigé dans la version en page 1.

Heu de mon coté, je vois pas ce que je peut faire avec si peu de détails....

Citation :

et comme le message d'erreur disparaît aussitôt apparu,

Normalement il faut cliquer sur un bouton pour faire disparaitre le message non ?

Et voilà, les deux chevaux sont de retour à l'hippodrome...
(Bon, je n'ai pas trouvé d'où pouvait venir la panne du programme de Nardo26
à mon long programme de 1615 lignes, peut-être est-ce le ddl qui déconne),
mais peut importe, les médecins ont donc mis une attelle à Reine de saba 26
qui va pouvoir cependant courir...
Le départ est donné, Reine de saba 26 boîtille un peu mais arrive à courir quand même, tandis que Belle de nuit 35 en profite pour courir à fond la caisse
et tenter de laisser la pauvre Reine de saba 26 sur place...
(ce que ces juments peuvent être garces entre elles !)
Mais Belle de nuit 35, prenant un tournant à pleine vitesse,
glisse sur le terrain boueux et se casse la figure par terre,
ah catastrophe, encore une mésaventure,
décidément, ces chevaux n'arriveront jamais sur la ligne d'arrivée...

C'est sur le programme FBI, paru dans la catégorie Inutilitaire, qu'a chuté
Belle de nuit :
Le programme décode le contenu des data entre guillemets
et ne s'aperçoit pas que ce ne sont que des chaînes de caractères,
(bon, mais je sens que JL35 va faire )