From alessiostalla at gmail.com  Tue Feb  9 09:58:58 2010
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Tue, 9 Feb 2010 10:58:58 +0100
Subject: [cells-devel] Cells on ABCL
Message-ID: <835c01921002090158ud229de9ye4cd001a756dfcf3@mail.gmail.com>

Hello,
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.

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 at 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.

Bye,
Alessio Stalla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cells-abcl.patch
Type: text/x-patch
Size: 1711 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20100209/b066080a/attachment.bin>

From ramarren at gmail.com  Tue Feb  9 11:08:52 2010
From: ramarren at gmail.com (Ramarren)
Date: Tue, 9 Feb 2010 12:08:52 +0100
Subject: [cells-devel] Cells on ABCL
In-Reply-To: <835c01921002090158ud229de9ye4cd001a756dfcf3@mail.gmail.com>
References: <835c01921002090158ud229de9ye4cd001a756dfcf3@mail.gmail.com>
Message-ID: <b840f45d1002090308u1c21edf9vb0748f73befa4909@mail.gmail.com>

Hello,

On Tue, Feb 9, 2010 at 10:58 AM, Alessio Stalla <alessiostalla at 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 at 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