NSDocument disc undo stack

[Steven]

Hello,

Where is the correct place to store an on-disc undo stack associated with a NSDocument instance ?
The stack may contain several potentially large files so we don't want them to occupy memory.
For a compound document the stack could reside in a directory NSFileWrapper.
For a single file document should a temporary directory be used ?
I guess the chosen location may need to persist beyond the occurrence of the automatic termination feature.
Any advice appreciated.
Thanks.

Steven.
_______________________________________________

Cocoa-dev mailing list (Coco...@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev-garchive-98506%40googlegroups.com

This email sent to cocoa-dev-ga...@googlegroups.com

[Graham Cox]

You can read and write to the Application Support folder.

But FILES in an Undo stack? That makes little sense to me.

If you want to undo changes to a file, store the changes or the command that will cause the changes in the undo stack. If you are changing the organisation of files on disc then save a description of that organisation in the undo stack. You may want to read up on the way Cocoa utilises Undo, because it sounds like you might not have a good grasp on it.

Even if you need to store very large objects in the undo stack, unless you can prove it's a serious problem, just let the memory get paged to disk VM naturally. It's rare that users need to undo a very long history, so even if the older history is paged out, the chances are the user will never know.

--Graham

On 24/03/2012, at 10:17 AM, Steven wrote:

> Hello,
>
> Where is the correct place to store an on-disc undo stack associated with a NSDocument instance ?
> The stack may contain several potentially large files so we don't want them to occupy memory.
> For a compound document the stack could reside in a directory NSFileWrapper.
> For a single file document should a temporary directory be used ?
> I guess the chosen location may need to persist beyond the occurrence of the automatic termination feature.
> Any advice appreciated.
> Thanks.
>
> Steven.
> _______________________________________________
>
> Cocoa-dev mailing list (Coco...@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:

> https://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com
>
> This email sent to graha...@bigpond.com

[Steven]

Thanks for the info Graham.
I'm using NSUndoManager. I thought that many large objects in the stack would cause memory pressure and would be better occupying disc space as they are only needed at undo/redo time. Good to know that the VM system will take care of it.

Steven.

[Doug Clinton]

I don't know if this was the issue that Steven was asking about, but I've been wondering if there is a recommended way to persist the undo stack so that it's still available if you restart the app, or close and re-open the document. It's always bothered me that there is this great mechanism for handling undo, but that all the history is thrown away when you close the app.

-- Doug

On 24 Mar 2012, at 01:04, Graham Cox wrote:

> https://lists.apple.com/mailman/options/cocoa-dev/doug%40wiredthing.com
>
> This email sent to do...@wiredthing.com

[Mike Abdullah]

I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, it's fairly easy to exhaust your address space if all deleted files are kept in-memory.

> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
>
> This email sent to coco...@mikeabdullah.net

[Graham Cox]

On 25/03/2012, at 5:34 AM, Doug Clinton wrote:

> I don't know if this was the issue that Steven was asking about, but I've been wondering if there is a recommended way to persist the undo stack so that it's still available if you restart the app, or close and re-open the document. It's always bothered me that there is this great mechanism for handling undo, but that all the history is thrown away when you close the app.

No easy way I know of. The undo architecture relies on a huge amount of state within the app external to the undo stack itself. You'd have to save all of that state somehow.

In fact, most apps throw away the undo history on a document save (you arrange this), as a way to recover the memory used by undo, since the whole state is being saved in the file anyway. Versions are the supported mechanism for persistent document undo.

--Graham

[James Montgomerie]

I don't think it's likely to be true in practice on 64-bit systems either. In theory, yes, the old data could get paged out, and will not be paged back in until the user uses it. In practice though, unless these pieces of old data are big, contiguous buffers taking up pages by themselves, the old data will likely live in pages that also contain at least a few things that are at least intermittently used, so you'll be constantly paging.

Jamie.

> https://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
>
> This email sent to ja...@montgomerie.net