> 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
