I have compiled and run Sage 3.2.3 on my T-Mobile G1 cell phone, and large portions of it actually work.
300 files had failing doctests; this means that all doctests passed in 864 files. A lot of the failing doctests are with pexpect (maxima, gap, etc.); I don't know why these fail. When I try simple things with gap and maxima, they do work. Many more tests fail due to timeouts; the 300-second timeout is far too short for the G1. (Doctesting any file with doctests takes >50 seconds; doctesting a file with no doctests takes >4 seconds. The entire doctest run took 270724 seconds, or a little over 3 days.) Unfortunately, it's far too slow to be useful for anything (just starting Sage takes about a minute, if there's enough free memory; but since Android likes to keep the memory full all the time, there never is enough free memory, and it takes much longer to start). So I don't plan to do anything further with the project. Of course, the sensible way to do this is to find some nice fast computer and set up a cross-compiler. I didn't do this the sensible way; I actually did the build on the cell phone. And of course, the build would stop every once in a while due to a bug, which I would then patch around. So, adding up the 14 chunks of compilation involved, the entire compile took 20943 minutes of real time (about 14.5 days) and 9438 minutes (about 6.5 days) of CPU time. You'll note that the CPU time adds up to less than half of the real time; most of the rest of the time was spent swapping. The G1 has about 100MB of RAM; I set up a swap file on my micro-SD card, to allow the build to proceed at all. On several files, the compiler uses more than 300MB. While compiling those files, the CPU is typically less than 1% active; I'm pretty sure that there were files that took more than a day to compile. The phone was essentially unusable for smartphone activities (web browsing, etc.) while the build was running. In fact, the whole smartphone UI crashed and restarted on a fairly regular basis during the build (I'm guessing it has some sort of watchdog timer and reboots itself if it detects that some operation is taking an unreasonably long time), but the build just continued anyway (running inside a screen session). The ATLAS tuning process took about 3.2 days (with almost as much CPU time as real time; that didn't swap much). Skimming through the logs, I see reports of numbers like 3 to 6 MFLOPs. The build was performed inside a Debian armel testing chroot; it's pretty nice being able to run real Debian on my cell phone. (Everything works; I can ssh in and out, etc., although when it's on the cell phone network, inbound connections are problematic because it's behind a NAT.) To make the whole project even more pointless, since the phone is running real Debian (inside the chroot), I can probably just wait a few weeks or months for Tim Abbott to get all the portability issues fixed in the sagemath Debian package, and then install Sage on the phone with apt-get. Here's the processor: cwi...@localhost:/tmp$ cat /proc/cpuinfo Processor : ARMv6-compatible processor rev 2 (v6l) BogoMIPS : 383.38 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 6TEJ CPU variant : 0x1 CPU part : 0xb36 CPU revision : 2 Cache type : write-back Cache clean : cp15 c7 ops Cache lockdown : format C Cache format : Harvard I size : 32768 I assoc : 4 I line length : 32 I sets : 256 D size : 32768 D assoc : 4 D line length : 32 D sets : 256 Hardware : trout Revision : 0080 Serial : 0000000000000000 Carl --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send 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 -~----------~----~----~----~------~----~------~--~---
