On Fri, May 14, 2010 at 09:58:57PM +0300, Igor Stasenko wrote:
On 14 May 2010 04:27, David T. Lewis <lewis@mail.msen.com> wrote:
On Fri, May 14, 2010 at 02:33:38AM +0300, Igor Stasenko wrote:
2010/5/14 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, May 13, 2010 at 8:26 PM, St??phane Ducasse <stephane.ducasse@inria.fr> wrote:
mariano
i just released a fix could you stress the system?
wiiiiiii
My .changes is now 36MB. It seems to work ok.
Don't climb too high , failing would be painfull :)
Actually you should keep climbing! The address mapping needs to do strange things on the 32MB boundaries for backward compatibility with the original 32MB address mapping. So keep loading those Seaside packages until you get to at least 150MB or so, just be to sure it keeps working over 32MB -> 64MB -> 96MB -> 128MB ...
Isn't it would be wiser to do a simple numerical tests, instead of manually tossing bunch of code into the .changes?
Of course numerical tests are needed, which is why I provided the tests in ExpandedSourceFileArrayTest. I'm sure that Pharo will pass all those tests. But the test that did not pass was a real user adding to a real changes file, which triggered a side effect unrelated to the numerical conversion. So I would have to say that skipping the crude manual test was not wiser in this case. Dave