purge stack

[mwieder]

I started looking into fixing bug #3932, separating the "delete stack" command into a "purge stack" for removing a substack and keeping "delete stack" for throwing it in the trash. As per the bug report, the current situation is scary and error-prone.

I've gotten as far as creating "purge" as a synonym for "delete", but I want to narrow its scope to just substacks. There are so many twisty little passages in this maze, with "delete" being used for so many different functions in so many different files that I'm having a hard time figuring out where a substack gets unattached from a mainstack.

Any guidance would be appreciated.

[monte]

hmm... can you actually purge a substack without deleting it from the stackfile? Do you mean limiting it to mainstacks? Perhaps purging any stack in a stackfile should remove the whole thing from memory? So it would be the same as delete <mainstack reference> is now with the exception it could be passed a substack reference. While delete <substack reference> is quite appropriate for what it does.

[mwieder]

Brain freeze. Never mind. I reread the bug report and I can deal with this.

[jacque]

I think you would do the world a favor if "purge" were implemented to remove (any) stack from memory. In the case of a substack it would have to simply close it, but for mainstacks it would save those of us who hesitate to "delete" a mainstack. I always get a twinge while typing "delete this stack", even though I know exactly what it will do.

[mwieder]

@Jacque- yes, that's where I'm heading with this. Sorry - I misremembered the details of the bug report when I started down this path and now I'm back on track.

[FourthWorld]

@Jacque- yes, that's where I'm heading with this. Sorry - I misremembered the details of the bug report when I started down this path and now I'm back on track.

I very much appreciate your tackling this, as it'll make things much simpler for newcomers and us cranky ol' timers as well.

But there's one problem with the application of your talents toward these sorts of "paper cut" issues: if you fix them all what will we have to complain about?

[mwieder]

OK - I'll make sure to throw in a few bugs for good measure

[mwieder]

Done. I've pushed the changes into a branch named "destroyStack" on my repository.
Before I issue a pull request I thought I'd throw this out for discussion first. Here's what I've done:

property "purgeStack" is a synonym for "destroyStack" and "destroyStack" has been deprecated.

Code: Select all

set the purgeStack of stack "foo" to true

new command: purge to replace the existing syntax of "delete stack" where stack is a mainstack.

Code: Select all

purge stack "foobar" -- removes stack "foobar" from memory.

This currently results in an error if purging the mainstack left orphan substacks in memory. This is the same behavior as currently exists, so I'm reluctant to change it in case something depends on it.

new command syntax: remove substack from mainstack

Code: Select all

remove stack "foo" from stack "bar"

where substack "foo" must be a substack of mainstack "bar" in order for the command execution to be successful.
I would love to use the form "remove substack" here instead of "remove stack", but it looks like I would either have to promote the keyword "substack" to a first-class object in order to do it, or bypass the scriptpoint and execpoint parsers, neither of which seemed like a particularly useful or interesting way to go.

the "delete stack" syntax in any form (mainstack or substack) has been deprecated.

The above has the effect of taking care of the related bugs 1081, 1072 and 3932.

[monte]

Hmm... remove stack "foo" from stack "bar" doesn't do what delete stack did when the stack was a substack does it? I think the delete stack syntax is more appropriate in that instance because you are actually deleting the stack. If remove stack simply sets the mainstack of the substack to itself then I like it although it's probably not necessary.

I think purge stack should purge the whole stackFile and throw an error if called on a substack. Also now that you've introduced remove into the equation I kind of like remove stack "foo" from memory.

[mwieder]

"remove stack foo from stack bar" does indeed do what "delete stack foo" does. The original problem in the bug report was that the "delete stack" syntax does two completely different things depending on whether you're dealing with a mainstack or a substack, and it's a constant source of confusion, or worse, a lost stack. Although now that you mention it, I could just set the substack's mainstack to itself instead of deleting it. That way it's up to the developer whether to purge it or not.

UPDATE: I tried that, and it turns out that just setting a stack's parent to NULL isn't enough. I'd probably have to prune it from the list of substacks of the mainstack as well because it's still listed that way.

And do note that deleting a substack only deletes it in memory - if you don't save the stack, it will still be there in the stack file.

I agree that purge stack should purge the substack list as well, but "delete stack" doesn't do that now. I don't want to change it just because I think it's right without understanding why that decision was made in the first place.

And I also like the "remove stack foo from memory" syntax, but that would also require making "memory" a chunk object. otherwise the parsers would barf. And we don't want that.

[jacque]

To me, "remove stack x from [mainstack] foo" implies changing the mainstack property, and "delete stack x" means delete it from the file. Using "delete" keeps the syntax consistent with deleting files on disk and just seems more intuitive to me.

"Purge", to me, means don't delete, but remove from memory. I think you've got that part covered. I'd like to see "delete" retained when I really do mean I want to get rid of the stack completely.

[mwieder]

The problem with that is that "delete stack foo" has never meant removing the disk file, just the stack in memory. I don't think it's wise to change the semantics for something as serious as losing a file - we already have "delete file" for that. I'm advocating deprecating the "delete stack" format entirely because it's just too confusing.

[mwieder]

OK - I have an experimental version working here that detaches the substack, promotes it to a mainstack, and keeps it in memory. It works, but it's a bit of a kludge, i.e., 1. clone the substack, 2. delete the original. It does what it's supposed to do but the Application Browser doesn't get updated until you click the refresh button.

Any hints on what would trigger a refresh of the App Browser?

Update: It *does*, however, update the Project Browser, so maybe that's OK.

[jacque]

The problem with that is that "delete stack foo" has never meant removing the disk file, just the stack in memory.

Actually, it does mean delete the stack -- if it's a substack. If you don't have a separate copy somewhere, it's gone forever. But as long as the original syntax remains valid, it's okay. Certainly not worth a <wrath> post.

[mwieder]

@Jacque- no, delete stack "foo" doesn't affect the stack file unless you save the stack. It only deletes the substack in memory.