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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-revolution > > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
