Files vs. Stacks
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Re: Files vs. Stacks
Definitely, once you get use to it, it is extremely flexible. A small palette (I initially was thinking invisible, but now am thinking palette) stack with a tiny script written as a plugin would work for automating the saving in whatever way you'd like, as it is incredibly easy to increment or even as Richard pointed out, use seconds or some date / time stamp as the versioning system for the save.
-
- VIP Livecode Opensource Backer
- Posts: 9823
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Files vs. Stacks
Ah, but you've wisely chosen to go straight to the source, literally, with your efforts updating the MetaCard IDE. That's where the real meat of the story is. Anything I could add amounts to little more than semi-random gossip.bogs wrote: ↑Fri Dec 22, 2017 11:36 pmUm, you can send that discussion my way if you want (getting the popcorn).FourthWorld wrote: ↑Fri Dec 22, 2017 11:01 pmExplaining the 25-year history of the code base would not seem relevant to his immediate concern.
EDIT: If you really find these sorts of niggly details interesting, check out the discussion in this enhancement request:
http://quality.livecode.com/show_bug.cgi?id=1061
Note especially the link in Comment 20, which leads to a specific bug report that is apparently at the heart of the issue.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9823
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Files vs. Stacks
Though to clarify, I agree with the OP that the IDE should make it as easy as practical to create names that are both unique AND meaningful.
Even MC fell short on the latter part, since its default names had no mnemonic value.
Devolution helps by asking for a name up front before creating a stack. Since it provides a default (for those rare cases where you want something right now and know you'll be throwing it away and therefore won't need a real name), so the penalty for not setting a meaningful name is just one Enter keystroke.
But devolution isn't the IDE. We need this sort of sensitivity to the workflow throughout the core IDE. Most objects are only sometimes named, and often not. But stacks are almost always given meaningful names, and the earlier in the workflow the better. The IDE should provide guidance to encourage that, IMO.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Files vs. Stacks
I found the read and linked read quite interesting indeed, with a lot of good ideas proposed. I really want to thank you for it, it gives me some ideas to plod over.FourthWorld wrote: ↑Sat Dec 23, 2017 1:53 amAh, but you've wisely chosen to go straight to the source, literally, with your efforts updating the MetaCard IDE. That's where the real meat of the story is. Anything I could add amounts to little more than semi-random gossip.bogs wrote: ↑Fri Dec 22, 2017 11:36 pmUm, you can send that discussion my way if you want (getting the popcorn).FourthWorld wrote: ↑Fri Dec 22, 2017 11:01 pmExplaining the 25-year history of the code base would not seem relevant to his immediate concern.
EDIT: If you really find these sorts of niggly details interesting, check out the discussion in this enhancement request:
http://quality.livecode.com/show_bug.cgi?id=1061
Note especially the link in Comment 20, which leads to a specific bug report that is apparently at the heart of the issue.
While it is true I've learned a ton going through the Mc IDE and reading the code (and especially the comments) from all of you who were there before me, I find the random gossip and memories of people there at the time equally educating, and two of the main sources of that education for me have been you and Jacque, as well as side conversations with many others.
I also concur completely on the needs of a default name popup such as devolution provides, but where the IDE might hybrid it is when no name/same name is provided by the user, such as a timestamp on the stack or even something as simple as Mc's putting the milliseconds (the user would need no knowledge of this, it is strictly for the IDE) it was made on which would be highly unlikely to be repeated on another stack.
Playing devil's advocate, I have actually found having a file name and internal stack name quite useful on occasion, although like the OP I found it initially irritating, confusing, and inexplicable initially.
I'll stop derailing the main topic though heh, and reminisce on my own dime as it were
-
- Livecode Opensource Backer
- Posts: 9358
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Files vs. Stacks
Well, the IDE does number the "Untitled" stacks; 1,2,3 which is, at least, a start.a default name
As was pointed out earlier; there IS a problem with the possible mismatch between
a stack's name and the saved file:
Yesterday I renamed stack "Drag" to "Drag 2" and had to remember to
perform a save as so that the stack was not saved into my "Drag.livecode" file.
AS far as I can see what is needed is for the save command to be disabled when
a user changes the name of a stack, and when they then attempt to perform
a save the save as command kicks in instead.
Re: Files vs. Stacks
Looks like your quote is missing a few words eh? The context was based on the value of the IDE presenting you with a "default name popup", ostensibly to allow you to provide a name on creation or, if someone preferred it, to skip naming with no more than an extra [Enter/Return] key press.richmond62 wrote: ↑Sat Dec 23, 2017 9:30 amWell, the IDE does number the "Untitled" stacks; 1,2,3 which is, at least, a start.a default name
I do see the value in your statements past that, though at some point we should have to deal with our own blunders. After all, isn't that what teaches us the most? In my case certainly, it is my biggest screw-ups that were the most lasting lessons.
-
- Livecode Opensource Backer
- Posts: 9358
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Files vs. Stacks
I do, constantlyat some point we should have to deal with our own blunders
And I wonder what all the fuss is about in this discussion: unless, of course,
we want to dumb LiveCode down to the point where we can just go away
and do something else while it cooks up programs for us.
Re: Files vs. Stacks
We certainly did go astray didn't we? I suspect some people would love that idea, me, I'll stick with what I got till it doesn't work anymore
-
- VIP Livecode Opensource Backer
- Posts: 7228
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Files vs. Stacks
Please, no. That would be terribly disruptive. Think how you'd feel if your word processor did that.AS far as I can see what is needed is for the save command to be disabled when
a user changes the name of a stack, and when they then attempt to perform
a save the save as command kicks in instead.
As to the original question, the problem is that LC tracks open stacks by their short names and not by their file names. Two stacks with the same name cause conflict. Once you know that, you can accommodate. You can choose the purge option in the warning dialog, which removes the first one from memory. Or you can cancel, temporarily change the name of the original (without saving) and then reopen the second one.
Since file names are ignored except when saving the stack, those don't need to be changed.
A mainstack can have attached secondary stacks which LC calls substacks. These are saved into the same file on disk, and when the mainstack opens, its substacks are opened too. They aren't initially visible but they're in RAM and can also conflict with other stacks opened later. (This is the most common conflict I usually see.) If that happens I open two versions of the same stack in two different copies of LC if possible.
As mentioned, I also turn on the LC preference to create all new stacks with destroystack set to true, so that closing them also removes them from RAM. Computers are fast enough now that there's rarely a need to keep them idling in the background except in some very specific cases.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Livecode Opensource Backer
- Posts: 9358
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Files vs. Stacks
Well I'm glad I understand what destroystack means:the LC preference to create all new stacks with destroystack set to true
I thought it meant that it would destroy the stack.
It's a comfort to have terms that don't mean what they say.
-
- VIP Livecode Opensource Backer
- Posts: 7228
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Files vs. Stacks
That's a common complaint, it should have been "purgestack". On the other hand, "destroy" is frequently used in programming to mean "remove the structure from memory." Raney used that terminology when implementing the property and I'm sure it seemed intuitive to him.richmond62 wrote: ↑Sat Dec 23, 2017 6:57 pmWell I'm glad I understand what destroystack means:the LC preference to create all new stacks with destroystack set to true
I thought it meant that it would destroy the stack.
It's a comfort to have terms that don't mean what they say.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Files vs. Stacks
Purge sounds like GAS escaping, stick with DESTROY !
Re: Files vs. Stacks
I am getting the sense that the solution to the problem is to just use the LC settings to turn the problem off. So I will now have "destroy stack" set to true for all new stacks. The problem is that to a beginner it all seems so esoteric. "Destroy" sounds bad or at least destructive. Surely I should set the bad/destructive thing to false? And for all I knew the business of keeping stacks in memory was part of the "LiveCode way" which would eventually make sense to me.
And I note that by leaving destroyStack as false, you open up another set of options: what to do with the file when you close the last stack: Don't close the file/Close the file/Ask, with the default set to "Don't close the file". So I was letting the files as well as the stacks hang around – another possible cause of confusion?
My own beginner-ish, really uninformed opinion would be that settings should be the other way round by default.
Anyway thanks all for a very instructive discussion which has also given me some ideas.
-- DavidF.
And I note that by leaving destroyStack as false, you open up another set of options: what to do with the file when you close the last stack: Don't close the file/Close the file/Ask, with the default set to "Don't close the file". So I was letting the files as well as the stacks hang around – another possible cause of confusion?
My own beginner-ish, really uninformed opinion would be that settings should be the other way round by default.
Anyway thanks all for a very instructive discussion which has also given me some ideas.
-- DavidF.
Re: Files vs. Stacks
Here is a pretty good stub on the subject from Max's wiki (the wiki is a good address to bookmark, btw, the examples in it are usually a bit clearer and more extensive than the dictionary).
Something else that might be helpful to learn the concepts might be the old Mc help stacks, which you can download from here (too large to put on the forum). You can either run them from inside the IDE, or make them a standalone and use them outside the IDE (which is how I use it).
There is a lot of information in there that I find easier to access than the newer formats, and much of it still applies, though obviously not all of it. There are 3 tutorials that work no issue. There are 11 example scripts that cover a lot of ground, the reference still applies as far as I can tell, subjects are categorized and easy to access.
There is also the scripting conferences stacks that Jacque put together (invaluable, but rambling), and the byu online lessons material (includes great reference stuff).
That amount of info should serve you well in learning, hope it helps.
Something else that might be helpful to learn the concepts might be the old Mc help stacks, which you can download from here (too large to put on the forum). You can either run them from inside the IDE, or make them a standalone and use them outside the IDE (which is how I use it).
There is a lot of information in there that I find easier to access than the newer formats, and much of it still applies, though obviously not all of it. There are 3 tutorials that work no issue. There are 11 example scripts that cover a lot of ground, the reference still applies as far as I can tell, subjects are categorized and easy to access.
There is also the scripting conferences stacks that Jacque put together (invaluable, but rambling), and the byu online lessons material (includes great reference stuff).
That amount of info should serve you well in learning, hope it helps.
Last edited by bogs on Sun Mar 11, 2018 11:31 pm, edited 1 time in total.
-
- VIP Livecode Opensource Backer
- Posts: 9823
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Files vs. Stacks
IMO that should be on by default. Can anyone here think of a reason changing that default, at least in the IDE, would be a problem?
Agreed:The problem is that to a beginner it all seems so esoteric. "Destroy" sounds bad or at least destructive.
http://quality.livecode.com/show_bug.cgi?id=3932
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn