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