On 5 June 2010 10:44, Robert Bradshaw <[email protected]> wrote:
> On Jun 5, 2010, at 1:55 AM, David Kirkby wrote:
> Fortunately, most patches only involve rebuilding a small number of files
> (potentially just pure Python in the Sage library), so a full rebuild would
> not be needed.
But a lot of standard .spkg files do get updated on a regular basis.
I've got about 10 .spkg files awaiting review just now. But I'm far
from the only one.
>> I urge William if possible to try to get some money for a decent SPARC
>> machine. 't2' is very very very slow. The skynet SPARC boxes are just
>> very slow. They are old machines running at 1.28 GHz. (The Blade 2500
>> was introduced in 2003, so they are 7 years old).
>>
>> If Oracle would agree, selling or part-exchanging 't2' would be one
>> solution. I suspect 't2' would fetch nearly enough money to buy a
>> eight-core M3000, which would blow 't2' away for what we use it for.
>> ('t2' is designed for a VERY different task to what we use it for).
>
> If we had a pull, rather than push, build farm, then those with hardware
> they cared about Sage working on could participate by donating their cycles
> more easily. That's a more scaleable solution as well. Perhaps we could take
> advantage of http://gcc.gnu.org/wiki/CompileFarm occasionally as well?
There is a big problem with Solaris on SPARC though.
Despite a lot of money/time/effort being spent on it, nobody
developing it has any decent SPARC hardware. Available hardware
consists of:
* ''t2' , modern machine, 900 MHZ, designed for something very
different to what we use it for
* 7 year old 1.28 GHz Sun Blade 2500 on Skynet
* 8 year old, 1.2 GHz Sun Blade 2000 of mine.
The fastest SPARC on the GCC build farm is 500 MHz..
IMHO, if William possibly can, I believe he should look at trading
that T5240 for something more suitable.
> How do deal with spgks vs. the standard library is a sticky issue--certainly
> the latter could be automated much more easily, and is where most of the
> development takes place (though also much less likely to be platform
> dependent).
At the moment most standard packages build on SPARC in 64-bit mode
the library does not. To be fair, I know of one of the problems and
have not fixed it yet, but I would not be surprised if there are
others.
>> So 70% (based on that small sample) are patches to correct defects.
>
> Some of those ticket numbers looked familiar, and indeed three of them that
> I worked on should have been labeled enhancement. (Defect is the default, if
> one doesn't change it--it's probably be better to have a blank default then
> it's clear when something hasn't been filed correctly.) Still way to many
> bugs.
Really, correctly classifying these things is pretty important, as it
would allow any trends to be found, like an unusually large change in
the fraction of bugs would be worrying.
I think there needs to be a "bugfix+enhancement" option as some of the
patches correct a bug, but enhance something too.
> I'm a huge fan of both more testing and more automation.
>
> - Robert
Dave
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
