[m-dev.] for review: the new debugger command set

[Erwan Jahier]

Zoltan Somogyi wrote:

> > Sorry it is totaly out of purpose but I can't help with showing you how
> > simply (and funny ;-) this can be done in Opium...
> 
> I knew it could be done simply in Opium, but it just so happens that
> the amount of code required is about the same in C. 

Hmm... a little bit more I think; and spreaded in 7 files ! a 'grep -n
histo <your diff> | wc -l' ---> 66 ! (about 35 if we remove the ones
appearing in the documentation).

My version is more easy to write, more easy to maintain, and can be
change easily. Any user could have written it.
 
> Since it uses direct
> array update, the C code executes in bounded time, whereas the Opium
> version requires at least logarithmic time, and your code requires time
> proportional to depth. Since I have seen the depth exceed 15000, this
> can be somewhat important.

Well, I suppose I could have used arrays too... I don't see why do you
say my code is logarithmic: it just stops at each event and increments
the rigth integer (maybe you mean that the update is logarithmic ?). 

But OK, your implementation is much much more faster at least because
there is no socket traffic but also because your more close to the
metal.

My aim was not to told you you should have used opium to do that but
just to point that it could be easily done in opium; but since you say
you knew it, sorry about that.

This make me think I should show you my code one of these days ...


> > > +i.e. until it reaches a non-final port inside any predicate. Reports
> >
> > don't you mean a final port here ?
> >
> > > +an error if the current event refers to a non-final port.
> >
> > don't you mean a final port again ???
> 
> Thanks for spotting this.
> 
> The implementation continues execution until it reaches a final port,
> as you say. It does not check what port you are at when you give the command,
> so the documentation above is doubly wrong.
> 
> However, I don't think the current implementation does what it was intended
> to do, which is allowing the user to skip past large numbers of nearly
> identical events. These can happen at least four ways:
> 
>         depth event
> 
> 1       100     EXIT
>          99     EXIT
>          98     EXIT
>          97     EXIT
>          96     EXIT
>          ..     ....
>          51     EXIT
>          50     <non-EXIT>      want to stop here
> 
> 2       100     FAIL
>          99     FAIL
>          98     FAIL
>          ..     ....
>          51     FAIL
>          50     <non-FAIL>      want to stop here
> 
> 3       100     FAIL
>          99     REDO
>          99     FAIL
>          98     REDO
>          98     FAIL
>          ..     ....
>          51     REDO
>          51     FAIL
>          50     REDO
>          50     <non-FAIL>      want to stop here
> 
> 4        50     REDO
>          51     REDO
>          98     REDO
>          99     REDO
>          99     REDO
>          ..     ....
>         100     REDO
>         100     <non-REDO>      want to stop here
> 
> (The second sequence is the same as the third, except that it is from
> a program which was compiled witht --no-trace-redo.)
> 
> The name "forward" is an appropriate name for a command that implements
> the last three sequences. It should stop whenever it finds an event which
> is not REDO or FAIL.
> 
> Maybe we need a new command for implementing the first, which should stop
> whenever it finds an event which is not EXIT. Any suggestions?
> 
> Actually, it may be useful to have two variants of each command,
> one that pays attention only to the event type and one which also
> stops if the procedure involved in the event changes.

This make me think to something Mireille told me to suggest you a few
months ago: you could provide a kind of f_get/1 (forward_move/1)
primitive within the internal debugger too.
Then user could specify queries like:
f_get([port=not(exit)])
f_get([pred=foo, port=exit])
f_get([chrono=1..300, depth=3..10, pred=[foo1, foo2, foo3],
module=not([io, list, bar]), port=[exit,fail], ...]) 
...


then you could define alias:
alias step 	f_get([])
alias forward	f_get(port=not[redo, fail])
alias forward2  f_get([pred=not(foo) or port=not[redo, fail] ])    
...

of course, it may be a little short for the next release.



-- 
R1.