You are ignoring my proclaimed purpose of improving the testing of ASDF. Sent from my iPhone
> On Aug 25, 2016, at 22:21, Faré <fah...@gmail.com> wrote: > > I'd rather keep it simple. > > End-users don't care WHY something is failing, just THAT it is failing > gracefully and that the reason for failure is known. Users > (programmers) can use M-. from the error to find the source and > comments. A short link to a suitable cliki.net page might help explain > the proper investigation procedure. > > I see no reason for some programmer-intensive protocol that leads to > large image size increase for no clear benefit that M-. won't bring. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Those "organizers" who confuse coordination and cooperation will have 100% > coordination for 0% cooperation. All costs, no benefits. > > >> On Thu, Aug 25, 2016 at 10:37 PM, Robert Goldman <rpgold...@sift.net> wrote: >>> On 8/23/16 Aug 23 -9:55 AM, Elias Pipping wrote: >>> >>>> On 23 Aug 2016, at 15:50, Robert Goldman <rpgold...@sift.net> wrote: >>>> >>>> On 8/23/16 Aug 23 -6:42 AM, Elias Pipping wrote: >>>>> If we can agree on Robert’s unsupported-functionality error class, I’ll >>>>> work that into the merge request, too. >>>> >>>> I have a busy day today, but I will try to get it done. >>>> >>>> I was thinking of having slots for: >>>> >>>> - implementation >>>> - capability name >>>> - optional format control and format args that the programmer can use to >>>> provide additional information. E.g., for LW, say that it's for >>>> licensing reasons that the DELIVER capability is not available. >>>> >>>> If this sounds reasonable, I'll put it in, and try to find places it >>>> should be used. >>>> >>>> In an earlier email, Elias points out that there are related reasons why >>>> a function might have failed. I haven't had time to figure out whether >>>> these would call for additional condition classes. >>> >>> I was thinking: We’re trying to tell the user that what they’re doing does >>> not >>> work. Yes, the function does exist, you’re passing the right number of >>> arguments and the right keywords but there’s a problem. The problem could >>> be: >>> >>> - Your lisp is very old or very new or nobody’s gotten around to looking >>> into >>> it, so even though your lisp might provide the necessary functionality, the >>> wrapper hasn’t been made to cover it yet (that’s what the master branch >>> currently uses (error “not implemented: ~S” #’function-name) for) >>> - You’re passing a combination of parameters that is not supported on this >>> lisp (that’s what the master branch currently uses (assert) for) >>> - The function or combination of parameters you’re calling it with is >>> affected by a known bug on your lisp that we cannot work around. >>> >>> I was thinking that to the user, it does not make a difference which one of >>> those three reasons a function call fails for, so we could use one condition >>> for all three, and unsupported-functionality captures the concept pretty >>> well. >>> >>> The capability name would often have to be a rather long description than >>> just >>> a name this way, though, I’m afraid. I’m not sure if I understand the >>> purpose >>> behind the ‘implementation' key of the condition. If a feature is e.g. >>> missing >>> on lisp A and B, and you’re on lisp A, if would simply contain “A”? Or would >>> it contain something like “A personal edition prior to version 2.5?” >> >> I was focusing on the implementation, and perhaps a version number, >> because I have mostly been thinking about how I would use this new error >> class in the tests. In particular, I was thinking of running the tests >> on all lisp implementations, and catching expected failures, rather than >> doing what we do now, which is disable the tests on platforms where we >> believe a function is not available. >> >> If we were to run tests on all implementations/platforms, and catch >> expected errors, that would help us detect unexpected successes, when >> functionality that used to be broken starts to work. >> >> Well, I have also been thinking about how nice it would be to have an >> understandable, standard error message for users who use an unsupported >> function by accident. >> >> What about: >> >> 1. Capability -- what we were trying to do. >> 2. Implementation name -- string, or could be a keyword, if we were to >> add a list of keywords. >> 3. Optional version number >> 4. Optional platform (for, e.g., "this works on SBCL > 1.2, but not on >> Windows.") >> 5. Additional information (e.g., LW personal edition) >> >> We could have a signal-unsupported-capability function that would >> auto-collect some of these slot values, to make this easier to use. >> >> There's no tearing hurry for this, so I'm happy to have some more email >> cycles so that we can get it right. >> >> Best, >> r >
