Stack name conflicts resolved?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Stack name conflicts resolved?

Richard Gaskin
I've grown weary of stack name conflict over the years, and this morning
decided to take some time to assess where we're really at with that and
see if perhaps there's a way to handle things more liberally than how
the IDE does now.

TL/DR version:  It seems there's actually no real problem at all.

Long version:


Setup
-----
I checked revfrontscriptlibrary and found that preOpenStack calls
revIDEHandleNewStack, which resides in revbackscriptlibrary.

In that handler I found this line #3199, which I commented out:

   revCheckStackCollision tStackName

That handler is apparently the one that compares the stacks in the stack
file being opened against a list of stacks already open, and if any
stack of the same name is found it brings up the stack name conflict
warning.

After commenting it out I made two stacks:

mainstack:  tA
  substack:  foo

mainstack   tB
  substack:  foo

On each mainstack is a button with:

   on mouseUp
      toplevel "foo"
   end mouseUp

Each foo substack contains an object to distinguish the stacks from one
another, so I can tell which foo stack is which at a glance.

With that prep out of the way, I began my experiment:


Experiment 1
------------
I started a fresh session in LC, and opened tA.

Then I opened tB.

And since I'd commented out revCheckStackCollision, no warning was
presented.

So then in stack tA I clicked the button, and it opened the foo substack
belonging to it.

Then I clicked the button in stack tB, and it opened the foo substack
belonging to it.


Experiment 2
------------
I created a third stack file, and added a button with the same script as
above.

When clicked, it opens the foo window belonging to the stack file which
had been opened first.



Results
-------
It would appear that the resolution of substack names follows a logical
path that looks for matching stacks in this order:

1. Within the same stack file as the script referring to it.

2. Within another stack file, in the order in which they were opened
during the session.

This seems more or less what I've been hoping to find for years:
http://quality.livecode.com/show_bug.cgi?id=1061

Unless there's something here that I've missed, it would appear that
stack name resolution is nearly as logical and useful across stack files
as icon ID resolution.

And just as we don't need to go through contortions to ensure that every
icon ID is unique across all stacks, as long as we remember the
resolution rule we can safely use stacks of the same name within the
current session.

That is, once we modify the IDE to allow it.

Is there something I've missed here?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Stephen Barncard-4
On Sat, Nov 5, 2016 at 11:28 AM, Richard Gaskin <[hidden email]>
wrote:

> I've grown weary of stack name conflict over the years, and this morning
> decided to take some time to assess where we're really at with that and see
> if perhaps there's a way to handle things more liberally than how the IDE
> does now.
>
> TL/DR version:  It seems there's actually no real problem at all.
>

Thanks Richard, this has been driving me nuts since.... the first day I
used Revolution, and it was terrifying. Most of the time I just forced quit.

One wonders how many 'solutions to non-problems' are there still working in
LC? Things we've been doing for years...

(ps I love the thread on the bug report. humor takes many forms.)

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
stephen barncard wrote:

 > On Sat, Nov 5, 2016 at 11:28 AM, Richard Gaskin wrote:
 >
 >> I've grown weary of stack name conflict over the years, and this
 >> morning decided to take some time to assess where we're really at
 >> with that and see if perhaps there's a way to handle things more
 >> liberally than how the IDE does now.
 >>
 >> TL/DR version:  It seems there's actually no real problem at all.
 >
 > Thanks Richard, this has been driving me nuts since.... the first day
 > I used Revolution, and it was terrifying. Most of the time I just
 > forced quit.
 >
 > One wonders how many 'solutions to non-problems' are there still
 > working in LC? Things we've been doing for years...

I should clarify that by "no real problem at all" I'm thinking in terms
of sharing stacks among potentially-large teams of people who know what
they're doing.  In my workflow, learning the rule of stack name
resolution isn't a big price to pay for the simplicity and flexibility
of being able to work on anything at any time regardless of its name.

So more specifically, it's fine *in the engine*.

But the *IDE* has different responsibilities.

I didn't close my feature request yet because I'm undecided about the
best way to provide useful guidance for new users who might spend all
day working on the wrong stack without some sort of warning.

Like you, I've had issues trying to use the existing dialog, never quite
certain what either option will do before I pick one, and never quite
sure it did what I thought it would do after I clicked it.  And like
you, I've usually found it at least mentally simpler to quit and start
with a fresh session.

But perhaps there's another option we haven't yet considered, one which
provides sufficient guidance so folks know which stack they're working
on, but perhaps less ominous and complex than the solution in place now.

Suggestions?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Monte Goulding-2
In reply to this post by Richard Gaskin

> On 6 Nov. 2016, at 5:28 am, Richard Gaskin <[hidden email]> wrote:
>
> That is, once we modify the IDE to allow it.

^ this is the issue. For the most part it isn’t the engine that has the issue with multiple stacks with the same name open it’s the IDE. There would be bucket loads of work involved in getting the IDE to play nicely with multiple stacks with the same name open.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
Monte Goulding wrote:

 >> On 6 Nov. 2016, at 5:28 am, Richard Gaskin wrote:
 >>
 >> That is, once we modify the IDE to allow it.
 >
 > ^ this is the issue. For the most part it isn’t the engine that has
 > the issue with multiple stacks with the same name open it’s the IDE.
 > There would be bucket loads of work involved in getting the IDE to
 > play nicely with multiple stacks with the same name open.

I imagine for good reason, but I'm curious: where does topstack not do
what an IDE needs?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Monte Goulding-2
I didn't say it couldn't be done. Possibly we would need versions of the mainstacks and openstacks that listed long IDs.

Sent from my iPhone

> On 6 Nov. 2016, at 9:08 am, Richard Gaskin <[hidden email]> wrote:
>
> I imagine for good reason, but I'm curious: where does topstack not do what an IDE needs?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

mwieder
In reply to this post by Monte Goulding-2
On 11/05/2016 03:02 PM, Monte Goulding wrote:
>
>> On 6 Nov. 2016, at 5:28 am, Richard Gaskin <[hidden email]> wrote:
>>
>> That is, once we modify the IDE to allow it.
>
> ^ this is the issue. For the most part it isn’t the engine that has the issue with multiple stacks with the same name open it’s the IDE. There would be bucket loads of work involved in getting the IDE to play nicely with multiple stacks with the same name open.

That is indeed the issue.
The IDE for some reason allows multiple controls with the same name but
keeps track of their individual identities, but insists that stack names
be unique in memory.

When new stacks are created in memory they are assigned the id 1002.
Why?
If there's a stack already in memory why not create the new stack with
the next sequential id?
Then the combination of id and filename should uniquely identify a stack.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Monte Goulding-2

> On 6 Nov. 2016, at 1:31 pm, Mark Wieder <[hidden email]> wrote:
>
> When new stacks are created in memory they are assigned the id 1002.
> Why?
> If there's a stack already in memory why not create the new stack with the next sequential id?
> Then the combination of id and filename should uniquely identify a stack.

Stack IDs aren’t really IDs at all they are just the max ID in a stack + 1. The first 1000 IDs are reserved. Card 1 is 1001 and therefore a new stack ID is 1002. Create a new object and the ID changes.

I guess we will discuss UUIDs next ;-)

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

mwieder
On 11/05/2016 09:38 PM, Monte Goulding wrote:
>
>> On 6 Nov. 2016, at 1:31 pm, Mark Wieder <[hidden email]> wrote:
>>
>> When new stacks are created in memory they are assigned the id 1002.
>> Why?
>> If there's a stack already in memory why not create the new stack with the next sequential id?
>> Then the combination of id and filename should uniquely identify a stack.
>
> Stack IDs aren’t really IDs at all they are just the max ID in a stack + 1. The first 1000 IDs are reserved. Card 1 is 1001 and therefore a new stack ID is 1002. Create a new object and the ID changes.

Yes, good point, but here's the thing:

Create two new stacks.
They both have the "ID" 1002.
Set the id of the second stack to 3000.
Now you have stacks 1002 and 3000.
Add a button to each stack.
The stack ids are now 1003 and 3001.

They're obviously different stacks.
You see two stacks on the screen, they have different ids.
Now rename the second stack to "Untitled 1"

The property inspector allows this, but now gets very confused.
If you try to bring up the property inspector of either stack, you get
only the first one it comes across, until you rename one.

I'd prefer the creation timestamp as a unique identifier for stacks, but
whatever we use, the short name by itself is inadequate to the task.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Monte Goulding-2

> On 7 Nov. 2016, at 3:57 am, Mark Wieder <[hidden email]> wrote:
>
> Now rename the second stack to "Untitled 1"
>
> The property inspector allows this, but now gets very confused.

Ah… well that’s probably a bug. If the IDE can’t handle multiple stacks with the same name it should not allow this. Even if the IDE were refactored to only refer to stacks by long ID it would still get confused by multiple stacks with the same name that are unsaved. I think the solution is a more robust object handle we can use in scripts it would help I think. Ideally we can get a handle to an object and pass it around and it won’t matter how much we change the ID or name of the object the handle will still be valid. If we had that then we could get lists of stack handles and not get confused if there are multiple with the same name.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Ben Rubinstein
On 06/11/2016 20:50, Monte Goulding wrote:
>
>> On 7 Nov. 2016, at 3:57 am, Mark Wieder <[hidden email]> wrote:
>>
>> Now rename the second stack to "Untitled 1"
>>
>> The property inspector allows this, but now gets very confused.
>
> Ah… well that’s probably a bug. If the IDE can’t handle multiple stacks with the same name it should not allow this. Even if the IDE were refactored to only refer to stacks by long ID it would still get confused by multiple stacks with the same name that are unsaved. I think the solution is a more robust object handle we can use in scripts it would help I think. Ideally we can get a handle to an object and pass it around and it won’t matter how much we change the ID or name of the object the handle will still be valid. If we had that then we could get lists of stack handles and not get confused if there are multiple with the same name.
>

My proposal in 2004 http://quality.livecode.com/show_bug.cgi?id=1061#c8 was
for the IDE to create not a UUID but a unique-in-this-session "stackID" (since
'id' of a stack is actually used for 'next ID'). There would thus be a way to
refer to stacks within the IDE completely uniquely.

Modifying all code in the IDE that referenced stacks would doubtless be quite
a large task; but once there is a way to reference stacks that is completely
unique, then fixing particular identified issues caused by stacks with the
same name would become simpler. Currently if I understand it correctly there
are issues which seem just too hard to fix: so instead
http://quality.livecode.com/show_bug.cgi?id=143 - the most egregious of these
issues - was 'fixed' by adding the check that Richard's trying to remove.

Ben

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
Ben Rubinstein wrote:

 > Currently if I understand it correctly there are issues which seem
 > just too hard to fix: so instead
 > http://quality.livecode.com/show_bug.cgi?id=143 - the most egregious
 > of these issues - was 'fixed' by adding the check that Richard's
 > trying to remove.

In all fairness, I'm not *trying* to remove it, but have in fact removed
it - in my own copy of the IDE.

As I noted in this post, I've not closed #1061 because I recognize that
the IDE has different responsibilities beyond those of our own apps:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232451.html

I'm just glad to find that the rule for looking up stacks by name built
into the engine is simple, understandable, and very useful.

We can have confidence that our standalones, which don't include
IDE-specific code, will allow stacks of the same name to run without
issue according to a fairly simple search rule.

This means that I can have a classroom of students sharing stacks
without having to impose all sorts of complicated schemes to ensure that
stack names are unique.

For standalones, the engine behavior is beautifully elegant.

But I do recognize that the IDE has a special role with special
responsibilities, and have left my original enhancement request open as
we explore ways to address that, hopefully arriving at a middle ground
which provides confidence about which stack we're working on while also
giving us the freedom to use stacks as easily as the engine allows.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Ben Rubinstein
Hi Richard,

No overtones intended by use of word "trying"! I should have said
"experimenting with" or similar...

I am interested though that you noted, if I understood correctly, that your
experiment showed that having two substacks with the same name didn't cause an
issue in the IDE when using the substack name with "toplevel". QC #143
suggests that (way) back in the day, there were serious issues that arose in
this situation when attempting to save changes to such stacks. Did you find
any evidence that this is still a problem?

best wishes,

Ben

On 07/11/2016 15:00, Richard Gaskin wrote:

> Ben Rubinstein wrote:
>
>> Currently if I understand it correctly there are issues which seem
>> just too hard to fix: so instead
>> http://quality.livecode.com/show_bug.cgi?id=143 - the most egregious
>> of these issues - was 'fixed' by adding the check that Richard's
>> trying to remove.
>
> In all fairness, I'm not *trying* to remove it, but have in fact removed it -
> in my own copy of the IDE.
>
> As I noted in this post, I've not closed #1061 because I recognize that the
> IDE has different responsibilities beyond those of our own apps:
> http://lists.runrev.com/pipermail/use-livecode/2016-November/232451.html
>
> I'm just glad to find that the rule for looking up stacks by name built into
> the engine is simple, understandable, and very useful.
>
> We can have confidence that our standalones, which don't include IDE-specific
> code, will allow stacks of the same name to run without issue according to a
> fairly simple search rule.
>
> This means that I can have a classroom of students sharing stacks without
> having to impose all sorts of complicated schemes to ensure that stack names
> are unique.
>
> For standalones, the engine behavior is beautifully elegant.
>
> But I do recognize that the IDE has a special role with special
> responsibilities, and have left my original enhancement request open as we
> explore ways to address that, hopefully arriving at a middle ground which
> provides confidence about which stack we're working on while also giving us
> the freedom to use stacks as easily as the engine allows.
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
Ben Rubinstein wrote:

 > No overtones intended by use of word "trying"! I should have said
 > "experimenting with" or similar...

No offense taken, I just want to be sure that my glee for discovering
the soundness and simplicity of the engine's handling of this does not
mean I recommend relying on the engine alone for others.

As we've seen in this discussion, there are some workflows which can
benefit from extra scripting to introduce a prohibition on using two
different stacks with the same name during development.


 > I am interested though that you noted, if I understood correctly,
 > that your experiment showed that having two substacks with the same
 > name didn't cause an issue in the IDE when using the substack name
 > with "toplevel". QC #143 suggests that (way) back in the day, there
 > were serious issues that arose in this situation when attempting to
 > save changes to such stacks. Did you find any evidence that this is
 > still a problem?

Good test case - thanks.

I hadn't tested it before because my primary interest here is in runtime
behavior.

In testing here this morning, I discovered what may well be the source
of some (if not a majority) of the issues surrounding stack name
conflicts: a bug in the topstack function itself.

Here's what I found:

I made two new mainstacks, both named "foo".

While attempting to add controls to them and saving them, I found a bug
in the topstack function.

Topstack should return the long name of the topmost stack of the lowest
mode.

Once saved, no two stacks will have the same topstack value, since it
includes the path, e.g,:

   stack "/home/user/Desktop/foo.livecode"
   stack "/home/user/Documents/foo.livecode"

With my IDE mod in place which allows me to open stacks which have the
same name (this could also be tested in a standalone), I found that
querying the topstack always and only returns the value of the stack
which had been opened first, regardless which one was actually topmost.

Of course, since the value of the topstack function itself is an
absolute reference that includes the path, it would seem reasonable to
expect that the engine at least attempt to take that distinguishing
factor into account when deriving the value it returns.

So I just filed a bug report on that:
http://quality.livecode.com/show_bug.cgi?id=18793

This still won't affect the subset of cases involving stacks of the same
short name in which both are newly created and have not yet been saved,
and for those the IDE prohibition on renaming/creating may suffice.

Similarly, downloaded stacks would not be distinguishable, since they
also have no value in their filename property.

But both of those are relative edge cases I'd be happy to handle through
other means once topstack is updated to at least attempt to use
available information for accurate results.

And once topstack reliably returns a more accurate reference, it would
seem many if not most of the issues we've been having would likely go away.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Mark Waddingham-2
In reply to this post by Richard Gaskin
On 2016-11-05 19:28, Richard Gaskin wrote:
> I've grown weary of stack name conflict over the years, and this
> morning decided to take some time to assess where we're really at with
> that and see if perhaps there's a way to handle things more liberally
> than how the IDE does now.
>
> That is, once we modify the IDE to allow it.
>
> Is there something I've missed here?

The engine has always been 'okay' (I believe) with substacks of the same
name when they are owned by *different* mainstacks - the only rule you
must follow in your code is that if you are referencing a substack when
the 'defaultStack' is not the main stack owning it, then you must use:

   stack ... of stack ...

Just as you would if you have two controls with the same name in two
different groups.

There is still the general problem of having multiple mainstacks with
the same name, or multiple substacks with the same name with the same
owner. Unfortunately, I'm not sure there is a general solution to that
(mainly because we use stack <name> as the reference for a specific
stack in script, and when you start making cross-stack references, any
search order is likely to cause 'surprising' results at unexpected
times).

I'd perhaps use the observation that you wouldn't expect to have two
files in the same folder with the same name on disk... So why expect to
be able to have two mainstacks with the same name in memory? (Or indeed,
two substacks with the same name owned by the same stack).

I think it would be generally true to say that in one project, you don't
want more than one (main) stack with the same name - as you would never
know what stack you were referring to in script. I'd actually propose
that the only use-case for multiple (main) stacks with the same name is
for the purposes of editing (in the IDE) - e.g. so you can compare and
contrast two revisions of the same stackfile. However, beyond opening
two instances of the IDE, that isn't possible at present.

I do wonder if the engine was a little bit more hard-line about stack
naming if some of the issues people find might go away. Also, it *might*
be reasonable for the engine to actually rename a stack when loaded if
there is already one with the same name in memory - so you can at least
access it; although it might not work because its scripts might still be
using 'stack <name>' to refer to itself (which, of course, would refer
to the originally opened stack and not itself).

In regards to the IDE as it is now - it uses long ids to reference
objects internally throughout - and because this means substacks are
always references as stack X of stack Y, it now does not break if you
have two substacks with the same name in memory. (However 'the finding
the right stack' problem still exists if you have a substack anywhere
with the same name as a mainstack).

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
Mark Waddingham wrote:

 > The engine has always been 'okay' (I believe) with substacks of the
 > same name when they are owned by *different* mainstacks - the only
 > rule you must follow in your code is that if you are referencing a
 > substack when the 'defaultStack' is not the main stack owning it,
 > then you must use:
 >
 >    stack ... of stack ...
 >
 > Just as you would if you have two controls with the same name in two
 > different groups.
 >
 > There is still the general problem of having multiple mainstacks with
 > the same name, or multiple substacks with the same name with the same
 > owner. Unfortunately, I'm not sure there is a general solution to
 > that (mainly because we use stack <name> as the reference for a
 > specific stack in script, and when you start making cross-stack
 > references, any search order is likely to cause 'surprising' results
 > at unexpected times).

In my ongoing tests it seems to be even better than that.

Apparently referring to a stack by short name will cause the engine to
resolve it somewhat similarly to how it resolves other universal
references like image IDs:

1. It looks for the stack in the same stack file as the script
    referring to it.

2. If not found, it searches other open stack files in the order
    in which they were loaded into the environment.

This appears to work well for both substacks and mainstacks (easy enough
to explore once I commented out line #3199 of revbackscriptlibrary,
worth doing at least temporarily to see how things run).

Given the apparent simplicity and consistency of how this works, I read
Ben's post earlier this morning with great interest, which pointed me to
cases where the engine appears to get confused by stacks with the same name:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232505.html

Since I'd already disabled the IDE's same-name check, I was empowered to
explore those issues and found what seems to be the heart of at least a
big chunk of this:

The topstack function returns a value that includes information it isn't
checking when it attempts its resolution to derive it.

Or more simply, topstack only checks short name, apparently using the
same load-order search path other stack-name-resolution methods rely on.

E.g.: if I have two stacks both named "foo" but saved to two different
files, no matter which one is on top "topstack()" will only return the
long name of the one opened first.

Since topstack includes the path, it would seem reasonable to expect
that the path would be checked as part of the resolution process, and
indeed useful if it were.

I included other notes related to this in my other post this morning:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232514.html

...along with the link to a new bug report for topstack:
http://quality.livecode.com/show_bug.cgi?id=18793

This won't handle all possible cases (caveats noted in report), but will
make the topstack function more reliable across a broader range of
circumstances, perhaps eliminating a majority of issues relating to
stack name conflicts.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

mwieder
In reply to this post by Mark Waddingham-2
Mark-

Those are (mostly) all good points.

But the problem that concerns me is not when I have done something stupid and end up with two stacks of the same name competing for memory space, but when the IDE suddenly pops up the warning message and I have no idea what has just happened. At that point I go to shutdown mode because the three options in the dialog are confusing and ambiguous (assuming a three-state ambiguity isn't a contradiction).

Using the long id to refer to stacks works (or at least should work) for all situations except for stacks that haven't yet been saved to disk. And for those stacks I would suggest storing the creation timestamp as a custom property on creating a new stack so that they can be distinguished. (but I also think the idea that a newly created stack gets the name "Untitled_1" needs revisiting).

I haven't yet had the chance to implement Richard's patch, but I'm looking forward to trying it out.
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
mwieder wrote:

 > Using the long id to refer to stacks works (or at least should work)
 > for all situations except for stacks that haven't yet been saved to
 > disk. And for those stacks I would suggest storing the creation
 > timestamp as a custom property on creating a new stack so that they
 > can be distinguished.

A UUID in the v9 file format could help a lot with those cases.

 > I haven't yet had the chance to implement Richard's patch, but I'm
 > looking forward to trying it out.

If/when you do, give this a whirl - in my initial tests it seems to work
well in delivering the true topstack even when the short name is the
same, accomplished by taking full advantage of the stack file path (just
added to BZ#18793 as inspiration how the engine might handle this even
better and certainly more efficiently):


function FixedTopStack
    put the stacks into tStackFiles
    put the openStacks into tStackNames
    put 0 into i
    repeat for each line tStackName in tStackNames
       add 1 to i
       put line i of tStackFiles into tStackFile
       if tStackFile is not empty then
          -- Mainstack?
          if the mainstack of stack tStackFile = tStackName then
             put "stack "& quote& tStackFile &quote into tStackRef
          else
             -- Substack:
             put "stack "&quote& tStackName &quote& " of stack "&quote  \
                   & tStackFile &quote into tStackRef
          end if
       else
          -- No stack filename:
          put "stack "& quote& tStackName &quote into tStackRef
       end if
       put the mode of tStackRef &tab& tStackRef &cr after tList
    end repeat
    delete last char of tList -- trailing CR
    set the itemdel to tab
    sort lines of tList numeric by item 1 of each
    put item 2 of line 1 of tList
    exit to top
    return item 2 of line 1 of tList
end FixedTopStack


If the topstack took the stack file path into account, most conflicts
would go away.

If the file format were extended so that stacks include a UUID property
at creation, that would provide distinction so complete that I'm unable
to think of a case where identifying the true topstack would fail.

For backward compatibility, topstack might first check the filename and
return that as it does now, e.g.:

   stack "/home/rg/something.livecode"

When the filename is empty, an enhanced topstack could return something
like

   stack uuid c5087287-7884-49a0-95e5-a4a3009221c2

This is similar to other cases where attempting to get the long name of
an object returns the long ID when the name is empty.

Since it only comes into play when stacks are unsaved, it would rarely
ever been seen.  And even then, topstack is commonly used in momentary
contexts so it would be rarely seen even then.

But would it would provide is a way of referring to all stacks that
would always work regardless of their short name and regardless if
they've ever been saved.

For now, just making sure topstack has checked the file path info it
delivers will by itself move things forward in a big way.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Monte Goulding-2

> On 8 Nov. 2016, at 6:24 am, Richard Gaskin <[hidden email]> wrote:
>
> > Using the long id to refer to stacks works (or at least should work)
> > for all situations except for stacks that haven't yet been saved to
> > disk. And for those stacks I would suggest storing the creation
> > timestamp as a custom property on creating a new stack so that they
> > can be distinguished.
>
> A UUID in the v9 file format could help a lot with those cases.


Ah… I knew we would get onto UUIDs ;-)

One thing to note is if objects have UUIDs then there’s no need to qualify the UUID with an object type and the engine should just work out if the object reference is a UUID then look up the corresponding object. In other words we don’t need `the <prop> of stack UUID <UUID>` we just need `the <prop> of <UUID>`.

For most of the issues this thread is discussing though I actually don’t think the main thing we need is UUIDs. We *think* we need UUIDs only because we are used to thinking of object references as strings. If we have an object reference (think `is strictly an object`) and we have versions of all APIs that return object references that can return these object references instead then we have something much better because it won’t need to be parsed from string -> object all the time.

Now if we have a UUID as a string representation of the object reference that’s fine and probably helpful. There’s obviously times where you need to do stuff that will turn the object reference into a string.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Stack name conflicts resolved?

Richard Gaskin
Monte Goulding wrote:

 > For most of the issues this thread is discussing though I actually
 > don’t think the main thing we need is UUIDs. We *think* we need UUIDs
 > only because we are used to thinking of object references as strings.
 > If we have an object reference (think `is strictly an object`) and we
 > have versions of all APIs that return object references that can
 > return these object references instead then we have something much
 > better because it won’t need to be parsed from string -> object all
 > the time.

I'd like that, and I agree, UUIDs are a longer-term consideration here.

For now many of our stack name conflicts could be resolved if topstack
used the path info it delivers to make sure it's returning the right
object reference.

http://quality.livecode.com/show_bug.cgi?id=18793

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12