[asdf-devel] Would like to disable bundle-op on known not-working implementation X platform combinations
Per the principle of failing obviously, I propose to raise an error upon attempts to use bundle-op with ECL or ABCL on Mac OSX. The bundle-op tests have been failing for me on those platforms for as long as I can remember. For ECL, at least, I believe this to be an implementation bug, having to do with the Mac's 32-/64-bit hybrid architecture. With the current disarray in ECL maintenance, I don't see any signs of this being fixed. For ABCL the cause of this issue is more mysterious, but it is still persistent. Unless someone squawks, where "squawks" includes "explains why this test failure is specific to me or provides a proposed patch," I will make that change. Cheers, r
On Fri, Jan 3, 2014 at 10:29 AM, Robert P. Goldman <rpgoldman@sift.info> wrote:
Per the principle of failing obviously, I propose to raise an error upon attempts to use bundle-op with ECL or ABCL on Mac OSX. The bundle-op tests have been failing for me on those platforms for as long as I can remember.
For ECL, at least, I believe this to be an implementation bug, having to do with the Mac's 32-/64-bit hybrid architecture. With the current disarray in ECL maintenance, I don't see any signs of this being fixed.
For ABCL the cause of this issue is more mysterious, but it is still persistent.
Unless someone squawks, where "squawks" includes "explains why this test failure is specific to me or provides a proposed patch," I will make that change.
Didn't you disable the test in e2b70dd1 before 3.0.3? Do you mean you want the code to issue an early error without even trying? I think that's a bad idea that only makes the real issue harder to see and fix; as long as the backtrace makes it clear where the thing is failing, there's no need to obfuscate the implementation bug. At worst, maybe wrap the issue in a handler-bind that adds ASDF's own warning to the error? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Christmas is the time when kids tell Santa what they want and adults pay for it. Deficits are when adults tell government what they want and their kids pay for it.
Yes, I want to disable this on platforms where it is known to fail. Unfortunately, the backtrace does not make it at all easy to tell where the failure has occurred, so the poor user will have no way to tell that the failure is not his or her fault but the fault of ASDF and the implementation. On ABCL the bundle files (jar files, IIRC), for some reason, are simply missing files that should be present. On ECL, something goes pear-shaped deep in the interaction with C. Neither test yields an error I can make heads or tails out of. I was thinking of issuing some form of warning that indicates that here be dragons, and the user is proceeding at his/her own risk. That isn't quite full disablement, but it will keep people from wasting their time in a futile way if it bombs out. Cheers Sent from my iPad
On Jan 3, 2014, at 23:10, Faré <fahree@gmail.com> wrote:
On Fri, Jan 3, 2014 at 10:29 AM, Robert P. Goldman <rpgoldman@sift.info> wrote: Per the principle of failing obviously, I propose to raise an error upon attempts to use bundle-op with ECL or ABCL on Mac OSX. The bundle-op tests have been failing for me on those platforms for as long as I can remember.
For ECL, at least, I believe this to be an implementation bug, having to do with the Mac's 32-/64-bit hybrid architecture. With the current disarray in ECL maintenance, I don't see any signs of this being fixed.
For ABCL the cause of this issue is more mysterious, but it is still persistent.
Unless someone squawks, where "squawks" includes "explains why this test failure is specific to me or provides a proposed patch," I will make that change. Didn't you disable the test in e2b70dd1 before 3.0.3?
Do you mean you want the code to issue an early error without even trying? I think that's a bad idea that only makes the real issue harder to see and fix; as long as the backtrace makes it clear where the thing is failing, there's no need to obfuscate the implementation bug. At worst, maybe wrap the issue in a handler-bind that adds ASDF's own warning to the error?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Christmas is the time when kids tell Santa what they want and adults pay for it. Deficits are when adults tell government what they want and their kids pay for it.
On Sat, Jan 4, 2014 at 12:00 PM, Robert P. Goldman <rpgoldman@sift.info> wrote:
Yes, I want to disable this on platforms where it is known to fail.
Unfortunately, the backtrace does not make it at all easy to tell where the failure has occurred, so the poor user will have no way to tell that the failure is not his or her fault but the fault of ASDF and the implementation.
On ABCL the bundle files (jar files, IIRC), for some reason, are simply missing files that should be present. On ECL, something goes pear-shaped deep in the interaction with C. Neither test yields an error I can make heads or tails out of.
I was thinking of issuing some form of warning that indicates that here be dragons, and the user is proceeding at his/her own risk. That isn't quite full disablement, but it will keep people from wasting their time in a futile way if it bombs out.
What about a cerror? That way, the user can still access the functionality if he's willing to debug it. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org War does not determine who is right — only who is left. — Bertrand Russell
participants (2)
-
Faré -
Robert P. Goldman