[armedbear-devel] [closer-devel] Closer-mop support for ABCL

[Pascal Costanza]

On 26 Aug 2012, at 17:14, Rudolf Schlatte <rudi at constantly.at> wrote:

> 
> On Aug 26, 2012, at 16:28, Pascal Costanza <pc at p-cos.net> wrote:
> 
>> Hi Rudi,
>> 
>> I'm now seeing other bugs: There is a Java-level index-out-of-bounds error caused by a call to %set-standard-instance-access somewhere. However, it's pretty hard to figure out where and why that happens, because the Java error message doesn't tell me where in the Lisp code I am. Can you recommend any tricks how to localize errors better?
> 
> Thanks, r14135 catches that and throws a Lisp-side type error.  This should give you a more helpful backtrace.  I think in general Lisp code should never result in uncaught Java exceptions, so I'd be happy to fix any that you find.


OK, thanks a lot! This works better now.

However, the error message doesn't seem to make any sense:

Error loading /Users/costanza/lisp/develop/closer/contextl/test/demo3.lisp at line 51 (offset 1410)
#<THREAD "interpreter" {3ADE1520}>: Debugger invoked on condition of type TYPE-ERROR
  The value 1 is not of type (INTEGER 0 1).
Restarts:
  0: TOP-LEVEL Return to top level.
[1] CX-USER(2): :bt

  0: (SYSTEM:BACKTRACE)
  1: (INVOKE-DEBUGGER #<TYPE-ERROR {4ADA1DC}>)
  2: org.armedbear.lisp.Lisp.error(Lisp.java:382)
  3: org.armedbear.lisp.Lisp.type_error(Lisp.java:423)
  4: org.armedbear.lisp.StandardObject$pf__set_standard_instance_access.execute(StandardObject.java:489)
  5: org.armedbear.lisp.Symbol.execute(Symbol.java:825)
  6: org.armedbear.lisp.LispThread.execute(LispThread.java:666)
  7: org.armedbear.lisp.clos_671.execute(clos.lisp:3409)

The reason for the confusing error message seems to be that the error message gives instance.slots.length as an upper bound, but I think it should give instance.slots.length-1.

Now I need to figure out why the class has only exactly one slot...


Pascal

--
Pascal Costanza