restarts vs debugger command

[Faré]

> But what about "normal" operation? E.g. I use "of-system" to declare and assert
> that the file is loaded through a correct system. Only a special
> variable works there as there is no condition at all.
>
Why would a file be loaded through the wrong system? Is it something
likely to happen? How often do you write systems with overlapping
files?

That said, if that's a concern you have, e.g. while cleaning up a big
hairy non-incremental build like the one we used to have for QRes at
ITA, instead of a dynamic check with a dynamic variable, why don't you
instead try a static analysis of your system files? See
asdf/contrib/detect-multiply-used-files.lisp for how to do just that.

Finally, going forward, if you use package-inferred-system, you will
be able to easily depend on single files from other systems without
introducing bad dependencies that prevent an incremental build.


> What edit-file does? It can call external editor, wait while user
> finishes the editing
> and then retry operation. But in SLIME and Lispworks my code does just
> some other
> thing: asynchronous message is sent to IDE so that file is opened in
> the IDE. The editing
> is done in another thread and maybe in anoter process (as with
> SLIME/EMACS). Debugger with all restarts is still available, so user
> can choose any restart. When user decides what to do, he can invoke
> the restart he wants.
>
It's your responsibility to have the edit-file function either
synchronize on some buffer commit (C-x # for emacsclient), or just
return immediately, at which point the loop kicks in and you're back
at the same menu, but with an editor window opened.

> After sending a message a control is returned to handler function.
> What is the reasonable action of that function? IMO the only
> reasonable action is to resignal the condition. This is unnecessary
> blinking, or unnecessary output: user just starting to edit, and
> resignaling does not supply user with any new useful information.
>
> This is the difference between restart and "debugger command". Restart
> either fixes the problem or resignals condition (maybe some new one).
> Debugger command (e.g. "show source" or "eval in frame") does another
> thing: it just evaluates some code in current context and then returns
> to the debugger without restarting.
>
OK, I can see that this is a limit with the restart interface, unless
you can somehow integrate the "waiting for the editor to be done" with
your debugger's interface.

> My extension can be kept separated, but it defines some around method
> and thus can interfere with other extensions which could also define
> the same method. This is not very good.
>
This might still be better than patching the source. And if such
conflict DOES occur, it will be time to add a hook for what will
*then* be a commonly used extension point.

> Also maybe I can use some wrapper function to asdf::oos instead of
> patching asdf, but it will not work in the cases where load-system is
> called implicitly, e.g. from ql:quickload.
>
oos is a deprecated API, and not one to define wrappers for. Maybe you
meant operate.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
As the Chinese say, 1001 words is worth more than a picture.  — John McCarthy