From metawilm at gmail.com  Thu May  1 16:42:18 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Thu, 1 May 2008 18:42:18 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <u9azlrakomn.fsf@paradicsom.nyc.corp.google.com>
References: <u9azlrakomn.fsf@paradicsom.nyc.corp.google.com>
Message-ID: <f6bc9b490805010942u354481eeib0b86dec9704add9@mail.gmail.com>

Hello Bob,

On Thu, May 1, 2008 at 5:52 PM, Robert Brown <brown at google.com> wrote:

> I tried to get CLPython up and running on the latest SBCL.  The diff below
> contains a couple of easy fixes.  SBCL wants BREAK's argument to be a
> string
> and SBCL's LOOP does not like a negative loop increment.


Thanks for the patches!


> The real porting problem right now is CLOS related.  SBCL does not like
> the
> following code in core/classes.lisp:
>
>    ;; Fix superclass and metaclass of PY-DICT.
>    (ensure-class 'py-dict
>                  :direct-superclasses (list 'py-core-object)
>                  :metaclass 'py-core-type)
>
> I get the following error:
>
>    debugger invoked on a SB-PCL::METAOBJECT-INITIALIZATION-VIOLATION in
> thread
>    #<THREAD "initial thread" {11701A79}>:
>      Cannot CHANGE-CLASS objects into CLASS metaobjects.
>    See also:
>      AMOP, Initialization of Class Metaobjects
>
> I think the problem is that PY-DICT is a normal class and the ENSURE-CLASS
> call tries to turn it into a metaclass.  Anyway, I'm far from a CLOS
> expert.


Well, class py-dict is not turned into a metaclass here, at least that's not
the intention. :) The superclass and metaclass of it are changed but py-dict
remains a non-metaclass class. So I think the actual error message is
incorrect, but something else is wrong.

The problem might be that you can not change the metaclasses of a class
using ensure-class. Could you please check if the call to ensure-class
without the metaclass change is accepted?

(ensure-class 'py-dict
                    :direct-superclasses (list 'py-core-object))

Thanks,
- Willem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080501/2fdf21f1/attachment.html>

From brown at google.com  Thu May  1 17:30:25 2008
From: brown at google.com (Robert Brown)
Date: Thu, 1 May 2008 13:30:25 -0400
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805010942u354481eeib0b86dec9704add9@mail.gmail.com>
References: <u9azlrakomn.fsf@paradicsom.nyc.corp.google.com>
	<f6bc9b490805010942u354481eeib0b86dec9704add9@mail.gmail.com>
Message-ID: <18457.65073.418462.998262@paradicsom.nyc.corp.google.com>


The call to ensure-class without

    :metaclass 'py-core-type

succeeds.

The call with the :metaclass argument fails inside change-class:

  (defmethod change-class ((instance standard-object) (new-class standard-class)
                           &rest initargs)
    (unless (class-finalized-p new-class)
      (finalize-inheritance new-class))
    (let ((cpl (class-precedence-list new-class)))
      (dolist (class cpl)
        (macrolet
            ((frob (class-name)
               `(when (eq class (find-class ',class-name))
                 (error 'metaobject-initialization-violation
                  :format-control "~@<Cannot ~S objects into ~S
                  metaobjects.~@:>"
                  :format-arguments (list 'change-class ',class-name)
                  :references (list '(:amop :initialization ,class-name))))))
          (frob class)
          (frob generic-function)
          (frob method)
          (frob slot-definition))))
    (change-class-internal instance new-class initargs))

CLASS is on the class precedence list of PY-CORE-TYPE.

bob

====================

Willem Broekema writes:
 > Hello Bob,
 > 
 > On Thu, May 1, 2008 at 5:52 PM, Robert Brown <brown at google.com> wrote:
 > 
 > > I tried to get CLPython up and running on the latest SBCL.  The diff below
 > > contains a couple of easy fixes.  SBCL wants BREAK's argument to be a
 > > string
 > > and SBCL's LOOP does not like a negative loop increment.
 > 
 > 
 > Thanks for the patches!
 > 
 > 
 > > The real porting problem right now is CLOS related.  SBCL does not like
 > > the
 > > following code in core/classes.lisp:
 > >
 > >    ;; Fix superclass and metaclass of PY-DICT.
 > >    (ensure-class 'py-dict
 > >                  :direct-superclasses (list 'py-core-object)
 > >                  :metaclass 'py-core-type)
 > >
 > > I get the following error:
 > >
 > >    debugger invoked on a SB-PCL::METAOBJECT-INITIALIZATION-VIOLATION in
 > > thread
 > >    #<THREAD "initial thread" {11701A79}>:
 > >      Cannot CHANGE-CLASS objects into CLASS metaobjects.
 > >    See also:
 > >      AMOP, Initialization of Class Metaobjects
 > >
 > > I think the problem is that PY-DICT is a normal class and the ENSURE-CLASS
 > > call tries to turn it into a metaclass.  Anyway, I'm far from a CLOS
 > > expert.
 > 
 > 
 > Well, class py-dict is not turned into a metaclass here, at least that's not
 > the intention. :) The superclass and metaclass of it are changed but py-dict
 > remains a non-metaclass class. So I think the actual error message is
 > incorrect, but something else is wrong.
 > 
 > The problem might be that you can not change the metaclasses of a class
 > using ensure-class. Could you please check if the call to ensure-class
 > without the metaclass change is accepted?
 > 
 > (ensure-class 'py-dict
 >                     :direct-superclasses (list 'py-core-object))
 > 
 > Thanks,
 > - Willem


From metawilm at gmail.com  Thu May  1 19:55:41 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Thu, 1 May 2008 21:55:41 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <18457.65073.418462.998262@paradicsom.nyc.corp.google.com>
References: <u9azlrakomn.fsf@paradicsom.nyc.corp.google.com>
	<f6bc9b490805010942u354481eeib0b86dec9704add9@mail.gmail.com>
	<18457.65073.418462.998262@paradicsom.nyc.corp.google.com>
Message-ID: <f6bc9b490805011255s1c1b3274s9c22498644fa1277@mail.gmail.com>

On Thu, May 1, 2008 at 7:30 PM, Robert Brown <brown at google.com> wrote:

> The call to ensure-class without
>
>     :metaclass 'py-core-type
>
> succeeds.
>
> The call with the :metaclass argument fails inside change-class:
>
>  (defmethod change-class ((instance standard-object) (new-class
> standard-class)
>                           &rest initargs)
>    (unless (class-finalized-p new-class)
>      (finalize-inheritance new-class))
>    (let ((cpl (class-precedence-list new-class)))
>      (dolist (class cpl)
>        (macrolet
>            ((frob (class-name)
>               `(when (eq class (find-class ',class-name))
>                 (error 'metaobject-initialization-violation
>                  :format-control "~@<Cannot ~S objects into ~S
>                  metaobjects.~@:>"
>                  :format-arguments (list 'change-class ',class-name)
>                  :references (list '(:amop :initialization
> ,class-name))))))
>          (frob class)
>          (frob generic-function)
>          (frob method)
>          (frob slot-definition))))
>    (change-class-internal instance new-class initargs))
>
> CLASS is on the class precedence list of PY-CORE-TYPE.
>

Thanks, I'm going to look into this.

- Willem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080501/ddf91684/attachment.html>

From metawilm at gmail.com  Sat May  3 12:34:13 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Sat, 3 May 2008 14:34:13 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805011255s1c1b3274s9c22498644fa1277@mail.gmail.com>
References: <u9azlrakomn.fsf@paradicsom.nyc.corp.google.com>
	<f6bc9b490805010942u354481eeib0b86dec9704add9@mail.gmail.com>
	<18457.65073.418462.998262@paradicsom.nyc.corp.google.com>
	<f6bc9b490805011255s1c1b3274s9c22498644fa1277@mail.gmail.com>
Message-ID: <f6bc9b490805030534xb42af42x38c2ebb79c300b99@mail.gmail.com>

On Thu, May 1, 2008 at 9:55 PM, Willem Broekema <metawilm at gmail.com> wrote:

> Thanks, I'm going to look into this.
>

Now the class bootstrapping is rewritten, so no need for such a class
redefinition anymore. Please give it a try. (On my SBCL 1.0.10 for Mac OS X
10.4, it fails with a strange "no suitable method for STREAM-ELEMENT-TYPE",
which is said to be fixed in a later version.) The change should be in
public CVS in an hour. Lispworks and Allegro still run the test suite fine.

- Willem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080503/20fafd04/attachment.html>

From jdn at math.carleton.ca  Tue May  6 04:19:17 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Tue, 6 May 2008 00:19:17 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
Message-ID: <Pine.LNX.4.64.0805060001290.3111@buddy>

I can confirm that compilation fails using SBCL 1.0.16 on a Ubuntu 7.10 
system with a:

"has no suitable method for STREAM-ELEMENT-TYPE, and so has fallen through 
to this method...."

error that crashes the whole session.  You can reproduce this behaviour 
with the following:

(defclass foo (standard-class) ())
(defclass bar () () (:metaclass foo))

Cheers,
Jason


From metawilm at gmail.com  Tue May  6 10:23:24 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Tue, 6 May 2008 12:23:24 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805060001290.3111@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
Message-ID: <f6bc9b490805060323k37f390eeh9fd90881c54f266@mail.gmail.com>

On Tue, May 6, 2008 at 6:19 AM, Jason Nielsen <jdn at math.carleton.ca> wrote:

> I can confirm that compilation fails using SBCL 1.0.16 on a Ubuntu 7.10
> system with a:
>
> "has no suitable method for STREAM-ELEMENT-TYPE, and so has fallen through
> to this method...."
>
> error that crashes the whole session.  You can reproduce this behaviour
> with the following:
>
> (defclass foo (standard-class) ())
> (defclass bar () () (:metaclass foo))
>

Thanks for the confirmation. Actually I hoped this would not occur in the
latest version, as Nikodemus Siivola said on 2008-01-15, in reply to what
seems a very similar issue reported by Pascal Costanza: "This seems to have
been fixed at some point during the last 10 months": <
http://article.gmane.org/gmane.lisp.steel-bank.devel/10603>

Custom metaclasses are crucial for CLPython. Hopefully someone feels
inclined to fix this SBCL issue.

- Willem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080506/8a47934f/attachment.html>

From jdn at math.carleton.ca  Tue May  6 13:48:32 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Tue, 6 May 2008 09:48:32 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805060323k37f390eeh9fd90881c54f266@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<f6bc9b490805060323k37f390eeh9fd90881c54f266@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0805060942080.11178@buddy>

On Tue, 6 May 2008, Willem Broekema wrote:

> On Tue, May 6, 2008 at 6:19 AM, Jason Nielsen <jdn at math.carleton.ca> wrote:
>
>> I can confirm that compilation fails using SBCL 1.0.16 on a Ubuntu 7.10
>> system with a:
>>
>> "has no suitable method for STREAM-ELEMENT-TYPE, and so has fallen through
>> to this method...."
>>
>> error that crashes the whole session.  You can reproduce this behaviour
>> with the following:
>>
>> (defclass foo (standard-class) ())
>> (defclass bar () () (:metaclass foo))
>>
>
> Thanks for the confirmation. Actually I hoped this would not occur in the
> latest version, as Nikodemus Siivola said on 2008-01-15, in reply to what
> seems a very similar issue reported by Pascal Costanza: "This seems to have
> been fixed at some point during the last 10 months": <
> http://article.gmane.org/gmane.lisp.steel-bank.devel/10603>
>
> Custom metaclasses are crucial for CLPython. Hopefully someone feels
> inclined to fix this SBCL issue.
>
> - Willem
>

Interesting, if you run in an sbcl console without slime:

(defclass foo (standard-class) ())
(defclass bar () () (:metaclass foo))

you get a different error message:

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" 
{A884551}>:
   The class #<STANDARD-CLASS STANDARD-OBJECT> was specified as a 
super-class of
   the class #<FOO BAR>, but the meta-classes #<STANDARD-CLASS 
STANDARD-CLASS>
   and #<STANDARD-CLASS FOO> are incompatible.  Define a method for
   SB-MOP:VALIDATE-SUPERCLASS to avoid this error.

so thinking this may be some sort of slime/sbcl problem I decided to try 
to asdf-install without slime.  The compilation fails much earlier with:

; registering #<SYSTEM #:LW-COMPAT {A8F48F9}> as LW-COMPAT
WARNING: change in instance length of class SB-PRETTY:PRETTY-STREAM:
   current length: 25
   compile time length: 27

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" 
{A884551}>:
   The class SB-PRETTY:PRETTY-STREAM was not changed, and there's no 
guarantee that
the loaded code (which expected another layout) will work.

This error also doesn't mean much to me.

Jason


From varuzza at gmail.com  Tue May  6 14:18:16 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Tue, 6 May 2008 11:18:16 -0300
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805060323k37f390eeh9fd90881c54f266@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<f6bc9b490805060323k37f390eeh9fd90881c54f266@mail.gmail.com>
Message-ID: <5d9c2e640805060718o68f46229nd15bf407ee789bc3@mail.gmail.com>

Same error with SBCL 1.0.16.11 on AMD64:

; compiling (DEFCLASS PY-DICT ...)
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread"
{100244CF51}>:
  The stream
  #<SB-SYS:FD-STREAM for "file
/home/varuzza/lisp/prog/clpython/core/early-dict.fasl" {10039AD0F1}>
  has no suitable method for STREAM-ELEMENT-TYPE, and so has fallen through
to
  this method.  If you think that this is a bug, please report it to the
  applicable authority (bugs in SBCL itself should go to the mailing lists
  referenced from <http://www.sbcl.org/>).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {10037950A1}> on
              #<ASDF:CL-SOURCE-FILE "early-dict" {10032E1401}>.
  1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {10037950A1}> on
              #<ASDF:CL-SOURCE-FILE "early-dict" {10032E1401}> as having
been
              successful.
  2: [ABORT ] Exit debugger, returning to top level.



On Tue, May 6, 2008 at 7:23 AM, Willem Broekema <metawilm at gmail.com> wrote:

> On Tue, May 6, 2008 at 6:19 AM, Jason Nielsen <jdn at math.carleton.ca>
> wrote:
>
> > I can confirm that compilation fails using SBCL 1.0.16 on a Ubuntu 7.10
> > system with a:
> >
> > "has no suitable method for STREAM-ELEMENT-TYPE, and so has fallen
> > through to this method...."
> >
> > error that crashes the whole session.  You can reproduce this behaviour
> > with the following:
> >
> > (defclass foo (standard-class) ())
> > (defclass bar () () (:metaclass foo))
> >
>
> Thanks for the confirmation. Actually I hoped this would not occur in the
> latest version, as Nikodemus Siivola said on 2008-01-15, in reply to what
> seems a very similar issue reported by Pascal Costanza: "This seems to
> have been fixed at some point during the last 10 months": <
> http://article.gmane.org/gmane.lisp.steel-bank.devel/10603>
>
> Custom metaclasses are crucial for CLPython. Hopefully someone feels
> inclined to fix this SBCL issue.
>
> - Willem
>
> _______________________________________________
> clpython-devel mailing list
> clpython-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/clpython-devel
>
>


-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose adhesive
power can therefore not be permanently guaranteed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080506/c62365f7/attachment.html>

From varuzza at gmail.com  Tue May 13 05:21:21 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Tue, 13 May 2008 02:21:21 -0300
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805060001290.3111@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
Message-ID: <5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>

I just discovered how to compile clpython in SBCL 1.0.16. If you remove the
declaration of py-dict to outside of the eval-when  SBCL won't go crazy
about the STREAM-ELEMENT-TYPE thing.

Apparently everything is ok. The commands suggested in the final of the
compilation process works without trouble.

I'm sending my changes.


On Tue, May 6, 2008 at 1:19 AM, Jason Nielsen <jdn at math.carleton.ca> wrote:

> I can confirm that compilation fails using SBCL 1.0.16 on a Ubuntu 7.10
> system with a:
>
> "has no suitable method for STREAM-ELEMENT-TYPE, and so has fallen through
> to this method...."
>
> error that crashes the whole session.  You can reproduce this behaviour
> with the following:
>
> (defclass foo (standard-class) ())
> (defclass bar () () (:metaclass foo))
>
> Cheers,
> Jason
>
> _______________________________________________
> clpython-devel mailing list
> clpython-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/clpython-devel
>



-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose adhesive
power can therefore not be permanently guaranteed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080513/1e1e5ebd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: early-dict.diff
Type: text/x-diff
Size: 493 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080513/1e1e5ebd/attachment.diff>

From metawilm at gmail.com  Tue May 13 07:40:59 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Tue, 13 May 2008 09:40:59 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
Message-ID: <f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>

On Tue, May 13, 2008 at 7:21 AM, Leonardo Varuzza <varuzza at gmail.com> wrote:

> I just discovered how to compile clpython in SBCL 1.0.16. If you remove
> the declaration of py-dict to outside of the eval-when  SBCL won't go crazy
> about the STREAM-ELEMENT-TYPE thing.


Okay, thanks! The eval-when is probably required for Allegro (and to be
strictly portable) though, so I'll introduce some read-time conditionals in
the code.

Apparently everything is ok. The commands suggested in the final of the
> compilation process works without trouble.


That's good news! How about the test suite, does that succeed (with just the
5 or so expected failures)?

- Willem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080513/45be0699/attachment.html>

From varuzza at gmail.com  Tue May 13 15:24:29 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Tue, 13 May 2008 12:24:29 -0300
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
Message-ID: <5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>

Nope, thing get little bit worst:

Errors detected in this test: 98 UNEXPECTED: 94
Successes this test:601


On Tue, May 13, 2008 at 4:40 AM, Willem Broekema <metawilm at gmail.com> wrote:
> On Tue, May 13, 2008 at 7:21 AM, Leonardo Varuzza <varuzza at gmail.com> wrote:
>
> > I just discovered how to compile clpython in SBCL 1.0.16. If you remove
> the declaration of py-dict to outside of the eval-when  SBCL won't go crazy
> about the STREAM-ELEMENT-TYPE thing.
>
>
> Okay, thanks! The eval-when is probably required for Allegro (and to be
> strictly portable) though, so I'll introduce some read-time conditionals in
> the code.
>
>
> > Apparently everything is ok. The commands suggested in the final of the
> compilation process works without trouble.
>
> That's good news! How about the test suite, does that succeed (with just the
> 5 or so expected failures)?
>
> - Willem
>



-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose
adhesive power can therefore not be permanently guaranteed.


From metawilm at gmail.com  Tue May 13 21:13:03 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Tue, 13 May 2008 23:13:03 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
Message-ID: <f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>

On Tue, May 13, 2008 at 5:24 PM, Leonardo Varuzza <varuzza at gmail.com> wrote:

> Nope, thing get little bit worst:
>
> Errors detected in this test: 98 UNEXPECTED: 94
> Successes this test:601


You get further than I do (on SBCL 1.0.10): compilation now succeeds (update
in CVS), but SBCL crashes when attempting to create a Python function.
Apparently you don't have this problem? If this issue is fixed in SBCL in
the mean time, that would be great.

By the way, the module handling is rewritten so that CMUCL does not complain
about modification of literal objects anymore. But CMUCL ends with an
illegal instruction when creating a Python function; that is shown below
this SBCL backtrace.

Things are still fine on Allegro and LispWorks.

- Willem

[SBCL 1.0.10]
* (clpython::make-py-function :name "foo" :context-name "foo" :lambda
(lambda () 42))

debugger invoked on a TYPE-ERROR:
  The value #<invalid object #x466F1171> is not of type LIST.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(NTHCDR #<error printing object>)
0] backtrace

0: (NTHCDR #<error printing object>)
1: (SB-PCL::SLOT-UNBOUND-INTERNAL #<error printing object>)
2: (SB-PCL::SET-ARG-INFO #<error printing object>)
3: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER
     ("#<...>" . "#<...>")) #<error printing object>)
4: ((LAMBDA
        (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL.
         "#<...>" . "#<...>")) #<error printing object>)
5: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS))
    #<unavailable argument>
    #<unavailable argument>
    #<CLPYTHON::FUNCALLABLE-PYTHON-CLASS CLPYTHON::PY-FUNCTION>)
6: (CLPYTHON::MAKE-PY-FUNCTION)
7: (SB-INT:SIMPLE-EVAL-IN-LEXENV
    (CLPYTHON::MAKE-PY-FUNCTION :NAME "foo" :CONTEXT-NAME "foo" :LAMBDA
                                (LAMBDA () 42))
    #<NULL-LEXENV>)
8: (INTERACTIVE-EVAL
    (CLPYTHON::MAKE-PY-FUNCTION :NAME "foo" :CONTEXT-NAME "foo" :LAMBDA
                                (LAMBDA () 42)))
9: (SB-IMPL::REPL-FUN NIL)
10: (SB-IMPL::REPL-FUN NIL)
11: ((LAMBDA ()))
12: ((LAMBDA ()))
13: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {11631A8D}>)
14: (SB-IMPL::TOPLEVEL-REPL NIL)
15: (SB-IMPL::TOPLEVEL-INIT)
16: ((LABELS SB-IMPL::RESTART-LISP))



[ CMU Common Lisp Stage 3 20071107T024924 (19D), running on Banaan ]
[ With core:
/Users/willem/dev/lisp/cmucl-2007-11-x86-darwin/lib/cmucl/lib/lisp.core ]
[ Dumped on: Wed, 2007-11-07 11:49:28+01:00 on lapputoppu.local ]

* (clpython::make-py-function :name "foo" :context-name "foo" :lambda
(lambda () 42))
; [GC threshold exceeded with 30,814,104 bytes in use.  Commencing GC.]
; [GC completed with 16,801,584 bytes retained and 14,012,520 bytes freed.]
; [GC will next occur when at least 28,801,584 bytes are in use.]
./cmucl.sh: line 2:  7029 Illegal instruction
~/dev/lisp/cmucl-2007-11-x86-darwin/bin/lisp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080513/2ccedcda/attachment.html>

From jdn at math.carleton.ca  Tue May 13 21:43:50 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Tue, 13 May 2008 17:43:50 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0805131739190.7268@octopus>

On Tue, 13 May 2008, Willem Broekema wrote:

> On Tue, May 13, 2008 at 5:24 PM, Leonardo Varuzza <varuzza at gmail.com> wrote:
>
>> Nope, thing get little bit worst:
>>
>> Errors detected in this test: 98 UNEXPECTED: 94
>> Successes this test:601
>
>
> You get further than I do (on SBCL 1.0.10): compilation now succeeds (update
> in CVS), but SBCL crashes when attempting to create a Python function.
> Apparently you don't have this problem? If this issue is fixed in SBCL in
> the mean time, that would be great.
>
> By the way, the module handling is rewritten so that CMUCL does not complain
> about modification of literal objects anymore. But CMUCL ends with an
> illegal instruction when creating a Python function; that is shown below
> this SBCL backtrace.
>
> Things are still fine on Allegro and LispWorks.
>
> - Willem
>
> [SBCL 1.0.10]
> * (clpython::make-py-function :name "foo" :context-name "foo" :lambda
> (lambda () 42))
>

Well I can confirm that it now compiles and seems to run.  I also get the 
same message when running the tests.  The following works using sbcl 
1.0.16:

>>> foo(10)
; Evaluation aborted.
CLPYTHON> (repl)
[CLPython -- type `:q' to quit, `:help' for help]
>>> (defun foo (x) (+ x 10))
CLPYTHON.APP.REPL::FOO
>>>  #'foo
#<FUNCTION CLPYTHON.APP.REPL::FOO>
>>> foo = _
; in: LAMBDA NIL
;     (CLPYTHON.AST.NODE:|assign-stmt|
;    (CLPYTHON.AST.NODE:|identifier-expr| CLPYTHON.USER::_)
;    ((CLPYTHON.AST.NODE:|identifier-expr| CLPYTHON.USER::|foo|)))
; --> LET SETF LET* MULTIPLE-VALUE-BIND LET SETF LET* MULTIPLE-VALUE-BIND
; --> LET
; ==>
;   (SB-KERNEL:%PUTHASH #:G2 #:G3 #:G5)
;
; caught WARNING:
;   Destructive function SB-KERNEL:%PUTHASH called on constant data.
;   See also:
;     The ANSI Standard, Special Operator QUOTE
;     The ANSI Standard, Section 3.2.2.3
;
; compilation unit finished
;   caught 1 WARNING condition
#<function #<FUNCTION CLPYTHON.APP.REPL::FOO> {1003059CC9}>
>>> foo (20)
30
>>> a=[10, 20, 30]
; in: LAMBDA NIL
;     (CLPYTHON.AST.NODE:|assign-stmt| (CLPYTHON.AST.NODE:|list-expr| (10 
20 30))
;                                    ((CLPYTHON.AST.NODE:|identifier-expr|
;                                      CLPYTHON.USER::|a|)))
; --> LET SETF LET* MULTIPLE-VALUE-BIND LET SETF LET* MULTIPLE-VALUE-BIND
; --> LET
; ==>
;   (SB-KERNEL:%PUTHASH #:G2 #:G3 #:G5)
;
; caught WARNING:
;   Destructive function SB-KERNEL:%PUTHASH called on constant data.
;   See also:
;     The ANSI Standard, Special Operator QUOTE
;     The ANSI Standard, Section 3.2.2.3
;
; compilation unit finished
;   caught 1 WARNING condition
[10, 20, 30]
>>> a[1:]
[20, 30]

Cheers,
Jason


From metawilm at gmail.com  Tue May 13 22:16:38 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Wed, 14 May 2008 00:16:38 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805131739190.7268@octopus>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
Message-ID: <f6bc9b490805131516h3bcd5496u8de77d991c6e0378@mail.gmail.com>

On Tue, May 13, 2008 at 11:43 PM, Jason Nielsen <jdn at math.carleton.ca> wrote:
> Well I can confirm that it now compiles and seems to run.  I also get the same message when running the tests.

Good, then I must find a way to run 1.0.16 too.

> >>> foo = _
>
> ; in: LAMBDA NIL
> ;     (CLPYTHON.AST.NODE:|assign-stmt|
> ;    (CLPYTHON.AST.NODE:|identifier-expr| CLPYTHON.USER::_)
> ;    ((CLPYTHON.AST.NODE:|identifier-expr| CLPYTHON.USER::|foo|)))
> ; --> LET SETF LET* MULTIPLE-VALUE-BIND LET SETF LET* MULTIPLE-VALUE-BIND
> ; --> LET
> ; ==>
> ;   (SB-KERNEL:%PUTHASH #:G2 #:G3 #:G5)
> ;
> ; caught WARNING:
> ;   Destructive function SB-KERNEL:%PUTHASH called on constant data.
> ;   See also:
> ;     The ANSI Standard, Special Operator QUOTE
> ;     The ANSI Standard, Section 3.2.2.3
> ;
> ; compilation unit finished
> ;   caught 1 WARNING condition
> #<function #<FUNCTION CLPYTHON.APP.REPL::FOO> {1003059CC9}>

This modifying of constants should be fixed now in CVS.

- Willem


From varuzza at gmail.com  Tue May 13 22:57:56 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Tue, 13 May 2008 19:57:56 -0300
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
Message-ID: <5d9c2e640805131557m70bc2d8ev64584afb96b04a09@mail.gmail.com>

Executing the code bellow for the first time

(run "
def foo(x):
  return x+1")

I got this error on SBCL 1.0.16:

===== SLDB output
========================================================================
The value 563404091678720 is not of type LIST.
   [Condition of type TYPE-ERROR]

Restarts:
  0: [ABORT-REQUEST] Abort handling SLIME request.
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{1003601911}>)

Backtrace:
  0: (NTHCDR 10 563404091678720)[:EXTERNAL]
  1: (SB-PCL::SLOT-UNBOUND-INTERNAL #<error printing object>)
  2: (SB-PCL::SET-ARG-INFO #<error printing object>)[:EXTERNAL]
  3: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER
(STANDARD-GENERIC-FUNCTION)) #<error printing object>)[:EXTERNAL]
  4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.))
#<error printing object>)
  5: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable
argument> #<unavailable argument> #<FUNCALLABLE-PYTHON-CLASS
PY-FUNCTION>)[:EXTERNAL]
  6: (MAKE-PY-FUNCTION)[:EXTERNAL]
  7: ((LAMBDA NIL))
  8: (CALL-WITH-PY-ERRORS #<CLOSURE (LAMBDA NIL) {1002EBCB39}>)
  9: ((LAMBDA (&KEY GLOBALS-HANDLER (CALL-PRELOAD-HOOK T) (MODULE-NAME
(QUOTE "__main__")) (MODULE-PATH (QUOTE "")))) :GLOBALS-HANDLER NIL
:CALL-PRELOAD-HOOK T :MODULE-NAME "__main__" :MODULE-PATH "")
 10: (RUN-PYTHON-AST (CLPYTHON.AST.NODE:|module-stmt|
(CLPYTHON.AST.NODE:|suite-stmt| (#))))[:EXTERNAL]
 11: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN "
def foo(x):
  return x+1") #<NULL-LEXENV>)
 12: (SWANK::EVAL-REGION "(run \"
def foo(x):
  return x+1\")

" T)
===== SLDB output
========================================================================

Trying to run the code again I get this other error:

===== SLDB output
========================================================================
Heap exhausted: 8491880448 bytes available, 4503772160131216
requested. PROCEED WITH CAUTION!
   [Condition of type SB-KERNEL::HEAP-EXHAUSTED-ERROR]

Restarts:
  0: [ABORT-REQUEST] Abort handling SLIME request.
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{1003676911}>)

Backtrace:
  0: (SB-KERNEL::HEAP-EXHAUSTED-ERROR 8491880448 4503772160131216)
  1: ("foreign function: #x41DEC2")
  2: ("foreign function: #x40BCFE")
  3: ("foreign function: #x41953F")
  4: ("foreign function: #x4196A5")
  5: ("foreign function: #x41A900")
  6: ("foreign function: #x41B0DC")
  7: ("foreign function: #x41DF1A")
  8: (SB-PCL::ALLOCATE-STANDARD-FUNCALLABLE-INSTANCE #<SB-PCL::WRAPPER
#<FUNCALLABLE-PYTHON-CLASS PY-FUNCTION> {10026C51C1}> NIL)
  9: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable
argument> #<unavailable argument> #<FUNCALLABLE-PYTHON-CLASS
PY-FUNCTION>)[:EXTERNAL]
 10: (MAKE-PY-FUNCTION)[:EXTERNAL]
 11: ((LAMBDA NIL))
 12: (CALL-WITH-PY-ERRORS #<CLOSURE (LAMBDA NIL) {10032A0D79}>)
 13: ((LAMBDA (&KEY GLOBALS-HANDLER (CALL-PRELOAD-HOOK T) (MODULE-NAME
(QUOTE "__main__")) (MODULE-PATH (QUOTE "")))) :GLOBALS-HANDLER NIL
:CALL-PRELOAD-HOOK T :MODULE-NAME "__main__" :MODULE-PATH "")
 14: (RUN-PYTHON-AST (CLPYTHON.AST.NODE:|module-stmt|
(CLPYTHON.AST.NODE:|suite-stmt| (#))))[:EXTERNAL]
 15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN "
def foo(x):
  return x+1") #<NULL-LEXENV>)
 16: (SWANK::EVAL-REGION "(run \"
def foo(x):
  return x+1\")

" T)
 17: ((LAMBDA NIL))
 18: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T))
#<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL)
{1002CCA469}>)
 19: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL) {1002CCA469}>)
 20: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(run \"
def foo(x):
  return x+1\")

") #<NULL-LEXENV>)
===== SLDB output
========================================================================

-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose
adhesive power can therefore not be permanently guaranteed.


From varuzza at gmail.com  Wed May 14 00:42:47 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Tue, 13 May 2008 21:42:47 -0300
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <5d9c2e640805131557m70bc2d8ev64584afb96b04a09@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<5d9c2e640805131557m70bc2d8ev64584afb96b04a09@mail.gmail.com>
Message-ID: <5d9c2e640805131742h4924092bo90ca7b7b4dc34bc2@mail.gmail.com>

Making the instance of python-function in REPL:

(make-instance 'py-function :fname '|cl-user::f|)

I got the same error:


============ SLDB =====================

The value 8595300352 is not of type LIST.
   [Condition of type TYPE-ERROR]

Restarts:
  0: [ABORT-REQUEST] Abort handling SLIME request.
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{100385CA01}>)

Backtrace:
  0: (NTHCDR 10 8595300352)[:EXTERNAL]
  1: (SB-PCL::SLOT-UNBOUND-INTERNAL #<error printing object>)
  2: (SB-PCL::SET-ARG-INFO #<error printing object>)[:EXTERNAL]
  3: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER
(STANDARD-GENERIC-FUNCTION)) #<error printing object>)[:EXTERNAL]
  4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.))
#<error printing object>)
  5: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable
argument> #<unavailable argument> #<FUNCALLABLE-PYTHON-CLASS
PY-FUNCTION>)[:EXTERNAL]
  6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (MAKE-INSTANCE (QUOTE PY-FUNCTION)
:FNAME (QUOTE |cl-user::f|)) #<NULL-LEXENV>)
  7: (SWANK::EVAL-REGION "(make-instance 'py-function :fname '|cl-user::f|)

=======================================

On Tue, May 13, 2008 at 7:57 PM, Leonardo Varuzza <varuzza at gmail.com> wrote:
> Executing the code bellow for the first time
>
>  (run "
>  def foo(x):
>   return x+1")
>
>  I got this error on SBCL 1.0.16:
>
>  ===== SLDB output
>  ========================================================================
>  The value 563404091678720 is not of type LIST.
>    [Condition of type TYPE-ERROR]
>
>  Restarts:
>   0: [ABORT-REQUEST] Abort handling SLIME request.
>   1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
>  {1003601911}>)
>
>  Backtrace:
>   0: (NTHCDR 10 563404091678720)[:EXTERNAL]
>
>   1: (SB-PCL::SLOT-UNBOUND-INTERNAL #<error printing object>)
>   2: (SB-PCL::SET-ARG-INFO #<error printing object>)[:EXTERNAL]
>
>   3: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER
>  (STANDARD-GENERIC-FUNCTION)) #<error printing object>)[:EXTERNAL]
>   4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
>  SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.))
>
> #<error printing object>)
>   5: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable
>  argument> #<unavailable argument> #<FUNCALLABLE-PYTHON-CLASS
>  PY-FUNCTION>)[:EXTERNAL]
>   6: (MAKE-PY-FUNCTION)[:EXTERNAL]
>   7: ((LAMBDA NIL))
>   8: (CALL-WITH-PY-ERRORS #<CLOSURE (LAMBDA NIL) {1002EBCB39}>)
>   9: ((LAMBDA (&KEY GLOBALS-HANDLER (CALL-PRELOAD-HOOK T) (MODULE-NAME
>  (QUOTE "__main__")) (MODULE-PATH (QUOTE "")))) :GLOBALS-HANDLER NIL
>  :CALL-PRELOAD-HOOK T :MODULE-NAME "__main__" :MODULE-PATH "")
>   10: (RUN-PYTHON-AST (CLPYTHON.AST.NODE:|module-stmt|
>  (CLPYTHON.AST.NODE:|suite-stmt| (#))))[:EXTERNAL]
>   11: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN "
>  def foo(x):
>   return x+1") #<NULL-LEXENV>)
>   12: (SWANK::EVAL-REGION "(run \"
>  def foo(x):
>   return x+1\")
>
>  " T)
>  ===== SLDB output
>  ========================================================================
>
>  Trying to run the code again I get this other error:
>
>  ===== SLDB output
>  ========================================================================
>  Heap exhausted: 8491880448 bytes available, 4503772160131216
>  requested. PROCEED WITH CAUTION!
>    [Condition of type SB-KERNEL::HEAP-EXHAUSTED-ERROR]
>
>  Restarts:
>   0: [ABORT-REQUEST] Abort handling SLIME request.
>   1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
>  {1003676911}>)
>
>  Backtrace:
>   0: (SB-KERNEL::HEAP-EXHAUSTED-ERROR 8491880448 4503772160131216)
>   1: ("foreign function: #x41DEC2")
>   2: ("foreign function: #x40BCFE")
>   3: ("foreign function: #x41953F")
>   4: ("foreign function: #x4196A5")
>   5: ("foreign function: #x41A900")
>   6: ("foreign function: #x41B0DC")
>   7: ("foreign function: #x41DF1A")
>   8: (SB-PCL::ALLOCATE-STANDARD-FUNCALLABLE-INSTANCE #<SB-PCL::WRAPPER
>  #<FUNCALLABLE-PYTHON-CLASS PY-FUNCTION> {10026C51C1}> NIL)
>
>   9: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable
>  argument> #<unavailable argument> #<FUNCALLABLE-PYTHON-CLASS
>  PY-FUNCTION>)[:EXTERNAL]
>   10: (MAKE-PY-FUNCTION)[:EXTERNAL]
>   11: ((LAMBDA NIL))
>   12: (CALL-WITH-PY-ERRORS #<CLOSURE (LAMBDA NIL) {10032A0D79}>)
>   13: ((LAMBDA (&KEY GLOBALS-HANDLER (CALL-PRELOAD-HOOK T) (MODULE-NAME
>  (QUOTE "__main__")) (MODULE-PATH (QUOTE "")))) :GLOBALS-HANDLER NIL
>  :CALL-PRELOAD-HOOK T :MODULE-NAME "__main__" :MODULE-PATH "")
>   14: (RUN-PYTHON-AST (CLPYTHON.AST.NODE:|module-stmt|
>  (CLPYTHON.AST.NODE:|suite-stmt| (#))))[:EXTERNAL]
>   15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (RUN "
>  def foo(x):
>   return x+1") #<NULL-LEXENV>)
>   16: (SWANK::EVAL-REGION "(run \"
>  def foo(x):
>   return x+1\")
>
>  " T)
>   17: ((LAMBDA NIL))
>   18: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T))
>  #<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL)
>  {1002CCA469}>)
>   19: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL) {1002CCA469}>)
>   20: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(run \"
>  def foo(x):
>   return x+1\")
>
>  ") #<NULL-LEXENV>)
>  ===== SLDB output
>  ========================================================================
>
>
>
>  --
>  The most fundamental particles in this product are held together by a
>  "gluing" force about which little is currently known and whose
>  adhesive power can therefore not be permanently guaranteed.
>



-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose
adhesive power can therefore not be permanently guaranteed.


From jdn at math.carleton.ca  Wed May 14 19:46:27 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Wed, 14 May 2008 15:46:27 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805131739190.7268@octopus>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
Message-ID: <Pine.LNX.4.64.0805141543240.16462@octopus>

I've attached a diff from my local changes to the current cvs.  Very 
simple stuff that I think might be useful.  It is all #+sbcl specific so 
won't affect anything else.  Please feel free to use it or discard it at 
your discretion.

Cheers,
Jason

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdn.diff
Type: text/x-diff
Size: 8681 bytes
Desc: 
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080514/8ff7650c/attachment.diff>

From metawilm at gmail.com  Wed May 14 20:35:12 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Wed, 14 May 2008 22:35:12 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805141543240.16462@octopus>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
Message-ID: <f6bc9b490805141335p62f1dad3mfb0f7f0e5daaf4fb@mail.gmail.com>

On Wed, May 14, 2008 at 9:46 PM, Jason Nielsen <jdn at math.carleton.ca> wrote:
> I've attached a diff from my local changes to the current cvs.  Very simple
> stuff that I think might be useful.  It is all #+sbcl specific so won't
> affect anything else.  Please feel free to use it or discard it at your
> discretion.

Thanks for the additions, I'll include them.

- Willem


From metawilm at gmail.com  Thu May 15 22:16:21 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Fri, 16 May 2008 00:16:21 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <5d9c2e640805131742h4924092bo90ca7b7b4dc34bc2@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<5d9c2e640805131557m70bc2d8ev64584afb96b04a09@mail.gmail.com>
	<5d9c2e640805131742h4924092bo90ca7b7b4dc34bc2@mail.gmail.com>
Message-ID: <f6bc9b490805151516k5a4e770bu55d7fdf394492e80@mail.gmail.com>

On Wed, May 14, 2008 at 2:42 AM, Leonardo Varuzza <varuzza at gmail.com> wrote:
> Making the instance of python-function in REPL:
>
> (make-instance 'py-function :fname '|cl-user::f|)
>
> I got the same error:
>
>
> ============ SLDB =====================
>
> The value 8595300352 is not of type LIST.
>   [Condition of type TYPE-ERROR]

This occured in SBCL 1.0.16 on Mac OS X too.

As a work-around there is now a fall-back to regular Lisp functions,
with the new setting *create-simple-lambdas-for-python-functions* that
is true for SBCL. You lose a little bit by not having first-class
Python functions, like their name and dict, but for most Python code
that doesn't matter.

Now the test suite to run almost fine: just 10 similar tests for
invalid syntax detection fail. SBCL signals a compiler error instead
of passing on the syntax error raised during the macroexpansion.
Should be fixable.

- Willem


From varuzza at gmail.com  Thu May 15 23:52:09 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Thu, 15 May 2008 20:52:09 -0300
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805151516k5a4e770bu55d7fdf394492e80@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<5d9c2e640805131557m70bc2d8ev64584afb96b04a09@mail.gmail.com>
	<5d9c2e640805131742h4924092bo90ca7b7b4dc34bc2@mail.gmail.com>
	<f6bc9b490805151516k5a4e770bu55d7fdf394492e80@mail.gmail.com>
Message-ID: <5d9c2e640805151652q1e0a29fake021c60c55c31ba2@mail.gmail.com>

Working on SBCL 10.0.16 on Linux too. Only 10 unexpected failures.


On Thu, May 15, 2008 at 7:16 PM, Willem Broekema <metawilm at gmail.com> wrote:
> On Wed, May 14, 2008 at 2:42 AM, Leonardo Varuzza <varuzza at gmail.com> wrote:
>> Making the instance of python-function in REPL:
>>
>> (make-instance 'py-function :fname '|cl-user::f|)
>>
>> I got the same error:
>>
>>
>> ============ SLDB =====================
>>
>> The value 8595300352 is not of type LIST.
>>   [Condition of type TYPE-ERROR]
>
> This occured in SBCL 1.0.16 on Mac OS X too.
>
> As a work-around there is now a fall-back to regular Lisp functions,
> with the new setting *create-simple-lambdas-for-python-functions* that
> is true for SBCL. You lose a little bit by not having first-class
> Python functions, like their name and dict, but for most Python code
> that doesn't matter.
>
> Now the test suite to run almost fine: just 10 similar tests for
> invalid syntax detection fail. SBCL signals a compiler error instead
> of passing on the syntax error raised during the macroexpansion.
> Should be fixable.
>
> - Willem
>



-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose
adhesive power can therefore not be permanently guaranteed.


From jdn at math.carleton.ca  Fri May 16 13:29:02 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Fri, 16 May 2008 09:29:02 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805141543240.16462@octopus>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
Message-ID: <Pine.LNX.4.64.0805160925030.19718@buddy>

When running sbcl in a console without slime I get the following error 
when requiring clpython:

This is SBCL 1.0.16.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
; loading system definition from
; /usr/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM SB-BSD-SOCKETS {AB53C41}> as SB-BSD-SOCKETS
; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {ACC3309}> as 
SB-BSD-SOCKETS-TESTS
* (require 'clpython)

; loading system definition from /home/jdn/.sbcl/systems/closer-mop.asd 
into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM #:CLOSER-MOP {B116399}> as CLOSER-MOP
; loading system definition from /home/jdn/.sbcl/systems/lw-compat.asd 
into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM #:LW-COMPAT {B247471}> as LW-COMPAT
WARNING: change in instance length of class SB-PRETTY:PRETTY-STREAM:
   current length: 25
   compile time length: 27

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" 
{A884589}>:
   The class SB-PRETTY:PRETTY-STREAM was not changed, and there's no 
guarantee that
the loaded code (which expected another layout) will work.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {A9A44A1}> on
               #<ASDF:CL-SOURCE-FILE "yacc" {A9A44B1}>.
   1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A9A44A1}> on
               #<ASDF:CL-SOURCE-FILE "yacc" {A9A44B1}> as having been 
successful.
   2: [ABORT ] Exit debugger, returning to top level.

(SB-KERNEL::CHECK-LAYOUT
  #<SB-KERNEL:LAYOUT for SB-PRETTY:PRETTY-STREAM {950DC29}>
  #<SB-KERNEL:STRUCTURE-CLASSOID SB-PRETTY:PRETTY-STREAM>
  27
  #(#<SB-KERNEL:LAYOUT for T {905F621}>
    #<SB-KERNEL:LAYOUT for STRUCTURE-OBJECT {905F659}>
    #<SB-KERNEL:LAYOUT for STREAM {91A51C1}>
    #<SB-KERNEL:LAYOUT for SB-KERNEL:ANSI-STREAM {905FB69}>)
  4
  0)

which seems to be a problem with lw-compat.  When using clpython with 
slime this error doesn't occur and I get:

**********************************
End CLPython test
Errors detected in this test: 14 UNEXPECTED: 10
Successes this test:695
;
; compilation unit finished
;   caught 12 fatal ERROR conditions
;   caught 3 WARNING conditions
;   caught 22 STYLE-WARNING conditions
;   printed 23 notes

when running the test suite (Ubuntu 7.10 on both amd64 and x86 systems).

Jason


From metawilm at gmail.com  Sat May 17 15:32:29 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Sat, 17 May 2008 17:32:29 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805160925030.19718@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
	<Pine.LNX.4.64.0805160925030.19718@buddy>
Message-ID: <f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>

On Fri, May 16, 2008 at 3:29 PM, Jason Nielsen <jdn at math.carleton.ca> wrote:
> When running sbcl in a console without slime I get the following error when
> requiring clpython:
> [...]
> ; loading system definition from /home/jdn/.sbcl/systems/closer-mop.asd into
> ; #<PACKAGE "ASDF0">
> ; registering #<SYSTEM #:CLOSER-MOP {B116399}> as CLOSER-MOP
> ; loading system definition from /home/jdn/.sbcl/systems/lw-compat.asd into
> ; #<PACKAGE "ASDF0">
> ; registering #<SYSTEM #:LW-COMPAT {B247471}> as LW-COMPAT
> WARNING: change in instance length of class SB-PRETTY:PRETTY-STREAM:
>  current length: 25
>  compile time length: 27

Does not sound good...

> which seems to be a problem with lw-compat.

Indeed.

>  When using clpython with slime this error doesn't occur and I get:
>
> **********************************
> End CLPython test
> Errors detected in this test: 14 UNEXPECTED: 10
> Successes this test:695

All unexpected errors should now be gone!

- Willem


From jdn at math.carleton.ca  Sat May 17 16:17:17 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Sat, 17 May 2008 12:17:17 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>
References: <Pine.LNX.4.64.0805060001290.3111@buddy> 
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com> 
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com> 
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com> 
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com> 
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
	<Pine.LNX.4.64.0805160925030.19718@buddy>
	<f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0805171210250.16486@buddy>

On Sat, 17 May 2008, Willem Broekema wrote:

> On Fri, May 16, 2008 at 3:29 PM, Jason Nielsen <jdn at math.carleton.ca> wrote:
>> When running sbcl in a console without slime I get the following error when
>> requiring clpython:
>> [...]
>> ; loading system definition from /home/jdn/.sbcl/systems/closer-mop.asd into
>> ; #<PACKAGE "ASDF0">
>> ; registering #<SYSTEM #:CLOSER-MOP {B116399}> as CLOSER-MOP
>> ; loading system definition from /home/jdn/.sbcl/systems/lw-compat.asd into
>> ; #<PACKAGE "ASDF0">
>> ; registering #<SYSTEM #:LW-COMPAT {B247471}> as LW-COMPAT
>> WARNING: change in instance length of class SB-PRETTY:PRETTY-STREAM:
>>  current length: 25
>>  compile time length: 27
>
> Does not sound good...
>
>> which seems to be a problem with lw-compat.
>
> Indeed.

Turns out that closer-mop (the latest from the darcs repo) doesn't rely on 
lw-compat (I've attached for your convenience).  So I removed the old 
lw-compat and closer-mop and rebuilt.  Clpython builds and runs the tests 
successfully:

**********************************
End CLPython test
Errors detected in this test: 4
Successes this test:705


However, when I require clpython in an raw sbcl console I still get the 
error:

; loading system definition from /home/jdn/.sbcl/systems/closer-mop.asd 
into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM #:CLOSER-MOP {B116399}> as CLOSER-MOP
WARNING: change in instance length of class SB-PRETTY:PRETTY-STREAM:
   current length: 25
   compile time length: 27

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" 
{A884589}>:
   The class SB-PRETTY:PRETTY-STREAM was not changed, and there's no 
guarantee that
the loaded code (which expected another layout) will work.

which is similar to before but now closer-mop is the culprit.  If you 
accept a few time it will load and run the tests so it doesn't seem as 
serious as one may think.

Out of curiosity I just:

(require 'closer-mop)

and it loads fine so I don't think the problem is there.  Not sure what 
slime adds to the mix such that it doesn't have any trouble.

Cheers,
Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: closer-mop.tar.gz
Type: application/octet-stream
Size: 145134 bytes
Desc: 
URL: <https://mailman.common-lisp.net/pipermail/clpython-devel/attachments/20080517/6f36a930/attachment.obj>

From metawilm at gmail.com  Sat May 17 16:44:57 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Sat, 17 May 2008 18:44:57 +0200
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805171210250.16486@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
	<Pine.LNX.4.64.0805160925030.19718@buddy>
	<f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>
	<Pine.LNX.4.64.0805171210250.16486@buddy>
Message-ID: <f6bc9b490805170944r1b1f214fq15bcca09f3381aca@mail.gmail.com>

On Sat, May 17, 2008 at 6:17 PM, Jason Nielsen <jdn at math.carleton.ca>
> Turns out that closer-mop (the latest from the darcs repo) doesn't rely on
> lw-compat (I've attached for your convenience).  So I removed the old
> lw-compat and closer-mop and rebuilt.  Clpython builds and runs the tests
> successfully:
>
> **********************************
> End CLPython test
> Errors detected in this test: 4
> Successes this test:705

Good, same output as for me.

> and it loads fine so I don't think the problem is there.  Not sure what
> slime adds to the mix such that it doesn't have any trouble.

At the moment I don't use slime, so I don't have the problem. But as
it seems unrelated to CLPython, let's not discuss that issue further
here. Perhaps you could ask on the SBCL list?

- Willem


From jdn at math.carleton.ca  Sat May 17 16:45:13 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Sat, 17 May 2008 12:45:13 -0400 (EDT)
Subject: [clpython-devel] Re: CLPython on SBCL
In-Reply-To: <Pine.LNX.4.64.0805171210250.16486@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy> 
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com> 
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com> 
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com> 
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com> 
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
	<Pine.LNX.4.64.0805160925030.19718@buddy>
	<f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>
	<Pine.LNX.4.64.0805171210250.16486@buddy>
Message-ID: <Pine.LNX.4.64.0805171240250.16486@buddy>

On Sat, 17 May 2008, Jason Nielsen wrote:

> and it loads fine so I don't think the problem is there.  Not sure what slime 
> adds to the mix such that it doesn't have any trouble.
>

So slime does indeed do something since:

* (require 'swank)

[snip]

;; loading #P"/var/cache/common-lisp-controller/1001/sbcl/swank/fasl/sbcl-1.0.16.debian-linux-x86/swank-presentation-streams.fasl"
WARNING: change in instance length of class PRETTY-STREAM:
   current length: 25
   new length: 27


then loading clpython works as though loading from within slime.  There is 
a fix I believe in swank-presentation-streams.lisp.

Cheers,
Jason


From omouse at gmail.com  Sun May 18 23:43:11 2008
From: omouse at gmail.com (Rudolf)
Date: Sun, 18 May 2008 19:43:11 -0400
Subject: [clpython-devel] Computer Language Shootout benchmarks
Message-ID: <edf654070805181643x1c6f704m342afeda3d7d05b9@mail.gmail.com>

Has anyone had any luck running any of them? I just tried three
(pidigts, nsieve, and recursive) and got some nice exceptions in
return.

Thanks
-Rudolf Olah


From metawilm at gmail.com  Mon May 19 08:45:04 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Mon, 19 May 2008 10:45:04 +0200
Subject: [clpython-devel] Computer Language Shootout benchmarks
In-Reply-To: <edf654070805181643x1c6f704m342afeda3d7d05b9@mail.gmail.com>
References: <edf654070805181643x1c6f704m342afeda3d7d05b9@mail.gmail.com>
Message-ID: <f6bc9b490805190145r5d9bf3adk4b43587d17779c4a@mail.gmail.com>

On Mon, May 19, 2008 at 1:43 AM, Rudolf <omouse at gmail.com> wrote:
> Has anyone had any luck running any of them? I just tried three
> (pidigts, nsieve, and recursive) and got some nice exceptions in
> return.

Rudolf, I guess you are the first to try running them. Let's spread
the work: if you see some Python code failing, please extract a
minimal test case for the error and post it to the list.

- Willem


From jdn at math.carleton.ca  Sat May 24 20:36:49 2008
From: jdn at math.carleton.ca (Jason Nielsen)
Date: Sat, 24 May 2008 16:36:49 -0400 (EDT)
Subject: [clpython-devel] New error,
	recent cvs update on SBCL 1.0.16 (Ubuntu 7.10)
In-Reply-To: <Pine.LNX.4.64.0805171210250.16486@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy> 
	<5d9c2e640805122221s20b26cf6md62e32736b92d617@mail.gmail.com> 
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com> 
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com> 
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com> 
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
	<Pine.LNX.4.64.0805160925030.19718@buddy>
	<f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>
	<Pine.LNX.4.64.0805171210250.16486@buddy>
Message-ID: <Pine.LNX.4.64.0805241632200.25817@buddy>

Hello,

I'm getting the following error:

; ==>
;   CLPYTHON.PARSER::$1
;
; note: deleting unreachable code
; in: LAMBDA NIL
;     'CLPYTHON.AST.NODE:|suite-stmt|
;
; note: deleting unreachable code
WARNING:
    change in instance length of class CLPYTHON::MODULE-GLOBALS-HANDLER:
   current length: 7
   compile time length: 9

both when compiling and loading clpython.  The compile (when accepting the 
error) and testing completes with 4 errors as expected.  However when I 
try to start up the repl I get the following:

The function CLPYTHON.APP.REPL::REPL-1 is undefined.
    [Condition of type UNDEFINED-FUNCTION]

Jason


From metawilm at gmail.com  Sat May 24 21:12:29 2008
From: metawilm at gmail.com (Willem Broekema)
Date: Sat, 24 May 2008 23:12:29 +0200
Subject: [clpython-devel] New error,
	recent cvs update on SBCL 1.0.16 (Ubuntu 7.10)
In-Reply-To: <Pine.LNX.4.64.0805241632200.25817@buddy>
References: <Pine.LNX.4.64.0805060001290.3111@buddy>
	<f6bc9b490805130040u6d727973ibf81def55435170e@mail.gmail.com>
	<5d9c2e640805130824v118aec55u400a7cb3eb7938d5@mail.gmail.com>
	<f6bc9b490805131413g46c71072y506180d5190c1907@mail.gmail.com>
	<Pine.LNX.4.64.0805131739190.7268@octopus>
	<Pine.LNX.4.64.0805141543240.16462@octopus>
	<Pine.LNX.4.64.0805160925030.19718@buddy>
	<f6bc9b490805170832h1793809cgdd8cdbb5bca53307@mail.gmail.com>
	<Pine.LNX.4.64.0805171210250.16486@buddy>
	<Pine.LNX.4.64.0805241632200.25817@buddy>
Message-ID: <f6bc9b490805241412o61bcb55fqd66a26bca7264ca8@mail.gmail.com>

Hi Jason, thanks for the update...

On Sat, May 24, 2008 at 10:36 PM, Jason Nielsen <jdn at math.carleton.ca> wrote:
> WARNING:
>   change in instance length of class CLPYTHON::MODULE-GLOBALS-HANDLER:
>  current length: 7
>  compile time length: 9

It's true that I removed two fields from the struct. I would expect
the ASDF system to handle recompilation of the relevant files. In any
case, to force a complete recompilation of the system:
 (asdf:operate 'asdf:load-op :clpython :force t)

> both when compiling and loading clpython.  The compile (when accepting the
> error) and testing completes with 4 errors as expected.  However when I try
> to start up the repl I get the following:
>
> The function CLPYTHON.APP.REPL::REPL-1 is undefined.
>   [Condition of type UNDEFINED-FUNCTION]

That function should be in app/repl/repl.lisp ... maybe it is not
found as a result of a previous error? What happens if you load
repl.lisp manually?

For me things are working fine on SBCL 1.0.16, FWIW.

- Willem