Hi Michael
[...]
Releasing open source means that people *may* fix their own bugs, or
abandon the code.
[...]
I agree with all the points made.
Moreover let me add that code is one expression of a set of good
ideas, and ideas want to be free! ;)
I've decided to release the source code of
Stelios Xanthakis wrote:
...
- It's incompatible with CPython. Not all programs run.
...
- The demo is an x86/linux binary only. You shouldn't trust binaries,
run it in a chrooted environment not as root!
Hope it works!
Whatever the merits of a system like this, a closed system with bugs
I have read about parrot. How is that progressing?
Stelios Xanthakis wrote:
Hi.
pyvm is a program which can run python 2.4 bytecode (the .pyc files).
A demo pre-release is available at:
http://students.ceid.upatras.gr/~sxanth/pyvm/
Facts about pyvm:
- It's FAST. According to the
Hi,
Kay Schluehr wrote:
Why this? eval() consumes a string, produces a code object and executes
it. Wether the code-object is bytecode or a chunk of machine code makes
a difference in the runtime but does not alter the high level
behavioural description of eval(). In either way the
Stelios Xanthakis wrote:
Kay Schluehr wrote:
Yes. What we are seeking for and this may be the meaning of Armins
intentiously provocative statement about the speed of running HLLs is a
successor of the C-language and not just another VM interpreter that is
written in C and limits all
Armin Steinhoff wrote:
pyvm has that. A big part of it is written in lightweight C++ [1].
Realy ? I have downloaded the lwc distribution and checked it out.
It was a surprise that none of the examples are working.
I'm using SuSE 9.0 with gcc 3.3.1 ...
:(
Is there a working version
Stelios Xanthakis wrote:
Also, for the other part of the thread, I think that bytecode may
be in fact faster than machine code JIT.
Forgot to add: It depends of course on how good is the bytecode.
IMO Python's bytecode is pretty good for its purpose which is
executing a dynamic language
Armin Steinhoff wrote:
Is there a working version of lwc ???
pyvm is written in lwc-2.0 which is not yet released because
nobody's using it.
As you mentioned it ... lwc-2.0 is used for pyvm. So it is used :)
Do you have an idea when lwc-2.0 will be releast ?
Everyone who are
Stelios Xanthakis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Also, for the other part of the thread, I think that bytecode may
be in fact faster than machine code JIT. Here is a theory:
Suppose that for each algorithm there is the ideal implementation
which executes at the
On 11 May 2005 19:48:42 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote:
Stelios Xanthakis [EMAIL PROTECTED] writes:
I didn't know much about PyPy. It seems that pyvm is *exactly* what
pypy needs to boost its performance. Does pypy has the vm in python
as well? Does pypy have a compiler
Kay Schluehr wrote:
Yes. What we are seeking for and this may be the meaning of Armins
intentiously provocative statement about the speed of running HLLs is a
successor of the C-language and not just another VM interpreter that is
written in C and limits all efforts to extend it in a
- hacking SWIG. Shouldn't be too hard and will instantly give
us access to wx, qt, etc.
Mike You can't assume that because some package is a C/C++ library
Mike wrapped for Python that it uses SWIG. pyqt, for example, doesn't
Mike use SWIG at all. It uses SIP, which is
[Paul Rubin]
It's true that CPython doesn't have a compiler and that's
a serious deficiency.
Hi, Paul. I did not closely follow all of the thread, so maybe my
remark below, only repeats what others might have said and I missed?
Deep down, why or how not having a [traditional, to-native-code]
Paul Rubin wrote:
Yes, there are several Python compilers already
...
It's true that CPython doesn't have a compiler and that's a serious
deficiency. A lot of Python language features don't play that well
with compilation, and that's often unnecessary. So I hope the baseline
Stelios Xanthakis wrote:
Kay Schluehr wrote:
Yes. What we are seeking for and this may be the meaning of Armins
intentiously provocative statement about the speed of running HLLs
is a
successor of the C-language and not just another VM interpreter
that is
written in C and limits all
François Pinard [EMAIL PROTECTED] writes:
Deep down, why or how not having a [traditional, to-native-code]
compiler is a deficiency for CPython? We already know that such a beast
would not increase speed so significantly, while using much more memory.
I'd say the opposite. The 4x speedup
Andrew Dalke [EMAIL PROTECTED] writes:
Years ago, presented at one of the Python conferences, was a program
to generate C code from the byte code The conclusion I recall
was that it wasn't faster - at best a few percent - and there was a
big memory hit because of all the duplicated code.
I don't think Python can ever beat
carefully coded C for running speed, but it can and should aim for
parity with compiled Lisp.
But common lisp compilers often beat C compilers in speed for similar
tasks
of moderate complexity. In particular, CMUCL beats GCC in numerical
computations.
David
[Paul Rubin]
François Pinard [EMAIL PROTECTED] writes:
Deep down, why or how not having a [traditional, to-native-code]
compiler is a deficiency for CPython? We already know that such a
beast would not increase speed so significantly, while using much
more memory.
I'd say the
Paul Rubin wrote:
Despite the shrieks of the Python is not Lisp! crowd, Python
semantics and Lisp semantics aren't THAT different, and yet compiled
Lisp implementations com completely beat the pants off of interpreted
Python in terms of performance.
I know little about Lisp compilation, so
Rocco Moretti [EMAIL PROTECTED] writes:
Python, as a procedural language, makes extensive use of globals
mutable variables IIUC, in Lisp, as a functional language, all
politics is local. Global-like variables are much rarer, and
mutability is severely limited.
Some people write Lisp
Paul Rubin wrote:
Roger Binns [EMAIL PROTECTED] writes:
Err, you proved my point! Prothon was fine at the VM level. The
author couldn't figure out how to get a decent sized standard
library, and ultimately ended up abandoning his VM for .Net since
that gets you a large standard
Paul Rubin http://[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Roger Binns [EMAIL PROTECTED] writes:
What kind of stuff is in the existing Python C library that couldn't
be reimplemented or retargeted pretty easily? Most of it is either
wrappers for standard C functions (system
Kay Schluehr [EMAIL PROTECTED] writes:
Delete the standard and You still obtain huge librarys for .Net, Java
and Python. I also regret that Prothon starved in infancy but it might
be exeggerated to demand that each language designer or one of his
apostels should manage a huge community that
Roger Binns [EMAIL PROTECTED] writes:
Some examples are gui toolkits (eg wxPython), SSL (eg M2Crypto, pyopenssl)
and database (pysqlite, APSW). These aren't in the shipped with Python
library but are widely used.
M2Crypto is a straightforward SWIG wrapper around OpenSSL, I thought.
I don't
Roger Binns wrote:
I am not very interested on C compatibility.
That will rule out all the gui frameworks, SSL, cryptography
and numerous other packages. Have a look at what happened to
Prothon. What ultimately killed it was the problem of having
a decent library. You don't have to make
Paul Rubin wrote:
I hope that PyPy will replace CPython once it's solid enough. Trying
to stay backwards compatible with the legacy C API doesn't seem to me
to be that important a goal. Redoing the library may take more work
than the Prothon guy was willing to do for Prothon, but PyPy has
In article [EMAIL PROTECTED],
Roger Binns [EMAIL PROTECTED] wrote:
could You tell us a bit more about Your motivation to create an
alternative C-Python interpreter?
I'd also be curious to know if the performance gains would remain
once it gets fleshed out with things like closures, long
Stelios Xanthakis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
- hacking SWIG. Shouldn't be too hard and will instantly give
us access to wx, qt, etc.
Have you ever written a non-trivial extension using Swig? It isn't
as simple as you would think. There are a lot of little
Stelios Xanthakis [EMAIL PROTECTED] writes:
I didn't know much about PyPy. It seems that pyvm is *exactly* what
pypy needs to boost its performance. Does pypy has the vm in python
as well? Does pypy have a compiler that produces 2.4 bytecodes?
Pypy makes native machine code, not bytecode.
Stelios Xanthakis [EMAIL PROTECTED] writes:
- hacking SWIG. Shouldn't be too hard and will instantly give
us access to wx, qt, etc.
You can't assume that because some package is a C/C++ library wrapped
for Python that it uses SWIG. pyqt, for example, doesn't use SWIG at
all. It
Paul Rubin wrote:
Kay Schluehr [EMAIL PROTECTED] writes:
Delete the standard and You still obtain huge librarys for .Net,
Java
and Python. I also regret that Prothon starved in infancy but it
might
be exeggerated to demand that each language designer or one of his
apostels should manage
Kay Schluehr wrote:
could You tell us a bit more about Your motivation to create an
alternative C-Python interpreter? There is AFAIK no such ambitious
project that has ever survived. The last one I remember died shortly
after it was born:
The motivation is that I just needed some bytecode
[EMAIL PROTECTED] wrote:
This project is probably a LOT of work; maybe people can tell us about
such efforts *before* doing so much work, so we can discuss it, and
avoid wasting time.
It is a lot of work indeed.
Usually, when people announce we shall create X, it doesn't happen.
And you
Roger Binns wrote:
could You tell us a bit more about Your motivation to create an
alternative C-Python interpreter?
I'd also be curious to know if the performance gains would remain
once it gets fleshed out with things like closures, long numbers,
new style classes and a C library
[Stelios Xanthakis]
I'm afraid this may end up dead before unborn too. So it depends what
people want. If nobody cares, [...]
People might not care so much about what could be done about your
project, unless you give them proper and complete means for evaluating
the state of affairs. Your
Stelios Xanthakis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Maybe you can explain us why it is so fast, and/or maybe you can work
with the other developers to improve the speed of the normal CPython,
this can require equal or less work for you, and it can produce more
I am not very interested on C compatibility.
That will rule out all the gui frameworks, SSL, cryptography
and numerous other packages. Have a look at what happened to
Prothon. What ultimately killed it was the problem of having
a decent library. You don't have to make the C library
Roger Binns [EMAIL PROTECTED] writes:
That will rule out all the gui frameworks, SSL, cryptography
and numerous other packages. Have a look at what happened to
Prothon.
I think it would be enough to retarget SWIG.
What ultimately killed it was the problem of having a decent
library.
Paul Rubin wrote:
Roger Binns [EMAIL PROTECTED] writes:
That will rule out all the gui frameworks, SSL, cryptography
and numerous other packages. Have a look at what happened to
Prothon.
I think it would be enough to retarget SWIG.
What ultimately killed it was the problem of having
Paul Rubin http://[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Roger Binns [EMAIL PROTECTED] writes:
That will rule out all the gui frameworks, SSL, cryptography
and numerous other packages. Have a look at what happened to
Prothon.
I think it would be enough to retarget SWIG.
Roger Binns [EMAIL PROTECTED] writes:
Err, you proved my point! Prothon was fine at the VM level. The
author couldn't figure out how to get a decent sized standard
library, and ultimately ended up abandoning his VM for .Net since
that gets you a large standard library. Jython also gets a
Paul Rubin wrote:
Stelios Xanthakis [EMAIL PROTECTED] writes:
- The demo is an x86/linux binary only. You shouldn't trust binaries,
run it in a chrooted environment not as root!
Are you going to release the source? If not, it's a lot less interesting.
From the website:
...the source
djw [EMAIL PROTECTED] writes:
Paul Rubin wrote:
Stelios Xanthakis [EMAIL PROTECTED] writes:
- The demo is an x86/linux binary only. You shouldn't trust binaries,
run it in a chrooted environment not as root!
Are you going to release the source? If not, it's a lot less interesting.
Hi.
pyvm is a program which can run python 2.4 bytecode (the .pyc files).
A demo pre-release is available at:
http://students.ceid.upatras.gr/~sxanth/pyvm/
Facts about pyvm:
- It's FAST. According to the cooked-bench benchmark suite it finishes
in 55% of the time python takes;)
-
Stelios Xanthakis wrote:
Hi.
pyvm is a program which can run python 2.4 bytecode (the .pyc files).
A demo pre-release is available at:
http://students.ceid.upatras.gr/~sxanth/pyvm/
Facts about pyvm:
- It's FAST. According to the cooked-bench benchmark suite it
finishes
in 55%
I've seen the benchmarks, they look quite interesting.
This project is probably a LOT of work; maybe people can tell us about
such efforts *before* doing so much work, so we can discuss it, and
avoid wasting time.
Maybe you can explain us why it is so fast, and/or maybe you can work
with the
Kay Schluehr wrote:
Stelios Xanthakis wrote:
pyvm is a program which can run python 2.4 bytecode (the .pyc files).
A demo pre-release is available at:
http://students.ceid.upatras.gr/~sxanth/pyvm/
could You tell us a bit more about Your motivation to create an
alternative C-Python
could You tell us a bit more about Your motivation to create an
alternative C-Python interpreter?
I'd also be curious to know if the performance gains would remain
once it gets fleshed out with things like closures, long numbers,
new style classes and a C library compatibility shim.
Roger
Stelios Xanthakis [EMAIL PROTECTED] writes:
- The demo is an x86/linux binary only. You shouldn't trust binaries,
run it in a chrooted environment not as root!
Are you going to release the source? If not, it's a lot less interesting.
--
http://mail.python.org/mailman/listinfo/python-list
50 matches
Mail list logo
