5 ms·

This is very interesting, but I have a lot of questions about how "keeping documents as in-memory object" works in practice -- because files gives us lots of fe

by theamk 7y ago

This is very interesting, but I have a lot of questions about how "keeping documents as in-memory object" works in practice -- because files gives us lots of features we depend on, without even realizing it. - Upgrade software: right now, my "txt" files are independent from "/usr/bin/emacs". I can upgrade emacs to the later version, and use it to re-open the same documents. This does not seem possible if by file is "text window + object pointer + editor code". - Move/copy files between machines -- I can copy most of the files, but not objects. I can also save older versions, send them by email or messengers, and so on. - Recover from bad software -- the other day, my computer decided it wants to have a full-screen uncloseable window. A reboot fixed this right up. Good thing it was not persistent. - Recover from crashes. What do you do if you write a presentation, and a programming error causes program to stop responding if you ever draw a green circle of certain size? In regular OS, you restart your software, load the latest savefile, and avoid green circles in the future. In PhantomOS, looks like you will be screwed. The only thing that Phantom seems to offer is snapshots, but they are pretty extreme (the whole system is reverted), and even then, it only helps with some classes of bugs, the ones which are obvious enough that you notice them right away.

dzavalishin 7y ago
Actually things in Phantom are not SO different from usual world. - You can install new version of class code. Of course, app code have to do migration by hand, but that's the case in nowadays world - if you change data file format, you have to convert. - There's no problem to migrate object tree over the net. Even storing it to a file is not a problem. - Persistence does not _forbid_ to restart things. It just does not restart 'em on reboot. Eggs in your fridge are (more or less) persistent :), but you still can throw 'em away and put in fresh ones. We're living in a persistent world and do not suffer too much from it, right? Non-persistence of software world is just innatural. We're very used to it, and that's all.
- theamk 7y ago
  Thanks for the answers, I am glad to hear from the author! - What do you mean "app code have to do migration by hand"? I'd say that most of the existing file formats need no migration -- images, videos, music basically don't change; and even very complex file formats like Microsoft doc only change with major versions, not with the minor ones -- MS word had tens of thousands code updates (service packs, localization, etc..) but only a dozen or so file formats. - What do you mean by "restart" in "Persistence does not _forbid_ to restart things."? if by "restart", you mean "kill all the threads related to object", then I don't think it will help in most cases. If you have a bug in "Draw()" function, this bug will still be there after thread restart. If by "restart", you mean "wipe all the state, and start from the clean slate", then won't this destroy all the documents user made? --- We live in persistent world, and we do suffer a lot from it, we are just very used to it. I have to wash my dishes every day, buy new clothes, and repair my car. I would love to be able to "save" the make, model, and license plate # of my car, then "restart" it to get a brand-new car with the same properties. Default persistence of everything is annoying, and moving it to software is just unnatural :)
  - dzavalishin 7y ago
    Well, you just can't imagine non-persistent world. :) I'll try to illustrate. In non-persistent world you have to disassemble and store to special boxes all the objects in a room before getting out of that room. Or else it all will just vanish. :) On migration: if you change code in Phantom in a way that does not change object representation, you can just use new code with old data. New paintDocumentPart() can be called for same document object as long as interface is the same. The problem is with objects with running threads in them. You can't change implementation which is currently running. Hopefully, it would not be a usual case. As far as I see, Phantom applications won't need forever running threads at all. os ->(repaint)->window->(get state of)->document or doc->(update state trigger)->window->(repaint)->canvas In either case it's just an event. Update and finish. Actually, Phantom was a huge mind game of mine for years (first ideas started to form some 25 years ago) and one of the reasons to start actual implementation was that I can't imagine all of the potential problems and solutions for such an environment. But - I don't want Phantom to be just a test bed for new ideas. I hope it will find its place as practical tool.
    - theamk 7y ago
      I can certainly imagine a non-persistent world -- why do you keep saying that I cannot? It is called "restaurant". You come in and get a clean, fresh table. You sit on it and eat, and if you have leftovers, you put them in special boxes. When you leave, everything on the table that you did not put in a box disappears. Very nice and handy! ===== So what happens in case of errors? os ->(repaint)->window->(get state of)->document->(EXCEPTION: LIST INDEX OUT OF RANGE) Does this result in losing the document forever?
      - dzavalishin 7y ago
        Word->Open file->Error reading file: LIST INDEX OUT OF RANGE Does this? Your point is obvious, but not specific to persistent environment. Things are getting broken sometimes. Actually, back in 2009 when first message about Phantom appeared, I've got a message from team in Stanford. THey did an experiment about things we discuss. Relatively big Java program was stopped in the middle of work, serialized to (I believe) XML and some objects were removed from that XML. After that program state was de-serialized and program continued to run. Experiments shown that modern code degrades quite gracefully in such cases. Most of time problems were not global and affected just parts of program's abilities. But again, it is not a persistent world specific problem. If your code is wrong, no matter where index lies - in persistent memory object or in file. Index will be wrong. The question is how system must be built, what kinds of services it must provide to limit app ability to shoot itself in a foot. That is one of the goals of this project.

by theamk 7y ago

dzavalishin 7y ago

Actually things in Phantom are not SO different from usual world. - You can install new version of class code. Of course, app code have to do migration by hand, but that's the case in nowadays world - if you change data file format, you have to convert. - There's no problem to migrate object tree over the net. Even storing it to a file is not a problem. - Persistence does not _forbid_ to restart things. It just does not restart 'em on reboot. Eggs in your fridge are (more or less) persistent :), but you still can throw 'em away and put in fresh ones. We're living in a persistent world and do not suffer too much from it, right? Non-persistence of software world is just innatural. We're very used to it, and that's all.

theamk 7y ago
Thanks for the answers, I am glad to hear from the author! - What do you mean "app code have to do migration by hand"? I'd say that most of the existing file formats need no migration -- images, videos, music basically don't change; and even very complex file formats like Microsoft doc only change with major versions, not with the minor ones -- MS word had tens of thousands code updates (service packs, localization, etc..) but only a dozen or so file formats. - What do you mean by "restart" in "Persistence does not _forbid_ to restart things."? if by "restart", you mean "kill all the threads related to object", then I don't think it will help in most cases. If you have a bug in "Draw()" function, this bug will still be there after thread restart. If by "restart", you mean "wipe all the state, and start from the clean slate", then won't this destroy all the documents user made? --- We live in persistent world, and we do suffer a lot from it, we are just very used to it. I have to wash my dishes every day, buy new clothes, and repair my car. I would love to be able to "save" the make, model, and license plate # of my car, then "restart" it to get a brand-new car with the same properties. Default persistence of everything is annoying, and moving it to software is just unnatural :)
- dzavalishin 7y ago
  Well, you just can't imagine non-persistent world. :) I'll try to illustrate. In non-persistent world you have to disassemble and store to special boxes all the objects in a room before getting out of that room. Or else it all will just vanish. :) On migration: if you change code in Phantom in a way that does not change object representation, you can just use new code with old data. New paintDocumentPart() can be called for same document object as long as interface is the same. The problem is with objects with running threads in them. You can't change implementation which is currently running. Hopefully, it would not be a usual case. As far as I see, Phantom applications won't need forever running threads at all. os ->(repaint)->window->(get state of)->document or doc->(update state trigger)->window->(repaint)->canvas In either case it's just an event. Update and finish. Actually, Phantom was a huge mind game of mine for years (first ideas started to form some 25 years ago) and one of the reasons to start actual implementation was that I can't imagine all of the potential problems and solutions for such an environment. But - I don't want Phantom to be just a test bed for new ideas. I hope it will find its place as practical tool.
  - theamk 7y ago
    I can certainly imagine a non-persistent world -- why do you keep saying that I cannot? It is called "restaurant". You come in and get a clean, fresh table. You sit on it and eat, and if you have leftovers, you put them in special boxes. When you leave, everything on the table that you did not put in a box disappears. Very nice and handy! ===== So what happens in case of errors? os ->(repaint)->window->(get state of)->document->(EXCEPTION: LIST INDEX OUT OF RANGE) Does this result in losing the document forever?
    - dzavalishin 7y ago
      Word->Open file->Error reading file: LIST INDEX OUT OF RANGE Does this? Your point is obvious, but not specific to persistent environment. Things are getting broken sometimes. Actually, back in 2009 when first message about Phantom appeared, I've got a message from team in Stanford. THey did an experiment about things we discuss. Relatively big Java program was stopped in the middle of work, serialized to (I believe) XML and some objects were removed from that XML. After that program state was de-serialized and program continued to run. Experiments shown that modern code degrades quite gracefully in such cases. Most of time problems were not global and affected just parts of program's abilities. But again, it is not a persistent world specific problem. If your code is wrong, no matter where index lies - in persistent memory object or in file. Index will be wrong. The question is how system must be built, what kinds of services it must provide to limit app ability to shoot itself in a foot. That is one of the goals of this project.