Any Clue..

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: [hidden email] [[hidden email]] On Behalf Of Diogenes Moreira [[hidden email]]
Sent: Wednesday, January 19, 2011 7:42 AM
To: [hidden email]
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

Thanks..

On 19 January 2011 13:57, Schwab,Wilhelm K <[hidden email]> 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..



--
Best regards,
Igor Stasenko AKA sig.

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: [hidden email] [[hidden email]] On Behalf Of Diogenes Moreira [[hidden email]]
Sent: Wednesday, January 19, 2011 8:03 AM
To: [hidden email]
Subject: Re: [Pharo-project] Any Clue..

Thanks..

On Wed, Jan 19, 2011 at 9:57 AM, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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: [hidden email]<mailto:[hidden email]> [[hidden email]<mailto:[hidden email]>] On Behalf Of Diogenes Moreira [[hidden email]<mailto:[hidden email]>]
Sent: Wednesday, January 19, 2011 7:42 AM
To: [hidden email]<mailto:[hidden email]>
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

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.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Wednesday, January 19, 2011 8:08 AM
To: [hidden email]
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..

On 19 January 2011 14:14, Schwab,Wilhelm K <[hidden email]> 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?



--
Best regards,
Igor Stasenko AKA sig.

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


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Wednesday, January 19, 2011 8:35 AM
To: [hidden email]
Subject: Re: [Pharo-project] Any Clue..

On 19 January 2011 14:14, Schwab,Wilhelm K <[hidden email]> 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?



--
Best regards,
Igor Stasenko AKA sig.

Pharo's improvement is significant compared to squeak .. can restore the environmentwith 2 click .. things up to version 3.10 of squeak was almost impossible. always hadto play something on the Change ..

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

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




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Yanni Chiu [[hidden email]]
Sent: Wednesday, January 19, 2011 11:22 AM
To: [hidden email]
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

On 19 January 2011 17:38, Schwab,Wilhelm K <[hidden email]> 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.



--
Best regards,
Igor Stasenko AKA sig.