Re: Name shadows another variable

[Peter Haworth]

On Fri, Jun 27, 2014 at 7:08 PM, Mark Wieder  wrote:

> If you at some time in the past turned on variable preservation and
> had a script variable of the same name you are now using for a handler
> variable, then that variable scope is still stored with the stack.
> Until you can compile the script with no errors, that conflict will
> still remain. In other words, the stack has stored a reference to the
> named variable with a wider scope than you are now giving it, and that
> reference won't be wiped out until a successful script compilation.
>

Hi Mark,
Having read your theory more closely, I had high hopes that we might
finally have a recipe to reproduce this problem so here's my experiment.

Strict Compile Mode = on
Preserve variables = on

Created a test stack
In the stack script, defined a scrip level variable foo
In a handler in the script, defined a handler level variable named foo.
Compiled - got name shadows variable error as expected.
Changed the name of the handler variable to foo2, compiled with no error.
Saved the stack, closed and removed from memory.

Opened the stack again.
Turned Preserve variables off
Deleted the script level variable foo
Changed the name of the handler level variable foo2 back to foo
Compiled - no errors

I had hoped the error would come up again in that last step but it didn't.

It's entirely possible I haven't understood your theory correctly so if
there's some other experiment I should be trying, let me know.  I;d really
like to track down this thing!

Thanks,
Pete

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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: Name shadows another variable

[Peter Haworth]

On Fri, Jun 27, 2014 at 7:08 PM, Mark Wieder  wrote:

> So... ensure that variable preservation is unchecked, change the name
> of the variable to something without a conflict, compile the script,
> and save the stack. I think that should clear up the problem for this
> stack. Since I never use variable preservation and always have strict
> compilation enabled I haven't run into this problem, and can't say for
> certain whether this will do the trick, but it makes sense to me that
> way. I also haven't looked to see where variables are being stored,
> and maybe someone else has a better sense of that.
>

Hi Mark,
Thanks for the idea.

I'm not sure I fully understand your explanation but I do have Variable
Preservation turned on.

It's unlikely there's a clash of variable names in a different scope since,
like most of us, I use a naming convention for global, script local, and
handler local variables.  Having said that, the stack in question is one
I've just started working on again after a long break and I may not have
been as "educated" about variable naming conventions when I last worked on
it :-)

I tried what you suggested. After changing the name of the variable in
question, the error went away for that instance of the variable  but the
same message came up for the same variable name in a different handler.  At
least it's consistent!

Following that, I just continued changing variable names until the error
stopped occurring - there were a couple of other variable names that were
used in multiple handlers - and now all seems to be OK again.  Not all
variable names that were declared in different handlers were flagged by the
way.


Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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: Name shadows another variable

[Jerry Jensen]

On Jun 27, 2014, at 7:08 PM, Mark Wieder  wrote:

> Pete-
> 
> Friday, June 27, 2014, 9:31:20 AM, you wrote:
> 
>> A full description is in my QCC report number 10511
> 
> Having now read the bug report (*very* interesting reading) my
> thinking is that this may well be connected to variable preservation
> rather than explicitVars, even if you don't currently have variable
> preservation turned on. Here's my current theory:

I have had trouble with this shadowing thing in the past, on more complicated 
projects than I'm working on now.
I just checked, for the first time in a long time, and found variable 
preservation ON. I always use explicitVars.
In the troubled times, I would often see the problem shortly after successful 
compiles, with the error seemingly unrelated to what I'm working on at the 
moment. Quit & Restart LC would make the trouble go away (and a successful 
compile) for a while.
This one is SLIPPERY.
I'll report if I see it again with variable preservation now off (for good).
I'm now using 6.6.2, the troubles were with older 6.?.? versions. OSX 10.8.x in 
troubled times, OSX 10.9.3 now.
.Jerry



___
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: Name shadows another variable

[Mark Wieder]

Pete-

Friday, June 27, 2014, 9:31:20 AM, you wrote:

> A full description is in my QCC report number 10511

Having now read the bug report (*very* interesting reading) my
thinking is that this may well be connected to variable preservation
rather than explicitVars, even if you don't currently have variable
preservation turned on. Here's my current theory:

If you at some time in the past turned on variable preservation and
had a script variable of the same name you are now using for a handler
variable, then that variable scope is still stored with the stack.
Until you can compile the script with no errors, that conflict will
still remain. In other words, the stack has stored a reference to the
named variable with a wider scope than you are now giving it, and that
reference won't be wiped out until a successful script compilation.

So... ensure that variable preservation is unchecked, change the name
of the variable to something without a conflict, compile the script,
and save the stack. I think that should clear up the problem for this
stack. Since I never use variable preservation and always have strict
compilation enabled I haven't run into this problem, and can't say for
certain whether this will do the trick, but it makes sense to me that
way. I also haven't looked to see where variables are being stored,
and maybe someone else has a better sense of that.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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: Name shadows another variable

[Peter Haworth]

Hi Craig,
The error message "name shadows another variable" is  shown as when strict
compile mode is on.  It's supposed to indicate that the name of a declared
variable has already been declared somewhere else in the script, perhaps
with another local statement in the same script/handler or in a global
declaration for the script.

Problem is that it is sometimes displayed when there is no clash of names
and the only way to get out of it (as far as I know) is to quite Livecode
and run again.

A full description is in my QCC report number 10511

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>


On Thu, Jun 26, 2014 at 4:54 PM,  wrote:

> Peter,
>
>
> Can you tell me more about what this error is and does?
>
>
> Craig
>
>
___
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: Name shadows another variable

[Alex Tweedly]

On 27/06/2014 06:43, Peter Haworth wrote:

Bottom line is, this shouldn't happen, there should be no need for any
workaround.

A recent thread talked about "paper cuts".  For me this is an open,
festering wound!



I absolutely agree. And it's been festering for a long time.

One annoying thing about it is that its long term survival confirms the 
suspicion that the RunRev development team don't routinely use 
explicitvariable checks (otherwise it would have bothered them enough to 
fix it by now). This failure to use a simple, easy safety mechanism 
makes me worry about how quality conscious their internal development 
processes are.


It should at least be possible to produce a "debug" version of the IDE 
which would provide additional info in a log file or similar whenever a  
"variable shadowing" error happens, in the hope that this additional 
info would help to track it down. It's been occurring regularly, but 
without being reproducible, for so long it might need an indirect 
approach to get to the bottom of it.


-- Alex.

___
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: Name shadows another variable

[Peter Haworth]

Hi Mike,
My workaround is to turn off strict compilation mode, compile and turn it
back on again but that's fraught with dangerous consequences if I forget to
switch it on again.

Bottom line is, this shouldn't happen, there should be no need for any
workaround.

A recent thread talked about "paper cuts".  For me this is an open,
festering wound!

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>


On Thu, Jun 26, 2014 at 6:08 PM, Mike Bonner  wrote:

> Not sure i'd know WHERE to do it, guess it depends on the script, but..
> could you use "delete variable..." to fix the problem without having to
> restart lc?  Of course this would probably require you to understand the
> source of the problem.  Another thing I wonder about is the variable
> preservation preference setting.  Wonder if you could pop the tick out of
> that, compile, then pop it back in.  Pain in the butt though.  There is a
> property (the preservervariables) also, that defaults to false I believe,
> but the recommendation in the dictionary is to not mess with that one.
>
>
> On Thu, Jun 26, 2014 at 5:54 PM,  wrote:
>
> > Peter,
> >
> >
> > Can you tell me more about what this error is and does?
> >
> >
> > Craig
> >
> >
> >
> > -Original Message-
> > From: Peter Haworth 
> > To: How to use LiveCode 
> > Sent: Thu, Jun 26, 2014 5:12 pm
> > Subject: Name shadows another variable
> >
> >
> > The above error has been flagged intermittently and incorrectly when
> > compiling a script with Strict Compilation Mode turned on for as long as
> > I've been using Livecode.
> >
> > In the last couple of days, the error has been flagged every time I
> compile
> > a script in one particular application.  I restart Livecode and all is
> OK -
> > same combination of stacks, no recompile necessary.
> >
> > As far as I know, that's the only way to get around the issue unless I
> > switch off Strict Compilation Mode which I am not willing to do.
> >
> > I know the bug has been entered at the QCC several times and I also know
> > that so far it has been impossible to provide a recipe to reproduce it. I
> > will add the stack exhibiting the problem to one of the error reports but
> > I've done that in the past and RunRev have been unable to reproduce it.
> >
> > I am practically at a standstill with development of this application
> until
> > this problem is fixed.
> >
> > It seems to me that someone at RunRev needs to take responsibility for
> > finding what causes this problem using old fashioned methods, like going
> > through the code, or reproduce it themselves.
> >
> > Pete
> > lcSQL Software <http://www.lcsql.com>
> > Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
> > SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
> > ___
> > 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
> >
> ___
> 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: Name shadows another variable

[Mike Bonner]

Not sure i'd know WHERE to do it, guess it depends on the script, but..
could you use "delete variable..." to fix the problem without having to
restart lc?  Of course this would probably require you to understand the
source of the problem.  Another thing I wonder about is the variable
preservation preference setting.  Wonder if you could pop the tick out of
that, compile, then pop it back in.  Pain in the butt though.  There is a
property (the preservervariables) also, that defaults to false I believe,
but the recommendation in the dictionary is to not mess with that one.


On Thu, Jun 26, 2014 at 5:54 PM,  wrote:

> Peter,
>
>
> Can you tell me more about what this error is and does?
>
>
> Craig
>
>
>
> -Original Message-
> From: Peter Haworth 
> To: How to use LiveCode 
> Sent: Thu, Jun 26, 2014 5:12 pm
> Subject: Name shadows another variable
>
>
> The above error has been flagged intermittently and incorrectly when
> compiling a script with Strict Compilation Mode turned on for as long as
> I've been using Livecode.
>
> In the last couple of days, the error has been flagged every time I compile
> a script in one particular application.  I restart Livecode and all is OK -
> same combination of stacks, no recompile necessary.
>
> As far as I know, that's the only way to get around the issue unless I
> switch off Strict Compilation Mode which I am not willing to do.
>
> I know the bug has been entered at the QCC several times and I also know
> that so far it has been impossible to provide a recipe to reproduce it. I
> will add the stack exhibiting the problem to one of the error reports but
> I've done that in the past and RunRev have been unable to reproduce it.
>
> I am practically at a standstill with development of this application until
> this problem is fixed.
>
> It seems to me that someone at RunRev needs to take responsibility for
> finding what causes this problem using old fashioned methods, like going
> through the code, or reproduce it themselves.
>
> Pete
> lcSQL Software <http://www.lcsql.com>
> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
> SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
> ___
> 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
>
___
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: Name shadows another variable

[dunbarx]

Peter,


Can you tell me more about what this error is and does?


Craig



-Original Message-
From: Peter Haworth 
To: How to use LiveCode 
Sent: Thu, Jun 26, 2014 5:12 pm
Subject: Name shadows another variable


The above error has been flagged intermittently and incorrectly when
compiling a script with Strict Compilation Mode turned on for as long as
I've been using Livecode.

In the last couple of days, the error has been flagged every time I compile
a script in one particular application.  I restart Livecode and all is OK -
same combination of stacks, no recompile necessary.

As far as I know, that's the only way to get around the issue unless I
switch off Strict Compilation Mode which I am not willing to do.

I know the bug has been entered at the QCC several times and I also know
that so far it has been impossible to provide a recipe to reproduce it. I
will add the stack exhibiting the problem to one of the error reports but
I've done that in the past and RunRev have been unable to reproduce it.

I am practically at a standstill with development of this application until
this problem is fixed.

It seems to me that someone at RunRev needs to take responsibility for
finding what causes this problem using old fashioned methods, like going
through the code, or reproduce it themselves.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
___
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

Name shadows another variable

[Peter Haworth]

The above error has been flagged intermittently and incorrectly when
compiling a script with Strict Compilation Mode turned on for as long as
I've been using Livecode.

In the last couple of days, the error has been flagged every time I compile
a script in one particular application.  I restart Livecode and all is OK -
same combination of stacks, no recompile necessary.

As far as I know, that's the only way to get around the issue unless I
switch off Strict Compilation Mode which I am not willing to do.

I know the bug has been entered at the QCC several times and I also know
that so far it has been impossible to provide a recipe to reproduce it. I
will add the stack exhibiting the problem to one of the error reports but
I've done that in the past and RunRev have been unable to reproduce it.

I am practically at a standstill with development of this application until
this problem is fixed.

It seems to me that someone at RunRev needs to take responsibility for
finding what causes this problem using old fashioned methods, like going
through the code, or reproduce it themselves.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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