On Sun, Oct 11, 2009 at 4:22 PM, Gonzalo Tornaria <torna...@math.utexas.edu> wrote: > > On Sun, Oct 11, 2009 at 8:09 PM, Dr. David Kirkby > <david.kir...@onetel.net> wrote: >> >> Gonzalo Tornaria wrote: >>> Would it make more sense to include something like busybox >>> (www.busybox.net) into sage? >> >> I do not believe so. > > [snip] > >> Sage is designed to run on workstations and servers, not small embedded >> systems. As such, would it not be better to support the Unix standard? > > My point is, wouldn't it be better if developers use the exact tools > that sage is targeting? > > A standard is nothing more than an abstraction; the actual tools will > always deviate from the standard in one way or another (if nothing > else, by having more features available). When you write unix shell > scripts, testing compatibility with varying real tools is already > quite hard; testing compatibility with a standard may be impossible. > > The suggestion is, instead of targeting an abstract standard (posix), > why not target a particular implementation of the standard. Busybox is > just one option; there may be others (e.g. gnu shellutils/textutils). > One advantage of busybox is its size which makes it reasonably "cheap" > to include with sage. > > Take into account that most developers use gnu tools every day, so > gnuisms are bound to show up one way or another. You'll have to be > chasing them forever :-) > > Besides, IMHO, sticking with "pure posix" seems as silly as it would > be sticking with python 2.3 (say) "because that's the lowest common > version available in the supported targets". > >> BusyBox appears to support a subset of the options of the more common >> GNU tools. That subset may not be sufficient and I feel would likely be >> too limiting. > > Posix supports a subset of the options of the more common GNU tools. > That subset is often not sufficient, and too limiting (and sometimes > frustrating for users of GNU tools). YMMV :-) > > Just my 2 cents on this issue... >
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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
