Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!bloom-beacon!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc
From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
Newsgroups: comp.lang.icon
Subject: Re: (none)
Message-ID: <1989Sep22.150638.21014@rpi.edu>
Date: 22 Sep 89 15:06:38 GMT
References: <8909181359.AA18860@megaron.arizona.edu>
Distribution: inet
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 41

I tried e-mail on this and it bounced so...

In article <8909181359.AA18860@megaron.arizona.edu>, pax@ihcup.UUCP writes:
> Ralph, Cheyenne,
> 
> I know that you are not really very interested in the 640K DOS
> situation with Icon.  But, I have customers running Icon programs
> that I've written for them and they sure don't want to trash their
> existing 640K machines - at least not right now.
> 
> Any help at all you can give me on memory management will be most
> appreciated.  Especially some words specifically on how to best
> trim the size of tables and lists as the items are no longer needed.

Garbage collection should take care of most of this, also If I remember
correctly you can delete from a table. pop, pull or get from a list to dispose
of extra entries.

> Also, I believe I can recreate dependably a problem with the
> system() function in DOS Icon.  Depending upon how large the
> program is, system() may or may not do anything.  No error
> or failure return - it's just as if the call was skipped.

You may have run out of memory to load COMMAND.COM. It does
seem odd however that there is no failure event or value returned to
indicate this failure.

To resolve the memory problem try the following:

   1. Trim your program

   2. set the STRSIZE and BLOCKSIZE environment variables so that less
      than 65k is allocated for these regions

   3. trim out TSRs like sidekick


Frank Filz
Center For Integrated Electronics
Rensselaer Polytechnic Institute
vicc@unix.cie.rpi.edu