[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
Linux certainly allows that mistake. What about OSX? ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen@veloxit.no] Sent: Saturday, March 12, 2011 6:29 PM To: Pharo-project@lists.gforge.inria.fr 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 <henrik.s.johansen@veloxit.no> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen@veloxit.no] Sent: Saturday, March 12, 2011 7:29 PM To: Pharo-project@lists.gforge.inria.fr 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 <bschwab@anest.ufl.edu> 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
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen@veloxit.no] Sent: Saturday, March 12, 2011 7:29 PM To: Pharo-project@lists.gforge.inria.fr 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
-- 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
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
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
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
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
participants (4)
-
Henrik Sperre Johansen -
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse