Standalone build workaround

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

Standalone build workaround

Stephen MacLean via use-livecode
The standalone builder no longer locks messages; the docs say this:

"As an attempt to improve this situation, the code that locks messages
when closing and opening stacks for standalone builds has been removed.
This means that where previously mainstacks would not receive openStack
and closeStack messages during standalone build, they now do."

First off, is this true only for openstack and closestack, or for all
open*/close* messages, such as opencard, openbackground, etc.?

Secondly, if the suggested workaround is placed into an openStack handler:

on openstack
   if the environment is "development" and the mode of stack
"revStandaloneProgress" > 0 then
     exit openStack
   end if
end openstack

The IDE throws an error: can't find stack

Suggestions? I'm trying to help someone debug this problem, as the stack
has an openStack handler that needs to run. If the issue only applies to
openStack messages, then we can change the handler to openCard instead.
If the problem is for all open* messages then we need another solution.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.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: Standalone build workaround

Stephen MacLean via use-livecode
Hello Jacque,

The Standalone Builder closes and opens the stack when building a
standalone, so this means that all the messages that are sent when closing
and opening the stack will be sent. So yes, all the (pre)open*/close*
messages are expected to be sent.

The "if" block should change to:

 if the environment is "development" AND there is a stack
"revStandaloneProgress" AND the mode of stack
"revStandaloneProgress" > 0 then
     exit handlerName
   end if


as when you open the stack for the first time (without having built a
standalone before), the stack "revStandaloneProgress" is not loaded yet
(thus the "can't find stack error).

So you could write a function:

function isBuildingStandalone
   return the environment is "development" AND \
         there is a stack "revStandaloneProgress" AND \
            the mode of stack "revStandaloneProgress" > 0
end isBuildingStandalone

and then in e.g. the openstack handler:

on openstack
   if isBuildingStandalone() then
      exit openstack
   end if
   ..
   ..
end openstack

Similar in all other (pre)open*/close* messages.

Kind regards,
Panos
--

On Wed, Sep 19, 2018 at 9:31 AM J. Landman Gay via use-livecode <
[hidden email]> wrote:

> The standalone builder no longer locks messages; the docs say this:
>
> "As an attempt to improve this situation, the code that locks messages
> when closing and opening stacks for standalone builds has been removed.
> This means that where previously mainstacks would not receive openStack
> and closeStack messages during standalone build, they now do."
>
> First off, is this true only for openstack and closestack, or for all
> open*/close* messages, such as opencard, openbackground, etc.?
>
> Secondly, if the suggested workaround is placed into an openStack handler:
>
> on openstack
>    if the environment is "development" and the mode of stack
> "revStandaloneProgress" > 0 then
>      exit openStack
>    end if
> end openstack
>
> The IDE throws an error: can't find stack
>
> Suggestions? I'm trying to help someone debug this problem, as the stack
> has an openStack handler that needs to run. If the issue only applies to
> openStack messages, then we can change the handler to openCard instead.
> If the problem is for all open* messages then we need another solution.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.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
>
_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode
On Tue, Sep 18, 2018 at 11:31 PM J. Landman Gay via use-livecode <
[hidden email]> wrote:

> The standalone builder no longer locks messages; the docs say this:
>
> "As an attempt to improve this situation, the code that locks messages
> when closing and opening stacks for standalone builds has been removed.
> This means that where previously mainstacks would not receive openStack
> and closeStack messages during standalone build, they now do."
>

Where in the docs does it say this (or what is the "situation" the code is
trying to improve)?
_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
On 9/19/18 1:05 PM, Geoff Canyon via use-livecode wrote:

> On Tue, Sep 18, 2018 at 11:31 PM J. Landman Gay via use-livecode <
> [hidden email]> wrote:
>
>> The standalone builder no longer locks messages; the docs say this:
>>
>> "As an attempt to improve this situation, the code that locks messages
>> when closing and opening stacks for standalone builds has been removed.
>> This means that where previously mainstacks would not receive openStack
>> and closeStack messages during standalone build, they now do."
>>
>
> Where in the docs does it say this (or what is the "situation" the code is
> trying to improve)?

The Release Notes, page 3. The situation it tries to fix:

"The standalone builder has always needed to close the stacks it builds
for reasons pretty deeply ingrained in the code. However this causes a
few problems, for example:
values in script locals become empty
behaviors are broken when the parent script is on / in a stack which closes"

I'm finding that the workaround is more trouble than the initial issues.
The stack I'm helping with has multiple open* and close* handlers, and
they all need to be updated.

I'd like a toggle somewhere so we can choose whether to use the new
build behavior. Backward compatibility is broken now. His build was
throwing dozens of errors and always failed, and he was ready to drop LC
entirely after a week trying to fix it himself.

Not everyone reads this list or the release notes, and even if he had,
the release notes are wrong.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.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: Standalone build workaround

Stephen MacLean via use-livecode
J. Landman Gay wrote:

>> On Tue, Sep 18, 2018 at 11:31 PM J. Landman Gay via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>
>>> The standalone builder no longer locks messages; the docs say this:
>>>
>>> "As an attempt to improve this situation, the code that locks messages
>>> when closing and opening stacks for standalone builds has been removed.
>>> This means that where previously mainstacks would not receive openStack
>>> and closeStack messages during standalone build, they now do."
>>>
>>
>> Where in the docs does it say this (or what is the "situation" the code is
>> trying to improve)?
>
> The Release Notes, page 3. The situation it tries to fix:
>
> "The standalone builder has always needed to close the stacks it builds
> for reasons pretty deeply ingrained in the code. However this causes a
> few problems, for example:
> values in script locals become empty
> behaviors are broken when the parent script is on / in a stack which closes"
>
> I'm finding that the workaround is more trouble than the initial issues.
> The stack I'm helping with has multiple open* and close* handlers, and
> they all need to be updated.

^ this

Building a standalone is the whole point of the process of developing
with LC, and now that it's so disruptive it kills the joy of choosing
LiveCode.

For more than a decade I've believed making the SB into a separate
process would be a good idea.

It's no longer a good idea.  It's now a necessity.

--
  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: Standalone build workaround

Stephen MacLean via use-livecode

Jacqueline:

 > I'm finding that the workaround is more trouble than the
 > initial issues.

Amen. This kind of workaround, I could understand if we were doing it
ourselves; although I would hope for it to be a little more elegant even
then.

But as an official workaround that comes with the product - it doesn't
work. This, and the approach that led to this, needs to be rethought.

Richard:

 > so disruptive it kills the joy of choosing LiveCode.

Yep, LC/RR started out designing the IDE (if memory serves, I do vaguely
and fondly remember the days of v1, not to mention 273) and as important
as the engine is, it's good never to forget your roots. This is the face
of LiveCode that everyone sees and experiences.
Seeing/touching/interacting really is very necessary to the user, as
important as it ever was. :)

(BTW I hasten to add, not needing another total makeover, just giving
appropriate attention to high IDE quality. Sometimes that involves
changes, other times maybe thinking twice about changes - looking before
leaping is an old but excellent philosophy. Changes don't always have to
be big. Hone is a good word for a tool.)

 > For more than a decade I've believed making the SB into a
 > separate process would be a good idea.
 > It's no longer a good idea.  It's now a necessity.

Indeed a good idea - another perhaps easy option (if it works) might be
to close the stack completely during the build, and open it again when
completely finished, or let us do so. We don't really need to see the
stack sitting there in the IDE during the build, it doesn't accomplish
anything. Either way, the current solution is not viable.

PS - one person who mentioned this issue to me a few days ago could have
had a quick fix for his project, but may have talked himself out of it.
I'm always here if needed - to talk yes, but more especially to fix. ;)

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode


> On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Building a standalone is the whole point of the process of developing with LC, and now that it's so disruptive it kills the joy of choosing LiveCode.
>
> For more than a decade I've believed making the SB into a separate process would be a good idea.
>
> It's no longer a good idea.  It's now a necessity.

Unfortunately we are caught between leaving the stack in a state where any local variables that are meant to be initialised are unset or letting the engine do its thing when the stack reopens and send messages that allow those initialisations to occur. The latter, while a big change, was considered the lesser of two evils because at least it allows you to code around the situation rather than just ending up with a stack in a state where you need to quit and restart the IDE.

Ideally, yes, standalone building (at least the parts that manipulate the open stacks causing them to need to be reverted) would be a separate process.

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: Standalone build workaround

Stephen MacLean via use-livecode
I am very late to this conversation, but does this mean that a very naive user, devising a simple app that is going to end up as a standalone, will suddenly be plunged into weird unguided coding issues just because the code contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’ handler (I use those a lot myself)? If this is true, then I agree with Richard that LiveCode has suddenly got a loss less attractive in its central function - the creation of software that runs on the developer’s chosen platform(s). Just tell me I’m wrong.

Graham

> On 20 Sep 2018, at 00:47, Monte Goulding via use-livecode <[hidden email]> wrote:
>
>
>
>> On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode <[hidden email]> wrote:
>>
>> Building a standalone is the whole point of the process of developing with LC, and now that it's so disruptive it kills the joy of choosing LiveCode.
>>
>> For more than a decade I've believed making the SB into a separate process would be a good idea.
>>
>> It's no longer a good idea.  It's now a necessity.
>
> Unfortunately we are caught between leaving the stack in a state where any local variables that are meant to be initialised are unset or letting the engine do its thing when the stack reopens and send messages that allow those initialisations to occur. The latter, while a big change, was considered the lesser of two evils because at least it allows you to code around the situation rather than just ending up with a stack in a state where you need to quit and restart the IDE.
>
> Ideally, yes, standalone building (at least the parts that manipulate the open stacks causing them to need to be reverted) would be a separate process.
>
> 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


_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode
Oh THIS is the issue I was having where I launch a modal stack to ask for a password when I open my mainstack! Jacques informed me I can shift-ctrl-cmd right-click the stack and set the style to topLevel and the compiler would proceed as normal, but Panagiotis solution looks better. I will implement that instead.

Bob S


> On Sep 18, 2018, at 23:31 , J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> The standalone builder no longer locks messages; the docs say this:
>
> "As an attempt to improve this situation, the code that locks messages when closing and opening stacks for standalone builds has been removed. This means that where previously mainstacks would not receive openStack and closeStack messages during standalone build, they now do."
>
> First off, is this true only for openstack and closestack, or for all open*/close* messages, such as opencard, openbackground, etc.?
>
> Secondly, if the suggested workaround is placed into an openStack handler:
>
> on openstack
>  if the environment is "development" and the mode of stack "revStandaloneProgress" > 0 then
>    exit openStack
>  end if
> end openstack
>
> The IDE throws an error: can't find stack
>
> Suggestions? I'm trying to help someone debug this problem, as the stack has an openStack handler that needs to run. If the issue only applies to openStack messages, then we can change the handler to openCard instead. If the problem is for all open* messages then we need another solution.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.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


_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode
Read my post, but yes if your handlers do something that can potentially interfere with the standalone builder running (like opening a stack modally) then things can get wiggy. You cannot simply suspend messages before building (as I understand it) because the standalone builder needs to send messages itself.

Bob S


> On Sep 19, 2018, at 16:20 , Graham Samuel via use-livecode <[hidden email]> wrote:
>
> I am very late to this conversation, but does this mean that a very naive user, devising a simple app that is going to end up as a standalone, will suddenly be plunged into weird unguided coding issues just because the code contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’ handler (I use those a lot myself)? If this is true, then I agree with Richard that LiveCode has suddenly got a loss less attractive in its central function - the creation of software that runs on the developer’s chosen platform(s). Just tell me I’m wrong.
>
> Graham

_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode
That's what happened to the person I'm helping. He's not a sophisticated
coder and needed someone else to write a basic openstack handler a few
years ago. He's been tinkering with the stack now and then and building new
apps occasionally as it changed. He called me, very distressed, and was
ready to throw out LC entirely. He'd been trying for a week to build the
app and was getting infinite repeated error dialogs that couldn't be
dismissed. The error dialog was empty so there was no clue what was wrong
and clicking the Script button did nothing.

He had contacted support but couldn't afford the rate they wanted to debug
the problem. He had no idea why the build suddenly failed all of a sudden.
He's a paying Indie customer and LC would have lost him.

So yeah, there's repercussions. I do understand the choice the team had to
make, but most of us were used to the old way and had already accommodated.

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On September 19, 2018 6:22:05 PM Graham Samuel via use-livecode
<[hidden email]> wrote:

> I am very late to this conversation, but does this mean that a very naive
> user, devising a simple app that is going to end up as a standalone, will
> suddenly be plunged into weird unguided coding issues just because the code
> contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’
> handler (I use those a lot myself)? If this is true, then I agree with
> Richard that LiveCode has suddenly got a loss less attractive in its
> central function - the creation of software that runs on the developer’s
> chosen platform(s). Just tell me I’m wrong.
>
> Graham
>
>> On 20 Sep 2018, at 00:47, Monte Goulding via use-livecode
>> <[hidden email]> wrote:
>>
>>
>>
>>> On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode
>>> <[hidden email]> wrote:
>>>
>>> Building a standalone is the whole point of the process of developing with
>>> LC, and now that it's so disruptive it kills the joy of choosing LiveCode.
>>>
>>> For more than a decade I've believed making the SB into a separate process
>>> would be a good idea.
>>>
>>> It's no longer a good idea.  It's now a necessity.
>>
>> Unfortunately we are caught between leaving the stack in a state where any
>> local variables that are meant to be initialised are unset or letting the
>> engine do its thing when the stack reopens and send messages that allow
>> those initialisations to occur. The latter, while a big change, was
>> considered the lesser of two evils because at least it allows you to code
>> around the situation rather than just ending up with a stack in a state
>> where you need to quit and restart the IDE.
>>
>> Ideally, yes, standalone building (at least the parts that manipulate the
>> open stacks causing them to need to be reverted) would be a separate process.
>>
>> 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
>
>
> _______________________________________________
> 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




_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode

Jacqueline:

 > So yeah, there's repercussions. I do understand the choice the
 > team had to make, but most of us were used to the old way and
 > had already accommodated.

I would go further. I would say that change is not always value-free;
it's not simply a question of what people are accustomed too. (Although
that can be important too.)

But no, I would say that objectively there is such a thing as a bad
change, a wrong choice, and this is a good example. The side effects of
the cure seem to be worse than the original problem. We could probably
find a way to measure and compare before/after in terms of user efforts
and user problems.

This issue doesn't affect me much personally because of my own coding
habits, thank goodness, but it is an excellent example of how solving a
problem the wrong way can lead to bigger problems. Interesting....

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode
I do understand the dilemma and I can adapt. But to be fair, an
uninitialized variable doesn't require a restart of the IDE. It's possible
to script around that too, it's usually a one-liner, and doesn't have to be
inserted in as many places.

But what mainly concerned me was how it affected someone who couldn't
explain the change and the inexplicable cascade of errors, and was
frustrated enough to leave the platform behind.

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On September 19, 2018 5:49:20 PM Monte Goulding via use-livecode
<[hidden email]> wrote:

>> On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode
>> <[hidden email]> wrote:
>>
>> Building a standalone is the whole point of the process of developing with
>> LC, and now that it's so disruptive it kills the joy of choosing LiveCode.
>>
>> For more than a decade I've believed making the SB into a separate process
>> would be a good idea.
>>
>> It's no longer a good idea.  It's now a necessity.
>
> Unfortunately we are caught between leaving the stack in a state where any
> local variables that are meant to be initialised are unset or letting the
> engine do its thing when the stack reopens and send messages that allow
> those initialisations to occur. The latter, while a big change, was
> considered the lesser of two evils because at least it allows you to code
> around the situation rather than just ending up with a stack in a state
> where you need to quit and restart the IDE.
>
> Ideally, yes, standalone building (at least the parts that manipulate the
> open stacks causing them to need to be reverted) would be a separate process.
>
> 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




_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
What about a front script for the build process that would intercept and discard these messages? Could be inserted just before each action that used to be protected by lock messages (close/open stack).

Thanks,
Brian
On Sep 19, 2018, 11:41 PM -0500, J. Landman Gay via use-livecode <[hidden email]>, wrote:

> I do understand the dilemma and I can adapt. But to be fair, an
> uninitialized variable doesn't require a restart of the IDE. It's possible
> to script around that too, it's usually a one-liner, and doesn't have to be
> inserted in as many places.
>
> But what mainly concerned me was how it affected someone who couldn't
> explain the change and the inexplicable cascade of errors, and was
> frustrated enough to leave the platform behind.
>
> --
> Jacqueline Landman Gay | [hidden email]
> HyperActive Software | http://www.hyperactivesw.com
> On September 19, 2018 5:49:20 PM Monte Goulding via use-livecode
> <[hidden email]> wrote:
>
> > > On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode
> > > <[hidden email]> wrote:
> > >
> > > Building a standalone is the whole point of the process of developing with
> > > LC, and now that it's so disruptive it kills the joy of choosing LiveCode.
> > >
> > > For more than a decade I've believed making the SB into a separate process
> > > would be a good idea.
> > >
> > > It's no longer a good idea. It's now a necessity.
> >
> > Unfortunately we are caught between leaving the stack in a state where any
> > local variables that are meant to be initialised are unset or letting the
> > engine do its thing when the stack reopens and send messages that allow
> > those initialisations to occur. The latter, while a big change, was
> > considered the lesser of two evils because at least it allows you to code
> > around the situation rather than just ending up with a stack in a state
> > where you need to quit and restart the IDE.
> >
> > Ideally, yes, standalone building (at least the parts that manipulate the
> > open stacks causing them to need to be reverted) would be a separate process.
> >
> > 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
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode

Brian:

 > What about a front script for the build process that would
 > intercept and discard these messages?

There you go! That might be a smooth solution. Or close the stack during
build, and offer a user preference of whether to automatically reopen.

Usually there are some fairly good solutions possible, better than
doubling-down on a dilemma and the lesser of two evils. This could turn
out rather nicely. :)

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.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: Standalone build workaround

Stephen MacLean via use-livecode
Just out of interest, what sorts of things are causing problems in
openStack while building a standalone that do not happen when opening
stacks for the first time in the IDE? To put it another way, is it simply
the re-running of openStack that is causing problems, or is something going
wrong? Something like a ‘cascade of errors’ sounds like the latter.

On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode <
[hidden email]> wrote:

>
> Brian:
>
>  > What about a front script for the build process that would
>  > intercept and discard these messages?
>
> There you go! That might be a smooth solution. Or close the stack during
> build, and offer a user preference of whether to automatically reopen.
>
> Usually there are some fairly good solutions possible, better than
> doubling-down on a dilemma and the lesser of two evils. This could turn
> out rather nicely. :)
>
> Best wishes,
>
> Curry Kenworthy
>
> Custom Software Development
> LiveCode Training and Consulting
> http://livecodeconsulting.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
>
_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
When I build a standalone, I use a splash stack, which when run in a standalone opens the mainStack. I do not typically have the mainstack already open, because as has been mentioned multiple times, any stacks already open after a build, say when building for a separate platform (I still cannot build for multiple platforms in one pass like I used to) will pop up stack already open dialogs and ask me to ignore or purge (no uninitiated user wants to "purge" any of his stacks it's quite unnerving the first time you see it).

So I always QUIT LC, and relaunch to avoid any stack already open errors. What I think is happening is that the copys of the stacks in the standalone are being left open, so subsequent opening of the stacks produces this error. Otherwise, subsequent opening of the stacks are opening the standalone versions instead of the originals because LC gets confused about stack name references.

That's just me blind guessing though.

Bob S


> On Sep 20, 2018, at 04:40 , Ali Lloyd via use-livecode <[hidden email]> wrote:
>
> Just out of interest, what sorts of things are causing problems in
> openStack while building a standalone that do not happen when opening
> stacks for the first time in the IDE? To put it another way, is it simply
> the re-running of openStack that is causing problems, or is something going
> wrong? Something like a ‘cascade of errors’ sounds like the latter.
>
> On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode <
> [hidden email]> wrote:
>
>>
>> Brian:
>>
>>> What about a front script for the build process that would
>>> intercept and discard these messages?
>>
>> There you go! That might be a smooth solution. Or close the stack during
>> build, and offer a user preference of whether to automatically reopen.
>>
>> Usually there are some fairly good solutions possible, better than
>> doubling-down on a dilemma and the lesser of two evils. This could turn
>> out rather nicely. :)
>>
>> Best wishes,
>>
>> Curry Kenworthy
>>
>> Custom Software Development
>> LiveCode Training and Consulting
>> http://livecodeconsulting.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
>>
> _______________________________________________
> 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

_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
And the engine itself can support multiple stacks open with the same name.
If you do though, you have to use the long name to be sure you access the
correct one and the IDE isn't built to always do that.  (I've created a
demo that validates that the engine can handle this.  The engine does
prevent opening different files with the same stack name though, so I had
to clone and then save the clones with different file names but the same
stack name.)

For what Bob mentions, it sounds like the stand alone builder isn't keeping
track of all the stacks that get opened so that it can set destroyStack to
true and close them.  Possibly could be as easy as getting a list of open
stacks at the end and if the long name of any happens to be in the temp
location, then close them before reopening the stack for use in the IDE
post-build.

Brian

On Thu, Sep 20, 2018 at 9:37 AM Bob Sneidar via use-livecode <
[hidden email]> wrote:

> When I build a standalone, I use a splash stack, which when run in a
> standalone opens the mainStack. I do not typically have the mainstack
> already open, because as has been mentioned multiple times, any stacks
> already open after a build, say when building for a separate platform (I
> still cannot build for multiple platforms in one pass like I used to) will
> pop up stack already open dialogs and ask me to ignore or purge (no
> uninitiated user wants to "purge" any of his stacks it's quite unnerving
> the first time you see it).
>
> So I always QUIT LC, and relaunch to avoid any stack already open errors.
> What I think is happening is that the copys of the stacks in the standalone
> are being left open, so subsequent opening of the stacks produces this
> error. Otherwise, subsequent opening of the stacks are opening the
> standalone versions instead of the originals because LC gets confused about
> stack name references.
>
> That's just me blind guessing though.
>
> Bob S
>
>
> > On Sep 20, 2018, at 04:40 , Ali Lloyd via use-livecode <
> [hidden email]> wrote:
> >
> > Just out of interest, what sorts of things are causing problems in
> > openStack while building a standalone that do not happen when opening
> > stacks for the first time in the IDE? To put it another way, is it simply
> > the re-running of openStack that is causing problems, or is something
> going
> > wrong? Something like a ‘cascade of errors’ sounds like the latter.
> >
> > On Thu, 20 Sep 2018 at 06:11, Curry Kenworthy via use-livecode <
> > [hidden email]> wrote:
> >
> >>
> >> Brian:
> >>
> >>> What about a front script for the build process that would
> >>> intercept and discard these messages?
> >>
> >> There you go! That might be a smooth solution. Or close the stack during
> >> build, and offer a user preference of whether to automatically reopen.
> >>
> >> Usually there are some fairly good solutions possible, better than
> >> doubling-down on a dilemma and the lesser of two evils. This could turn
> >> out rather nicely. :)
> >>
> >> Best wishes,
> >>
> >> Curry Kenworthy
> >>
> >> Custom Software Development
> >> LiveCode Training and Consulting
> >> http://livecodeconsulting.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
> >>
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
_______________________________________________
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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode
Maybe it's a little of both. I was helping out over screen sharing and
only saw the openstack handler. The app uses a splash-screen model and
we did get the conflict Bob described, where the stack the app opens
threw a large number of repeated warnings about same-named stack
conflicts. It took several dismissals to get rid of them. I don't know
what handlers are in the separate mainstack but he said he fixed "all of
them" that had open* and close* handlers. This was before we had a check
to see if the revStandaloneProgress stack existed.

Also during builds, a blank script error dialog appeared. It was
unresponsive and empty so we don't know what it was trying to report. A
stream of other error messages popped in and out of existence so fast we
couldn't read them, so they weren't modal but their content is unknown.

All this happened in LC 9 so I had him move back to LC 8. I told him to
remove the content stack from memory and from inclusions and try
building only the splash app, and that worked, so the problem points to
the content stack. When he added it back into the Stacks pane in
Standalone Settings the "can't find stack" error happened because the
incorrect workaround handler was still in place. I've sent him the
updated handler Panos posted and haven't heard back yet, but that should
fix it.

The release notes need updating so we have a record of the correct
workaround.

Like I said, it isn't the adaptation we need to do that bothers me as
much as the idea that a lot of people won't know what's happening and
will blame LC. That's what this person did. He had a bit of a rant about
how LC didn't test enough and are producing shoddy software. I spent
some time explaining what the real issue was and he then understood. But
I'm concerned about other customers out there.

On 9/20/18 6:40 AM, Ali Lloyd via use-livecode wrote:
> Just out of interest, what sorts of things are causing problems in
> openStack while building a standalone that do not happen when opening
> stacks for the first time in the IDE? To put it another way, is it simply
> the re-running of openStack that is causing problems, or is something going
> wrong? Something like a ‘cascade of errors’ sounds like the latter.


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.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: Standalone build workaround

Stephen MacLean via use-livecode
In reply to this post by Stephen MacLean via use-livecode


> On 20 Sep 2018, at 2:51 pm, Brian Milby via use-livecode <[hidden email]> wrote:
>
> What about a front script for the build process that would intercept and discard these messages? Could be inserted just before each action that used to be protected by lock messages (close/open stack).

I think if that solution could work then lock messages could work. The issue is some components actually need those open messages to function correctly. We are working on a complete replacement to the standalone builder scripts which will resolve this kind of issue but it will still be a some time before they can become part of the IDE.

I’ve proposed a stop gap solution internally which I think would work well but will probably need to wait until Ali is back next week before we can throw it around. The idea is to not move the entire standalone build to a separate process (we will likely do that when we move to our complete replacement) but to just move the bits that modify the stackfiles (copy resources, set passwords etc). So we would have a command line app that took the path to the stackfiles on disk and all the settings, modified the stackfiles and saved them somewhere else. Then the IDE can continue on and can do the whole process without closing the stack at all.

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