Analyse d'un programme source .bas

Moi je suis abasourdi par la qualité du commentateur de course
Il est trop fort, les mots choisis sont supers

L'avantage c'est qu'il trouve les erreurs il ne fait pas que commenter

Oh, oh, on dirait que Belle de nuit 35 reprend du poil de la bête !
Bon, mais maintenant, c'est...
et pour la suite de la course, ce sera pour plus tard,
demain ou dans quelques jours...

@jl35: en fait, le problème est dans la commande
c$ = mid$(a$, u%, 300)
Cela a déjà été signalé sur le forum. Panoramic interprète le contenu de l'expression de droite, au moment de l'affectation dans une variable, et NON au moment de l'utilisation dans une expression. Il découvre alors, comme pour une constante, que le string est entouré de guillemets, et il les élimine. La preuve ? Il suffit de regarder ton morceau de code auquel j'ai ajouté une seule ligne, mais sans fioritures de présentation, et on voit d'autant mieux:

Code:

dim a$, c$, u%
FONT_NAME 0, "Lucida Console"
a$ = "s$="+chr$(34)+chr$(34)+":e$="+chr$(34)+chr$(34)+":n$="+chr$(34)+chr$(34)
print "a$                = " + a$
u% = 5: print "u%                = " + str$(u%)
print "mid$(a$, u%, 300) = " + mid$(a$, u%, 300)
c$ = mid$(a$, u%, 300): print "c$                = " + c$

print c$

end

c'est bien le contenu de c$ qui n'est pas correct ! Ce serait à Jack de se prononcer si c'est un effet voulu (pourquoi pas, mais alors, il faut le documenter), ou si c'est un bug.

C'est bien ce que je suggérais, et j'aurais tendance à considérer ça comme un bug, pour moi une chaîne de caractères doit pouvoir contenir n'importe quel caractère de 0 à 255.

Ca y est, l'adaptation est faite et le système fonctionne.
La course a donc repris, les chevaux sont très en forme tous les deux,
les pur-sang ont revêtu leur plus belle parure
Reine de saba 26 (casaque doré or et tunique bleu roi)
et Belle de nuit 35 (casaque rouge vif et tunique jaune fluo)
sont au coude à coude et on ne peut pas encore dire qui va l'emporter...

J'ai vérifié avec les 8 programmes que j'avais précédemment essayés,
là, ça va beaucoup plus vite, car il n'y a pas d'erreur pour le moment,
et le vérificateur que j'ai fait me dit dit simplement s'il y a une erreur (ou plus) ou pas
je vérifierai plus tard les deux programmes à une plus grande échelle,
donc, la suite au prochain épisode...

(ne manquez surtout pas notre feuilleton « Tiercé 35-26 »...)

C'est haletant !

Yes... mais je connais déjà le résultat :
Belle de nuit vainqueur !
-> il y a une faille dans mon prog sauf si je casse tout et que je recommence à 0...

Alors là... par expérience je ne me hasarderai jamais à dire qu'il n'y a pas de failles dans le mien !

Un rapide aperçu de votre feuilleton hippique quotidien :
Reine de saba 26 vient de prendre la tête du peloton
sur Belle de nuit 35 qui commence à s'essouffler...
Voyez combien le résultat est encore incertain,
la suite de la course au prochaine épisode...

Bon, concrètement, ça veut dire que j'ai trouvé de nouvelles erreurs :

1) le pg de JL35 trouve une variable d (qui existe, certes, mais ailleurs)
dans des lignes comme :
item_add 17,a$
ou
if instr(a$,".")=0 then item_add 17,a$
bref des lignes où il y a toujours item_add

2) très particulier, avec filebin_block_read
si j'utilise une variable y%(2500)
et que j'écris filebin_block_read 1,2,y%
(sans les parenthèses, ce qui marche)
Le programme de JL35 ne trouve pas la variable y%
alors, j'ai failli laisser tomber en me disant : là, je chipote
mais le problème, c'est que le programme de Nardo26
ne s'y trompe pas, il reconnaît y%
et le classe dans la catégorie y%(2500)

Décidément, ces percherons surprendront toujours...
Je n'ai fait d'essais que sur 8 nouveaux programmes,
la suite du haletant feuillon au prochain numéro !

Tu vois bien Nardo que rien n'est perdu !
Pour le d intempestif avec item_add, je regarde.

Par contre, l'utilisation de y% pour le tableau y%(2500) me surprend, je n'aurais pas pensé que ça puisse marcher ! et d'abord ça va s'écrire à quel endroit dans le tableau si on ne précise pas ?
Moi je cherche y%( et évidemment là je ne trouve pas...
Mais je m'incline, de mauvaise grâce, si c'est utilisé comme ça...

Gnniii, gnniii, gnniii !
(rire méphistophélique)


(sauf que Méphisto..., maintenant il va aller )
à demain, ou plus...

Mon cher jjn4 (et autres oiseaux de mauvais augures),

1) j'ai corrigé la grossière erreur de trouver la variable d dans item_add etc. (et autres erreurs du même acabit), j'en suis honteux, mais bon, c'est fait.

2) concernant l'erreur selon laquelle je ne trouve pas la variable tableau y%(2500) dans filebin_block_read 1,2,y%, je ne fais rien parce que je trouve que cette syntaxe est incorrecte, même si cette incorrection n'est pas détectée par Panoramic.
Ce n'est pas normal d'écrire cette instruction de cette façon, et je ne veux pas cautionner tes mauvaises habitudes !
La documentation demande de préciser à quel endroit du tableau les octets doivent être rangés, et dans le cas que tu cites, où vont-ils aller ? pour moi, même si ça marche, c'est une erreur de syntaxe, avec un résultat indéterminé.
Je rappelle la documentation Panoramic concernant FILEBIN_BLOCK_READ:

Citation :

FILEBIN_BLOCK_READ N,C,V%(P)
LIT C OCTETS DANS LE FICHIER BINAIRE NUMÉRO N ET STOCKE LES
VALEURS DANS LE TABLEAU V% A PARTIR DE L'INDICE P

......

Code:

EXEMPLE
rem ouvre un fichier binaire en lecture
filebin_open_read 1,"file.abc"
rem on se positionne en 5
filebin_position 1,5
rem lit 10 octets
filebin_block_read 1,10,v%(7)
rem affiche le second octet lu
print v%(8)
rem ferme le fichier binaire
filebin_close 1

Cela dit, jjn4, bravo et merci quand même pour ton travail d'investigation, efficace et constructif, je reconnais que tu en as peut-être plus bavé pour écrire les tests que nous pour écrire le programme !

PS j'édite mon programme en 1ère page, maintenant il est parfait (enfin... j'espère.. )

Si, si, la syntaxe est correcte - Panoramic stocke les valeurs à partir de l'indice 2500 ! L'erreur, elle est dans la VALEUR 2500 et non pas dans la syntaxe. Il aurait fallu passer y%(0) pour lire jusqu'à 2500*4 octets, ou y%(300) pour en lire un peu moins, etc. Mais la syntaxe V%(P) est valide et a un sens - elle permet de remplir le tableau à partir de l'indice P avec le nombre d'octets voulus, quel qu'en soit le contenu. Ca, c'est à gérer dans l'application, après la lecture. Mais il faudrait bien détecter le y%(...) comme référence au tableau y%(2500).

Mon cher Klaus, on ne s'est pas bien compris ou je me suis mal exprimé, en tout cas je suis entièrement d'accord avec ce que tu dis.

L'exemple que donnait jjn4 était celui-ci:

Citation :

2) très particulier, avec filebin_block_read
si j'utilise une variable y%(2500)
et que j'écris filebin_block_read 1,2,y%
(sans les parenthèses, ce qui marche)
Le programme de JL35 ne trouve pas la variable y%
alors, j'ai failli laisser tomber en me disant : là, je chipote
mais le problème, c'est que le programme de Nardo26
ne s'y trompe pas, il reconnaît y%
et le classe dans la catégorie y%(2500)

et pour moi c'est incorrect, je considère que la variable y% de cette ligne ne correspond pas au tableau y%(..) déclaré, donc je ne fais pas le rapprochement. Il manque dans la ligne après y% les parenthèses 'tableau' et l'indice de rangement, sinon ça n'a pas de sens. C'est pour moi une erreur de syntaxe, et pourtant apparemment ça n'est pas détecté par panoramic.

Je viens d'essayer, pour vérifier:

Code:

DIM y%(2500), i%, a$

FILEBIN_OPEN_READ 1,"C:\Textes\LOREM.TXT"
FILEBIN_BLOCK_READ 1,20,y%
FILEBIN_CLOSE 1
FOR i% = 1 TO 20: a$ = a$ + CHR$(y%(i%)): NEXT i%
PRINT a$
END

Panoramic ne signale aucune erreur et lit bien le début du fichier dans le tableau, à partir de l'indice 0 du tableau. Mais c'est ambigü, et je maintiens que c'est une syntaxe incorrecte.
Dis-moi ce que tu en penses ?

Oui, c'est une syntaxe incorrecte. La doc impose bien une variable indicée avec spécification d'un indexe. Et à d'autres endroits, Panoramic fait bien la différence, au niveau syntaxe:

Code:

dim i%, k%,y%(2500)
print adr(k%)  : ' ça marche
print adr(y%)  : ' c'est rejeté !
print str$(adr(y%(0)))  : ' passe, mais résultat 0 !
print str$(adr(y%(1)))  : ' passe, mais résultat 0 !
print str$(adr(y%(2)))  : ' passe, mais résultat 0 !
print str$(adr(y%(3)))  : ' passe, mais résultat 0 !

Cela porta à réfléchir. As-tu essayé de passer y%(0), puis y%(10) à file_block_read pour voir où il place les données ? Mes résultats "adr" s'expliquent peut-être par le fait qu'en réalité, y%(n) est une expression en NON une référence à l'endroit où est stocké le n-ième élément de y%, et adr() ne peut pas retourner l'adresse d'une expression. Néanmoins, d'après la doc, Panoramic arrive à faire cet exploit avec file_block_read. Bizarre...

Bien entendu si on précise un indice dans le tableau du filebin_block_read, les données sont rangées à cet indice, mais si on ne précise pas d'indice (ni de parenthèses d'ailleurs) c'est rangé à partir de zéro du tableau.
J'aurais admis à la rigueur la syntaxe y%(), avec indice 0 implicite, mais là sans les parenthèses c'est quand même étonnant que ça marche.

Et tes exemples montrent bien qu'il y a une lacune, c'est normal qu'il rejette la syntaxe adr(y%), pas normal qu'il l'accepte dans le block read.

Et pour les adresses dans le tableau, ce n'est pas au point, en fait quand tu fais:
ADR(y%(0)) ou ADR(y%(10)), il rend le CONTENU du tableau à cet emplacement, et non l'adresse !

Trop fort !
Mon prog tient compte des bugs de panoramic !!!!

@Naro26 : mais c'est que tu as raison, en plus !

Des nouvelles de notre course folle et des paris que vous avez fait :
La course a repris, et Reine de saba 26, toujours en forme,
revêtue cette fois-ci d'une casaque marbrée rouge et or et d'une tunique fauve,
trotte comme une dératée, et devance encore Belle de nuit 35 d'une courte tête,
pauvre Belle de nuit qui n'a que des déboires depuis le début de cette course,
la suite de votre palpitant feuilleton au prochain épisode...

Pas sérieux, JL35
l'erreur que ton programme faisait avec les d,
maintenant, il les fait avec les a
(sur des programmes que j'avais vérifiés et où il ne le faisait pas)
il me déclare une variable « a » à la ligne suivante :

Citation :

if fa=1 then a$="Click on an image included"+chr$(13)+"in a directory containing"+chr$(13)+"very much photos"

(nota: la variable a existe dans le programme, mais pas à cette ligne)
Décidément, rien ne vaut les percherons !
(et JL35 qui pensait que sa dernière version était (presque) parfaite)
Gnniii, gnniii, gnniii

Citation :

Hâtez-vous lentement, et, sans perdre courage,
Vingt fois sur le métier remettez votre ouvrage :
Polissez-le sans cesse et le repolissez ;
Ajoutez quelquefois, et souvent effacez. [...]
Boileau (l'Art Poétique)

mea culpa, un petit oubli (de rebouclage) dans la suppression des éléments entre quotes.

Bon, alors les dernières nouvelles de la course hippique :
Les deux chevaux courent au coude à coude avec mordant,
lorqu'au moment de sauter une haie,
Belle de nuit 35 s'emmêlent les pinceaux et fait une chute spectaculaire sur le sol,
suivie bientôt par Reine de saba 26 qui s'étale à son tour et roule comme un tonneau.
Catastrophe ! Les deux juments sont au sol, vont-elles pouvoir se relever ?
Vous le saurez en suivant le prochain épisode de Tiercé-35-26
prochainement sur votre écran...

Alors, voilà ce qui se passe exactement :
A la vérification faite avec le programme :

Citation :

rem ' Alerte-Incendie
dim f , g , h , i , j , k , m , n , a$ , c$ , b$(1) , t(24) , l(4,4) , cp

ce programme est édité dans la catégorie Inutilitaires,
il comporte les variables ci-dessus précisées.
Le programme de JL35 l'analyse ainsi :

Citation :

****** LISTE DES VARIABLES (15) ******

4) [3]
a$ [3],58,59,60,65,66,71,72,73,74,75,76,101,102,103
b$(1) [3],6,59,72
c$ [3],7,75
cp [3],45,52,76,112
f [3],36,48,51
g [3],61,64
h [3],57,58,65
i [3],12,14,15,16,17,18,19,21,37,38,39,40,41,42,44,46,48,
50,56,70,83,84,85,86,93,95,97,104,113,114
j [3],13,14,15,16,17,18,19,20,41,42,47,48,49,81,87,94,95,
96,114
k [3],36,38,43,82,85
l(4 [3],41,48,114
m [3],82,85
n [3],36,39,44
t(24) [3],38,39,44,56,70,104,113

Autrement dit, il coupe la variable l(4,4) et en fait 2 variables :
4) et l(4
et compte donc 15 variables alors qu'il n'y en a que 14.

Quant au programme de Nardo 26 :
il ne trouve pas la variable h située à la ligne 58 qui est :

Citation :

a$="L'immeuble a pris feu, il y a "+str$(h)+" morts par votre faute"

par contre, il la trouve à la ligne 65 qui est presque identique :

Citation :

a$="Vous êtes condamné à "+str$(h)+" années de prison"+chr$(13)+chr$(13)+"Fin"

Aïe, aïe, aïe, que de péripéties dans cet incroyable feuilleton !

Aïe, les tableaux à deux dimensions...
Je vais finir par prendre le mors aux dents !

C'est réparé.
J'y avais bien pensé aux tableaux à double entrée, mais ça ne marchait que s'il n'y avait pas d'autres tableaux avant dans le dim.
J'ai changé l'algorithme de détection, maintenant ça devrait aller.

C'est vrai que la place de Zitrone/JJN4 est la meilleure





A+

Je vois vraiment pas pourquoi la ligne 58 est zappée !

Peut-être l'apostrophe dans la chaîne qui précède qui met le bazar (L'immeuble...) ?

Meeuuuufff, Zitrone, il n'y a aucune ressemblance !
La preuve, Voilà Léon Zitrone (en caricature) :

et me voici (en caricature) :

Voyez bien que ça ressemble pas du tout !