Path: utzoo!utgpu!watmath!att!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: <7341@rpi.edu>
Date: 15 Sep 89 12:29:53 GMT
References: <8909141951.AA11958@megaron.arizona.edu>
Sender: usenet@rpi.edu
Distribution: inet
Lines: 57

In article <8909141951.AA11958@megaron.arizona.edu>, pax@ihcup.UUCP writes:
> I also would like to see the equivalent of
> argv[0] so that an Icon program could discover its name.

Should be relatively easy actually since ICONX needs to know the name.
Have to think about the syntax though. I don't recall off hand the syntax/
strategy for parameters and this is not something to break existing programs
over.

> If you are going to be working with the DOS implementation, let me note that my
> biggest problem with it has been, without a doubt, memory management.  I run
> Icon on several different types of UNIX machines without any difficulties but
> on DOS I am forever playing with [STAT,STR,HEAP]SIZE trying to get a large
> Icon program to just load.  Once loaded, there are lots of "dead stops" that
> seem, somehow, to be associated with running out of some memory resource.
> It has been a very frustrating task to simply port a running Icon program 
> into the DOS environment.  I realize that this is caused, not by the Icon
> implementation, but by restrictions imposed by DOS.  What I need is more help
> and information from Icon as to what is really going on with memory management.

> The DOS version needs some tools, or indicators, that monitor or report on
> memory usage.  Where is the memory going, how much, how fast, etc.  Perhaps
> some data could be dumped at the conclusion of every garbage collection that
> would help in understanding the programs' needs for memory resources.

From my understanding, Icon requires almost 640k of memory (including system
etc., one note is to be carefull of how many TSRs you have loaded. Thus,
since a full sized program/memory space won't fit, you have to jiggle for
each. Note the new & variables in V7.5 for allocation and garbage collection
tracing. They may help your situation some what. How long did you wait for
after the dead stop? I'm not sure how Icon's garbage collection compares with
others but I remember one LISP interpreter warning that garbage collections
could take several minutes. If you are using 90% of a region and the items
are small objects, garbage collection could take a while. If that is not
the case, perhaps you have discovered a bug when the ammount of space left
is really small. I will leave further comments to other more experienced
people.

>As an old SNOBOL4/SPITBOL programmer from way the hell back, I must admit that
> I miss in Icon the SNOBOL4/SPITBOL rather generous capabilities for tracing.
> I'd like to see the equivalent functionality available in Icon.  The features
> are well documented and were very useful.

I doubt that I will do much in that line. That could be a major problem
actually. If anything, I was thinking of producing a more production
model without the tracing. A question there would be how much run time
memory allocation and time would actually be saved? If it would only be
a few percent I see no reason to do it. This would be set up as a complementary
ICONX if done, the tracing is still needed for development purposes.

Frank Filz


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