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