Mailing List Archive

> I don't know how much memory other people have in their machiens, but
> in this machine (128Mb), I get the following trying to compile a CVS
> checkout of Python:
>
> gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
> ./unicodedatabase.c:53482: virtual memory exhausted
>
> I hope that this is a temporary thing, or we ship the database some
> other manner, but I would argue that you should be able to compile
> Python on a machine with 32Mb of RAM at MOST.... for an idea of how
> much VM this machine has, i have 256Mb of SWAP on top of it.

I'm not sure how to fix this, short of reading the main database from
a file. Marc-Andre?

--Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum writes:
>I'm not sure how to fix this, short of reading the main database from
>a file. Marc-Andre?

Turning off optimization may help. (Or it may not -- it might be
creating the data structures for a large static table that's the
problem.)

--amk

Christopher Petrilli wrote:
>
> I don't know how much memory other people have in their machiens, but
> in this machine (128Mb), I get the following trying to compile a CVS
> checkout of Python:
>
> gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
> ./unicodedatabase.c:53482: virtual memory exhausted
>
> I hope that this is a temporary thing, or we ship the database some
> other manner, but I would argue that you should be able to compile
> Python on a machine with 32Mb of RAM at MOST.... for an idea of how
> much VM this machine has, i have 256Mb of SWAP on top of it.

I had similar effects, what made me work on a compressed database
(see older messages). Due to time limits, I will not get ready
before 1.6.a1 is out. And then quite a lot of other changes
will be necessary by Marc, since the API changes quite much.
But it will definately be a less than 20 KB module, proven.

ciao - chris(2)

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home

Guido van Rossum wrote:
>
> > I don't know how much memory other people have in their machiens, but
> > in this machine (128Mb), I get the following trying to compile a CVS
> > checkout of Python:
> >
> > gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
> > ./unicodedatabase.c:53482: virtual memory exhausted
> >
> > I hope that this is a temporary thing, or we ship the database some
> > other manner, but I would argue that you should be able to compile
> > Python on a machine with 32Mb of RAM at MOST.... for an idea of how
> > much VM this machine has, i have 256Mb of SWAP on top of it.
>
> I'm not sure how to fix this, short of reading the main database from
> a file. Marc-Andre?

Hmm, the file compiles fine on my 64MB Linux machine with about 100MB
of swap. What gcc version do you use ?

Anyway, once Christian is ready with his compact
replacement I think we no longer have to worry about that
chunk of static data :-)

Reading in the data from a file is not a very good solution,
because it would override the OS optimizations for static
data in object files (like e.g. swapping in only those pages
which are really needed, etc.).

An alternative solution would be breaking the large
table into several smaller ones and accessing it via
a redirection function.

--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/