Differences between revisions 15 and 32 (spanning 17 versions)
⇤ ← Revision 15 as of 2008-04-16 22:45:14 →
Size: 2322
Editor: MichaelAbshoff
Comment: various updates
← Revision 32 as of 2009-05-04 13:13:24 → ⇥
Size: 4293
Editor: MichaelAbshoff
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Hello, I study math at the University of Dortmund. Most of the time I spend with SAGE is dedicated around packages and their portability. I added valgrind support to Sage 2.8.3 and have been using various valgrind tools to investigate Sage's memory consumption. == Contact Information ==
Line 5: Line 5:
I also recently become a release manager for Sage and I chaired a number of releases: 2.8.11, 2.8.13-2.8.15, 2.9, 2.9.2, 2.10 and 2.10.1-3, 2.10.4 (together with Robert Miller), 3.0. Since it looks like few people want to do this job it is very likely that I will do a lot more of those.  * For an email address check [[http://groups.google.com/groups/profile?enc_user=GGRP9BcAAAAZQo9hoMaeKCAqGq1BeY9EHqZiDvCVswhrZ6TQxKj0ww|this Google profile]]
 * I hang out in #sage-devel on freenode
Line 7: Line 8:
== Task Table == == Involvement with Sage ==
Line 9: Line 10:
=== Currently Working on ===
 * Probably chairing the current Sage release
 * Solaris port of Sage.
 * FreeBSD port of Sage.
 * MSVC port of Sage
 * Cygwin re-port of Sage.
 * optional spkgs: CoCoA 4.7.x, ApCoCoALib & CoCoALib, g++ 4.2
 * hunt mem-leaks in C/C++ code of Sage
 * DebianSAGE		 In addition of heading the Solaris as well as Windows port of Sage I am also the main release manager. So far I have chaired 33 releases:

 * 2.8.11, 2.8.13-2.8.15
 * 2.9, 2.9.2-3
 * 2.10, 2.10.1-3, 2.10.4 (together with Robert Miller)
 * 2.11
 * 3.0, 3.0.1-6
 * 3.1, 3.1.1-4
 * 3.2, 3.2.1-3
 * 3.3
 * 3.4, 3.4.1-2

I still study math at the University of Dortmund and one day will finish my degree :)

== Sage Projects ==

=== High Level ===

 * Chairing the current Sage release
 * [[solaris|Solaris port of Sage]]
 * [[freebsd|FreeBSD port of Sage]]
 * [[windows|MSVC port of Sage]]
 * [[windows|Cygwin re-port of Sage]]
 * [[osx64|64 bit OSX port of Sage]]
 * [[ps3|PS3 port of Sage]]
 * hunt mem-leaks in C/C++ code of Sage
 * [[DebianSAGE]]
Line 19: Line 38:
 * [[http://trac.sagemath.org/sage_trac/query?status=new&status=assigned&status=reopened&owner=mabshoff&order=priority|My open trac tickets]] (the idea was shamelessly stolen from Martin Albrecht)
 * Maintain the [[sage.math/SageBinaries|collection]] of Sage releases installed on sage.math. This can be useful to pinpoint regressions or just to use older Sage releases
Line 20: Line 41:
=== Short Term ===
 * [:windows:port Sage to Windows]
 * build unified Setup.py for gdmodule - less important now due to drop of the Cygwin drop (officially)
 * multivariate polynomial arithmetic via CoCoALib
 * computation of approximate vanishing ideals via ApCoCoALib (needs multivariate polynomial arithmetic via CoCoALib)
 * check targets for various SAGE packages like gmp and linbox		 === Low Level: Build System Improvements ===
Line 27: Line 43:
=== Long Term ===
 * F4/F5 in CoCoALib with interface to SAGE		 A list of things on my ToDo list related to the build system. As things mature they will be moved to their own SEP:
Line 30: Line 45:
=== Interesting Ideas ===
 * port SAGE code to MinGW/MSVC - probably done when hell freezes over - but one can at least dream.
 * fix pari issue on cygwin - details FIXME		  * compiler classes, i.e. gcc, icc, sun cc, MSVC
 * the construct 'export MAKE="make -j10"' is bad, we need something like SAGE_BUILD_THREADS and SAGE_MAKE and use those
 * Sage on 64 bit OSX 10.5 and higher, Solaris, FreeBSD
 * gcc 4.4 snapshots or whatever else is coming up
 * OSX 10.6 coming up
 * Cygwin support coming back
 * Fortran infrastructure rework - i.e. support for g77, g95, gfortran and the SiCortex Fortran compiler
 * SAGE_DEBUG mode - i.e. '-O0 -g' - but this also needs to work with SAGE64
 * Custom CFLAGS, CXXFLAGS
 * Custom CC, CXX, FORTRAN compilers, i.e. 'CC == gcc-4.2'
 * Tier 1 vs. Tier 2 support: Tier 1 - builds and passes doctests vs. Tier 2: builds, but can fail some doctests. For Tier 2 only some configs might even build
 * SAGE_BUILD_TMPDIR:
  * use it instead of spkg/build - this could be scratch space or a tmpfs disk
  * write a script that does du -sch before deleting the spkg dir in build and then logs the amount of data, then we can use some common table in the sage_scripts repo to check for available space before building an spkg
 * spkg cleanup: split rpy.spkg from r.spkg, move the boost headers to its own spkg from polybori.spkg.
 * tmpfs like solutions for temp build dir:
  * Solaris - tmp is automatically mounted as tmpfs
  * Linux - tmpfs - http://en.wikipedia.org/wiki/TMPFS: "Usage of tmpfs for example is "mount -t tmpfs -o size=1G,nr_inodes=10k,mode=0700 tmpfs /space" which will allow up to 1 GiB in RAM/swap with 10240 inodes and only accessible by the owner of the directory /space. The filesystem's maximum size can also be changed on-the-fly, like "mount -o remount,size=2G /space"."
  * OSX: http://lists.apple.com/archives/darwin-kernel/2004/Sep/msg00004.html
Line 35: Line 67:
 * [[http://trac.sagemath.org/sage_trac/query?status=closed&owner=mabshoff&order=priority|My closed trac tickets]] (the idea was shamelessly stolen from Martin Albrecht)
Line 38: Line 71:
Line 41: Line 73:
 * Porting mathematical open source code to Solaris, Windows and any odd Unix out there.    * Porting mathematical open source code to Solaris, Windows and any odd Unix out there.
Line 44: Line 75:
 * google group sage-devel
 * google group linbox-devel
 * google group linbox-use
 * [http://apcocoa.org/forum/ the ApCoCoA & CoCoA forum]		  * google groups sage-devel, sage-support, linbox-devel, group linbox-use
 * [[http://apcocoa.org/forum/|the ApCoCoA & CoCoA forum]]
Line 49: Line 78:
Line 51: Line 79:
CategoryHomepage  CategoryHomepage

Michael Abshoff's Wiki SAGE page

Contact Information

Involvement with Sage

In addition of heading the Solaris as well as Windows port of Sage I am also the main release manager. So far I have chaired 33 releases:

  • 2.8.11, 2.8.13-2.8.15
  • 2.9, 2.9.2-3
  • 2.10, 2.10.1-3, 2.10.4 (together with Robert Miller)
  • 2.11
  • 3.0, 3.0.1-6
  • 3.1, 3.1.1-4
  • 3.2, 3.2.1-3
  • 3.3
  • 3.4, 3.4.1-2

I still study math at the University of Dortmund and one day will finish my degree :)

Sage Projects

High Level

Low Level: Build System Improvements

A list of things on my ToDo list related to the build system. As things mature they will be moved to their own SEP:

  • compiler classes, i.e. gcc, icc, sun cc, MSVC
  • the construct 'export MAKE="make -j10"' is bad, we need something like SAGE_BUILD_THREADS and SAGE_MAKE and use those
  • Sage on 64 bit OSX 10.5 and higher, Solaris, FreeBSD
  • gcc 4.4 snapshots or whatever else is coming up
  • OSX 10.6 coming up
  • Cygwin support coming back

  • Fortran infrastructure rework - i.e. support for g77, g95, gfortran and the SiCortex Fortran compiler

  • SAGE_DEBUG mode - i.e. '-O0 -g' - but this also needs to work with SAGE64
  • Custom CFLAGS, CXXFLAGS
  • Custom CC, CXX, FORTRAN compilers, i.e. 'CC == gcc-4.2'
  • Tier 1 vs. Tier 2 support: Tier 1 - builds and passes doctests vs. Tier 2: builds, but can fail some doctests. For Tier 2 only some configs might even build
  • SAGE_BUILD_TMPDIR:
    • use it instead of spkg/build - this could be scratch space or a tmpfs disk
    • write a script that does du -sch before deleting the spkg dir in build and then logs the amount of data, then we can use some common table in the sage_scripts repo to check for available space before building an spkg
  • spkg cleanup: split rpy.spkg from r.spkg, move the boost headers to its own spkg from polybori.spkg.
  • tmpfs like solutions for temp build dir:

Done Tasks

  • My closed trac tickets (the idea was shamelessly stolen from Martin Albrecht)

  • See the Changelog, the google groups sage-devel and sage-support and #sage-devel on freenode.
  • DMG installation image for MacOSX [other people did most of the work here]
  • make all packages using BLAS/Lapack use the Accelerate Framework on MacOSX. Patch for Linbox exists and will hopefully show up in Linbox svn soon

Other Software Interests

  • Linbox with MSVC
  • Porting mathematical open source code to Solaris, Windows and any odd Unix out there.

Places where I can be found

MichaelAbshoff (last edited 2009-05-04 13:13:24 by MichaelAbshoff)