[cells-devel] A thing that does not work well with Cells...

[Peder Chr. Nørgaard]

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.

	
-- 
Peder Chr. Nørgaard     e-mail: pcn at pogt.dk
Gefionsvej 19
DK-8230 Åbyhøj          tel: +45 87 44 11 99
Denmark                 mob: +45 30 91 84 31

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mofs.lisp
Type: text/x-java
Size: 1413 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20090520/6a49dbe0/attachment.java>