Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!hpfcbig!diamant
From: diamant@hpfcbig.SDE.HP.COM (John Diamant)
Newsgroups: comp.sys.handhelds
Subject: Re: Todo program
Message-ID: <1010010@hpfcbig.SDE.HP.COM>
Date: 27 Mar 91 05:39:26 GMT
References: <1991Mar12.144908.1088@truevision.com>
Organization: HP SESD, Fort Collins, CO
Lines: 40

In my previous note (announcing my 1.0 mods to the TODO program),
I mentioned a memory usage program I encountered while working on
TODO.  I'd like to find out what solutions are available to this
problem.

The TODO program manipulates a large GROB which it creates with BLANK,
modifies one line at a time with REPL and then stores in PICT.
My problem is that the GROB may be larger than half of remaining
memory, and the above approach causes two copies to appear in
memory at once.  I need a way to manipulate the PICT directly.

One solution I see is as follows:
Use PDIM to create the correct size PICT
Use a version of REPL (syseval?) which operates directly on the
	PICT instead of on the stack

Another would be to somehow move the large GROB from the stack
to PICT rather than copying it (so that at any one time, only
one copy existed on the stack).  From what I can tell, STO requires
twice the memory of the object being stored.  This is either because
the store doesn't remove from the stack until the copy succeeds or
because the LAST STACK memory retained another copy of the stack
object.  If this second guess is true, then I need a way to turn
off LAST STACK.  I can turn off LASTARG, but haven't found out how
to turn off LAST STACK.  A solution to this problem would make
TODO be able to operate on lists twice as large for any given amount
of free memory as it can now.

If any of the proposed solutions involve a SYSEVAL, do they work
for all versions for the 48?

Thanks in advance,

John Diamant
Software Engineering Systems Division
Hewlett Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hpfcla,hplabs}!hpfclp!diamant

This response does not represent the official position of, or statement
by, the Hewlett-Packard Company.