Save stacks periodically to avoid crashes? [OT]

[Jim Ault]

My remarks were tongue-in-cheek... losing unimportant stuff does not leave a
mark, so fades from memory.  Using a computer to meet a deadline provides
its own stress for most people, thus leaves a mark every time    :-)

Jim Ault
Las Vegas


On 3/25/06 5:58 PM, "Dennis Brown" <see3d at writeme.com> 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