William Stein wrote: > > I really like Gonzalo's suggestion to think of specific tools and also > the actual people involved, rather than abstractions and standards. > > Ideas for tools: > > * a GNU toolchain > * Busybox > * Python itself > > One can make a strong argument for writing a lot of the spkg-install's > in Python, which provides a powerful well-documented cross-platform > abstraction for all standard OS stuff (copying files, joining PATHs, > making tarballs), which is also easier to refactor. And this > abstraction is certainly more cross platform than POSIX. As an > example, the build system for the Windows port is written in Python > (by Blair Sutton) and it is nicely cross-platform in flavor. > > For the Sage notebook code, during the last two weeks I've spent a lot > of time replacing things like "/" and explicit calls to "tar", etc., > with OS-independent Python code (e.g., os.path.join; import tarfile, > etc.). > > -- William
I can see some advantages in this too, but also some pretty significant disadvantages. * Native compilers are normally better than the GNU ones (I know you found a report the other day, where this was not so, but if you look at all the comments, you will find many thought the testing was seriously flawed). * Native compilers are more fussy about the quality of C code than the GNU compilers. By using native compilers, we can find problems and report them upstream, or fix them ourselves. * An all-GNU approach would lead people to spend even less time testing code on other platforms. In my experience, testing on other platforms is one of the best way to track bugs. I recall once pulling my hair out over a problem I only ever see on AIX. When I did finally tracked that problem down, I realised that it was a locking problem in my multi-threaded code. It could have potentially hit any platform. I also recall a colleague who had some multi-threaded code which worked fine on Linux, but when run on a quad processor Sun, would fail. He eventually found it was a bug in his code, which for some reason had never showed on Linux, but was in effect waiting to hit one at a later date. The bug I found the other day http://sagetrac.org/sage_trac/ticket/7188 was only noticed when I tested on HP-UX. I'd never noticed it on Solaris, though it was actually broken there too. I realise in this case, the bug was pretty insignificant, but had the code been tested on Solaris, (which is a supported platform), it would have been found. As more and more machines have multiple cores, more and more code will be written to exploit multiple CPUs. Bugs in such code can easily be missed, and just result in the occasional incorrect result. By encouraging testing on multiple platforms, such bugs are more likely to surface. Using an all-GNU toolchain will just give people less incentive to test on other platforms. Some components of Sage (lcalc being one example that comes to my mind), took steps to hide warning messages using GNU-specific flags (-Wa,-W if memory serves me correct). I only found that, since Sun's assembler did not understand the -W flag. Such behavior would not be discovered by testing with an all GNU tools. IMHO, Sage could do with a bit more emphasis on quality. Using all GNU tools in an attempt to increase portability, would certainly be a step in the wrong direction to me. 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 -~----------~----~----~----~------~----~------~--~---
