On Fri, May 14, 2010 at 09:58:57PM +0300, Igor Stasenko wrote: > On 14 May 2010 04:27, David T. Lewis <[email protected]> wrote: > > On Fri, May 14, 2010 at 02:33:38AM +0300, Igor Stasenko wrote: > >> 2010/5/14 Mariano Martinez Peck <[email protected]>: > >> > > >> > > >> > On Thu, May 13, 2010 at 8:26 PM, St??phane Ducasse > >> > <[email protected]> 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
