Break window does not appear for an unbound variable

[devhawala]

Hello,

here a probably idiot question from a user trying to learn Commonlisp with Medley+Maiko (me).

I'm working through the document "An_Introduction_to_Medley_Release_2.0_Feb92.pdf" found at Bitsavers, using it as a tutorial for my first steps in Medley.

My problem is the "Break package example" in chapter "10. Break package": the expected "break window" simply does not appear when the intentionally wrong function is invoked; instead, the message "DUMMY is an unbound variable" is issued immediately in the executive window, and nothing else happening.

Here's a screenshot:

Is there some additional preparation step needed in Medley 3.51 (compared to Medley 2.0) to get into the debugger (aka. break window) for an unbound variable?

Replacing "DUMMY" with "(BREAK)" in the function does open the break window as expected.

I am using the current version of Maiko (built locally in my Linux environment) and the "full.sysout"-loadup from the current Medley release (medley-220613-c5eb54a3).

Sorry for the interruption and thanks for helping, Hans

[nbriggs]

Type RETRY at it if it doesn’t break

[masinter]

Not so long ago, I tried to tweak the heuristics (see man breakcheck) by setting helptime and helpdepth in the MEDLEYDIR-INIT. I apparently wasn't successful; the man page says it counts internal calls to EVAL against HELPDEPTH but I think this currently only counts stack frames for Interlisp evaluator.

HELPTIME is also a problem since medley on modern machines is so fast that 8 frames of calls takes les than a millisecond. But if you try (setf il:helptime -1) and you will always get a break on error.

I think in the interest of preserving the Interlisp 'experience' we should fix the il:helpdepth comparison to count what Interlisp-10 counted, which was calls to user functions.

[devhawala]

Thank you for the help.

retry works, although requiring to invoke the function first, but it's OK.

Using (set il:helptime -1), also works, but trying to get the value of an unbound variable at an Exec prompt also opens the break window...

So i experimented a bit and tried (set il:helptime 0), which works better at the Exec prompt level: (fact 0) opens the break window, but simply dummy tells "DUMMY is an unbound variable", which is what i was expecting initially. However i understand from your explanation of il:helptime that this may be specific for Medley's execution speed in my environment (Ubuntu 20.04 running in a VirtualBox on an Intel i7-3770 CPU @ 3.40GHz Windows10 machine).
(just for the records: (set il:helptime 1) had no positive effect, i.e. no break window; the initial value of helptime was 1000)

As it worked well so far, i'll stick with (set il:helptime 0)

Greetings, Hans

[masinter]

Should be fixed by PR #932 ...can you try it? #412 covers the same issue, will close it.

[devhawala]

Hello, after a git pull, i checked out the branch better-breakcheck, built the loadups and then ran the tmp/full.sysout.

Doing the above tests (invokling the intentionally wrong fact function or simply entering dummy in an exec-window) now always opens the debugger window. Personally i would have preferred that entering dummy simply tells "unbound variable" without opening the debugger, but the behavior is now like in other CommonLisp environments, so it's OK.

So merge the better-breakcheck branch, this issue can then be closed.

Thanks, Hans

[masinter]

I wanted to tweak things so that they would follow the "Interlisp" way (and also backtrace) for showing "interesting" stack frames also when you do get a break. tested using definition of fact with DUMMY vs. typeing a asadasd variable in XCL and Interlisp execs.

I've updated PR #932. I'm wondering if we should run a little benchmark in MEDLEYDIR-INIT and reset HELPTIME accordingly.... 😆

[masinter]

@pamoroso as we discussed your experience... I think to fix this we need to change the heuristic. The stack depth doesn't seem effective.

What distinguishes cases where you want a break vs. those where you just want an error because you've already determined what you want to try instead.

[pamoroso]

So far the only case I need is triggering an unconditional break to get a Break Window, for which the RETRY Exec command seems to work fine.