question: Python or Lua for rejuvenation of old PCs?

[John Benson]

Hi, I've been experimenting with Lua on my Tandem Himalaya K100 system (a
decade-old 4-CPU fault-tolerant server from Tandem/Compaq/HP) because it
looked like it was simpler to port than Python. Since I've only got 128 MB
per CPU and the system is already loaded with SQL and transaction processing
monitor software, it's small footprint was also very attractive. Anyway
that's how I got interested in Lua.

There has already been some discussion of Lua in this forum. At this stage
in my understanding, I'd characterize it as highly idiosyncratic, but very
dynamic in the same way Python is: it has reference rather than variable
copy semantics and functions are first-class objects. It can do OOP, but
data and method packaging are shoehorned into a somewhat complicated Swiss
Army Knife table construct. It's indexes are also unity-based and there are
no slices as in Python. However, it's sufficiently different that it
shouldn't be too hard keeping the two languages separate, unlike, say
Spanish and Portuguese.

That said, I had a project in the back of my head of putting Python on my
old PCs ranging from 4MB up to 128 MB RAM as a last-ditch attempt to avoid
facing reality and getting rid of them. However, I'm now beginning to wonder
if I would be better served by putting Lua on the low-end PCs instead. I'm
thinking of using them as nodes in a distributed, fault-tolerant home
monitoring and control system that would be easy to port later to embedded
microcontrollers.

I suppose that my question is best phrased as this: What is a comfortable
minimum RAM size that a PC needs to have to comfortably run modern Python
for non-memory-intensive applications (i.e. no big database crunching or
other thrashy stuff). I'm thinking about just polling sensors and actuating
control devices over RS-232/RS-485/LAN and doing some chitchat between the
nodes over the LAN. Based on the response, I'll draw the line between my Lua
machines and my Python machines.

Thanks in advance for any information you may have.

[Terry Reedy]

"John Benson" <js******@bensonsystems.com> wrote in message
news:ma*************************************@pytho n.org...

I suppose that my question is best phrased as this: What is a comfortable
minimum RAM size that a PC needs to have to comfortably run modern Python
for non-memory-intensive applications (i.e. no big database crunching or
other thrashy stuff). I'm thinking about just polling sensors and actuating control devices over RS-232/RS-485/LAN and doing some chitchat between the nodes over the LAN. Based on the response, I'll draw the line between my Lua machines and my Python machines.

I did my first useful Python work with old DOS version on a 4 MB machine.
Disk memory size and running RAM memory size are different issues. I have
read that Lua beats Python on minimal disk footprint but have no idea of
running size. On Windows, Python.exe is very small but does import several
modules, though I believe it could be built to require less.

Terry J. Reedy

[Frank Bechmann]

maybe these links help, even if you have to look at the numbers and
charts w/ some care:

http://dada.perl.it/shootout/craps_mem.html
quite old win2K machine (partly running cygwin tools)
Python 2.3.2 vs. Lua 5.0 (and Lua 4.0)
Lua (both versions, Lua 5.0 is even better) lead on memory usage
http://www.bagley.org/~doug/shootout...l=3&wordfreq=5
even older linux machine
Python 2.1 vs. Lua 4.0
Python leads on memory usage

having read your application specs FORTH came to my mind, having the
advantage that it is even more crude, so you have even less chances to
intermix both languages. and no one will doubt that it is usefull for
embedded controller tasks.

[Paul Rubin]

fB*******@web.de (Frank Bechmann) writes:

having read your application specs FORTH came to my mind, having the
advantage that it is even more crude, so you have even less chances to
intermix both languages. and no one will doubt that it is usefull for
embedded controller tasks.

He's not asking about a tiny embedded processor. Something with a 1
MB image would be fine. FORTH would be over (under?) kill. That
level of inconvenience is not needed.

[Frank Bechmann]

he was writing about a

distributed, fault-tolerant home monitoring and control system that
would be easy to port later to embedded microcontrollers
which is not so far from
embedded controller tasks

if my english is not too worse.

and whether FORTH is too much of an inconvenience is in the eyes of
the beholder - but I have to admit that your statement is true for the
vast majority of programmers and that I forgot to add a :).