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