Stack with the same name loop

Pi Digital sean at pidigital.co.uk
Thu Oct 7 10:26:16 EDT 2021


Hi Mark (both :) )

Thanks for your explanation. Very thorough. 

What I don’t understand is why the engine needs to delete the old reference (weak handle) when invoking a ‘save as’. Is it not just a matter of resaving you a new location and making the pointer to the storage device for that instance? Why does it need to save it and then remove from memory at all? Just carry on with what is already in memory without the need to reload. That’s why we use a ‘save as’ anyway. 

Thanks again. 

Sean


> On 7 Oct 2021, at 14:40, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> On 2021-10-06 22:30, Mark Wieder via use-livecode wrote:
>> That's what I do as well. Kill, then go do something else for a bit.
>> Reading the code that invokes this dialog (the reloadstack handler in
>> revbackscriptlibrary.livecodescript) isn't much help. It's only the
>> IDE that can't handle this, not the engine.
>> This would all be moot if the IDE used the long id of the stack
>> instead of just the short name of the stack, but that would require
>> work.
> 
> That isn't true - the problem is a lot deeper than that.
> 
> Most 'stack' related engine syntax works with the short name of stacks e.g. defaultStack, topStack, stackFiles.
> 
> The IDE is built using the engine, so has to work within the limitations the engine has.
> 
> Internally the engine references stacks by 'weak handles' (basically pointers which 'know' when the thing they are pointing at has been deleted) - it does not use names... However the way stacks are referenced by script (as mentioned above) do use the short name - to keep things simple.
> 
> Of course it would be possible to add new syntax and such - and it would be possible to update the IDE to use it (and thus the 'irksome' dialog could be removed).
> 
> However, the reality is that, that endeavour (which would be a very large amount of work) would only shift the problem - onto users themselves.
> 
> If user code did not use the new syntax, then chances are they would end up causing really hard to track down issues in their own code due to having two stacks with the same name. This is regardless of whatever resolution order was chosen to resolve conflicts - unless user code also uses unique stack references, there is no choice which would not stop problems from happening.
> 
> I'd like to point out that this is not me copping out here - it is merely pointing out that simplicity does come with restrictions - and as it stands, one of these restrictions (with livecode) is uniquely named stacks.
> 
> I'd further point out that 'critical things having unique name' isn't that rare. For example, you can't have two files with the same name in a folder for example (even though on UNIX systems, every file has an internal unique integer id - the inode number) and you can't have two handlers, variables, methods, types (or any named thing) with the same name (in the same namespace) in any language that I know of.
> 
> So, may I suggest, the problem to solve is to figure out why the dialog which spawned this thread does not work correctly in some circumstances?
> 
> I say some circumstances, because it does work precisely as advertised in a (fresh) IDE after it has been started:
> 
>  1) Create a stack "Foo" - save it as "FooEmpty.livecode" and remove from memory
>  2) Create another stack "Foo" - place a button on it and save it as "FooButton.livecode"
>  3) Load FooEmpty.livecode from the menu - ask to Purge. FooEmpty appears (and FooButton goes)
>  4) Add a tab control to FooEmpty.
>  5) Load FooButton.livecode from the menu - ask to Save, FooEmpty is saved and FooButton appears.
>  6) Load FooEmpty.livecode from the menu - ask to Purge, FooEmpty appears (now with tab control) and FooButton has gone.
> 
> The correct behavior of that dialog is precisely what you would expect from the button names:
> 
>  1) Cancel - the loading of the new stack does not happen.
>  2) Purge - the existing stack of the same name is removed from memory without saving first, and the new stack is loaded.
>  3) Save - the existing stack of the same name is saved and then removed from memory, and the new stack is loaded.
> 
> The effect observed (the looping) could be an interaction with a component in the IDE (which somehow causes the stack which should be being removed to be reloaded), or it could be some code pattern in user stacks which cause much the same problem. In the former case, we need to fix the IDE to be 'purge safe in this case', in the latter case we need to understand the pattern so that we can change the mechanism to not be affected by it.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



More information about the use-livecode mailing list