Comment savoir le numéro de ligne qui appel une procédure ?

[Shadow]

Salut,

Comment savoir le numéro de ligne qui appel une procédure ?
J'aurais besoin de savoir comment faire pour savoir quel ligne dans mon code à appeler tel procédure, ex:

Code : Tout sélectionner

1: Procedure Machin()
2:   Debug "Machin() a été appelé depuis la ligne: 6" 
3: EndProcedure
4: 
5: 
6: Machin()
7: 

Mais je ne vois rien dans PB qui face ça !

[Zorro]

parceque ton code ne reste pas tel quel

Purebasic est un compilateur , ce qui signifie que ton code remplis de ligne de Texte, ne reste pas ainsi
il est transformé en mnemonique assembleur au moment de l'execution

Purebasic n'est pas un interpréteur, mais un compilateur .....
c'est impossible de connaitre le numéro de ligne, car celles-ci pour Purebasic n'existent pas !!

elle ne sont visible QUE dans le cadre de ton editeur .(pour un coté pratique, pour nous codeur, mais le code, il s'en fout )
la preuve, tu ne peux pas ecrire 10 Goto 10 en Purebasic

[Shadow]

Ok comment faire alors ?
Merci.

[Zorro]

tu peux eventuellement utiliser les "parametres" de procedure pour recuperer l'info

comme ceci :

Code : Tout sélectionner

Procedure Machin(x)
   Debug "Machin() a été appelé depuis machin("+str(x)+")"
 EndProcedure


Machin(1) ; on passe dans l'appel un numero d'identification

Machin(3)

machin(2)

[Shadow]

Pas bête, merci

[Ar-S]

Heu... PB est futé

Code : Tout sélectionner

Debug "Procedure toto ligne " + #PB_Compiler_Line
Procedure toto()
procedurereturn 1
endprocedure

Debug "Appel de ma proce toto ligne " + #PB_Compiler_Line
toto()

 

[Shadow]

Merci Ar'S, zorro ma donner une bonne méthode aussi.

[Ar-S]

Oui enfin quand le compilo possède une constante dédiée, je ne vois pas l’intérêt d'ajouter un paramètre à une proce.
J'ai donné l'info fais en ce que tu veux.

[Naheulf]

En plus, la constante #PB_Compiler_Line se met à jour automatiquement si tu ajouter d'autre lignes de code avant.

Si néanmoins tu veut vraiment passer le numéro de ligne en paramètre de ta procédure, utilise cette constante au lieu d'un numéro de ligne écrit en dur à la main.

[Shadow]

C'est se que j'ai fais merci

[Ollivier]

L'option << commented >> permet de donner l'équivalent ASM de chaque ligne.

En inventoriant tous les opérations ASM CALL avec une map : myLine(Str(CallAddress) ) = LineNumber

Dans une procédure, si on sait le nombre et la qualité de chaque argument, on calcule le décalage. Grâce au décalage et au pointeur de pile, on retrouve l'adresse.

Et grâce à l'adresse et la map, on retrouve la ligne.

Ça nécessite de créer la map, à chaque compilation, en pré-compilation et un fichier d'inclusion pour avoir une procédure qui retourne la ligne d'appel.

[Zorro]

un prg compilé en EXE , n'a aucun moyen de connaitre le numero de ligne
puisque celle-ci n'existe pas APRES compilation

il ne reste QUE des Adresses Mémoire rien d'autre

la fonction "Debug" ne marche plus sur un Prg compilé (EXE) ... car tout le contexte lié au débuggage disparait

la constante que vous donnez, ne concerne que le Cadre de l’éditeur, et SEULEMENT ce cadre (en cours de compilation, mais plus apres)

les Numéros de ligne, n'ont pas d’existence dans un code Compilé , ou alors, on m'a caché le fait que Purebasic soit un INTERPRETEUR .....
mais je ne pense pas etre passé a coté de cette information .....


ps: "Commented" est une directive de compilation qui permet de ressortir le listing AVANT la transformation en Exécutable
un exécutable en fonctionnement, NE PEUX PAS connaitre les numéros de lignes

extrait de la DOc :

#PB_Compiler_Line : Numéro de la ligne du fichier en cours de compilation, utile pour debogguer.

encore une fois ceci est une directive de compilation , ça n'a aucun intérêt pour un prg compilé ....
c'est directement lié a l'editeur ..... sans l'editeur (ou un editeur externe) ceci n'a pas d'existence ...

hors la question etait clair , c'est bien dans le cadre d'un Executable Compilé (code en fonctionnement ) qu'il voulait récupérer le numéro de la ligne de l'appel de la fonction
et dans ce cadre , seul les paramètres de fonction peuvent renvoyer une information valable
parce que si c'etait pas dans ce cadre là , il suffit de lire son listing pour savoir quelle Appel , appel la procedure......

les numéros de ligne, n'existent pas pour un Prg Compilé (Exe) point barre ...

toutes ces directives de compilation et les fonctions lié au débugger ne marchent que dans le cadre de la mise au point du code
compilation avec Débugger ON

mais dans le cadre de la VRaie compilation , tout ceci s'envole .. il ne reste que des ADRESSES MEMOIRE , et alors seul les parametres permetent de savoir
ce qui est a l'origine d'un Appel de procedure

[Marc56]

Code : Tout sélectionner

un prg compilé en EXE , n'a aucun moyen de connaitre le numero de ligne
puisque celle-ci n'existe pas APRES compilation

Dans certains cas on peut ajouter ces informations

Dixit l'aide: Utiliser le compilateur en ligne de commande
-l, --linenumbering, /LINENUMBERING: ajoute des informations concernant les lignes et les fichiers sources à l'exécutable, qui peut le ralentir considérablement. Ce qui permet à la bibliothèque OnError d'indiquer le fichier et le numéro de ligne en cas d'erreur.

Exemple de résultat:
https://www.purebasic.fr/english/viewto ... =4&t=74837
https://www.purebasic.fr/english/viewto ... 87#p551087

Bien souvent (et pas seulement en PB) on compile les versions beta avec ces options pour informer plus précisément les développeurs.



Edit: j'ai testé /LINENUMBERING avec le compilateur ligne de commande et l'exempel de la doc (OnError): ça n'affiche pas le numéro de ligne

[Zorro]

le commutateur /linenumbering est lié a l'utilisation du débuggeur


lorsque tu compiles avec le DEbugger ON , tu ne fait pas une "Vraie" compilation ....

je parle de Programme Compilé final .... pas de code Managé par un Débuggeur ...

je veux dire, il ne faut pas laisser penser que le mode Particulier "Compilation+Debugage" soit une compilation complète ...

. je ne connais pas le fonctionnement interne de Purebasic, mais je doute que si un Fichier Executable est généré (pas vérifié ce point )
il soit du meme acabit qu'un Executable Standard .... , je ne pense pas qu'on puisse utiliser un Prg compilé de la sorte ....(en dehors de l'editeur bien sur)



mais apres tout..... finalement ..... peut etre ... je ne me suis pas relancé dans les arcanes de Purebasic depuis un moment donc ..... mais je doute quand meme


@Marc56 tu as essayé avec l'ajout de " /DEBUGGER " ??


en clair, il ne faut pas confondre "compilation Avec Debuggeur" qui concerne l'editeur et le debuggage (un mode tres spécial) et Compilation-> dans le but d'avoir un Exe ....

en matiere de programmation , perso, je pense toujours "Version final" (d'ou ma reponse a propos des numéros de lignes)

[Marc56]

Code : Tout sélectionner

 tu as essayé avec l'ajout de " /DEBUGGER " ??

Oui, ça ouvre le debuger externe

Il y a forcement une façon de faire puisque les versions beta de PB indiquent ce numéro de ligne.
Ici l'un des messages trouvé sur
https://www.purebasic.fr/english/viewto ... 3d#p551087
Il indique Line 245


si on fait -d -l alors l'exe généré fait 250 ko de plus et l'erreur avec le numéro de ligne s'affiche en mode texte et propose d'ouvrir le débuguer en ligne (il semble donc que celui-ci soit alors embarqué dans l'exe d'où la taille) ?

Code : Tout sélectionner

[Debugger Warning]  The OnError library may not catch all errors with enabled debugger.
[Debugger Warning]  File: OnErrorLine.pb (Line: 3)

[Debugger Error]  Invalid memory access. (write error at address 10)
[Debugger Error]  File: OnErrorLine.pb (Line: 4)
  Fatal error. Do you want to open the Debugger console? (Yes, No)
y

==============================================
 PureBasic Console Debugger
==============================================

Type 'help' for command options.
DEBUGGER::