Hello,

On Tue, Feb 9, 2010 at 10:58 AM, Alessio Stalla alessiostalla@gmail.com wrote:

I'm interested on having Cells running on ABCL. I have downloaded the latest snapshot from the Ramarren branch and it appears that only a few read conditionals are missing (for the MOP package) to make Cells compile and load fine; attached you find the patch.

I have applied the patch to my repository.

However, the tests fail due to an issue I had already found the first time I tried Cells on ABCL (see http://www.mail-archive.com/cells-devel@common-lisp.net/msg00582.html). The fix for that is apparently simple - replace delete with remove in c-unlink-used (link.lisp) - but His Kennyness himself said that this naive fix can have a bad impact on performance, so I have not included it in my patch. To me, one sensible option would be to enable the "fix" only on ABCL (it's better to have less than optimal performance than to have no Cells at all!), but it's a decision that should be taken by the Cells developers.

Unfortunately, I am not really a Cells developer, I just cleaned some things up for cells-gtk to run. So I don't quite understand what the code is doing and the context. Which is why I have no idea whether cd-useds list can contain duplicates. If it cannot, the code doesn't really make sense, since as far as I can tell doing this:

diff --git a/link.lisp b/link.lisp index 047783f..7407876 100644 --- a/link.lisp +++ b/link.lisp @@ -78,7 +78,7 @@ See the Lisp Lesser GNU Public License for more details. (progn (count-it :unlink-unused) (trc nil "c-unlink-unused" c :dropping-used (car useds)) - (c-unlink-caller (car useds) c) + (caller-drop (car useds) c) (rplaca useds nil)) (progn ;; moved into record-caller 060604 (caller-ensure (car useds) c)

would be strictly equivalent when the function is done and eliminate the inner delete entirely, which should fix ABCL problem. Unless I don't see something. I am not sure what would happen if the cd-useds list contained duplicates, and if it did what would happen when caller-drop is called multiple time.

At least, if I am getting the control flow correctly. As far as I can tell the reversed recursion doesn't care the the list is not being destructively modified on the unwind, but I am not sure how the caller unlinking interacts with this whole thing.

The tests pass, anyway, and if I put (assert (equal (cd-useds c) (remove-duplicates (cd-useds c)))) before nail-unused in c-unlink-unused it doesn't signal an error from cells-gtk demo application. I am not sure how and if it affects performance.

But that does not preclude the possibility that there are cases when there could be duplicates, although I am fairly sure that the only place where this list is being added to is record-caller, which doesn't allow duplication.

It would be best if someone who knows how this works could comment on that fix, or at least test it.

Regards, Jakub Higersberger