The only thing I wonder is why all this is important 
for a normal user application...? Perhaps because I never 
needed such thing, but if the goal is to check the 
arguments involved in an RTE, we have oError:args 
(just like Clipper).

Brgds,
Viktor

On 2010 Mar 3, at 02:40, Przemysław Czerpak wrote:

> On Wed, 03 Mar 2010, francesco perillo wrote:
> 
> Hi,
> 
>> I'm writing a personal message so that info won't get public :-)
> 
> OK, but I'm setting CC to harbour-devel list in answer because
> it may help other users and I hope future HVM developers :-) to
> understand how HVM works.
> 
>> but I must say that at least one function is documented in
>> doc/en/hvm.txt: *      __DBGVMVARLGET( <nProcLevel>, <nLocal> ) --> <xRetVal>
> 
> Serious mistake. I'll remove it ASAP.
> BTW this description is wrong. <nLocal> is not an index to local variable.
> 
>> I now "think to know" what valtype S is in the stack... it IS the
>> first item pushed in the stack and is the pointer to the function that
>> is going to be executed...
>> Let's see in a real life example, where the code from .ppo is DevOut(
>> aPrinter[ s_ptr_selec ] ):
>> 
>> Local  13:    S    Symbol: DEVOUT
>> Local  14:    U    <don't know to display type U>
> 
> "U" is NIL, Try
>   ? valtype( "NIL" )
> 
> It's QSELF() value. Inside method it's an object.
> 
>> Local  15:    A    Len:    4
>> Local  16:    N    13.00
>> Local  17:    C    "W/B,GR+/W,N/N,B/N,W+/BG,B/N"
>> Local  18:    N    0.00
>> 
>> aPrinter (local15) has len 4, s_ptr_selec (local16) is 17 so out of
>> bound error is generated...
> 
> There are no local<n> variables. There are only items on HVM stack.
> Some of them belongs to declared function parameters, some of them
> contains additional parameters when user passed more parameters then
> was declared by function, some others belongs to local variables and
> rest is used by currently executed code, i.e. partially calculated
> expressions, WITH OBJECT values, FOR EACH iterators, BEGIN SEQUENCE
> envelopes, called function parameters, etc.
> The function stack frame contains:
> 
>   1              FUNCTION SYMBOL OR METHOD SYMBOL
>   2              QSELF() VALUE (NIL FOR FUNC/PROC, OBJ FOR METHODS)
>   3              DECLARED PARAMETERS <n>
>      ...
>   3 + <n>        ADDITIONAL <m> PARAMETERS IF PASSED MORE THEN <n> PARAMS
>      ...
>   3 + <n> + <m>  LOCAL VARIABLE <l>
>      ...
>   3 + <n> + <m> + <l>  ITEMS ALLOCATED BY EXECUTED CODE <k>
>      ...
>   3 + <n> + <m> + <l> + <k>  NEXT FUNCTION FRAME SYMBOL
> 
>> I could not explain what Local17 and 18 were for... but then realized
>> the following:
>> the function has 5 parameters but in this specific case there are only
>> 3 of them specified in the function call...
>> Since LocalCount = number_of_locals - number_of_params
>> and since number_of_params is 2 less than what should be, LocalCount
>> is 2 bigger than necessary... and so 2 spurious stack elements are
>> printed...
>> So, question 1: is it possible to retrieve the number of parameters
>> declared in a function ?
> 
> Yes. It's possible to retrieve number of declared parameters (<n>+<m> in
> above scheme).
> It's also possible to retrieve number of passed parameters (<n> in above
> scheme)
> 
> It's not possible to detect number of local variables (<l> in above
> scheme) so it's not possible to guess when local variables stops
> and begins execution context items.
> 
> It's possible to detect the whole frame size so <k> is also known.
> 
>> Question 2: for object method I get valtype S... but for function
>> invocation not always... is there a rule ?
> 
> In all cases you have function or method symbol as 1-st item in
> function method frame.
> 
>>> __DBGVMVARL[GS]ET() is internal debug function function and
>>> it cannot be used without additional information which is available
>>> only for debugger.
>> but it works at the moment, in harbour 2.0.0, the one I will use for
>> at least one year...
> 
> And after a year you decided to check what it exactly does and you are
> asking why your code does not work as you want ;-)
> 
> You can always use any internal HVM functions for your own risk.
> It's your choice. I only hope that I do not see any message from
> you when we remove above functions i.e. making some modifications
> in HVM stack or debugger code.
> 
>>>> 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
>> Ok, I had such case... 2 unused locals did shift all the others and
>> they didn't match the values.
> 
> No, you do not have such case.
> You only wrongly expected that 2-nd parameter of __DBGVMVARL[GS]ET()
> function is index to local variables and it isn't.
> 
> In a while I'll add to SVN new function __DBGVMLOCALLIST() which returns
> array with <l> and <k> items in the above function frame scheme and
> below I'm attaching the code which should help you to understand few
> things if you look at <k> items attached to LOCAL variables.
> As I said it's not possible to detect real number of local variables
> in current code. It may change in the future if we store this information
> in hb_vm[V]Frame() function but now it can be done only indirectly for
> code compiled for debugger with -b switch catching the messages with
> names of local variables which are sent to debugger from HVM.
> 
>> The debugger builds aCallStack calling a c function passing it a
>> "info" parameter... is it possible to use such "info" not inside the
>> debugger (I didn't check myself... ) Any other way ?
> 
> You have to modify the debugger code.
> In my opinion it's much easier and cleaner to create own mini debugger.
> 
> best regards,
> Przemek
> <tstframe.prg>_______________________________________________
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to