UNDO-function (reloaded)

[uni_instructor]

Dear Liviu

You wrote to another request concerning this topic:

Unfortunately, there is no Undo button, because it is too difficult to implement one now 

As I see there a a few requests related to the missing UNDO function. (my own request included).
Some users made suggestions concerning possible solutions by using powerful CVS approaches like GIT or Mercurial.

I know implementing a reasonable CVS in FET would be a tough job. So why not keeping it simple?
I remember there was a suggestion that I should do a manual versioning by saving my project data into new FET-files. That is what I am currently doing. Additionally I keep manual (paper) records and comments of my changes.
But it is always a hassle and error-prone to keep all my manual  recordings up to date.

So I would like to suggest a simpler approach:

FET uses internal data structures to store all basic data and planing constraints and FET can save these data structures into a .FET file.

How much programming effort does it cost to create dynamic duplicates in memory of these data structures? I know it will cost additional system-memory and a little bit of time for storing the data-duplicates, but modern computers are fast and provide Gigabytes of memory, so why should we care about a few hundred Megabytes of additional memory consumption? Actually the real additional memory consumption should be rather low, as I found from my own tests an measurements, since FET has a rather small memory footprint.

I conceive that it should be possible to implement a mechanism for creating/duplicating and switching dynamically between these data structures. In that way it will be possible to keep a history of all (or the last #n) changes and to step back to an earlier planning stage if necessary. A step back would also delete all succeeding planning stages / sets of planning/constraint data.
Additionally it is possible to store in parallel  some short (UNDO-) information that gives the user a hint about the last change steps. Furthermore the whole super-data structure (containing the current set of planning/constraint data and its predecessors ) could be saved into an extended .FET file, so that we can revert to previous planning stages even after a program restart.

Below I added some figures illustrating my idea.

Regards

UI

Code Select Expand


  Dynamic pointer array/ buffer of max n stages
    \
     \
      \
  O    \
  |     \
  |     +--+
  +---->|#1|------|EOL
        +--+
         |  +-------+
         o--XInfo #1|
         |  +-------+
         |
         |
         |Step 1
     +---X-----+
     |Data #1  |
     |+---++--+|
     || A ||  ||
     |+---+|T ||
     |+---+|C ||
     || R ||  ||
     |+---++--+|
     +---------+
          A   Current stage
          |
          +----Data set containing
               room/activities/time
               constraints etc.
======================================================================
Data structure after #n change steps

  Dynamic pointer array/ buffer of max n stages
    \
     \                    UNDO/Revert back to step #2
      \                +---------------------------------+
  O    \               |                                 |
  |     \              V                                 |
  |     +--+          +--+          +--+                +--+
  +---->|#1|--------->|#2|--------->|#3|--------------->|#n|------|EOL
        +--+          +--+          +--+                +--+
         |  +-------+  |  +-------+  |  +-------+        |  +-------+
         o--XInfo #1|  o--XInfo #2|  o--XInfo #3|        o--XInfo #n|
         |  +-------+  |  +-------+  |  +-------+        |  +-------+
         |             |             |                   |
         |             |             |                   |
         |Step 1       |Step 2       |Step 3             |Step n
     +---X-----+   +---X-----+   +---X-----+         +---X-----+
     |Data #1  |   |Data #2  |   |Data #3  |         |Data #n  |
     |+---++--+|   |+---++--+|   |+---++--+|         |+---++--+|
     || A ||  ||   || A ||  ||   || A ||  ||         || A ||  ||
     |+---+|T ||   |+---+|T ||   |+---+|T || *  *  * |+---+|T ||
     |+---+|C ||   |+---+|C ||   |+---+|C ||         |+---+|C ||
     || R ||  ||   || R ||  ||   || R ||  ||         || R ||  ||
     |+---++--+|   |+---++--+|   |+---++--+|         |+---++--+|
     +---------+   +---------+   +---------+         +---------+
                                                     Current stage

======================================================================
Data structure after UNDO and revert to change step #2

  Dynamic pointer array/ buffer of max n stages
    \
     \
      \
  O    \
  |     \
  |     +--+          +--+
  +---->|#1|--------->|#2| -----|EOL
        +--+          +--+
         |  +-------+  |  +-------+
         o--XInfo #1|  o--XInfo #2|
         |  +-------+  |  +-------+
         |             |
         |             |
         |Step 1       |Step 2
     +---X-----+   +---X-----+
     |Data #1  |   |Data #2  |
     |+---++--+|   |+---++--+|
     || A ||  ||   || A ||  ||
     |+---+|T ||   |+---+|T ||
     |+---+|C ||   |+---+|C ||
     || R ||  ||   || R ||  ||
     |+---++--+|   |+---++--+|
     +---------+   +---------+
                   Current stage




[Liviu Lalescu]

Hello, UI,

Your ideas are interesting. I added your complete post in the TODO file. Thank you!

To make a complete and perfect and memory efficient undo function would be a titanic task now, after all the code was written without undo in mind. And I admit I have no good knowledge of how to implement an undo function.

To implement what you are suggesting is also complicated. But I do not quite like it because of the memory waste. And saving a file with say 1000 undo versions might lead to a 1 GB file if the file has 1 MB (the internal memory consumption is lower than the .fet XML file).

[bachiri401]

Hello Mr LIVIU
I think UNDO button is somthing great but if is time and effort consuming
it is not an emergency in itself
I think right now what should be focused on is " more constraints/ more timetables generation speed""
but as far as the form and buttons i think it is not highly needed

THANK YOU MR LIVIU I REALY APPRECIATE  FET PROGRAMME DEVELOPMENT

[uni_instructor]

Dear Liviu

Your ideas are interesting. I added your complete post in the TODO file. Thank you!

Nice to read!   
At least it would be a possibility to implement an UNDO feature without a complete rewrite of FET.

To make a complete and perfect and memory efficient undo function would be a titanic task now, after all the code was written without undo in mind. And I admit I have no good knowledge of how to implement an undo function.

I know, my suggested approach is not memory efficient and sophisticated, nevertheless it is a feasible approach.

To implement what you are suggesting is also complicated. But I do not quite like it because of the memory waste. And saving a file with say 1000 undo versions might lead to a 1 GB file if the file has 1 MB (the internal memory consumption is lower than the .fet XML file).

I don't think that all FET users will need an UNDO with 1000 levels. Even MS-Office does not offer an infinite UNDO. But as I wrote, modern computers have a lot of memory - so who cares.
The number of UNDO-levels can be restricted, maybe an a user-defined setting. I think max. 10-25 UNDO-levels by default should be sufficient and this would not be such a significant memory waste.

Regards   

UI

[Liviu Lalescu]

Dear UI,

I also added our further conversation in the TODO file. Thank you! 

[Liviu Lalescu]

Furthermore the whole super-data structure (containing the current set of planning/constraint data and its predecessors ) could be saved into an extended .FET file, so that we can revert to previous planning stages even after a program restart.

Dear UI,

I revisited this topic. It seems that your words quoted above are not solved in FET-6.12.0 and higher versions. What do you say, it would be a good point to try also this (saving the history to the hard disk)? Or it might confuse the user rather than help?

There is also @ngoctp29121982 who suggested this.

If saving the history on the hard disk, we need to forget the forward (redo) states and only keep the backward (undo) states. And save history only if the user saves the .fet file. Otherwise there might appear problems in the implementation. Is that OK?

Hmm... there is a problem: say the history size becomes around 10 MB, and the .fet file size only ~200 kb. At each save operation, we save 10.2 MB instead of only 200 kb...

[ngoctp29121982]

Great, it would be better if you allow users to save history and use that history as well

[Liviu Lalescu]

Yes, but could you also reply your opinion about this: when the user saves the file, only the backward history (undo steps) (not also the forward history - redo steps) will be saved on the disk. And I might make the default steps of this saved history only 20 steps, and maximum 100? Is that OK?

[ngoctp29121982]

I feel very good
Thank you very much

[Liviu Lalescu]

Hello,

I made it, in a snapshot (test version) for now: https://lalescu.ro/liviu/fet/download/test/

Please test and let me know.

[ngoctp29121982]

I will try and reply soon

[ngoctp29121982]

Hello, liviu,
Why in the memory history section do you not allow retrieving data from n=1-100 but allow retrieving data from n=2-101?

[Liviu Lalescu]

Hello, ngo,

No, on file save/save as we save and retrieve 1...100. Please add 100 tags and check (or lower the latest saved states to only 5 and add 5 tags).

[ngoctp29121982]

Thank you!
Why don't you allow selecting 12 to 15 constraints out of order or selecting random numbers n, m... at the same time?

[Liviu Lalescu]

You are welcome!

Sorry, but I don't understand.