That's an excellent observation ;) This is actually what happend when we
first wrote that game - there was a NULL-dereference in the game logic and
it caused a 'persistent segmentation fault'. It's really important for
programmers to step up when it comes to creating software that uses
this type of memory directly. Everyone essentially becomes a file system
developer, which is not necessarily a good thing.
Our hope is that high level languages like python will also help in this
regard by making sure that the programmer cannot shoot himself in the foot
as easily as it is possible in C.
Piotr
2016-05-20 12:30 GMT+02:00 Steven D'Aprano
On Wed, May 18, 2016 at 01:44:12PM -0400, R. David Murray wrote:
[...]
The main target would of course be the data the program wants to preserve between runs, but one of the examples at pmem.io is a game program whose state is all in nvram. If the machine crashes in the middle of the game, upon restart you pick up exactly where you left off, including all the positioning information you might consider to be part of the "hot loop" part of the program.
Wouldn't that mean you're restarting the game in the same state it was in just before it crashed? Which means (assuming the crash is deterministic) the very next thing the game will do is crash.
-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/