Editing component being compiled when compilation failed.

[Faré]

On Wed, Jul 8, 2015 at 5:40 PM, 73budden . <budden73 at gmail.com> wrote:
> Take a look at latest commit:
>
> https://bitbucket.org/budden/budden-tools/src/3cc8612a622055a4ac58be7f496c506332ab01de/asdf-3.1.4-tools.lisp?at=default


>>> 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:
> 1. Minimum effort.
> 2. Maximum portability.
> 3. 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