First, I hope there *is* a shortcut and that someone corrects the record promptly. Second, my (Ubuntu) computer just called home and wanted to install updates to a thing called d-bus, which was described as a simple IPC mechanism. Being the curious sort, I did a search and found this: http://en.wikipedia.org/wiki/D-Bus The timing was quite convenient. A Windows port is said to exist, and there is mention of its running as a daemon, which would be needed to replace the mechanism Dolphin exploits. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Diogenes Moreira [diogenes.moreira@gmail.com] Sent: Wednesday, January 19, 2011 8:03 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Any Clue.. Thanks.. On Wed, Jan 19, 2011 at 9:57 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I have seen this only a couple of times, and I am not aware of a shortcut to returning to a working image and recovering lost changes. As an aside, I am suspicious that opening an image more than once leads to much more badness than is generally acknowledged. I am convinced it was central to my most recent meltdown. The only reason I don't have more trouble is that I have learned to scan the task bar before launching Pharo. We need a cross-platform way to detect that a given image is open and to at least optionally warn and offer to exit without doing any damage. Dolphin does so by creating a Windows synchronization object (either a semaphore or an event??) tied to the image name, and if that object exists, it sternly warns against proceeding. Deployed executables do not do this check by default. Good luck retrieving your work! ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Diogenes Moreira [diogenes.moreira@gmail.com<mailto:diogenes.moreira@gmail.com>] Sent: Wednesday, January 19, 2011 7:42 AM To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: [Pharo-project] Any Clue.. Hi folks.. this morning, at try start my enviroment, pharo said... "Read failed or premature end of image file".. Any Clue to solve it, will be welcome. Well I can get a clean image and apply de changes.. but somebody have a shortcut..?? Best

On 19 January 2011 13:57, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:

I have seen this only a couple of times, and I am not aware of a shortcut to returning to a working image and recovering lost changes.  As an aside, I am suspicious that opening an image more than once leads to much more badness than is generally acknowledged.  I am convinced it was central to my most recent meltdown.  The only reason I don't have more trouble is that I have learned to scan the task bar before launching Pharo.

We need a cross-platform way to detect that a given image is open and to at least optionally warn and offer to exit without doing any damage.  Dolphin does so by creating a Windows synchronization object (either a semaphore or an event??) tied to the image name, and if that object exists, it sternly warns against proceeding.  Deployed executables do not do this check by default.

There is nothing wrong starting multiple processes using single .image file. During startup, vm just reads data from it. And when writing to an .image file, a process who first opens it should obtain a global lock on it, so nothing will have chances to interfere. So, it seems that image file was damaged or not written completely..

Good luck retrieving your work!

________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Diogenes Moreira [diogenes.moreira@gmail.com] Sent: Wednesday, January 19, 2011 7:42 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Any Clue..

Hi folks..

 this morning, at try start my enviroment, pharo said... "Read failed or premature end of image file".. Any Clue to solve it, will be welcome.

Well I can get a clean image and apply de changes.. but somebody have a shortcut..??

Best

-- Best regards, Igor Stasenko AKA sig.

On 19 January 2011 14:14, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:

Sig,

Please forgive me for being skeptical, but it is certainly worthy of a test on my end.  How do the multiple processes coordinate access to the change log?  Not having seen an IDE complain about access to either image or changes, and knowing that I have been bitten by this, I am not sure how to square it.

Access to single .changes file are handled by image, and i think it is handled well (it barks that .changes cannot be opened, if some other process already opened it). But that is a completely different story , because .image file are handled by vm itself, not by image.. From VM perspective, a .changes file are not mandatory in order to run your image, so why it should care about it?

Bill

________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, January 19, 2011 8:08 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Any Clue..

There is nothing wrong starting multiple processes using single .image file. During startup, vm just reads data from it. And when writing to an .image file, a process who first opens it should obtain a global lock on it, so nothing will have chances to interfere. So, it seems that image file was damaged or not written completely..

-- Best regards, Igor Stasenko AKA sig.

On 19/01/11 8:48 AM, Schwab,Wilhelm K wrote:

Sig,

Are we discussing the same OS? What you are describing matches my experience on Windows; on Linux, AFAIK, one can just stomp all over the files and leave a mess. Perhaps something has changed to make it safer since I last trashed an image that way.

I agree that there are times when it does not matter, so any safety mechanism needs to be optional, or better yet tied to a development session vs. a deployed session.

Bill

I run a common .image file that is interpreted multiple times with a different start up script. There is no .changes file. This works on MacOSX and Ubuntu. This is the behaviour I want to have, so such a "safety mechanism" would definitely need to be optional. -- Yanni

On 19 January 2011 17:38, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:

Of course.  But the IDE should be smart enough to prevent disaster.

on linux, if there is no proper exclusive write-file locking supported through primitives, one could always create a .lock file and put a process id there. so before opening a .changes file for writing any image first should check if there are a .lock file and if value stored in it has same proc id as currently running one. and after closing .changes file it should delete .lock file. oh.. except that probably there is no way to obtain process id .. there is no such primitive if i remember correctly. Not a big deal.. you can use a GUID generated at image startup time to obtain same effect. But all this logic can be implemented in image.

________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Yanni Chiu [yanni@rogers.com] Sent: Wednesday, January 19, 2011 11:22 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Any Clue..

On 19/01/11 8:48 AM, Schwab,Wilhelm K wrote:

...

Sig,

Are we discussing the same OS?  What you are describing matches my experience on Windows; on Linux, AFAIK, one can just stomp all over the files and leave a mess.  Perhaps something has changed to make it safer since I last trashed an image that way.

I agree that there are times when it does not matter, so any safety mechanism needs to be optional, or better yet tied to a development session vs. a deployed session.

Bill

I run a common .image file that is interpreted multiple times with a different start up script. There is no .changes file. This works on MacOSX and Ubuntu. This is the behaviour I want to have, so such a "safety mechanism" would definitely need to be optional.

-- Yanni

-- Best regards, Igor Stasenko AKA sig.