Sorry, I sent this directly to Kenny instead of to the mailing list.
Alessio
---------- Forwarded message ---------- From: Alessio Stalla alessiostalla@gmail.com Date: Tue, May 26, 2009 at 10:53 PM Subject: Re: [cells-devel] Cells on ABCL To: Kenneth Tilton kentilton@gmail.com
On Tue, May 26, 2009 at 2:17 PM, Kenneth Tilton kentilton@gmail.com wrote:
Does ABCL provide a backtrace that might show in which function the error originates?
abcl's backtrace does not seem very useful:
[1] CL-USER(8): :bt 0: (BACKTRACE-AS-LIST) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {7F84C9}>) 2: (CELLS::CV-TEST-PERSON-3) 3: (CELLS::CV-TEST-PERSON) 4: (FUNCALL CELLS::CV-TEST-PERSON) 5: (SYSTEM::%TIME #<FUNCTION (LAMBDA ()) {1E6DBAA}>) 6: (CELLS::TEST-CELLS) 7: (SYSTEM::%EVAL (CELLS::TEST-CELLS))
Also: IIRC, ct-assert says what it is doing as it goes. So how far are you getting? If I am wrong on that, just add some print statements so we can narrow it down.
This is what it prints before it fails:
(CELLS::ATTEMPTING (EQL 1 (LENGTH (CELLS::CD-USEDS (CELLS::MD-SLOT-CELL CELLS::P (QUOTE CELLS::THOUGHT)))))) 0> output thought #<cells::person {15eb44d}> "speedy, slow down!"0> i am thinking "speedy, slow down!" (CELLS::ATTEMPTING (EQL 2 (LENGTH (CELLS::CD-USEDS (CELLS::MD-SLOT-CELL CELLS::P (QUOTE CELLS::THOUGHT)))))) 0> output thought #<cells::person {15eb44d}> "nice and easy does it"0> i am thinking "nice and easy does it" (CELLS::ATTEMPTING (EQL 1 (LENGTH (CELLS::CD-USEDS (CELLS::MD-SLOT-CELL CELLS::P (QUOTE CELLS::THOUGHT)))))) Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type STRUCTURE-OBJECT.
Probably it's an abcl bug (I've seen other times bugs that were apparent in the form of "NIL is not of type X"). In the next few days I'll be at the ELS, so I won't have much time to spend on the subject, but asap I'll try to debug it.
Bye, Alessio
Le 26 mai 09 à 22:55, Alessio Stalla alessiostalla@gmail.com a écrit :
Sorry, I sent this directly to Kenny instead of to the mailing list.
Alessio
---------- Forwarded message ---------- From: Alessio Stalla alessiostalla@gmail.com Date: Tue, May 26, 2009 at 10:53 PM Subject: Re: [cells-devel] Cells on ABCL To: Kenneth Tilton kentilton@gmail.com
On Tue, May 26, 2009 at 2:17 PM, Kenneth Tilton kentilton@gmail.com wrote:
Does ABCL provide a backtrace that might show in which function the error originates?
abcl's backtrace does not seem very useful:
[1] CL-USER(8): :bt 0: (BACKTRACE-AS-LIST) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {7F84C9}>) 2: (CELLS::CV-TEST-PERSON-3) 3: (CELLS::CV-TEST-PERSON) 4: (FUNCALL CELLS::CV-TEST-PERSON) 5: (SYSTEM::%TIME #<FUNCTION (LAMBDA ()) {1E6DBAA}>) 6: (CELLS::TEST-CELLS) 7: (SYSTEM::%EVAL (CELLS::TEST-CELLS))
Also: IIRC, ct-assert says what it is doing as it goes. So how far are you getting? If I am wrong on that, just add some print statements so we can narrow it down.
This is what it prints before it fails:
(CELLS::ATTEMPTING (EQL 1 (LENGTH (CELLS::CD-USEDS (CELLS::MD-SLOT-CELL CELLS::P (QUOTE CELLS::THOUGHT)))))) 0> output thought #<cells::person {15eb44d}> "speedy, slow down!"0> i am thinking "speedy, slow down!" (CELLS::ATTEMPTING (EQL 2 (LENGTH (CELLS::CD-USEDS (CELLS::MD-SLOT-CELL CELLS::P (QUOTE CELLS::THOUGHT)))))) 0> output thought #<cells::person {15eb44d}> "nice and easy does it"0> i am thinking "nice and easy does it" (CELLS::ATTEMPTING (EQL 1 (LENGTH (CELLS::CD-USEDS (CELLS::MD-SLOT-CELL CELLS::P (QUOTE CELLS::THOUGHT)))))) Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type STRUCTURE-OBJECT.
Probably it's an abcl bug (I've seen other times bugs that were apparent in the form of "NIL is not of type X"). In the next few days I'll be at the ELS, so I won't have much time to spend on the subject, but asap I'll try to debug it.
I'll be there too. If you have it on a laptop I could take a look at it while we're there.
Bye, Alessio
cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
I have found out the problem with Cells on abcl after a bit of debugging.
The function c-unlink-useds in link.lisp uses delete, which somehow destructively modifies something it should not - the list of useds gets one item shorter (not the list inside the cell but the list "useds" in c-unlink-unused, which apparently shares structure with the list inside the cell, but who knows). Replacing delete with remove does the trick. I don't know if this is caused by abcl's delete being buggy but I doubt it, since the implementation of delete in abcl is taken from cmucl, and that should be bug-free enough ;) however, I'll investigate this further.
(Thomas, I saw you at the ELS but in the end I didn't want to bother you with this - I wanted to keep the fun for me ;) thanks for your offer of help, anyway).
So now tests appear to pass. And, apart from using remove and adding a few read conditionals, no changes to cells are required for it to work on abcl. Abcl itself needs to be slightly modified (it needs to expose a couple of internal MOP functions). I'll talk to the devs about incorporating these changes on trunk and hopefully in the coming 0.15 release of abcl.
Bye, Alessio S.
Alessio Stalla wrote:
I have found out the problem with Cells on abcl after a bit of debugging.
The function c-unlink-useds in link.lisp uses delete, which somehow destructively modifies something it should not -
Right you are. But it is not doing it should not -- that labels from gets passed the same structure being acted on by the delete, so the outer guy of course sees that.
I have always hated that code, but one attempt to clean it up did have a performance hit so it has to stay a little ugly.
I think the remove works but is the wrong fix (and will be a performance killer scaled up). I see that the outer block of code does its own cleanup of useds, so it is being done twice -- very efficiently, but twice. What I think needs doing is avoiding the inner delete by mutating the list differently. I will stare at it and see what I can come up with.
Thx for the detective work.
kt
the list of useds
gets one item shorter (not the list inside the cell but the list "useds" in c-unlink-unused, which apparently shares structure with the list inside the cell, but who knows). Replacing delete with remove does the trick. I don't know if this is caused by abcl's delete being buggy but I doubt it, since the implementation of delete in abcl is taken from cmucl, and that should be bug-free enough ;) however, I'll investigate this further.
(Thomas, I saw you at the ELS but in the end I didn't want to bother you with this - I wanted to keep the fun for me ;) thanks for your offer of help, anyway).
So now tests appear to pass. And, apart from using remove and adding a few read conditionals, no changes to cells are required for it to work on abcl. Abcl itself needs to be slightly modified (it needs to expose a couple of internal MOP functions). I'll talk to the devs about incorporating these changes on trunk and hopefully in the coming 0.15 release of abcl.
Bye, Alessio S.
cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.53/2154 - Release Date: 06/04/09 05:53:00
-
Alessio Stalla -
Kenneth Tilton -
Thomas F. Burdick