Re: Stack name conflicts resolved?

[Richard Gaskin]

I made no reference to stack ID; I'm familiar with its role as a 
container for the ID incrementer.


The short name of a stack is not the only distinguishing attribute.  Its 
file path is also available.


Indeed, topstack returns the path as a part of the stack reference, but 
apparently does not check the path when resolving that reference.


I wrote an example function showing how this can be handled in script 
using information we have available today, included in Comment 1 in the 
bug report I filed on this:

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

Of course the engine could do that far more efficiently, and indeed it 
would require fixing this in the engine because LiveCode doesn't provide 
a means of overriding built-in functions.


Once fixed, we'll be able to open up old copies of our stacks to check 
or copy things, or open up another project that happens to have a stack 
named something common like "About" which we may have in the one we're 
working on, or any number of other cases which have given rise to 
discussions of workarounds here.  Many such workflows would become as 
graceful as the language itself.


SuperCard had no such limitation, and IIRC neither did OMO, Gain 
Momentum, Tookbook, or even HyperCard.


Indeed, the LiveCode engine itself has no such prohibition:  it allows 
opening stacks with the same name, and any references using a stack's 
short name are resolved using a simple and predictable rule:


The stack containing the script is checked first, and if not found it 
checks stacks in the order they were loaded during the current session.


The only limitation with this is what Ben pointed me to, problems 
copying and pasting objects or other actions dependent on topstack or 
other things related to the stack reference resolution topstack relies 
on, like default stack.


Topstack is normally the stack with the highest layer of the lowest mode.

But in the current engine resolution, when given a short name it appears 
to use load order only, without taking into account window layer.


Since two different stack files will have different paths (as Mark 
Waddingham reminded us, file systems enforce that very consistently for 
us), most issues with working on multiple stacks with the same value in 
the name property go away once the stack resolution uses available path 
information to return a more accurate value.



Given the long history of the IDE and engine development, I can 
understand how we got where we are.  The IDE has been owned by LiveCode 
Ltd. far longer than the engine, and back then prohibiting stacks from 
have the same name value was by far the simpler option. And once that 
was in place, it was no longer possible to explore the issue further, so 
it's remained that way so long we've all just come to accept that it's 
just how things are.


But once I experimented with disabling the IDE block, I was at last able 
to explore the engine behaviors in isolation.  They're generally pretty 
good, in almost all respects as flexible as what SuperCard provides, 
with the sole exception of an incomplete algorithm used for internal 
resolution of the stack reference.


And since that can be done in script, it would seem reasonable to at 
least suggest looking into how this might be refined in the engine.


--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:


As he said, the stack ID is not really it's ID. In other words LC does not use the stack 
ID to identify it. Think of the stack ID as "the next ID to be assigned to a new 
object" much like SQL maintains a value in a master table of some sort with the next 
unique ID for each unique numerical column.

So unlike any other object whose unique-ness can be determined by it's ID, a 
stack can only be differentiated by it's name.

Bob S



On Nov 5, 2016, at 11: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.

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 

Re: Stack name conflicts resolved?

[Bob Sneidar]

As he said, the stack ID is not really it's ID. In other words LC does not use 
the stack ID to identify it. Think of the stack ID as "the next ID to be 
assigned to a new object" much like SQL maintains a value in a master table of 
some sort with the next unique ID for each unique numerical column. 

So unlike any other object whose unique-ness can be determined by it's ID, a 
stack can only be differentiated by it's name. 

Bob S


> On Nov 5, 2016, at 11: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.
> 
> 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
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Monte Goulding]

> On 8 Nov. 2016, at 6:24 am, Richard Gaskin  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  of stack UUID ` we just need `the  of 
`.

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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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  into tStackRef
 else
-- Substack:
put "stack "& tStackName & " of stack "  \
  & tStackFile  into tStackRef
 end if
  else
 -- No stack filename:
 put "stack "& quote& tStackName  into tStackRef
  end if
  put the mode of tStackRef & tStackRef  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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[mwieder]

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
 ahsoftw...@gmail.com
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Stack-name-conflicts-resolved-tp4710098p4710173.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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  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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Mark Waddingham]

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  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 ' 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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Monte Goulding]

> On 7 Nov. 2016, at 3:57 am, Mark Wieder  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Mark Wieder]

On 11/05/2016 09:38 PM, Monte Goulding wrote:



On 6 Nov. 2016, at 1:31 pm, Mark Wieder  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
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Monte Goulding]

> On 6 Nov. 2016, at 1:31 pm, Mark Wieder  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Mark Wieder]

On 11/05/2016 03:02 PM, 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.


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
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Monte Goulding]

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  wrote:
> 
> I imagine for good reason, but I'm curious: where does topstack not do what 
> an IDE needs?


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[Monte Goulding]

> 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.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stack name conflicts resolved?

[stephen barncard]

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...

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

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode