From: Matthew D. S. <ak...@ch...> - 2008-10-29 14:04:58
|
I'm not trying to be snarky, but how seriously is portability in the build process pursued at this point? I tried, unsuccessfully, to build CVS HEAD under three different non-sbcl hosts (clisp 2.43, clozure-cl 1.1, and abcl 0.11), and each host failed with a different problem. Is it worth my while to try to get these issues resolved, or is sbcl _the_ bootstrap compiler? Matt |
From: Christophe R. <cs...@ca...> - 2008-10-29 14:27:55
|
"Matthew D. Swank" <ak...@ch...> writes: > Is it worth my while to try to get these issues resolved Yes. Or at least some of them. The maintainers of abcl and openmcl are (or at least used to be; abcl has changed hands recently) generally receptive to patches fixing bugs that cause the sbcl bootstrap not to work. Also, it's possible that some newer sbcl code is causing breakage, but since you say that each host breaks in a distinct way that might be less likely. It's a bit difficult to tell from a largely information-free email, whether snarkily intended or not. > or is sbcl _the_ bootstrap compiler? No. Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2008-10-29 16:05:32
Attachments:
ccl-build.diff
|
Christophe Rhodes <cs...@ca...> writes: > "Matthew D. Swank" <ak...@ch...> writes: > >> Is it worth my while to try to get these issues resolved > > Yes. Or at least some of them. The maintainers of abcl and openmcl > are (or at least used to be; abcl has changed hands recently) > generally receptive to patches fixing bugs that cause the sbcl > bootstrap not to work. Also, it's possible that some newer sbcl code > is causing breakage, but since you say that each host breaks in a > distinct way that might be less likely. It's a bit difficult to tell > from a largely information-free email, whether snarkily intended or > not. Here's a workaround for the issues that cropped up with openmcl-1.2 ("Clozure Common Lisp Version 1.2-r10552 (LinuxX8664)") for me. The basic points are: * OpenMCL complains (as in returns the diagnostic that compilation failed) if you have a clause in a typecase that is shadowed by a different one. I don't think that that should be a full failure, and I suggest that it be reported to Clozure. * OpenMCL does not have a compliant array upgrading lattice. I suspect that this is an intentional non-compliance on Clozure's part, but by all means report it to them. * OpenMCL's base-char type is the same as OpenMCL's character type. The first two points are demonstrably OpenMCL's fault, and are workaroundable; the instance of the third that tripped up the build is easy to remove. The resulting binary fails only those tests that it was expected to fail. Cheers, Christophe |
From: Matthew D. S. <ak...@ch...> - 2008-10-30 03:01:54
|
On Wed, 29 Oct 2008 16:05:25 +0000 Christophe Rhodes <cs...@ca...> wrote: > Christophe Rhodes <cs...@ca...> writes: > > > "Matthew D. Swank" <ak...@ch...> writes: > > > >> Is it worth my while to try to get these issues resolved > > > > Yes. Or at least some of them. ... > > Here's a workaround for the issues that cropped up with openmcl-1.2 > ("Clozure Common Lisp Version 1.2-r10552 (LinuxX8664)") for me. The > basic points are: > > * OpenMCL complains (as in returns the diagnostic that compilation > failed) if you have a clause in a typecase that is shadowed by a > different one. I don't think that that should be a full failure, > and I suggest that it be reported to Clozure. > > * OpenMCL does not have a compliant array upgrading lattice. I > suspect that this is an intentional non-compliance on Clozure's > part, but by all means report it to them. > > * OpenMCL's base-char type is the same as OpenMCL's character type. > > The first two points are demonstrably OpenMCL's fault, and are > workaroundable; the instance of the third that tripped up the build is > easy to remove. The resulting binary fails only those tests that it > was expected to fail. > > Cheers, > > Christophe > Thanks for the patch. Just to be clear, is the patch just to show how to work around the non-conformant behavior, or is it also for inclusion in sbcl? Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein. |
From: Christophe R. <cs...@ca...> - 2008-10-30 08:21:42
|
"Matthew D. Swank" <ak...@ch...> writes: > Thanks for the patch. Just to be clear, is the patch just to show > how to work around the non-conformant behavior, or is it also for > inclusion in sbcl? I'll probably commit it to sbcl at some point, because when the workarounds are sufficiently simple, and arguably make the code a little clearer than before, it's probably worth doing. What would be less likely are making the sbcl code noticeably uglier or more complex; in such circumstances, we'd expect users to report bugs in the other implementations and wait for fixes to come that way. Of course, for legitimate differences of opinion about how to implement the standard, we try to be portable, except in cases where it would be a huge effort (e.g. cross-compiling from a lisp with only one kind of float might be difficult...) Cheers, Christophe |