Greetings! You should be able to do this interactively at runtime,
e.g. without recompiling, as follows:
(SETQ SI::*MULTIPLY-STACKS* 4)
This increases all stack sizes by a factor of 4 using 'malloc'. If
you can pin your failure down to a single command, run a command like
the above and repeat your failing command, then iterate until you
failure goes away.
I believe the multiply-stacks can only be set like this at toplevel,
so that attempting to have it run automatically on stack exhaustion in
the middle of running code is not an option, though I suppose we could
look into this to make sure.
Please keep us posted.
Take care,
Gunther Schadow <address@hidden> writes:
Hi Camm and other GCL developers, thanks, I could now get to
the GCL 2.6.1 version. And I can configure larger stack limits.
However, it turns out that I am not good at guessing how much
I need. I increased everything by a factor of 8 and still
ran into trouble. Problem is it takes 20 minutes or more for it to
exhaust its limits, so testing is slow.
I am wondering: would it not be possible to do memory allocation
completely dynamically? I see that you use those FRSSIZE and other
*SSIZE constants to dimension actual arrays that are
used for those stacks. Now either I should just max those out
completely or a more graceful way would be to use malloc and
realloc to add pages to those stacks. Hmm, I guess realloc would
over time waste address space in holes. I guess I should just
max those out entirely and let the virtual memory subsystem
take care of the paging.
I wonder how other LISP systems are dealing with this?
regards
-Gunther
Camm Maguire wrote:
Greetings! Yes, savannah/subversions is apparently down until
tomorrow. Did you try the utexas url? This should work.
Take care,
Gunther Schadow <address@hidden> writes:
Camm, this is still a no go:
cvs [login aborted]: connect to
subversions.gnu.org(199.232.41.2):2401 failed: Connection timed out
traceroute:
7 121 ms 420 ms 341 ms 206.108.108.213
8 160 ms 411 ms 310 ms 64.230.223.41
9 130 ms 200 ms 311 ms 206.108.103.129
10 230 ms 401 ms 310 ms 64.230.242.98
11 331 ms 410 ms 401 ms 206.108.104.170
12 220 ms 411 ms 410 ms 199.235.123.253
13 * * * Request timed out.
seems like the last hop is offline or firewalled?
-Gunther
Camm Maguire wrote:
Greetings! Unfortunately, ftp.gnu.org is still locked due to the
recent compromise, and to make matters worse, so are the Debian
sites.
sounds to me as if there is one of two problems (1) the OS
that both gnu.org and debian is relying on is insecure or (2) there is
just starting to be too much of a monoculture of this OS around so
it's little better that M$ Doors.
--
Gunther Schadow, M.D., Ph.D.
address@hidden
Medical Information Scientist Regenstrief Institute for Health
Care
Adjunct Assistant Professor Indiana University School of
Medicine
tel:1(317)630-7960
http://aurora.regenstrief.org
--
Gunther Schadow, M.D., Ph.D. address@hidden
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
_______________________________________________
Gcl-devel mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gcl-devel