Re: [Gzz] Questions

[B. Fallenstein]

Tuomas Lukka wrote:
> Ok, let's start with these questions about the state of Leo:
>
> 1. What's currently coded, what's not?

For saving, the missing thing as far as I can see is something stringing 
it all together. We have:

  * History to keep an undo list
  * ChangeMerger (used by History) to merge the undo list changes
  * ChangeSplitter to split the changes returned by History into
    per-slice parts
  * ChangeSerializer to make this changes into a serializable form
    (recursive Maps/Lists/String arrays); this DOES NOT DO
    PREFLETS YET
  * Pickler to serialize the Map structure

What we need (besides preflet saving in ChangeSerializer), in Pseudocode:
    Save Leo's TransientTextScroll and create a new one

    Get the change since the last save from History
    Split the change
    For every slice's subchange:
        Create the Map structure for the change
        Make the Map structure into a byte stream (using Pickler)
        Save the byte stream

There may be details lurking in there, though.

>         - vstreams?

VStreams are coded and there are tests, but not for the new text calls 
you have added (for inserting, deleting, moving and copying text). 
Please limit changes here to VStreamSpace, AbstractVStreamSpace and 
TestVStreamSpace.

> 2. Could you go through the javadocs to make sure that
>    everything has at least minimal documentation as to
>    what it's supposed to be doing and where it's not doing that
>    yet, XXX.

Looks like minimal doc is everywhere. But I don't have the time to look 
through it closely..

> 3. Slices: how do they work now? 

Each slice is a Slice object. Each cell is a SliceCell that knows its 
slice. The cell creation commands and so on use that.

Each slice stores its preflets. Each Change stores a slices old/new 
preflet sets, if they have changed. A LeoImpl has a PrefletResolver that 
is able to attach/detach the slices in the Leo. When slices are 
attached, their preflets are resolved; when slices are detached, they 
are given preflets again, in conformance to Ted's spec.

With the current History implementation, slices are detached after every 
keypress (History.check() has to be called then). This could be done 
differently, as long as History.getChange() still returns a Change that 
is between two Leo versions with slices *detached*. (There may not be 
any inter-slice connections in the Change we're going to save.)

> 4. For which parts are the tests reasonably complete?

History (in History.spec.ly). VStreams (except the new interface). 
Preflet resolving (in Leo4.test.py).

ChangeSerializer has some testing, but does not seem to go very deep.

- Benja