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
On Tue, May 6, 2008 at 6:19 AM, Jason Nielsen jdn@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%3E
Custom metaclasses are crucial for CLPython. Hopefully someone feels inclined to fix this SBCL issue.
- Willem
On Tue, 6 May 2008, Willem Broekema wrote:
On Tue, May 6, 2008 at 6:19 AM, Jason Nielsen jdn@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%3E
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
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@gmail.com wrote:
On Tue, May 6, 2008 at 6:19 AM, Jason Nielsen jdn@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%3E
Custom metaclasses are crucial for CLPython. Hopefully someone feels inclined to fix this SBCL issue.
- Willem
clpython-devel mailing list clpython-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/clpython-devel
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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/clpython-devel
On Tue, May 13, 2008 at 7:21 AM, Leonardo Varuzza varuzza@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
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@gmail.com wrote:
On Tue, May 13, 2008 at 7:21 AM, Leonardo Varuzza varuzza@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
On Tue, May 13, 2008 at 5:24 PM, Leonardo Varuzza varuzza@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
On Tue, 13 May 2008, Willem Broekema wrote:
On Tue, May 13, 2008 at 5:24 PM, Leonardo Varuzza varuzza@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
On Tue, May 13, 2008 at 11:43 PM, Jason Nielsen jdn@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
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
On Wed, May 14, 2008 at 9:46 PM, Jason Nielsen jdn@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
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
On Fri, May 16, 2008 at 3:29 PM, Jason Nielsen jdn@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
On Sat, 17 May 2008, Willem Broekema wrote:
On Fri, May 16, 2008 at 3:29 PM, Jason Nielsen jdn@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
On Sat, May 17, 2008 at 6:17 PM, Jason Nielsen jdn@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
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
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
Hi Jason, thanks for the update...
On Sat, May 24, 2008 at 10:36 PM, Jason Nielsen jdn@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
FYI: A recent cvs pull of CLPython runs the test suite with:
********************************** End CLPython test Errors detected in this test: 3 Successes this test:718 ; ; compilation unit finished ; caught 12 fatal ERROR conditions ; caught 4 WARNING conditions ; caught 23 STYLE-WARNING conditions ; printed 25 notes
on the most recent version of sbcl (1.0.18).
Regards, Jason
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 ========================================================================
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@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.
On Wed, May 14, 2008 at 2:42 AM, Leonardo Varuzza varuzza@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
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@gmail.com wrote:
On Wed, May 14, 2008 at 2:42 AM, Leonardo Varuzza varuzza@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
clpython-devel@common-lisp.net
-
Jason Nielsen -
Leonardo Varuzza -
Willem Broekema