clpython-devel

clpython-devel@common-lisp.net

46 discussions

[clpython-devel] Can not login to cvspublic.franz.com
by Al Bat 15 Jan '09

15 Jan '09

Hi ! Sorry for asking such a stupid question. Is there any other way to download the current snapshot of CLPython? I've tried *"cvs -d :pserver:cvspublic@cvspublic.franz.com:/cvs-public login"* with password "* cvspublic*", as it was recommended. However, as a result, I receive only*"Connection refused" *from the server. I'm not sure, whether the failure is at the server's side. Can anybody confirm that this *cvs* way works. And in the case if it doesn't, can anybody be so kind to give me a hint on any alternative way of getting CLPython. By the way, how big is it? Maybe, it can be sent via email? Thanks! Al

2 3

[clpython-devel] Calling Python functions from Lisp [Re Franz thread: spr35431]
by Stuart C. Shapiro 09 Jan '09

09 Jan '09

I think that I have successfully installed CLPython. What I want to do is to call Python functions, defined in programs written by others, from Allegro Common Lisp. So here is a test Python program called test.py: ----------------------------- # A Python file to use to test clpython def test(): print "I am a Python function." return "I am done." print("The Python test file has been run.") ----------------------------- I loaded clpython, and did (note: this wasn't the first time I imported test, so test.fasl and test.pyc already existed.): ----------------------------- cl-user(3): (clpython:run "import test; test.test()") Warning: *import-recompiled-files* = #<equal hash-table with 0 entries> Warning: /net/projects/shapiro/clpython/test.fasl not in #<equal hash-table with 0 entries> ; Fast loading /net/projects/shapiro/clpython/test.fasl The Python test file has been run. Warning: *import-recompiled-files* = #<equal hash-table with 0 entries> Warning: /net/projects/shapiro/clpython/test.fasl not in #<equal hash-table with 0 entries> I am a Python function. "I am done." ----------------------------- First question: Why the Warning messages? How can I get rid of them? Notice that I can make use of the values returned by the Python function: ----------------------------- cl-user(4): (setf x (clpython:run "import test; test.test()")) Warning: *import-recompiled-files* = #<equal hash-table with 0 entries> Warning: /net/projects/shapiro/clpython/test.fasl not in #<equal hash-table with 0 entries> ; Fast loading /net/projects/shapiro/clpython/test.fasl The Python test file has been run. Warning: *import-recompiled-files* = #<equal hash-table with 0 entries> Warning: /net/projects/shapiro/clpython/test.fasl not in #<equal hash-table with 0 entries> I am a Python function. "I am done." cl-user(5): x "I am done." ----------------------------- What I'd really like to do now is to call test.test() as much as possible as though it were a Common Lisp function. One possible way is: ----------------------------- cl-user(6): (clpython:run "test.test()") Error: NameError: Variable `test' is unbound. [condition type: NameError] Restart actions (select using :continue): 0: Enter a Lisp value to use for `test'. 1: Return to Top Level (an "abort" restart). 2: Abort entirely from this (lisp) process. ----------------------------- But, the name of the function does not seem to survive from one call of clpython:run to another. Final question: How can I do this? stu -- Stuart C. Shapiro Professor, Department of Computer Science and Engineering University at Buffalo, The State University of New York 201 Bell Hall, Box 602000, Buffalo, NY 14260-2000, U.S.A. PHONE: 716-645-3180x125 FAX: 716-645-3464 shapiro(a)cse.buffalo.edu http://www.cse.buffalo.edu/~shapiro/

2 4

[clpython-devel] Will CLPython have a GIL?
by Anand Patil 03 Oct '08

03 Oct '08

Hi everyone, Will CLPython have a global interpreter lock? Will it allow different threads to touch Python objects simultaneously on different cores? Thanks, Anand

2 3

[clpython-devel] Installation problems
by Anand Patil 24 Sep '08

24 Sep '08

Hello, I'm trying to follow the installation instructions at http://common-lisp.net/project/clpython/ but it doesn't seem to be working. I know absolutely nothing about Lisp, so some more detailed step-by-step instructions would be very helpful. Here's what happens: * (require 'asdf) ("ASDF") * (asdf:operate 'asdf:load-op :clpython) ; loading system definition from /Users/anand/clpython.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM :CLPYTHON.PACKAGE {11A97AD9}> as CLPYTHON.PACKAGE ; registering #<SYSTEM :CLPYTHON.DEPEND {11CB5CE1}> as CLPYTHON.DEPEND ; registering #<SYSTEM :CLPYTHON.PARSER {11E49B21}> as CLPYTHON.PARSER ; registering #<SYSTEM :CLPYTHON.CORE {11FE6E79}> as CLPYTHON.CORE ; registering #<SYSTEM :CLPYTHON.LIB {1217F4F1}> as CLPYTHON.LIB ; registering #<SYSTEM :CLPYTHON.APP.REPL {11719139}> as CLPYTHON.APP.REPL ; registering #<SYSTEM :CLPYTHON.APP.PROFILER {118C4F59}> as ; CLPYTHON.APP.PROFILER ; registering #<SYSTEM :CLPYTHON.APP {11A6FEA1}> as CLPYTHON.APP ; registering #<SYSTEM :CLPYTHON {11C05761}> as CLPYTHON debugger invoked on a ASDF:MISSING-DEPENDENCY: component :CLOSER-MOP not found, required by #<SYSTEM "clpython.core" {122B0A71}> 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. ((LABELS ASDF::DO-ONE-DEP) ASDF:COMPILE-OP :CLOSER-MOP NIL) 0] Thanks in advance, Anand

2 1

[clpython-devel] Re: CLPython on SBCL
by Jason Nielsen 07 Jul '08

07 Jul '08

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

3 23

[clpython-devel] New errors in recent CVS
by Jason Nielsen 14 Jun '08

14 Jun '08

Hello, I just pulled the recent changes from cvs and get the following warning when building: The constant CLPYTHON.PARSER::+ALL-VALUES-NAMES+ is being redefined (from (CLPYTHON.PARSER:+NORMAL-VALUE+ CLPYTHON.PARSER:+AUGASSIGN-VALUE+ CLPYTHON.PARSER:+NO-VALUE+) to (CLPYTHON.PARSER:+NORMAL-VALUE+ CLPYTHON.PARSER:+AUGASSIGN-VALUE+ CLPYTHON.PARSER:+NO-VALUE+)) which I accept and the build finishes. When I run the test suite I get the following: ********************************** End CLPython test Errors detected in this test: 104 UNEXPECTED: 100 Successes this test:609 ; ; compilation unit finished ; caught 114 fatal ERROR conditions ; caught 4 ERROR conditions ; caught 3 WARNING conditions ; caught 22 STYLE-WARNING conditions ; printed 26 notes NIL There are a whole bunch of error messages when running the tests of the form: Reason: detected an unexpected error of type `#<SB-PCL::CONDITION-CLASS SB-C:COMPILER-ERROR>': which are the likely cause of the 100 extra failures. All of this is on a Ubuntu 7.10 box with sbcl 1.0.17... I built the latest sbcl along with the previous tarball I had and the test suite ran as expected so the problem is in recent updates. By the way I've been following Euro 2008 closely (I'm a huge soccer/football fan which isn't quite as common here in Canada) and the Dutch team are looking awesome! Nothing like kicking the asses of the reigning world champs and runners-up to start off the tournament ;-). Jason

2 2

[clpython-devel] Python just got a bit less dynamic
by Willem Broekema 13 Jun '08

13 Jun '08

Guido just limited the dynamicness of Python in a very sensible way, by declaring that the attributes of objects can only be regular strings. For users this does not change much, but for implementors this has significant benefits, so I like this limitation a lot. The implementation of attributes in CLPython and other implementations can now be cleaned up and made more efficient by removing hairy corner cases. CLPython can now always represent attributes by Lisp symbols. Also as a result, the five known failures in the CLPython test suite, which tested some hairy corner cases, are now defined to not be failures at all. The decisions: - Using non-string keys is undefined behavior; non-empty strings that are not valid as identifier according to the grammar are allowed: http://mail.python.org/pipermail/python-dev/2008-June/080309.html - String subclasses may be normalized to regular strings: http://mail.python.org/pipermail/python-dev/2008-June/080312.html - The restriction applies to both class dicts and instance dicts: http://mail.python.org/pipermail/python-dev/2008-June/080313.html - Frameworks currently using non-string attributes should change their behavior; http://mail.python.org/pipermail/python-dev/2008-June/080319.html - Willem

1 0

[clpython-devel] Computer Language Shootout benchmarks
by Rudolf 19 May '08

19 May '08

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

2 1

[clpython-devel] Re: CLPython on SBCL
by Willem Broekema 03 May '08

03 May '08

Hello Bob, On Thu, May 1, 2008 at 5:52 PM, Robert Brown <brown(a)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

2 3

[clpython-devel] RE: CLPython on LispWorks
by Jochen Schmidt 22 Apr '08

22 Apr '08

Hello Willem, I've tried to compile CLPython as you suggested in your message. There were two problems I had to solve: 1) Incomplete Definition in core/csetup.lisp The only Definition in this file was: (defun py-raise (exc-type string &rest format-args) "Raise a Python exception with given format string" (if +exceptions-are-python-objects+ (error exc-type :args (cons string format-args))) (error exc-type I just closed the two open parens to get it compiling. If I understood the code right - the incomplete part of this function would not get taken by LispWorks anyways (because on LispWorks you did set +exceptions-are-python-objects+ to T). 2) Reader Problem in exceptions.lisp There are two definitions for {Exception}, depending on the value of +exceptions-are-python-objects+. The decision which of the definitions applies is done by a reader-conditional which is setup within the same EVAL-WHEN like the definitions themselves; this means that the definitions are already through the reader before you push :exceptions- are-python-objects on *features*. The solution is to split the EVAL- WHEN form into two: One to push :exceptions-are-python-objects on *features* and the second one with the definitions of {Exception}. Actually I think the {Exception}-Definition wouldn't have to be within an EVAL-WHEN at all. After this two points CLPython compiles through and it seems to run - impressive! I've run your test-suite and the only failure was this one: Test failed: known failure: (CLPYTHON.PARSER:PARSE "def f(a=3,): pass") Reason: detected an unexpected error of type `#<CLPYTHON::PY-TYPE CLPYTHON.USER.BUILTIN.TYPE.EXCEPTION:|SyntaxError| 21A26D3B>': SyntaxError: Parse error at line 1, at token `)'. Expected one of: `(' `identifier' `*' `**'. [Internal error #<YACC:YACC-PARSE-ERROR 200FC37F> caught due to CLPYTHON.PARSER::*CATCH-YACC-CONDITIONS*] Which - as I understood the message - is a already known problem. Again: CLPython is a really impressive bit of work! Thanks for sharing it with us. ciao, Jochen Schmidt -- Jochen Schmidt CRISPYLOGICS Julienstr. 1, 90419 Nuremberg Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83 mailto:info@crispylogics.com http://www.crispylogics.com

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

clpython-devel