UNSUPPORTED-FUNCTIONALITY Error [was Re: Version 3.1.7.7 has been pushed]

Faré fahree at gmail.com
Fri Aug 26 11:42:24 UTC 2016


On Fri, Aug 26, 2016 at 12:50 AM, Robert P. Goldman <rpgoldman at sift.net> wrote:
> With all due respect, a few minutes ago you were saying I shouldn't expect to have the source code, in response to my desire to restore some of the source-finding functionality of load truename, but in this message you are telling me it's enough to have simple error objects because everybody has meta-dot to fall back upon.
>
You shouldn't have source code to *use* ASDF and understand THAT there
is a bug and its nature. Hence, asserts not being OK to trigger in
user-facing code. When additional run-program functionality is
exposed, its asserts must be turned to conditional errors.

But you SHOULD have source code to *debug* ASDF. If you want to make
your platform supported or discover why it isn't and what other
platforms ARE supported, it's alright to require source code. And it
is NOT alright to require programmers to duplicate the complex #+
patterns in source code into each and every error message. This way
lies madness, as it will be hell to synchronize the source code with
the in-source-code description of what precise implementations cause
the code to fail.

Already, I had a bug matching a list of #+... with a #-(or ...) as the
code evolved. If you believe you'll be able to provide for each error
message a list of supported implementations with its minimal supported
version number, you're sorely deluded.

What next? Have each error message include a matrix of which ASDF
version supports which interface with which bug fix on which versions
of which implementations? Including future versions? That's complete
madness.

If you believe some power users care about such details, a more
future-proof way, once again, is to include a short URL in the error
message, and maintain your compatibility matrix there.

If you're only trying to report version numbers, there's
implementation-identifier and asdf-version for that, and I don't see
any reason to decorate some error messages with that and not others.

As for testing ASDF, we have asdf-test:with-expected-failure to keep things sane
and #+ and leave-lisp to skip meaningless tests.

> So now I find myself arguing for the position you articulated in your last response! With respect to ASDF ( and explicitly as opposed to the case of my DSL, which happens to simply not work if the source code is not present), we know that programmers often have bundled copies of ASDF, provided by vendors without source, and so meta dot does not work.
>
That should be OK to use ASDF. If they hit ASDF limitations or bugs
and want to investigate, it is alright to require them to have ASDF
sources. Indeed, we encourage people to install the latest (release)
ASDF from source before they report a bug.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Who released the most slaves? The one who spent his wealth buying them back?
Or the capitalist who found a way to power mills with water? — Paul Claudel



More information about the asdf-devel mailing list