| From: | Rudi Chiarito |
| Date: | 20 Aug 2000 at 22:33:03 |
| Subject: | Re: AMIOPEN: Amiga python |
On Sun, Aug 20, 2000 at 03:43:47PM -0500, Marc Culler wrote:
> I think that python will make an ideal replacement for ARexx on the
There are already plans for SHEEP as the ideal replacement for ARexx,
but the more languages, the better.
I ported the GNU Eiffel compiler several months ago, but I still haven't
seen my patches merged into the latest official betas (umpf). If anybody
is looking for a new project, it could be interesting to write a new
backend for GNU Eiffel that outputs VP code (in addition to the existing
ones that output C source and Java bytecode).
> also believe that it will not be difficult to write an inter-process
> messaging module for python similar to the one that was added to REXX
> to create ARexx.
Actually, I remember that the Classic Amiga port of Python already had
IPC mechanisms to make Python talk to any program implementing an ARexx
port. That alone was proof that ARexx by itself is not as vital as most
would imply - i.e. you could talk to e.g. AmIRC using Python alone,
without any lines of ARexx code being involved.
> I have ported Python 1.6b1 to the new Amiga. I will post the port as
> soon as it passes the python test suite. At this point it fails only
> two tests. One of these failures is caused by a bug in the
> /lib/strftime tool, which I will report in a following message.
Already answered to that.
> Two things were slightly disappointing to me about this port. First,
> my python.00 executable is 551388 bytes, versus 319980 for the
> stripped linux executable. (The linux executable is version 1.5, and
> the Amiga version is 1.6, but I am pretty sure that the VP executable
> will be somewhat larger than the linux native version of the same
> program.) I had hoped that VP code would turn out to be more compact
> than Intel machine language. Second is that the VP version is
Could you mail me the sources, so that I can give them a quick try?
What options was it compiled with?
As far as executable size is concerned, there are more aggressive
optimizations coming in the linker (yes, the linker) that should help in
a fair number of cases. Now that I think of it, a project as large as GNU
Eiffel should give a rough idea of how effective they are, although the
compiler is already very careful about the C output it emits... let me
try rebuilding it. ;)
> somewhat slower. My Amiga SDK benchmarks at 3360.77 pystones/second,
> while the host linux system benchmarks at 5076.14 pystones/second.
What do pystones actually measure? Is floating point code involved? That
could explain something.