On Tue, 02 Mar 2010, francesco perillo wrote:
Hi,
> Thanks,
> but in a function like this:
> function fun( ff1, ff2, ff3 )
> local l1
> l1 := "L1"
> ? "FUN"
> ? TraceNow()
> return .T.
>
> and in TraceNow() I use __DBGVMVARLGET(level) to retrieve the local
> variable at "fun" level I get:
> Local1: C "f1"
> Local2: C "f2"
> Local3: U <don't know to display type U>
> Local4: C "L1"
> Local5: S <don't know to display type S>
> Local6: U <don't know to display type U>
These are expected results.
BTW
? sSymbol:name
shows symbol name.
"U" is NIL.
You can use hb_valToExp() to display any values.
__DBGVMVARL[GS]ET() is internal debug function function and
it cannot be used without additional information which is available
only for debugger.
Please also remember that we are free to remove this function in any
moment so you are using it for your own risk.
It's also the reason why I do not want to explain how it works on
public forum. Just simply it may increase number of people using it.
> Local1,2 and 3 are ff1 ff2 ff3
> Local4 is l1
> and Local5 and 6 ??? where are they from ?
For developers working on core code it's clear what this function does.
They are also free to modify HVM or debugger to work in different way,
change this function, remove it or replace by any other one.
We lost such freedom in farther developing when we begin to document
such low level code (BTW we should remove comments from vm/debug.c
because they are completely wrong in few cases).
> Is it also possible that the compiler removes local variables (both
> LOCAL or parameters) present in function definition not used in the
> function ? or that they are changed position in the LocalX list ?
Yes it's possible though in current compiler code it is used only to
eliminate unused local variables or replace some readonly local vars
like
local self := qself()
by direct qself() calls which is a little bit faster then accessing
local variables.
It may change it the future when we begin to add different optimizations.
> Is there a way to retrieve the variable names (after compiling with -b
> flag) as in the debugger ?
Yes. You have to write mini debugger which will collect such information
during code execution so later such names can be accessed. Or you can
change existing debugger code to extract such information from it.
Using public API you can create sth like:
proc dispStack()
local cProcName, nProcLine, cProcFile
local aParams, cParams
local i := 0
while ! empty( cProcName := PROCNAME( ++i ) )
nProcLine := PROCLINE( i )
cProcFile := PROCFILE( i )
aParams := HB_APARAMS( i )
cParams := hb_valToExp( aParams )
cParams := substr( cParams, 2, len( cParams ) - 2 )
? cProcFile + "[" + hb_ntos( nProcLine ) + "]: " + ;
cProcName + "(" + cParams + ")"
enddo
return
It shows:
<filename>[<line>]: <funcName>( <params,...> )
I.e.:
tst.prg[15]: FUN1("P1", "P2", "P3")
Anything more needs to touch internal code which we are free
to change without keeping backward compatibility.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
