xTalk Style Stack

[tperry2x]

Think I found a way to counteract that though, or at least negate the risk a lot.

on-disk.png (15.81 KiB) Viewed 221 times

While building my alternative inspector, it's fairly easy to check if the thing being clicked on exists on disk or not, or in RAM. Here's also where I can put in a command to do autosaves too, which is something I'd like to implement for OXT lite.

Edit: Sorry, I'll stop hijacking this post and continue documenting the stack format. I'll post that here when I've got something that I think is correct.

[richmond62]

Hoary Chestnut time.

Round about the time the dinosaurs were wiped out I was discovering HYPERCARD in Illinois (1993), and fell distinctly foul of the fact that,
unlike every other program on my Macintosh L475, it did NOT have a 'Save' thing in the menus, but autosaved every thing one did.

So: having gone down a distinctly primrose path and working out that I had got almost everything wrong, I could NOT revert to an earlier version, and had to spend about 3 hours unpicking what I had done in the previous 15 minutes.

NOW, that Mac L475 had a hard drive of 40 MB, so not much space.

Today, my iMac has about half a terabyte: of which about 20% is used.

So, while autosave may be a good thing, it needs to be more than 'just' autosave: it needs to autosave at intervals (and now I'm pausing for a nasty little tangential thought):
-------
Most autosaves save at time intervals: this makes little or no sense to me.

Might an autosave not autosave after a set number of keydowns instead? After all, I don't really need 25 autosaves that are identical just because I popped round the corner to the toilet.
-------
I believe that a series of autosaves (possibly with a timestamp appended to the file name) that would be listed in a dropdown menu (so you could revert to which ever one you wanted when you worked out you had gone 'off') would be fantastic.

[tperry2x]

That is a good point. A bit like "changes history" / "document history" in Google Docs or Microsoft365, where you can revert to previous autosaved versions (or even the history states palette in Photoshop), - and agreed, no point in saving 30 versions just because you left the stack open on your screen with no changes for the last half an hour. It probably needs to look at what is different between the saved version on disk, and what is stored in ram (temporary memory), and do a comparison to decide if an autosave is necessary or not.

[richmond62]

It probably needs to look at what is different between the saved version on disk, and what is stored in ram (temporary memory), and do a comparison to decide if an autosave is necessary or not.

I think you are over complicating things.

No need to get into "diffs", just how many times Chummy 'whopped' a key on their keyboard.

This way 'pee breaks' and so on won't cause problems (after all, it is NOT computers that cause problems, NOR, for that matter, is it humans that cause problems (with computers, at least): it is the human-computer interface where everything goes totally screwy).

Somehow (?) the IDE has to count keydowns without that screwing up whatever is going on in the end-user's stack, and at an interval, say, every 25/50 keydowns do a SAVE . . . AS with a time stamp appended.

[xAction]

No need to get into "diffs", just how many times Chummy 'whopped' a key on their keyboard.

Auto-Save is timed because a programmer and/or designer might need to read reference material, and in the 3 minutes between accessing perhaps several other windows in several other applications they may forget to save and/or maybe introduce an infinite loop that locks up the whole IDE and have to force quit and/or find a bug like I have and crash the whole app 20 times a day.

If anything auto-save should activate every single time you hit apply in a script.
Especially these days when "Help me AI, you're my only hope" leads to "Well, that broke everything!"

SSD hard drives have reached 30 Terabyte capacity, worrying about having twenty or two thousand 500k stack files piled up in a temp folder is no worry at all. Just another cache to clear at the end of the day.

[richmond62]

If anything auto-save should activate every single time you hit apply in a script.

I NEVER hit APPLY: I always go directly to SAVE.

Come to think of things . . . why not bung a SAVE line in the APPLY button of the scriptEditor?
-
Because Apple want to 'Make things different' I have changed round the CTRL and COMMAND keys on ALL my Macs so that my muscle memory does go all funny when I work on LInux or (very occasionally) Windows.

So, when editing scripts in RR/LC/OXT my left hand is poised over the 'S' key AND, on this:
-

pad.png (376.5 KiB) Viewed 204 times

-
On a side note, it is odd that the Genesis Thor 100 RGB side buttons yield this:
-

Screenshot 2024-03-19 at 16.04.09.png (52.03 KiB) Viewed 203 times

-

[xAction]

Saving an old version every save isn't a bad idea.
I save many copies of my projects, when I'm not being lazy.

Code: Select all

APP_01_18_2024.stack
APP_01_19_2024_CrazyFlights.stack
APP_01_19_2024_ListSelect.stack
APP_01_19_2024_ListSelectb.stack
APP_01_20_2024_WorkinOnit.stack
APP_01_21_2024_WorkinOnitSomeMore.stack
APP_01_22_2024_GENERIC_IZINGATTEMPT.stack
APP_01_22_2024_GENERIC_ScriptBlocks.stack
APP_01_22_2024_GENERIC_ScriptBlocksCompile.stack
APP_01_23_2024_GENERIC_ScriptBlocksCompile.stack
APP_01_23_2024_GENERIC_SetGameObjectScript.stack
APP_01_24_2024_GENERIC_FIXING_b_0_maybe.stack
APP_01_24_2024_GENERIC_FIXING_b_0_StillTrouble.stack
APP_01_24_2024_GENERIC_MUCH_SCRIPT_REWORK.stack
APP_01_25_2024_GENERIC_FIXING_b_0_StillTrouble.stack
APP_01_25_2024_MESS_BUT_SELECTION_IS_BACKs.stack
APP_01_25_2024_MESS_BUT_SELECTION_IS_BACKsb.stack
APP_01_25_2024_NEWGETANDSETGLOBALLY.stack
APP_01_25_2024_PM_NewScriptBlocksCollect.stack
APP_01_25_2024_PM_NewScriptBlocksCollect_betterheader.stack
APP_01_25_2024_PM_NewScriptBlocksCollect_CleanERMEANER.stack
APP_01_25_2024_PM_OLDSCRIPTBLOCKS_01_27_2024.stack
APP_01_25_2024_PM_WorkingOnScriptCompare.stack
APP_01_25_2024_ReplaceBasePropertiesWithgetGameObjectProperties.stack
APP_01_25_2024_SELECTIONWORKSAGAIN_NEWGLOBALSSTUFF.stack
APP_01_25_2024_WHEREWEAT.stack
APP_01_27_2024_DIRTY_DOT_METHOD_BREAKSIT.stack
APP_01_27_2024_DIRTY_DOT_METHOD_TOFIX.stack
APP_01_28_2024AM_BASE_Bubbletouch,.stack
APP_01_28_2024AM_BASE_BubbletouchTWO.stack
APP_01_28_2024AM_BASE_SELECTION_WORKS.stack
APP_01_28_2024AM_BASE_SELECTION_WORKSb.stack
APP_01_28_2024AM_BASE_SelectionCircleWorks.stack
APP_01_28_2024AM_DIRTY_DOT_METHOD_TOFIX - Copy.stack
APP_01_28_2024AM_DIRTY_DOT_WORKINGFIELDUPDATEDATASETTINGy.stack
APP_01_28_2024AM_DIRTY_DOT_WORKINGONIT.stack
APP_01_28_2024AM_TRUE_CLICK_AND_ZOOMy.stack
APP_01_28_2024AM_TRUE_CLICK_AND_ZOOMy_B.stack
APP_01_29_2024AM_TRUE_CLICK_AND_ZOOMy_Ab.stack
APP_01_29_2024PM_TRUE_CLICK_AND_ZOOMy_Abc - Copy.stack
APP_01_29_2024PM_TRUE_CLICK_AND_ZOOMy_Abc.stack
APP_01_29_2024PM_TRUE_CLICK_AND_ZOOMy_AbcD.stack
APP_01_30_2024PM_playplanetinitworksA.stack
APP_01_30_2024PM_TURNFINISHWORK..stack
APP_01_30_2024PM_TURNFINISHWORKMore.stack
APP_01_31_2024PM_WorkOnSendToPath.stack
APP_02_01_2024AM_SendToWorks_MobileProgress.stack
APP_02_01_2024AM_SendToWorks_MobileProgressB.stack
APP_02_02_2024AM_SendToWorks_MobileProgressC.stack
APP_02_02_2024PM_NOW_WITH_ERRORCODES_A.stack
APP_02_03_2024PM_NOW_WITH_ERRORCODES_C.stack
APP_02_06_2024PM_PickingUpAgain.stack
APP_02_06_2024PM_PickingUpAgain_FixedDuplicatesOfFunctions.stack
APP_02_08_2024_PM.stack
APP_02_08_2024AM.stack
APP_02_08_2024AM_FixedLeakInBaseData.stack
APP_02_09_2024_AM_MobileDataSetLeakFIXEDb - Copy.stack
APP_02_10_2024_AM_PATHS - SendToPathMobileRelativeFixed.stack
APP_02_10_2024_AM_PATHS - SendToPathMobileRelativeFixedb.stack
APP_02_11_2024_AM_PATHS - FIRSTFLEETNESS_ - B.stack
APP_02_11_2024_AM_PATHS - FIRSTFLEETNESS_.stack
APP_GENERIC_SHELL_001.stack
APP_RELATIVE_LERPS - wk.stack
APP_RELATIVE_LERPS.stack
APP_Relativity_works_mostly.stack
APP_Relativity_works_mostly_zoombroke.stack
APP_Relativity_works_mostly_zoomFixed.stack
APP_SendTo_Zoom_Works.stack
APP_SendTo_Zoom_Worksy - Copy.stack
InPractice_APP_LessFields.stack
InPractice_APP_WorkingExample_0001.stack
InPractice_GameLike - Refactor.stack
InPractice_REDEUX_MORE_SPECIFIC_SETS.stack
InpracticeAPP_SendTo_And_Zoom.stack
inpracticeGamescript

[richmond62]

It is interesting that you bung your date stamps on the front rather than on the back.

[xAction]

Sort by name will get incorrect sorting with
App_ABC_123
but be correct with
App_123_ABC

Especially if your file names are something like
APP_ThisVersion_123
APP_Anotherversion_123
APP_WhatwasIDoingTodayIForgot_123

Maybe not like that on the mac, I remember always being able to know exactly where things were on the mac and the "Sherlock" finding the things that I know exist, unlike windows that will screw up the search order, randomly choose a file view type, and tell me it can't find something I'm looking directly at.

Oh you sorted by date?
I assume you mean you wanted to look at the 400 folders you made months ago, before looking at that file you just downloded 3 seconds ago!

[richmond62]

No, not really as, when I am working on some long-term stuff (e.g. my Devawriter: 14 years and counting), I put each day's saves into folder that is date stamped.

So, using my Devawriter stack as an example, I have a folder called 'DWP_9_2_24' (i.e. 9 February 2024) and about 5 stacks in there; one of which is called 'DWP_14.05.livecode').

In the last 14 years (transitioning through 9 computers) I have only lost a saved version once: which doesn't seem that bad.