Save stacks periodically to avoid crashes? [OT]

J. Landman Gay jacque at hyperactivesw.com
Sat Mar 25 21:31:23 EST 2006


I can see how one might arrive at a correlation though. The more 
important the data, the more I generally type. The more I type, the more 
keystrokes. The more keystrokes, the more likely I am to hit that random 
number.

It is all starting to fall together for me. Thanks.

Dennis Brown wrote:
> Jim,
> 
> You need to tell your friend that that's ridiculous.  These programs  
> can't tell which data is important or when your deadline is.  It is  all 
> zeros and ones.  Nope, it is just a simple calculation.  The user  
> provides the correlation inadvertently.  If the data is important,  the 
> user will suffer more when it goes bye bye.  If the deadline is  
> looming, the user will be so engrosed in completing it on time, that  
> they will forget to save periodically.  That is why it is so  important 
> to wipe that ability to concentrate completely on a task to  the 
> exclusion of all else from the gene pool.
> 
> TIC
> Dennis
> 
> On Mar 25, 2006, at 4:13 PM, Jim Ault wrote:
> 
>> Thanks for clearing up part of the mystery for me.. I thought it  was 
>> some
>> sort of cubic spline and the volume under that surface.  Glad to  know 
>> it is
>> only a random number.
>>
>> One of my friends still believes it is an inverse proportion to the
>> importance of the data and the minutes until the deadline...
>> freq = importance/time = maximizing relative loss
>>
>> Jim Ault
>> Las Vegas
>>
>>
>> On 3/25/06 12:32 PM, "Dennis Brown" <see3d at writeme.com> wrote:
>>
>>> After a lot of clever hacking, I have found that I can almost always
>>> find the counter in any application that counts the number of
>>> keystrokes since the last save.  Once the counter crosses a certain
>>> threshold, a random number is invoked in each new keystroke.  If the
>>> random number matches the keystroke count, then a crash is provoked.
>>>
>>> It is all part of a secret programmers guild directive designed to
>>> help users learn to save and back up their work regularly.  It is
>>> expected that after 11 generations, the urge to save will become a
>>> reflex built into the human genome through natural selection.  Those
>>> who do not learn to save will become failures in life --unable to
>>> attract a mate. Their "bad" genes will then vanish from the species.
>>>
>>> Dennis ;-)
>>>
>>> On Mar 24, 2006, at 11:49 AM, Jon Seymour wrote:
>>>
>>>> Hi, I've been using Rev for about a year. I'm sure it won't shock
>>>> most of you to hear that periodically Rev just seems tired and
>>>> crashes. Now I am sure that coding glitches are sometimes at fault,
>>>> but generally speaking I think Rev (esp. 2.7) has stability issues.
>>>> Here's the thing, though: it seems that if I am saving the stack
>>>> periodically, which I would tend to do to avoid losing data in a
>>>> crash, the program actually crashes less. It's as if saving has
>>>> some benefit to memory management or who-knows-what-else in the
>>>> engine. It's like a "refresh" function. Has anyone else observed
>>>> this? Is there a rationale? Would it be smart to have a commercial
>>>> application save its stacks regularly, not only to store user
>>>> changes, but simply to confer stability?
>>
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
> 


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



More information about the use-livecode mailing list