I'm pretty much just waiting on an answer from the OpenMCL developers telling me where we're supposed to be getting MOP functions from. For kicks, I checked Classic MCL this weekend, and it partially works. One of the unbound-cells tests failed, and I didn't feel very inspired to debug it. That does mean it got pretty far through the test suite, though. When I get the answer back from the OpenMCL developers, I'll update the candidate, and ask the couple of you who had problems with it to see if it works. Then, release :-)
Here's the implementations I think Cells supports:
Allegro, SBCL, LispWorks, CMUCL, OpenMCL.
MCL was formerly supported and should not be very difficult to get working again.
What about CLISP? Is it in the same category as MCL, or does anyone use it?
Thomas F. Burdick wrote:
I'm pretty much just waiting on an answer from the OpenMCL developers telling me where we're supposed to be getting MOP functions from. For kicks, I checked Classic MCL this weekend, and it partially works. One of the unbound-cells tests failed, and I didn't feel very inspired to debug it.
My bad. I hate testing. I did not even run the tests under AllegroCL. I just fired up Cello and The Fabulous Spinning Shape Demo. To be honest, I would not be surprised if some tests need revision. And if I go ahead and remove autodetection of cycles, this will break any test designed to confirm that cycles are autodetected -- just do not remember if I have one.
That does mean it got pretty far through the test suite, though. When I get the answer back from the OpenMCL developers, I'll update the candidate, and ask the couple of you who had problems with it to see if it works. Then, release :-)
Here's the implementations I think Cells supports:
Allegro, SBCL, LispWorks, CMUCL, OpenMCL.
MCL was formerly supported and should not be very difficult to get working again.
What about CLISP? Is it in the same category as MCL, or does anyone use it?
Cells has always been tested under CLisp, and Cells-Gtk Classic was developed on CLisp. It should work there as well, if anyone cares to test. CLisp now has better (great, they say) MOP support, so things should only be getting easier.
One issue with CLisp was some crazy defstruct/include/conc-name behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the Cell defstructs have different conc-names.
btw, Cells has been observed running satisfactorily on CormanCL.
kt
Kenny Tilton writes:
Thomas F. Burdick wrote:
I'm pretty much just waiting on an answer from the OpenMCL developers telling me where we're supposed to be getting MOP functions from. For kicks, I checked Classic MCL this weekend, and it partially works. One of the unbound-cells tests failed, and I didn't feel very inspired to debug it.
My bad. I hate testing. I did not even run the tests under AllegroCL. I just fired up Cello and The Fabulous Spinning Shape Demo. To be honest, I would not be surprised if some tests need revision. And if I go ahead and remove autodetection of cycles, this will break any test designed to confirm that cycles are autodetected -- just do not remember if I have one.
Actually, I think it means that there is something broken on MCL, because the tests run to completion on SBCL.
Cells has always been tested under CLisp, and Cells-Gtk Classic was developed on CLisp. It should work there as well, if anyone cares to test. CLisp now has better (great, they say) MOP support, so things should only be getting easier.
Oh yeah. So the list is: Allegro, SBCL, LispWorks, CMUCL, CLISP, OpenMCL. Probably works: Corman Partially works: MCL
One issue with CLisp was some crazy defstruct/include/conc-name behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the Cell defstructs have different conc-names.
I had wondered about that. It did make the SBCL port more "exciting" because there were a couple cases of using a subclass' accessor on a parent class, which SBCL is picky about. I had meant to malign the conc-name decision, but I guess I forgot :-)
Thomas F. Burdick wrote:
Kenny Tilton writes:
One issue with CLisp was some crazy defstruct/include/conc-name behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the Cell defstructs have different conc-names.
I had wondered about that. It did make the SBCL port more "exciting" because there were a couple cases of using a subclass' accessor on a parent class, which SBCL is picky about.
Hmm. I seem to recall this. You could have gone (and can go) ahead and fix any of those. Good for SBCL!
I had meant to malign the conc-name decision, but I guess I forgot :-)
When I saw you cross swords with Sam or Bruno on c.l.l. over gratuitous differences i thought this issue might be part of it. One of them actually responded to me on this issue and heartily defended their approach. Oh, well. Glad to see their other progress on MOP and FFI. I wonder if they still mess up this concname thing.
kt
Kenny Tilton writes:
Thomas F. Burdick wrote:
Kenny Tilton writes:
One issue with CLisp was some crazy defstruct/include/conc-name behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the Cell defstructs have different conc-names.
I had wondered about that. It did make the SBCL port more "exciting" because there were a couple cases of using a subclass' accessor on a parent class, which SBCL is picky about.
Hmm. I seem to recall this. You could have gone (and can go) ahead and fix any of those. Good for SBCL!
Oh, I certainly fixed them -- if I hadn't, Cells would not be running on SBCL, and the software I delivered for my final two contracts as a consultant wouldn't run.
I had meant to malign the conc-name decision, but I guess I forgot :-)
When I saw you cross swords with Sam or Bruno on c.l.l. over gratuitous differences i thought this issue might be part of it. One of them actually responded to me on this issue and heartily defended their approach. Oh, well. Glad to see their other progress on MOP and FFI. I wonder if they still mess up this concname thing.
Heh, I meant I had intended to malign your non-idiomatic use of conc-names in Cells, not realizing that it was to support CLISP. That's definately on the list of gratuitous incompatabilities I hate in CLISP -- I'm definately interested in seeing how much of this gets fixed. They seem to have grown an interest in being able to bootstrap SBCL, so that should help push them in a compliant direction.
-
Kenny Tilton -
Thomas F. Burdick