From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from research.att.com ([192.20.225.2]) by hawkwind.utcs.toronto.edu with SMTP id <2714>; Tue, 25 May 1993 23:49:19 -0400
From:	rob@research.att.com
Date:	Tue, 25 May 1993 23:48:47 -0400
To:	sam-fans@hawkwind.utcs.toronto.edu
Subject: changes not in sequence
Message-Id: <93May25.234919edt.2714@hawkwind.utcs.toronto.edu>

rhubarb rhubarb.  it's just a bug that i never saw my way through to fix.

what the message means is that you've generated a list of changes to
be made atomically that don't occur in increasing non-overlapping
addresses in the file.  this is hard to do unless you put addresses inside
commands, e.g.
	x/./ -d
this particular example is an error - it will delete the same line many times -
but there are more complex examples that should work but don't.

the bug should be easy to fix, but it's not.
in principle, you (that is, i) just sort the transcript list and execute it in order.
(if the changes occur out of order, the address arithmetic in the update
routine will screw up.)  the problem is that, for vital efficiency, nearby changes
are folded together so many small adjacent modifications can be done in
one disk i/o (say), which makes it impossible to keep them separate in order
to be able to sort them.  hence the message.  i always intended to fix the
problem; i never saw how.

i have a whole new system now that contains much more efficient code to do
all this stuff, obviating the need for the extra level of cache and hence making
it possible to sort the changes (as in fact i do in this new system).  the code
could be retrofitted but it's a huge job and i think my time and others' is
better spent on other things, such as getting this new system working.

apologies.

-rob