the new packageing (broken up in several packages) has a curular
depency (cmucl depends on cmucl-normal depends on cmucl ...). i tried
to break the deadlock by installing one of the packages with --force,
but it won't configure: cmuclconfig returns with "can't allocate
memory (do you have more than 16MB?" (which i hsve). is there a
recommended sequence for installing the components? or is this an
unrelated problem. all other prerequisits are satisfied.
--
Hartmann Schaffer
Hartmann Schaffer wrote:
>
> the new packageing (broken up in several packages) has a curular
> depency (cmucl depends on cmucl-normal depends on cmucl ...). i tried
> to break the deadlock by installing one of the packages with --force,
> but it won't configure: cmuclconfig returns with "can't allocate
> memory (do you have more than 16MB?" (which i hsve). is there a
> recommended sequence for installing the components? or is this an
> unrelated problem. all other prerequisits are satisfied.
>
> --
>
> Hartmann Schaffer
You mean CMUCL 2.4.19 for Linux packaged in DEBIAN-Packages?
If the automaic installation with DEBIAN doesn't work, why not
simply convert it to a tgz? (I had no problems installing it as TGZ)
16 MB Ram? hm thats not much these days...
I think 128MB are a must today!!!
--
sincerely Yours,
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de
On Sun, 25 Jun 2000 04:16:11 +0000, Jochen Schmidt <···········@gmx.de>
wrote:
> 16 MB Ram? hm thats not much these days...
> I think 128MB are a must today!!!
I think that something less than this may be adequate for playing with Lisp
on a _personal_ workstation.
Some time ago I did an experiment with my Linux box (Pentium 200 with 64M
of RAM). I started a couple of instances of CMU CL running Garnet with all
of its demos--a dozen--running. I threw in also an Emacs process and a
Netscape one. There was still room available in RAM, and performance was
adequate.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Jochen Schmidt <···········@gmx.de> writes:
> Hartmann Schaffer wrote:
> >
> > the new packageing (broken up in several packages) has a curular
> > depency (cmucl depends on cmucl-normal depends on cmucl ...). i tried
Why are you posting this here? This package is in frozen, and the bug
is clearly release-critical; if no one has filed a bug report of the
appropriate severity yet, you should do that right away. Time is of
the essence right now.
> > to break the deadlock by installing one of the packages with --force,
> > but it won't configure: cmuclconfig returns with "can't allocate
> > memory (do you have more than 16MB?" (which i hsve). is there a
> > recommended sequence for installing the components? or is this an
> > unrelated problem. all other prerequisits are satisfied.
This may or may not be related; if you want to know for certain,
you'll have to trace what cmuclconfig is doing. The error message may
well be misleading.
> You mean CMUCL 2.4.19 for Linux packaged in DEBIAN-Packages?
> If the automaic installation with DEBIAN doesn't work, why not
> simply convert it to a tgz? (I had no problems installing it as TGZ)
A variation on this would be to download the source code with
apt-get source cmucl
then stare at it to find out which of cmucl and cmucl-normal should
be configured last, fix the dependencies in debian/control accordingly,
and "dpkg-buildpackage" the result.
> 16 MB Ram? hm thats not much these days...
He has more than that, he said.
> I think 128MB are a must today!!!
I know otherwise. (I have 64MB at home, and find that to be plenty for
my needs. Certainly the base system can run with much less; beyond that,
it all depends on your application. For embedded systems, even 16MB
can be a lot.)
·····@my-deja.com wrote:
> > I think 128MB are a must today!!!
>
> I know otherwise. (I have 64MB at home, and find that to be plenty for
> my needs. Certainly the base system can run with much less; beyond that,
> it all depends on your application. For embedded systems, even 16MB
> can be a lot.)
Yes sure, and if you would run a high-load-server you will surely need
more than 128 MB! I talked about a modern workstationlike machine and at
this level you will see that there is a huge difference between 64MB and
128MB.
If you open netscape, xemacs and e.g. a CMUCL session, there will be
not
much free space left and _I_ can not tolerate a always swapping system!
(But if you can...)
--
sincerely Yours,
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de
Jochen Schmidt <···········@gmx.de> writes:
> Yes sure, and if you would run a high-load-server you will surely need
> more than 128 MB! I talked about a modern workstationlike machine
> and at this level you will see that there is a huge difference
> between 64MB and 128MB.
> If you open netscape, xemacs and e.g. a CMUCL session,
Stop. In this thread I can certainly understand the CMUCL session,
and xemacs is also fairly LISPy under the bonnet. But you have no
business running that bloated monster known as Mozilla on top of it.
(Or are you working on browser support for LISP applets? Hmmm, should
try that in emacs-w3. The security implications would be... interesting.)
<·····@my-deja.com> writes:
> Jochen Schmidt <···········@gmx.de> writes:
>
> > Hartmann Schaffer wrote:
> > >
> > > the new packageing (broken up in several packages) has a curular
> > > depency (cmucl depends on cmucl-normal depends on cmucl ...). i tried
>
> Why are you posting this here? This package is in frozen, and the bug
> is clearly release-critical; if no one has filed a bug report of the
> appropriate severity yet, you should do that right away. Time is of
> the essence right now.
Indeed. OTOH I don't see how circular dependencies should be a
problem: Unless two package _Pre-depend_ on each other, installing
the packages at the same time should work out alright. What I imagine
the original posters problem might be is that he tries to install the
packages one at a time using dpkg, like this
dpkg -i cmucl_2.4.19_i386.deb
(=> Won't work, cmucl-{normal|small|...} missing)
dpkg -i cmucl-normal_2.4.19_i386.deb
(=> Won't work, too, since cmucl is missing)
That will not work. The correct way to install packages is to either
install them in one dpkg run, or better yet, use apt-get install,
which will handle the dependencies correctly by itself, i.e. either do
dpkg -i cmucl_2.4.19_i386.deb cmucl-normal_2.4.19_i386.deb
or
apt-get install cmucl-normal
(after you have set-up /etc/apt/sources.list and /etc/apt/apt.conf)
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
·····@my-deja.com 2000-06-25T12:12:06Z:
>> > to break the deadlock by installing one of the packages with
>> > --force, but it won't configure: cmuclconfig returns with "can't
>> > allocate memory (do you have more than 16MB?" (which i hsve). is
>> > there a recommended sequence for installing the components? or
>> > is this an unrelated problem. all other prerequisits are
>> > satisfied.
bglbv> This may or may not be related; if you want to know for
bglbv> certain, you'll have to trace what cmuclconfig is doing. The
bglbv> error message may well be misleading.
I didn't have problem with dependencies, but had the same memory
allocation error. Changing the last line in the cmuclconfig script,
lisp -eval '(load (open "library:config.lisp"))' -noinit
to
lisp -lazy -eval '(load (open "library:config.lisp"))' -noinit
should get it running.
--
Janne Rinta-M�nty
Janne Rinta-Manty wrote:
>bglbv> This may or may not be related; if you want to know for
>bglbv> certain, you'll have to trace what cmuclconfig is doing. The
>bglbv> error message may well be misleading.
>
>I didn't have problem with dependencies, but had the same memory
>allocation error. Changing the last line in the cmuclconfig script,
>
>lisp -eval '(load (open "library:config.lisp"))' -noinit
>
>to
>
>lisp -lazy -eval '(load (open "library:config.lisp"))' -noinit
>
>should get it running.
This is correct. I'll fix this in the next release...
Note that on 2.0.XX cmucl _only_ works with the -lazy flag.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/