[mdosnov2016]

Does anybody know how to set specific number of breakpoint iterations for the debugger to stop at?

E.g. using the getBPcount() or other relevant functions?
Can you give me an example?

[Thomas Linder Puls]

getBPcount and other predicates in debugApi can be used in PIE scripts in the Action field on a breakpoints properties.

It is an undocumented feature, and I am not quite sure how stable it is. I never use it myself.

Instead I use hard/soft breakpoints, and the strategies described in: Debugging tips: nothing.

If you press Debug -> Run Skipping Soft Breakpoints the debugger will not stop in Soft breakpoints only in Hard breakpoints. Typically you use this by setting a hard breakpoint in some high level code that brings you to the "right" state, and once you are in that state you continue the execution with Debug -> Run and then you will also stop in the soft breakpoints. That way you can (hopefully) skip the breakpoint for uninteresting cases, but stop in it in the interesting case.

[mdosnov2016]

my problem is rather more specific.
I want to repeat a certain times on a breakpoint, without pressing all the time the key.
Just imagine a breakpoint, that I want to examine only its 1000 and 100000th time of occurence,
without having to click or press the key 1000 and 100000 times!

[Paul Cerkez]

how about inserting a simple test step at the beginning of the iteration for a key board entry if the Iteration count = a specific number? (it's the way I used to do debugging in VIP before there was a debugger).

[Thomas Linder Puls]

Yes, that can be achieved using the "nothing" technique:

Original code (except for the comment):

Code: Select all

clauses
    iter(X, Y, Z) :-
        % Want to break here at 1000'th entry
        A = doSomething(X, Y),
        ...

"nothing" code:

Code: Select all

fact
    count : unsigned := 0.
 
clauses
    iter(X, Y, Z) :-
        count:= count +1,
        if count = 1000 then
            nothing() % breakpoint here
        end if,
        A = doSomething(X, Y),
        ...

It is of course "sad" to have to update the code to do the debugging. But the great advantage is that the changes you make are made in the normal language, and in with full access to state in the program.

So the test can be much more interesting than just number comparison. A count is rarely a good way to reach the interesting situation.

nothing is marked as deprecated to give you warnings that can remind you to remove the debugging code again once the debugging is finished.