Hi, fellow-cell'ers. I have this problem: I am attempting to port an existing bunch of software to Cells - to "cellulize" it. But there is one specific aspect - a "feature" that I am using - that does not work with Cells. I ask for advice.
The "existing bunch" has made a habit of using classes with a number of ":allocation :class" slots. We occasionally have to access these slots without having access to an instance of the class; therefore we use the trick of accessing the slot-in-case of "sb-mop:class-prototype <class>".
Now this has worked just fine until I start to cellulize the classes. Then it does not work at all. I have spent some time cooking down the problem. The attached file manifests the problem when you run it on an Sbcl system.
To answer the most obvious question: no. No, I haven't tried it on CMUCL or any other LISP system capable of supporting Cells. And to the second-most obvious question, also no. No, I don't want to rewrite my current implementation to use some other technique to access class-specific information.
My - shall we call it - hope is that someone with an in-deep knowledge of Cells can spot what aspect of SBCL class implementation that Cell fails to respect. I have spent a number of days digging into this, and I must admit failure. I simply cannot figure out why Cells make this otherwise fine working feature of SBCL fail. The failure happens someplace deep down in the PCL instance allocation, where all traces of Cells override ought to have disappeared...
The problem seems to be, that when a class defined with DEFMODEL, subclass of MODEL, has a class-allocated slot, the initialization of the SB-PCL:PROTOTYPE slot triggered by the first use of SB-MOP:CLASS-PROTOTYPE - fails. Actually, it fails so thoroughly, that even the error report from the failure - eh - fails. When the access attempt is finished and the error break terminated, the SB-PCL:PROTOTYPE slot is not NIL, as it was after DEFMODEL and FINALIZE-INHERITANCE. It is unbound. However that happens - I haven't got the foggiest idea. The attached file contains a few failed attempts to work around the problem by digging deeper into the SBCL CLOS implementation.
best regards --peder chr.