Sounds like a better idea to me, but I don't think it would solve the problem of multiple images almost simultaneously attempting to update themselves (as in a classroom)
Sent from my iPad
On Jun 30, 2016, at 13:31, Chris Muller asqueaker@gmail.com wrote:
Another thought...
Upon launching of the image, start a, temporary changes file, [image-name]-[some UUID].changes.
Upon image save, append the temp changes file to the main changes file, but in an atomic way (first do the append as a new unique filename, then rename it to the original changes file name).
Hmm, but then we would have to check two changes files when accessing sources..
On Thu, Jun 30, 2016 at 3:10 PM, Chris Muller asqueaker@gmail.com wrote:
In practice, this is not an issue that either Chris or I have noticed, probably because we are not doing software development (saving method changes) at the same time that we are running RemoteTask and similar. But I can certainly see how it might be a problem if, for example, I had a bunch of students running the same image from a network shared folder.
Maybe its time to consider a fundamental change in how method-sources are referred to. Taking inspiration from git... A content addressable key-value file store might solve concurrent access. Each CompiledMethod gets written to a file named for the hash of its contents, which is the only reference the Image getsto a method's source. Each such file would
It sounds like a lot of files.. so how would I move an image to another computer? I gotta know which files go with which image?
Plus, it doesn't really solve the fundamental problem of two images writing to the same file. Mutliple images could still change the same method to the same contents at the same time. You may have made the problem less-likely, except for when you have your first hash-collision of *different* sources (it COULD happen), in which case it wouldn't even require the changes to occur at the same time.
I guess it would also lose the order-sequence of the change log too... unless you were to try to use the underlying filesystem's timestamps on each file but... it wouldn't work after I've copied all the files via scp and because they all get new timestamps...
Might be better to teach the class, who are learning about Smalltalk anyway, about the nature of the changes file..?