changes not in sequence

changes not in sequence

[Ronnie Mainieri]

Dear Sam fans,

I'm still a little confused about the ``?changes not in sequence''
error message.   Is it that I'm not allowed to modify text that has
just been modified?   My vi instincts frequently lead me to this error
message, and I can't see what I'm doing wrong.

Could someone post an explanation of the modifications that lead to
this error message?

Thanks for the help,

Ronnie Mainieri

ronnie@raptor.lanl.gov

Re: changes not in sequence

[Ozan S. Yigit]

> 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 ...

are there any other improvements in the new system we can borrow for
sam? the message protocol between the term and the editor proper? any
new commands and/or interface ideas?

oz

changes not in sequence

[rob]

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