With a version of mcclim updated on march 31st Autowrite works fine. With the latest version I get the error below. Could somebody help me please?
Irene DURAND idurand@labri.fr writes:
With a version of mcclim updated on march 31st Autowrite works fine. With the latest version I get the error below. Could somebody help me please?
As I said in my reply to Fred Gilham, this is likely a bug in CMUCL 19c; it can probably be worked around, but to do so it would be nice to know what the bug is in the first place so that the CMUCL people can fix it; to achieve this, you can bisect the CVS to find the commit that changed things, then work out which portion of that commit exposes the problem.
Cheers,
Christophe
Quoting Christophe Rhodes (csr21@cam.ac.uk):
With a version of mcclim updated on march 31st Autowrite works fine. With the latest version I get the error below. Could somebody help me please?
| The class #<SB-KERNEL:STANDARD-CLASSOID CLIM-INTERNALS::BASIC-OUTPUT-RECORD> | is currently invalid. | [Condition of type SIMPLE-ERROR]
As I said in my reply to Fred Gilham, this is likely a bug in CMUCL 19c; it can probably be worked around, but to do so it would be nice to know what the bug is in the first place so that the CMUCL people can fix it; to achieve this, you can bisect the CVS to find the commit that changed things, then work out which portion of that commit exposes the problem.
That looks unlikely to be a CMUCL bug to me. :-)
It rather seems to be Christophe's removal of compatibility with older SBCL bugs, solved by either upgrading SBCL or reverting Christophe's recent McCLIM patches.
d.
David Lichteblau david@lichteblau.com writes:
Quoting Christophe Rhodes (csr21@cam.ac.uk):
With a version of mcclim updated on march 31st Autowrite works fine. With the latest version I get the error below. Could somebody help me please?
| The class #<SB-KERNEL:STANDARD-CLASSOID CLIM-INTERNALS::BASIC-OUTPUT-RECORD> | is currently invalid. | [Condition of type SIMPLE-ERROR]
As I said in my reply to Fred Gilham, this is likely a bug in CMUCL 19c; it can probably be worked around, but to do so it would be nice to know what the bug is in the first place so that the CMUCL people can fix it; to achieve this, you can bisect the CVS to find the commit that changed things, then work out which portion of that commit exposes the problem.
That looks unlikely to be a CMUCL bug to me. :-)
It rather seems to be Christophe's removal of compatibility with older SBCL bugs, solved by either upgrading SBCL or reverting Christophe's recent McCLIM patches.
Oh, whoops. Yes. Sorry, for two things: firstly, for completely failing to read the message, and secondly, for at one point in this development cycle deciding to remove workarounds for older SBCL bugs. (This looks like the same problem as the 19c thing, in my defence)
To see if this is the problem, try moving the (define-protocol-class design ()) in protocol-classes.lisp to above (define-protocol-class region (design)) in the same file.
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk wrote:
To see if this is the problem, try moving the (define-protocol-class design ()) in protocol-classes.lisp to above (define-protocol-class region (design)) in the same file.
Doing this fixes the problem. So I guess it's a problem with forward referenced classes in CMUCL and SBCL.
Fred Gilham gilham@csl.sri.com writes:
Christophe Rhodes csr21@cam.ac.uk wrote:
To see if this is the problem, try moving the (define-protocol-class design ()) in protocol-classes.lisp to above (define-protocol-class region (design)) in the same file.
Doing this fixes the problem. So I guess it's a problem with forward referenced classes in CMUCL and
older versions of
SBCL.
Feel free to trawl SBCL CVS to find the patch, and port it to your favourite Lisp implementation.
Cheers,
Christophe