David Roe wrote:
If 4.3 plus one single patch would do it, I think it's completely worth while.

Yes, me too. Minh has now created the file. I'm just building it now.

If you know what that patch should be, make a ticket and post it.

The patch is this one.

http://trac.sagemath.org/sage_trac/ticket/6595

it was very close to getting into Sage 4.3. Though after it did not, I expanded it somewhat, so it should work not only on Solaris, but on other operating systems too.

Having a version that works on Solaris out of the box is worth having an out of sequence release.

Yes, I thought so, which is why I suggested it.

Then we just need a source tarball at minimum, right?

Yes.

Are there sufficiently few architectures that making binaries is reasonable?

Yes. The only issue we have is that 't2' runs the latest version of Solaris 10, and so a binary built on there would not be guaranteed to run on an earlier version of Solaris 10. There have been about 7 updates since Solaris 10 was released in 2005. However, I have set up a machine here where I can build a binary on the first release of Solaris 10. It would be worth my while doing that. The only issue is the machine is quite old, so it will take several days to build, and several days for me to upload it!

If it's just source, then I'm sure we can give you a sequence of mercurial commands to build the appropriate tarball from one patch.

Minh has done it.

However, I agree with Robert that requiring patch authors to test their changes on every system Sage supports is unreasonable. That should be part of the release manager's job (though maybe we need better build farms and scripts to facilitate this).

I think given the advantages of building on multiple architectures (often bugs show on one but not on another), the fact there will be different rounding on different CPUs, does make it worth while. It is reasonable to assume some code works, just because it works on your computer?

See Williams comment on that ticket

"Wow. I fixed the first bug that the Sun compiler finds (which doesn't matter), and it next found two more similar issues -- which in fact *are* both major bugs. See attached patch."

Those serious bugs were both examples of where a function was called, a result computed, but never returned to the calling function. The Sun compiler did not accept that, but gcc/g++ did.

I regularly used to test software on multiple platforms, but a script which set up a load of ssh jobs on a remote system. Not elegant, but it did work. It really does tend to uncover bugs - especially if another compiler can be used.

But ideally a build farm is needed, but that is a non-trivial task to set up. It would take a lot of someone times. Unfortunately, 't2' would be a bottleneck, as the processors are very unsuitable for this sort of task.



Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to