Re: Help: Does anyone use legacy message box behavior?

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

>> On 8 Feb 2017, at 11:02 am, Richard Gaskin wrote:
>>
>> Monte Goulding wrote:
>> > ...You might think we don’t need to touch it but it has
>> > been touched recently because of a change in the way we
>> > retain object references.
>>
>> Now I'm curious: anything interesting there in terms of features,
> performance, or memory handling?
>
> The main advantage is stability.

That's a feature.  And a good one.  In my community meeting with Peter 
last week he outlined some of the effort going into v9 stability 
improvements, and I was quite impressed.


> You might remember that in one of the early 8 releases (not sure
> which one as it was just before I started) the memory management
> of objects changed so they would be released sooner if deleted
> within tight script loops instead of waiting for the next main
> loop to released them. It was a response to a bug where creating
> and deleting lots of objects in a loop bloated memory use I believe.
> Well deleting them earlier resulted in *lots* of instability where
> there were references to objects (say the internal defaultStack
> global for example) but the object had been deleted. Things like
> scripts still executing on objects that are meant to be deleted
> or setting the defaultStack to a stack that has just been deleted.
> Anyway in order to make it easier for us to resolve these issues
> Fraser wrote a class to use as an object handle whenever we want
> to keep a reference to an object. So now we can do stuff like
> t_stack.IsValid() before doing something with t_stack.
>
> For example one crash that I just fixed is this one: 
https://github.com/livecode/livecode/pull/5143 


>
> In that crash we were getting the stack of an object when it is being
> sent a message then using it later but the particular crashing code
> was deleting the stack the target object was on in a frontScript
> which was executed between getting the reference to the stack and
> using it. So the change now uses an object handle so we can check
> it’s still valid before sending the message after the frontScripts
> are executed ;-)

Sounds like a very good change.  Thanks for that background.  Even 
though I almost never write in C anymore, that under-the-hood stuff is 
very helpful for understanding how the engine works.




>> Thanks for running this by the community.
>
> It’s worth remembering that almost all of what we do is run by the
> community because everyone is free to subscrib to our github feed
> and comment on our PRs.

An excellent reminder.  The Github tools have made the process 
wonderfully visible.


--
 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: Help: Does anyone use legacy message box behavior?

[Monte Goulding via use-livecode]

> On 8 Feb 2017, at 11:02 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Monte Goulding wrote:
> 
> >> On 8 Feb 2017, at 3:04 am, Richard Gaskin wrote:
> >>
> >> My Message Box replacement sets the revMessageBox redirect to empty
> >> when it closes, and after doing so the LC IDE Message Box resumes
> >> normal behavior.
> >
> > Yes it does use it but it also (at least the single line msg box)
> > happens to conform to the old spec too (stack is named “Message
> > Box”). Also it sets it when loading the message box so that might
> > be fixing it for you.
> >>
> >> Is it necessary to remove the old behavior?
> >
> > Not overly so, however, every line removed is something we don’t
> > need to waste time maintaining. You might think we don’t need to
> > touch it but it has been touched recently because of a change in
> > the way we retain object references.
> 
> Now I'm curious: anything interesting there in terms of features, 
> performance, or memory handling?

The main advantage is stability. You might remember that in one of the early 8 
releases (not sure which one as it was just before I started) the memory 
management of objects changed so they would be released sooner if deleted 
within tight script loops instead of waiting for the next main loop to released 
them. It was a response to a bug where creating and deleting lots of objects in 
a loop bloated memory use I believe. Well deleting them earlier resulted in 
*lots* of instability where there were references to objects (say the internal 
defaultStack global for example) but the object had been deleted. Things like 
scripts still executing on objects that are meant to be deleted or setting the 
defaultStack to a stack that has just been deleted. Anyway in order to make it 
easier for us to resolve these issues Fraser wrote a class to use as an object 
handle whenever we want to keep a reference to an object. So now we can do 
stuff like t_stack.IsValid() before doing something with t_stack.

For example one crash that I just fixed is this one: 
https://github.com/livecode/livecode/pull/5143 


In that crash we were getting the stack of an object when it is being sent a 
message then using it later but the particular crashing code was deleting the 
stack the target object was on in a frontScript which was executed between 
getting the reference to the stack and using it. So the change now uses an 
object handle so we can check it’s still valid before sending the message after 
the frontScripts are executed ;-)
> 
> 
> > BTW our internal discussions have led us to consider dropping the
> > message box redirect entirely and just sending msgChanged to the
> > defaultStack which is inline with other messages. The less special
> > cases in the way we do things the better. The IDE pubsub library
> > can dispatch ideMsgChanged to any subscribers and they can do what
> > they like. If it’s unhandled or passed to the engine then it can be
> > sent to the appropriate system logs (or stdout… not sure which just
> > yet and perhaps will depend on if its in no ui mode as there’s a
> > legacy there).
> 
> My first inclination would be as you'd anticipated, that it would be such a 
> low priority as to be barely worth the net trade-off of trimming some code in 
> one place while writing other code elsewhere.
> 
> But if we're at last in a place where the IDE spec we're working with will 
> finally settle down, I'm okay with rewriting my stuff to work with it.
> 
> And best of all, since both the IDE code and our code will be coming from an 
> engine-borne message (I like msgChanged), I have options for how I handle 
> that, either through the IDE pubsub or in a well-managed frontscript as all 
> my other tools tend to use (which is why they don't generally break with IDE 
> changes ), and that freedom is as important to me as being able to rely on 
> the message within a standalone when I need to do that too.
> 
> In short, go for it. :)

;-) OK

> 
> Thanks for running this by the community.

It’s worth remembering that almost all of what we do is run by the community 
because everyone is free to subscrib to our github feed and comment on our PRs.

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: Help: Does anyone use legacy message box behavior?

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

>> On 8 Feb 2017, at 3:04 am, Richard Gaskin wrote:
>>
>> My Message Box replacement sets the revMessageBox redirect to empty
>> when it closes, and after doing so the LC IDE Message Box resumes
>> normal behavior.
>
> Yes it does use it but it also (at least the single line msg box)
> happens to conform to the old spec too (stack is named “Message
> Box”). Also it sets it when loading the message box so that might
> be fixing it for you.
>>
>> Is it necessary to remove the old behavior?
>
> Not overly so, however, every line removed is something we don’t
> need to waste time maintaining. You might think we don’t need to
> touch it but it has been touched recently because of a change in
> the way we retain object references.

Now I'm curious: anything interesting there in terms of features, 
performance, or memory handling?



> BTW our internal discussions have led us to consider dropping the
> message box redirect entirely and just sending msgChanged to the
> defaultStack which is inline with other messages. The less special
> cases in the way we do things the better. The IDE pubsub library
> can dispatch ideMsgChanged to any subscribers and they can do what
> they like. If it’s unhandled or passed to the engine then it can be
> sent to the appropriate system logs (or stdout… not sure which just
> yet and perhaps will depend on if its in no ui mode as there’s a
> legacy there).

My first inclination would be as you'd anticipated, that it would be 
such a low priority as to be barely worth the net trade-off of trimming 
some code in one place while writing other code elsewhere.


But if we're at last in a place where the IDE spec we're working with 
will finally settle down, I'm okay with rewriting my stuff to work with it.


And best of all, since both the IDE code and our code will be coming 
from an engine-borne message (I like msgChanged), I have options for how 
I handle that, either through the IDE pubsub or in a well-managed 
frontscript as all my other tools tend to use (which is why they don't 
generally break with IDE changes ), and that freedom is as important 
to me as being able to rely on the message within a standalone when I 
need to do that too.


In short, go for it. :)

Thanks for running this by the community.

--
 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: Help: Does anyone use legacy message box behavior?

[Monte Goulding via use-livecode]

> On 8 Feb 2017, at 3:04 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> I sent this a while ago, and oddly enough another message I'd sent lae came 
> in but this one did not.
> 
> After thinking about this some more, I wonder:  are you sure the LC IDE 
> doesn't rely on this?
> 
> My Message Box replacement sets the revMessageBox redirect to empty when it 
> closes, and after doing so the LC IDE Message Box resumes normal behavior.

Yes it does use it but it also (at least the single line msg box) happens to 
conform to the old spec too (stack is named “Message Box”). Also it sets it 
when loading the message box so that might be fixing it for you.
> 
> Is it necessary to remove the old behavior?

Not overly so, however, every line removed is something we don’t need to waste 
time maintaining. You might think we don’t need to touch it but it has been 
touched recently because of a change in the way we retain object references.

BTW our internal discussions have led us to consider dropping the message box 
redirect entirely and just sending msgChanged to the defaultStack which is 
inline with other messages. The less special cases in the way we do things the 
better. The IDE pubsub library can dispatch ideMsgChanged to any subscribers 
and they can do what they like. If it’s unhandled or passed to the engine then 
it can be sent to the appropriate system logs (or stdout… not sure which just 
yet and perhaps will depend on if its in no ui mode as there’s a legacy there).

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

Fwd: Re: Help: Does anyone use legacy message box behavior?

[Richard Gaskin via use-livecode]

I sent this a while ago, and oddly enough another message I'd sent lae 
came in but this one did not.


After thinking about this some more, I wonder:  are you sure the LC IDE 
doesn't rely on this?


My Message Box replacement sets the revMessageBox redirect to empty when 
it closes, and after doing so the LC IDE Message Box resumes normal 
behavior.


I don't mind modifying mine if needed, but since an empty revMessageBox 
redirect allows the LC IDE to resume use of its own Message Box, and 
since the LC IDE's Message Box stack is still named "Message Box", it 
would seem the engine behavior you describe is still in use.


Please let me know if I misunderstand.  But FWIW one nice thing about 
that behavior is that it keeps things simple, allowing a useful default 
in the IDE even if the revMessageBoxRedirect is set to not restored to a 
valid field reference.


Is it necessary to remove the old behavior?

- rg


 Forwarded Message 
Subject: Re: Help: Does anyone use legacy message box behavior?
Date: Tue, 7 Feb 2017 07:37:30 -0800
From: Richard Gaskin <ambassa...@fourthworld.com>
To: use-livecode@lists.runrev.com

Monte Goulding wrote:


I’m in the midst of making the message box redirect work in all
engines (https://github.com/livecode/livecode/pull/5156
<https://github.com/livecode/livecode/pull/5156>) and it would seem
that there’s a legacy message box behavior that could be removed from
the engine. It’s not used by the IDE. The behavior is if no message
box redirect is set then it looks for a stack named “Message Box”,
sets the text of the first field then raises the stack. As this is
only an IDE thing I strongly suspect we are ok to remove the code
but while I’m waiting for the team to wake up in Scotland I thought
I’d check here!

It would be easy to work around even if you have been depending on it
because it’s just setting the property and then handling msgChanged
to put msg where ever you want.


IIRC what you describe is the original engine behavior which drove the 
MC IDE.  I believe that was also used by early versions of the LC IDE.


The revMessageBoxRedirect global property was a solution added to 
satisfy a request I had for being able to use the MC IDE as a plugin 
within LC.  If the LC IDE now also uses that property itself that would 
seem a cleaner implementation.


Removing the engine behavior you describe will break the MC IDE, but 
given how few people use it these days I don't think that should be a 
reason to clutter the code base.  Those interested could easily add the 
one line of code needed to use revMessageBoxRedirect instead.


Personally, I don't use anything dependent on the older behavior, but I 
do use revMessageBoxRedirect very extensively; among other things I've 
been using a custom Terminal-like Message Box replacement for years.


Being able to use my custom Message Box in a standalone would be a 
godsend.  If removing the old behavior makes a cleaner way to do that I 
say go for it.


--
 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: Help: Does anyone use legacy message box behavior?

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

> I’m in the midst of making the message box redirect work in all
> engines (https://github.com/livecode/livecode/pull/5156
> ) and it would seem
> that there’s a legacy message box behavior that could be removed from
> the engine. It’s not used by the IDE. The behavior is if no message
> box redirect is set then it looks for a stack named “Message Box”,
> sets the text of the first field then raises the stack. As this is
> only an IDE thing I strongly suspect we are ok to remove the code
> but while I’m waiting for the team to wake up in Scotland I thought
> I’d check here!
>
> It would be easy to work around even if you have been depending on it
> because it’s just setting the property and then handling msgChanged
> to put msg where ever you want.

IIRC what you describe is the original engine behavior which drove the 
MC IDE.  I believe that was also used by early versions of the LC IDE.


The revMessageBoxRedirect global property was a solution added to 
satisfy a request I had for being able to use the MC IDE as a plugin 
within LC.  If the LC IDE now also uses that property itself that would 
seem a cleaner implementation.


Removing the engine behavior you describe will break the MC IDE, but 
given how few people use it these days I don't think that should be a 
reason to clutter the code base.  Those interested could easily add the 
one line of code needed to use revMessageBoxRedirect instead.


Personally, I don't use anything dependent on the older behavior, but I 
do use revMessageBoxRedirect very extensively; among other things I've 
been using a custom Terminal-like Message Box replacement for years.


Being able to use my custom Message Box in a standalone would be a 
godsend.  If removing the old behavior makes a cleaner way to do that I 
say go for it.


--
 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: Help: Does anyone use legacy message box behavior?

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> ...how would you use this feature, specifically in debugging a
> standalone, and what’s wrong with it now?

The revMessageBox redirect allows you to use any field to display data 
that would otherwise go to LC's Message Box; that is, any "put" without 
a specified destination.


When combined with an input field for triggering commands and querying 
functions and properties, you can effectively make a satisfyingly 
full-featured Message Box replacement.


This allows you to query information at runtime in a standalone.

When these fields are part of a separate window they can be useful in 
desktop apps, but they can also be contained within a group, which could 
be shown and hidden as needed, for debugging in mobile apps as well.


I had thought revMessageBoxRedirect was already part of the standalone 
engine, but apparently not.  Making it available to standalones opens up 
very flexible options for poking around in a LC app.


--
 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: Help: Does anyone use legacy message box behavior?

[Bob Sneidar via use-livecode]

what the heck is that?

Bob S


On Feb 6, 2017, at 19:28 , Monte Goulding via use-livecode 
> wrote:

message box redirect

___
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: Help: Does anyone use legacy message box behavior?

[Graham Samuel via use-livecode]

Forgive my stupidity, but how would you use this feature, specifically in 
debugging a standalone, and what’s wrong with it now?

TIA

Graham

> On 7 Feb 2017, at 07:16, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 2/6/17 9:28 PM, Monte Goulding via use-livecode wrote:
>> Hi Folks
>> 
>> I’m in the midst of making the message box redirect work in all
>> engines (https://github.com/livecode/livecode/pull/5156
>> ) and it would seem
>> that there’s a legacy message box behavior that could be removed from
>> the engine. It’s not used by the IDE. The behavior is if no message
>> box redirect is set then it looks for a stack named “Message Box”,
>> sets the text of the first field then raises the stack. As this is
>> only an IDE thing I strongly suspect we are ok to remove the code but
>> while I’m waiting for the team to wake up in Scotland I thought I’d
>> check here!
>> 
>> It would be easy to work around even if you have been depending on it
>> because it’s just setting the property and then handling msgChanged
>> to put msg where ever you want.
> 
> Do whatever it takes, I've been waiting for this for years. I could really 
> use it right now. Debugging standalones is an exercise in frustration.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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: Help: Does anyone use legacy message box behavior?

[J. Landman Gay via use-livecode]

On 2/6/17 9:28 PM, Monte Goulding via use-livecode wrote:

Hi Folks

I’m in the midst of making the message box redirect work in all
engines (https://github.com/livecode/livecode/pull/5156
) and it would seem
that there’s a legacy message box behavior that could be removed from
the engine. It’s not used by the IDE. The behavior is if no message
box redirect is set then it looks for a stack named “Message Box”,
sets the text of the first field then raises the stack. As this is
only an IDE thing I strongly suspect we are ok to remove the code but
while I’m waiting for the team to wake up in Scotland I thought I’d
check here!

It would be easy to work around even if you have been depending on it
because it’s just setting the property and then handling msgChanged
to put msg where ever you want.


Do whatever it takes, I've been waiting for this for years. I could 
really use it right now. Debugging standalones is an exercise in 
frustration.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Help: Does anyone use legacy message box behavior?

[Mark Wieder via use-livecode]

On 02/06/2017 07:28 PM, Monte Goulding via use-livecode wrote:


I’m in the midst of making the message box redirect work in all engines 
(https://github.com/livecode/livecode/pull/5156 
) and it would seem that 
there’s a legacy message box behavior that could be removed from the engine. It’s not 
used by the IDE. The behavior is if no message box redirect is set then it looks for 
a stack named “Message Box”, sets the text of the first field then raises the stack. 
As this is only an IDE thing I strongly suspect we are ok to remove the code but 
while I’m waiting for the team to wake up in Scotland I thought I’d check here!

It would be easy to work around even if you have been depending on it because 
it’s just setting the property and then handling msgChanged to put msg where 
ever you want.


Go for it. Would be nice to have redirect work any/every/where.

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

Help: Does anyone use legacy message box behavior?

[Monte Goulding via use-livecode]

Hi Folks

I’m in the midst of making the message box redirect work in all engines 
(https://github.com/livecode/livecode/pull/5156 
) and it would seem that 
there’s a legacy message box behavior that could be removed from the engine. 
It’s not used by the IDE. The behavior is if no message box redirect is set 
then it looks for a stack named “Message Box”, sets the text of the first field 
then raises the stack. As this is only an IDE thing I strongly suspect we are 
ok to remove the code but while I’m waiting for the team to wake up in Scotland 
I thought I’d check here!

It would be easy to work around even if you have been depending on it because 
it’s just setting the property and then handling msgChanged to put msg where 
ever you want.

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