William Stein wrote: > It's important to clarify what a banner is for, what is "useful > information" and for what purpose. First, think about this -- Every > time you read a question or bug report from a user, what do you often > ask the user? > > If it is a build question: > > * what OS exactly? what hardware exactly? what compiler? did you > customize (=screw anything up) on your OS? > > If it is a usage question: > > * which version of Sage? exactly what hardware do you have? how > much RAM? what OS? precisely what binary did you install or did you > build from source?
That's my point. In many cases people don't know themselves. I've built Sage with various compiler versions, various compilers and its easy to lose track of what is what. > flat:rh wstein$ sage > ---------------------------------------------------------------------- > | Sage Version 4.1.1, Release Date: 2009-08-14 | > | Type notebook() for the GUI, and license() for information. | > ---------------------------------------------------------------------- > > Regarding the current banner (see above), the information conveyed is: > > (1) the version of Sage -- by far the most important thing -- critical. Agreed. > (2) the date it was released -- I could care less and never look at this I guess it could be of use if someone uses a machine and finds Sage is 3 years old, they might consider looking around for a newer version. I doubt any developer would care, but it could be useful to an end user. > (3) How to start the notebook interface -- obviously I don't care, > but new users find this very important, I would guess? I think it is useful to have. > What is missing? > > (5) Is this an install from a binary -- I have sage installs all > over the place, some built from source, some from binary built > elsewhere, etc. Whether Sage was built from source *on this machine* or > not can have a profound impact on raw performance (because of libraries > like ATLAS). It would be very useful when I start Sage somewhere to > have something in the banner that indicates the build status of this > Sage install. Agreed. I suggest a test which indicates when it was built on a different machine and gives out more information in that case. Both Solaris and linux support 'hostid' but not OS X. I don't know if there is anything you could do other than look at the hostname. That is not very reliable, but is better than no test at all. > (6) stats on the actual computer I'm using -- this would be very > useful. If I fire up Sage on one of the 30-40 login shells I have, it > would in fact be very nice to have a line telling me that this computer > has 24 2.6Ghz processors and 128GB of RAM, but another has 1 1.6Ghz > processor and 1GB RAM. That would be a useful thing to have summarized > on startup, since it gives you a sense of how you should use Sage. It > would also be useful in any virtual machine that Sage runs in, since it > would remind the user that even if their computer has 16GB RAM and 16 > cores, the virtual machine might be configure to only use 384MB and 2 > cores. > (7) something about the system load -- whenever I fire up sage on > sage.math.washington.edu <http://sage.math.washington.edu> (say), I end > up having to check top to get a sense of what is realistic given current > load. So I do > > sage: !top I don't know how portable it is, but on Solaris at least, getloadavg() is a system call to get this. There is no need to rely on 'top', which is any case is not accurate on modern unix systems. I've never really managed to understand what the loadaverage is myself though. Certainly there appears to be some exponential (or similar) time-weighting of the data, which is not apparent from the man pages. With multi-core and multi-threaded CPUs, it is less clear what is a reasonable load average. I asked some time back on comp.unix.solaris what would be a reasonable load average for 't2'. It has 16 core and 128 hardware threads, so 16 or 128 might have been reasonable. But I gather it is not as simple as that now. However, I think it would provide something useful to look at while python loads! > to find out how much free RAM, what the recent load is, etc. Determining the amount of free memory is not so easy to do - I would not trust what 'top' say on a modern system. You detect when one is low on ram when pages get swapped to disk. Until that happens, I don't know of any sensible way of getting how much memory is free. > (8) is this a 64 or 32-bit Sage install -- this is often very > important since it impacts how I use Sage, and has a major impact on > runtimes. Yep, I agree. IMHO, it is better to put too much information than too little. One could always have a file which limits the output to the version and license if that is all one wanted to see. --~--~---------~--~----~------------~-------~--~----~ 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 URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
