purge stack

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: purge stack

Post by monte » Tue Aug 20, 2013 11:10 am

mwieder wrote:@Jacque- no, delete stack "foo" doesn't affect the stack file unless you save the stack. It only deletes the substack in memory.
I'm not really sure why we would make this distinction for delete stack and not for every other property... set the script... it's not really setting the script because you haven't saved the file? Doesn't make sense to me. That's why I've said a few times that delete stack is quite appropriate syntax for its action on substacks. Delete stack on a mainstack might also be appropriate if it leaves the substacks dangling with no mainstack.

I'd vote for a purge stack command that purges the whole stackfile from memory in one hit and throws an error if called on a substack. Also wondering if release and retain aren't nicer options than purge?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: purge stack

Post by LCMark » Tue Aug 20, 2013 1:15 pm

Just to throw my 2 pence in :)

I think we have to be careful not to make things more confusing which I do think 'purge' does - it alludes to a situation which is not the case.

At the moment there is a complete distinction between stackfiles and objects in memory - the association is the same as that between a document when loaded into a word-processor and a document when being edited in the app. In this context the verb 'delete' is correct - it means delete the object from the environment just the same as selecting text in a document and pressing the delete key deletes that text from the document (and memory). There is no continually active link between the objects unserialized in memory and the source from which they were unserialized from.

The 'purge' verb suggests that this association is something stronger (to my mind at least) - i.e. you can purge a stack from memory and then get it back exactly as it was before the purge by opening the stackfile again but this is only the case if you save in between.

I think the problem here is that the distinction between objects and stackfiles is not being adequately articulated, or not being made clear enough, and (some) people are still thinking LiveCode operates in a similar way to HyperCard in terms of object storage - which it does not.

It is important to remember that HyperCard had (essentially) an object store - in the sense that on-disk representation and in-memory representation of objects was 'in-sync' - if you modified text in a field in HyperCard that change would be written back to disk when appropriate without any 'save' intervention. In this sense 'purge' makes sense because you are just saying 'I don't need this stuff in memory at the moment, so please release any memory related to it if you can'. In the current way LiveCode operates there can be no 'purge' operation in the same sense, since it does not work in the same way - i.e. there is nothing to fall back upon to revert the purge. [ Perhaps a succinct way to look at this is HyperCard was database-based, LiveCode is document-based ].

To my mind 'delete' is precisely the correct verb to represent the operation that you are performing in the way LiveCode currently works - delete operates on things in memory and gets rid of them, it has no relation at all to how the objects in memory might be preserved for opening in a later session.

Now, if LiveCode 'projects' were an object-store *then* there would be a distinction between purge and delete. 'purge' would mean just remove the in-memory representation of the object to save memory (because LiveCode could retrieve it when it was next needed 'exactly' as it was before the purge), and 'delete' would mean remove the object all together from the object-store and memory. (i.e. You could imagine the in-memory representation being a fast access cache for the information stored in the object-store on disk, thus 'purge' is akin to just purging data from a cache which isn't used right now).

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: purge stack

Post by FourthWorld » Tue Aug 20, 2013 3:30 pm

runrevmark wrote:Now, if LiveCode 'projects' were an object-store *then* there would be a distinction between purge and delete. 'purge' would mean just remove the in-memory representation of the object to save memory (because LiveCode could retrieve it when it was next needed 'exactly' as it was before the purge), and 'delete' would mean remove the object all together from the object-store and memory.
This thread seems to have sprawled a bit, but that was my original request, for the similar reasons: the on-disk copy and the in-memory copy are two different things, and each needs some way to remove it which is distinct from the other.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: purge stack

Post by mwieder » Tue Aug 20, 2013 5:32 pm

The 'purge' verb suggests that this association is something stronger (to my mind at least) - i.e. you can purge a stack from memory and then get it back exactly as it was before the purge by opening the stackfile again but this is only the case if you save in between.
I don't understand this part. Once you purge a stack from memory there's nothing to save. Opening the stackfile does indeed return to the situation before the purge.

Or do you mean if you've made changes to the stack in memory and then purged? In that case your changes are lost if you haven't saved them. That's no different from closing a stack without saving changes in any other situation.

I don't have a strong objection to leaving the "delete" verb intact to remove a mainstack from memory. To me the more confusing syntax is when the delete verb is also applied to removing a substack from a mainstack. This is also the more dangerous of the two scenarios, because once you have removed a substack and have unsaved changes elsewhere in the stack, it's not recoverable - you either have to lose your unsaved changes or save the changes and lose the substack. That's why I think the more important part of this change is the new "remove" verb syntax for removing a substack from a mainstack in memory.

The significant downside of the HC-like object store format is that once you have made a change, it's committed and there's no going back.

Locked

Return to “Engine Contributors”