On Wed, Jul 8, 2015 at 5:40 PM, 73budden . budden73@gmail.com wrote:
Take a look at latest commit:
https://bitbucket.org/budden/budden-tools/src/3cc8612a622055a4ac58be7f496c50...
Also, you might want to split this into modifications/extensions to ASDF and code that interfaces to the Lispworks IDE.
Maybe. This is just a proof of concept. If it can be accepted to master branch of asdf, I'll try to rework it as needed. If not, I can use it as is.
ASDF has a history of accepting patches for essential functionality and/or for hooks that make extension easier: asdf-output-translations (née as output-files :around methods in common-lisp-controller or asdf-binary-locations), asdf-bundle (née asdf-ecl), various patches contributed by ITA Software, hooks added for poiu or asdf-dependency-grovel, utilities pulled from xcvb, the package-inferred-system inspired by quick-build, etc.
If your can propose a useful restart, and it indeed can't be added via a handler-bind, then we'll definitely consider it — although the maintainer to convince nowadays is Robert.
The general criterion I've used is that if it's a useful feature that cannot be portably bootstrapped from the existing asdf and cannot be retrofitted without patching the source either, it's probably worth accepting the feature and/or adding a hook that makes it possible to bootstrap it.
That's why I made asdf-bundle or package-inferred-system builtins rather than extensions — because there interface between them and the core requires some tight coupling, and once the proper hook is present, the incremental cost of the entire feature is small, whereas the inconvenience of pulling in an extension and doing it so without breaking something is high. On the other hand, POIU has hooks but isn't in ASDF itself, because it's not portable enough, and the hooks could be kept small while POIU remains somewhat large. (But designing around those hooks was instrumental in the conceptual cleanup of ASDF 3).
- It is very poor taste to use special variables and redefine
functions to access the current component.
Maybe, but my design goals were:
- Minimum effort.
- Maximum portability.
- Minimum code impact so that I can support
the tool if it is not accepted into core of asdf.
Extracting data from error condition seem to be more complex and non-portable. First of all, I know no portable way to access debugger stack. SWANK might help, but task can be rather complicated.
It's actually simple and totally portable. These are not implementation-defined conditions, but ASDF-defined conditions.
You 'access' a debugger stack by using handler-bind and restart-case. Then the user uses the debugger that can use the annotations. This modular design is a great strength of CL.
add a restart that doesn't even do the editing for you when it could, why don't you define a handler that adds a restart and re-signals?
What I've done is not so stupid. When we want to edit, re-signalling is unnecessary.
You don't understand what I said. I was thinking of a handler-bind that does something like (handler-bind ((some-asdf-condition (e) ... (restart-case (error e) (edit-file () :report ... (funcall *editor* (condition-component e)))))) ...)
Thus, you can add new restarts without having to patch the code, by just wrapping your editor's calls to asdf in proper handlers.
In fact we need context-dependent debugger command in this case, not a handler or restart.
restarts are EXACTLY "context-dependent debugger commands".
But there is no cross-implementation way to add debugger commands.
Yes there is, it's called... a restart.
Also we can't alter "help" command in a debugger so that we could inform the user of an existence of our "edit" command.
That's what the restart is for.
Fake restart is just a portable approximation to this desired behaviour.
A real restart beats fake restart any day.
Maybe I should also issue a warning on the restart like "This restart does nothing. Please read the restart's message".
No, just have the restart actually do the editing.
- Do NOT use keywordize and string-equal, use coerce-name and string=.
You're introducing subtle incompatibility in your semantics.
Ok, I changed code of of-system. For M-. symbol seem to be necessary and keywordize is the best thing I can do. Any other ideas?
If this is a limitation in your debugger, by all means, convert to keyword, but then: 1- do something magic (case inversion if it's reversible, or else error?) to convert from string to keyword. 2- use coerce-name (or the reverse of your magic transformation) to o back to system name. What you must not do is silently do the wrong thing when the system name isn't equal to the string-downcase of your keywordification.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A successful [software] tool is one that was used to do something undreamed of by its author. — S. C. Johnson