Update process broken by 13084

See title.
Probably caused by saving from multiple open copies of the same image so
the .changes file source was exported from was corrupted :)

Cheers,
Henry

Linux certainly allows that mistake.  What about OSX?




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Henrik Sperre Johansen [[hidden email]]
Sent: Saturday, March 12, 2011 6:29 PM
To: [hidden email]
Subject: [Pharo-project] Update process broken by 13084

See title.
Probably caused by saving from multiple open copies of the same image so
the .changes file source was exported from was corrupted :)

Cheers,
Henry

Den 13.03.2011 01:04, skrev Schwab,Wilhelm K:
> Linux certainly allows that mistake.  What about OSX?
As Steph/Markus used Macs today when pushing updates, I'm fairly certain
it does :)
After all, it's just a prettified BSD. (ok, some other differences as
well, like stack alignment requirements etc. :P)

Cheers,
Henry

On 13 March 2011 01:29, Henrik Sperre Johansen
<[hidden email]> wrote:
>
>
> Den 13.03.2011 01:04, skrev Schwab,Wilhelm K:
>> Linux certainly allows that mistake.  What about OSX?
> As Steph/Markus used Macs today when pushing updates, I'm fairly certain
> it does :)
> After all, it's just a prettified BSD. (ok, some other differences as
> well, like stack alignment requirements etc. :P)

yeah they wanted to use sse2/3 instructions in kernel and system libraries..
so system runs faster .. hehe..
and to do that they found nothing better than enforcing this rule in
call convention :)

>
> Cheers,
> Henry
>
>



--
Best regards,
Igor Stasenko AKA sig.

Someone (Sig??) mentioned a possible unix solution not too long ago.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Henrik Sperre Johansen [[hidden email]]
Sent: Saturday, March 12, 2011 7:29 PM
To: [hidden email]
Subject: Re: [Pharo-project] Update process broken by 13084

Den 13.03.2011 01:04, skrev Schwab,Wilhelm K:
> Linux certainly allows that mistake.  What about OSX?
As Steph/Markus used Macs today when pushing updates, I'm fairly certain
it does :)
After all, it's just a prettified BSD. (ok, some other differences as
well, like stack alignment requirements etc. :P)

Cheers,
Henry

On 13 March 2011 01:44, Schwab,Wilhelm K <[hidden email]> wrote:
> Someone (Sig??) mentioned a possible unix solution not too long ago.
>
>
yes, to put an exclusive write lock on a file.
Not sure if unix systems allow that



--
Best regards,
Igor Stasenko AKA sig.

But we do not publish the changes anymore.
So you think that the packages got corrupted?

Stef

On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote:

> See title.
> Probably caused by saving from multiple open copies of the same image so
> the .changes file source was exported from was corrupted :)
>
> Cheers,
> Henry
>

can you tell me the symptoms?
Which package/class got corrupted?

Stef
On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote:

> See title.
> Probably caused by saving from multiple open copies of the same image so
> the .changes file source was exported from was corrupted :)
>
> Cheers,
> Henry
>

yes now I see it.
I will try to see what we can do.
Argh.....

On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote:

> See title.
> Probably caused by saving from multiple open copies of the same image so
> the .changes file source was exported from was corrupted :)
>
> Cheers,
> Henry
>

I removed 13084, 13085 and 13086 from the pipe and I'm trying to redo them.

Stef

On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote:

> See title.
> Probably caused by saving from multiple open copies of the same image so
> the .changes file source was exported from was corrupted :)
>
> Cheers,
> Henry
>

Den 13.03.2011 10:49, skrev Stéphane Ducasse:
> But we do not publish the changes anymore.
> So you think that the packages got corrupted?
>
> Stef
Doesn't matter.

Here's what can happen:
- image1 is open, and thinks it's stream on the .changes is at end
- image2 is the same image, but just imported lots of methods from an MC
package, which you intend to include in an update.
- Image1 quits, and writes the "I quit!" message to the place it thinks
is the end of the .changes file.
-Image2  files out an MC, which fetches the method definitions to write
from the .changes file.

Presto, you have a corrupt method definition in your package, and will
get an error when trying to load it, telling it couldn't parse some
nonsensical string that couldn't possibly be the methods true source.

Cheers,
Henry

Ok I'm issuing a new 13084 and going over the other fixes and collecting in new integration. slowly

On Mar 13, 2011, at 12:29 AM, Henrik Sperre Johansen wrote:

> See title.
> Probably caused by saving from multiple open copies of the same image so
> the .changes file source was exported from was corrupted :)
>
> Cheers,
> Henry
>