CLPython now also runs on CMUCL Snapshot 2009-01 (19E). This is in addition to the already supported implementations: Allegro CL, Lispworks and SBCL.
Does anyone have a strong wish to have CLPython ported to yet another implementation?
- Willem
On Sat, 17 Jan 2009, Willem Broekema wrote:
CLPython now also runs on CMUCL Snapshot 2009-01 (19E). This is in addition to the already supported implementations: Allegro CL, Lispworks and SBCL.
Does anyone have a strong wish to have CLPython ported to yet another implementation?
- Willem
Hi Willem,
Great work! The only implementation that I can think of that might be useful (to me) is ecl but it isn't a major request as I primarily use sbcl.
Any hint of what the next steps for clpython are? Just curious ;-)!
Thanks for creating clpython, Jason
On Sat, Jan 17, 2009 at 3:31 PM, Jason Nielsen jdn@math.carleton.ca wrote:
Great work! The only implementation that I can think of that might be useful (to me) is ecl but it isn't a major request as I primarily use sbcl.
Okay, I'll wait until there is demand for it.
Any hint of what the next steps for clpython are? Just curious ;-)!
A few things that play:
- Getting the shootout benchmark running http://shootout.alioth.debian.org/. The result of the tests that can be run is that CLPython performance is not bad, but CPython is on average a bit faster.
- Running Sympy, a big pure-Python project, to show language completeness. Attempting this lead already to many small fixes and conversion of required Python standard library files.
- A future goal is to have an Emacs IDE for Python based on Slime. In particular I'd like to have a great debugger for stepping through Python code. If anyone has good ideas or wishes for this, let me know.
- Willem
On Sat, 17 Jan 2009, Willem Broekema wrote:
Any hint of what the next steps for clpython are? Just curious ;-)!
A few things that play:
- Getting the shootout benchmark running
http://shootout.alioth.debian.org/. The result of the tests that can be run is that CLPython performance is not bad, but CPython is on average a bit faster.
Interesting! Do you think this is because most of the CPython code in the benchmark relies on library functions that are compiled C code?
Have you thought about adding optional types to CLPython (a.l.a. PEP 3107 in Python 3.0)? If these expanded to type declarations in common lisp I think the performance could be improved significantly.... all speculation of course!
- Running Sympy, a big pure-Python project, to show language
completeness. Attempting this lead already to many small fixes and conversion of required Python standard library files.
Sweet... and something I'd find quite useful to boot!
- A future goal is to have an Emacs IDE for Python based on Slime. In
particular I'd like to have a great debugger for stepping through Python code. If anyone has good ideas or wishes for this, let me know.
Sounds great! Thanks for the list of goodness to come.
Jason
On Sat, Jan 17, 2009 at 10:48 PM, Jason Nielsen jdn@math.carleton.ca wrote:
- Getting the shootout benchmark running
http://shootout.alioth.debian.org/. The result of the tests that can be run is that CLPython performance is not bad, but CPython is on average a bit faster.
Interesting! Do you think this is because most of the CPython code in the benchmark relies on library functions that are compiled C code?
Some of the shootout benchmarks say more about the Lisp implementation than about CLPython: bintrees.py checks the speed of recursion and consing; chameneos-redux.py check the speed of acquiring and releasing process locks. But there are others that say more about Python implementation speed.
Once the shootout files can be run on CLPython, I intend to add the shootout files to the CLPython distribution, with a simple function to run them and at the same time run them in CPython.
Have you thought about adding optional types to CLPython (a.l.a. PEP 3107 in Python 3.0)? If these expanded to type declarations in common lisp I think the performance could be improved significantly.... all speculation of course!
That PEP only introduces the concept of annotations, not the semantics. And those semantics are not clear to me. For example, what should it mean to say "x" is an "int"?
- how many bits does it have? - does it overflow? - can it be an instance of a user-defined subclass of int? - can "x" is unbound at some point, causing a NameError?
This is also what I dislike about Cython: instead of basing numeric declarations on C number types, it would be so much more portable and smart to declare the range of the values: x is in (0 .. whatever).
If anyone feels the urge to aid in development, please take a look at the Python standard library, take one implemented in C, and try to convert that to Lisp. In clpython/lib/ is a start.
Cheers, - Willem
clpython-devel@common-lisp.net
-
Jason Nielsen -
Willem Broekema