Suspicious file in a binary distribution?

[Dr. David Kirkby]

Trying to create a binary distribution on Solaris, I find some rather suspicious
looking files are being added:

sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/symmetrica/
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/symmetrica/symmetrica.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/mpmath/
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/mpmath/utils.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/cremona/
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/cremona/homspace.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/cremona/mat.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/cremona/newforms.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_GF2.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_GF2E.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_GF2EContext.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_GF2EX.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_GF2X.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_lzz_p.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_lzz_pContext.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_lzz_pX.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_mat_GF2.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_mat_GF2E.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_mat_ZZ.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_ZZ.o
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/ntl/ntl_ZZX.o


There can not be any need for object files can there?

I've no idea where the directory temp.solaris-2.10-sun4u-2.6 comes from.

This could explain why the binary is much larger than William expected. (The
.tar.gz file is 729 MB in size, though I had to copy two gcc libraries that you
would not need to do on linux).

I would add, this was upgraded from 4.2 to 4.2.1. Would this temp directory have
been created then? I'm puzzled how it got there, but it seems wrong to me to be
copying over a huge number of .o (object) files.


Dave

[Dr. David Kirkby]

Having looked more, I see there is 135 MB in directories with the name
temp.solaris-2.10-sun4u-2.6.



drkirkby@kestrel:~/sage-4.2$ find . -name temp.solaris-2.10-sun4u-2.6
./spkg/build/ginv-1.9-20080723/src/build/temp.solaris-2.10-sun4u-2.6
./devel/sage-main/build/temp.solaris-2.10-sun4u-2.6
./devel/sage-myver/build/temp.solaris-2.10-sun4u-2.6
./dist/sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6
drkirkby@kestrel:~/sage-4.2$ du -ks `find . -name temp.solaris-2.10-sun4u-2.6`
11 ./spkg/build/ginv-1.9-20080723/src/build/temp.solaris-2.10-sun4u-2.6
138650 ./devel/sage-main/build/temp.solaris-2.10-sun4u-2.6
138650 ./devel/sage-myver/build/temp.solaris-2.10-sun4u-2.6
138650
./dist/sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6

[William Stein]

The reason for these files is so that if a user modifies the Sage
library and then types "sage -br" it takes a few seconds the first
time instead of an *hour*. This makes an absolutely dramatic
difference in whether or not somebody will develop on Sage. If their
first
experience is:

1. Modify Sage's library code
2. Type "sage -br" and wait 1-2 hours to see the result...

they probably aren't left with a warm fuzzy feeling. Given that an
extracted Sage install is about 1.5GB (or more), this extra 130MB is
well worth it.

-- William

[Dr David Kirkby]

Fair enough, I understand that now.

I'm puzzled why the Solaris binary is so big compared to the others. I
checked over it briefly and found the links to libraries are links,
not duplicate copies. Perhaps I have a core dump or something like
that - I will look more closely. If all is well, I'll upload version
4.2.1 built on the first release of Solaris 10.

I just looked on the Wolfram Research site, to see the size of the
binaries for a trial version.

http://www.wolfram.com/products/mathematica/experience/request.cgi

Solaris is the biggest, but not by a large amount. The sizes are:

Solaris 695.42 MB
Linux 647.57 MB
Mac 616.04 MB
Windows 474.76 MB

Dave

[rjf]

While it may not be entirely helpful to point it out, I thought that
one of the advantages of using
python was some kind of rapid development. NTL is not in python so
maybe it doesn't "count"?

In the Maxima environment, if someone detects an error in a lisp
function, FF then the function
can be replaced in the run-time environment, e.g. at a command line
(%i100) by:
:lisp (defun FF(x y z) <newdefinition>)

it could be run interpretively or compiled. Compilation can also be
invoked from the command line.

If the replacement works, the replacement (or a command to load the
compiled version from a file)
can be place in an initialization file so that the next time Maxima is
loaded, the fix is automatically loaded.

This doesn't fix the problem for people at remote locations. Early in
the Macsyma development when
essentially all users were running on one of 2 or 3 computers at MIT
via the ARPANET, such fixes
took effect for all users. Maybe such a setup could be used for the
web-based access to Sage.

(It's kind of interesting to realize that this idea -- of users
accessing a time-shared or networked-access
computer to use a math system -- was standard between say 1966 and
1980, and continued on for some time..)
(In the years after 1980 some 50 VAX-Macsyma test sites were set up,
and later the program was sold etc.)
RJF


I think that compiling all of Maxima typically takes between 10
minutes and an hour, depending on your
machine and your choice of Lisp system. That doesn't include re-
making the lisp system itself (probably
written in C) or the C compiler.

[Harald Schilly]

On Dec 2, 5:01 pm, rjf <fate...@gmail.com> wrote:
> In the Maxima environment, if someone detects an error in a lisp
> function, FF then the function
> can be replaced in the run-time environment, e.g. at a command line
> (%i100)  by:
>   :lisp (defun FF(x y z) <newdefinition>)
>

In the Python environment, if someone detects an error in a Python
function FF, then the function can be replaced in the run-time
environment, e.g. at a command line by:

>>> def FF(x):
... return 2*x
...
>>> print FF(2)
4

# FF is wrong, now correcting:

>>> def FF_correct(x):
... return 3*x
...

# and replacing

>>> FF = FF_correct
>>> FF(2)
6

>
> If the replacement works, the replacement (or a command to load the
> compiled version from a file)
> can be place in an initialization file so that the next time Maxima is
> loaded, the fix is automatically loaded.

That also holds for Python, but we tend to modify the source code
directly. Then the underlying version control system is used to
extract a patch that represents the modifications. Those patches can
be uploaded to our issue tracker for review, etc.

> ... such fixes

> took effect for all users. Maybe such a setup could be used for the
> web-based access to Sage.

That's in the planning stage for Sage. Collaborative environments for
development would foster even more contributions to the Sage project!

> (It's kind of interesting to realize that this idea -- of users
> accessing a time-shared or networked-access
> computer to use a math system -- was standard between say 1966 and
> 1980, and continued on for some time..)
> (In the years after 1980 some 50 VAX-Macsyma test sites were set up,
> and later the program was sold etc.)

Yes, it's "interesting". But personally, I tend to see this as a
probably erroneous break in the overall trend. In the 70ties the
social focus was still on a group, the 80ties focused on the
individual. In music, art, personal computing and more the people were
seen as individuals, not as part of groups. Often, there were
commercial interests behind - more PCs sold, more operating systems,
single artists pushed (pop idols), ... Internet and social
applications bring people back together since 2000. That's an
important trend for collaboratively developed software, especially
free/open source software.

>
> I think that compiling all of Maxima typically takes between 10
> minutes and an hour

We appreciate these rather short compilation times, since it is part
of Sage's compilation process.

H

[John H Palmieri]

On Dec 2, 10:46 am, Harald Schilly <harald.schi...@gmail.com> wrote:
> On Dec 2, 5:01 pm, rjf <fate...@gmail.com> wrote:
>
> > In the Maxima environment, if someone detects an error in a lisp
> > function, FF then the function
> > can be replaced in the run-time environment, e.g. at a command line
> > (%i100)  by:
> >   :lisp (defun FF(x y z) <newdefinition>)
>
> In the Python environment, if someone detects an error in a Python
> function FF, then the function can be replaced in the run-time
> environment, e.g. at a command line by:
>
> >>> def FF(x):
>
> ...     return 2*x

By the way, I discovered accidentally that from the command line (not
the notebook) if you type:

sage: ed # or %ed or %edit

then it opens up your favorite editor (whatever is set by the $EDITOR
shell variable). Then in the editor you can type

def FF(x):
long definition here
which would be really annoying
to type on the command line

then save it -- it gets written to a temporary file -- and the code
gets executed and you have thus redefined FF. Then later you can do

sage: ed FF

and it will let you modify your code. This is an ipython feature, it
seems. Should it be described somewhere in the Sage documentation?

--
John

[Nick Alexander]

> In the Python environment, if someone detects an error in a Python
> function FF, then the function can be replaced in the run-time
> environment, e.g. at a command line by:

This is technically true but in practice not useful. Most Python code
is not a top-level function; it is a class member function. It is
possible to update a member function (try it!), but not a Cython class
member function. And even when you do update a member function, there
is in general no way to update existing instances of the class,
meaning that your mis-behaving object is not fixed. Various modules
(reload, xreload) try to address this, but Python's design works
strongly against this. For example, even if you update top-level
function, any module that already imported the old version retains the
old version. Smalltalk and Lisp (including CLOS?) have supported this
feature since their inception. Ruby too.

Nick

[Nils Bruin]

On Dec 2, 11:47 am, John H Palmieri <jhpalmier...@gmail.com> wrote:
> sage: ed   # or %ed or %edit
>
> then it opens up your favorite editor (whatever is set by the $EDITOR
> shell variable).  Then in the editor you can type
>

> sage: ed FF
>
> and it will let you modify your code.  This is an ipython feature, it
> seems.  Should it be described somewhere in the Sage documentation?

edits made in this way will only affect the runtime copy. Upon the
next sage -b, they will be overwritten with the original definition.
If you want to edit sage library code, you can do edit
(sage.object.function,editor="vi") or something similar to open an
editor on the appropriate definition in the current hg branch. This
also works for cython code. Edits only take effect upon the next sage -
b.

[Minh Nguyen]

Hi John,

On Thu, Dec 3, 2009 at 6:47 AM, John H Palmieri <jhpalm...@gmail.com> wrote:

<SNIP>

> By the way, I discovered accidentally that from the command line (not
> the notebook) if you type:
>
> sage: ed # or %ed or %edit

That is so cool! And very useful, too! What a serendipitous discovery!

> and it will let you modify your code. This is an ipython feature, it
> seems. Should it be described somewhere in the Sage documentation?

That feature deserves some documentation at least in the Developers'
Guide. This is now ticket #7586 [1]. Users and developers, at least
myself, often work with the Sage command line to develop code or
modify existing source files. My typical work flow involves having two
terminal windows: one to show the Sage command line session; another
to show a terminal Emacs session. I would use the command "load"
and/or "attach" to (automatically) load the modified source file so
that I could experiment with the new code.

Of course, there's also the command "iload" to interactively load a
file. When using "iload", one has to repeatedly press Enter in order
to load the next line in a source file. But the good thing is that for
every line loaded with "iload", if the line produces some output then
the output is printed as well. One could think of "iload" sort of like
individually entering every line at the Sage command line interface.
As an aside, there's also the function "edit()" in the Sage library.

And now you report about "ed", "%ed" and "%edit" to do a similar thing
as described above, but without having to open two terminal windows.
Plus, after one is done editing a file, closing the editor would also
trigger an automatic reloading of the modified file. That is just
awesome to have and I'm grateful to the IPython developers for this
nifty feature.

[1] http://trac.sagemath.org/sage_trac/ticket/7586

--
Regards
Minh Van Nguyen

[Dan Drake]

On Wed, 02 Dec 2009 at 11:47AM -0800, John H Palmieri wrote:
> By the way, I discovered accidentally that from the command line (not
> the notebook) if you type:
>
> sage: ed # or %ed or %edit

Oh man, that is great. Often I am trying to type in a multi-line
statement and I mess something up and can't figure out how to fix it,
since there's no going back a line, or parenthesis highlighting,
etc...this is great!

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

[Jason Grout]

Dan Drake wrote:
> On Wed, 02 Dec 2009 at 11:47AM -0800, John H Palmieri wrote:
>> By the way, I discovered accidentally that from the command line (not
>> the notebook) if you type:
>>
>> sage: ed # or %ed or %edit
>
> Oh man, that is great. Often I am trying to type in a multi-line
> statement and I mess something up and can't figure out how to fix it,
> since there's no going back a line, or parenthesis highlighting,
> etc...this is great!
>

This is great. However, there is a warning message printed out for me.
Everything seems to work, but the warning message looks odd.

% sage
----------------------------------------------------------------------
| Sage Version 4.2.1, Release Date: 2009-11-14 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: ed
IPython will make a temporary file named: /tmp/ipython_edit_Rcmp2W.py
Editing...vi: /home/grout/sage/local/lib/libz.so.1: no version
information available (required by /usr/lib/libpython2.6.so.1.0)
done. Executing edited code...
'def f(x):\n summ=0\n for i in range(x):\n summ+=i\n return summ\n'

This is on Ubuntu 64-bit 9.10.

Jason

[John H Palmieri]

On Dec 2, 3:24 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Dan Drake wrote:
> > On Wed, 02 Dec 2009 at 11:47AM -0800, John H Palmieri wrote:
> >> By the way, I discovered accidentally that from the command line (not
> >> the notebook) if you type:
>
> >> sage: ed   # or %ed or %edit
>
> > Oh man, that is great. Often I am trying to type in a multi-line
> > statement and I mess something up and can't figure out how to fix it,
> > since there's no going back a line, or parenthesis highlighting,
> > etc...this is great!
>
> This is great.  However, there is a warning message printed out for me.
>   Everything seems to work, but the warning message looks odd.

Well, clearly you should be using emacs instead of vi :)

--
John

[Jason Grout]

Aah, the answer to all of life's problems! :)

% export EDITOR=emacs

% sage
----------------------------------------------------------------------
| Sage Version 4.2.1, Release Date: 2009-11-14 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: ed

IPython will make a temporary file named: /tmp/ipython_edit_2rTlsW.py
Editing... done. Executing edited code...
'def f(x):\n return sum(range(x))\n'
sage:

Jason

[Nick Alexander]

>> Well, clearly you should be using emacs instead of vi :)
>
> Aah, the answer to all of life's problems! :)

I would say, clearly you should use sage-mode from within emacs. Why
not edit emacs buffers with all the tools that you would expect, plus
deep integration between your buffers and the sage interpreter?

Nick

[Alex Ghitza]

On Wed, Dec 02, 2009 at 09:08:11PM -0800, Nick Alexander wrote:
>
> I would say, clearly you should use sage-mode from within emacs. Why
> not edit emacs buffers with all the tools that you would expect, plus
> deep integration between your buffers and the sage interpreter?
>

Nick,

I know you have other things to do, but do you think you could write a
quick-start guide to sage-mode? I am an emacs user (but nowhere near
a power user), and so far I've only used sage-mode as a syntax
highlighter when editing code. I would love to know a bit more about
what I can do with sage-mode. (If there's already a place where I can
find this out, please let me know.)


Best,
Alex



--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/

[Pierre]

> I know you have other things to do, but do you think you could write a
> quick-start guide to sage-mode?  

here are the very basics :

** install sage-mode as instructed, and modify your .emacs accordingly
(you didn't have any trouble there did you ?)

** go "alt-x run-sage" to start the thing. (Takes quite some time to
start, on my macbook.)

** some people (me, for example) also need to type in "alt-x sage-
view" to start the latex rendition of formulae. I also usually add,
whenever i'm going to plot something, "alt-x sage-view-disable-inline-
plots" so that my plots will appear in external windows. Apparently
that's just me ! but think of how much space the plots will take in an
emacs buffer.

** open a .sage file in emacs, and go "ctrl-c ctrl-c" whenever you
want to load the file into sage. Same with a .py i think. I forget
what happens with .spyx (i've only tried once out of curiosity).

** personally i add this to my .emacs :

(defun sage-attach-current-buffer ()
"attach current .sage file"
(interactive)
(process-send-string (get-buffer "*SAGE-main*")
(concat
"attach \""
(buffer-file-name (current-buffer))
"\"\n")))

this way i can go "alt-x sage-attach-current-buffer" and well, the
current buffer (which'd better be a .sage file) gets attached. It's
really cool : as soon as you save your file, the modifications are
taken into account. A typical quick sage session for me almost
invariably involves attaching a "foo.sage" (or temp.sage or
scratch.sage or...), keeping it in one buffer for long-ish function
definitions, and having sage itself in the buffer nex to it.

** that's about it!

[Nick Alexander]

On 4-Dec-09, at 12:33 AM, Pierre wrote:

>> I know you have other things to do, but do you think you could
>> write a
>> quick-start guide to sage-mode?

Thanks for posting the basics, Pierre. Allow me to add a few
interesting snippets.

> ** open a .sage file in emacs, and go "ctrl-c ctrl-c" whenever you
> want to load the file into sage. Same with a .py i think. I forget
> what happens with .spyx (i've only tried once out of curiosity).

The equivalent of using %ed, if you make your *scratch* buffer have
the sage-mode bindings by default:

* Select a region and try `sage-send-region' (C-c C-r).

For regular coders/testers, the following are essential.

* When interrogating code, ? and ?? open a *help* buffer and the
source code in a new buffer. For me, iut's faster to switch to my
*sage* buffer and interrogate the source than remember where a file
is. BTW, I map C-c C-z to `python-switch-to-python' and modify that
function to bring *sage* forward in the bottom half of the window.

* Also useful, `sage-send-doctest' (C-c C-j). At the end of a
doctest, send the doctest contents to the *sage* buffer and move to
the next doctest. Allows interactive running of doctests. With
prefix argument (C-u C-c C-j) sends all doctests in this docstring.

For sage library developers, the following are useful.

* First, `rerun-sage' kills sage (soft kill, then hard kill) and
restarts it without wiping your history.

* To rebuild the sage library, try `sage-build' (C-c C-b). This runs
`sage -b'. With prefix argument (C-u C-c C-b) this rebuilds and then
reruns sage, the equivalent of `sage -br'.

* To test the sage library, try `sage-test' (C-c C-t). This runs
`sage -tp 4 ...' and tries to guess what to test. Both `sage-test'
and `sage-build' interface to the `compile' emacs-mode and try to be
intelligient about presenting errors, etc.

Thanks again, Pierre, for getting this started.

Nick

[Robert Bradshaw]

On Dec 2, 12:12 pm, Nick Alexander <ncalexan...@gmail.com> wrote:
> > In the Python environment, if someone detects an error in a Python
> > function FF, then the function can be replaced in the run-time
> > environment, e.g. at a command line by:
>
> This is technically true but in practice not useful.  Most Python code  
> is not a top-level function; it is a class member function.  It is  
> possible to update a member function (try it!), but not a Cython class  
> member function.  And even when you do update a member function, there  
> is in general no way to update existing instances of the class,  
> meaning that your mis-behaving object is not fixed.  

It is possible to change the class definition at Python, and have all
instantiated objects updated:

sage: G = SymmetricGroup(5); G
Symmetric group of order 5! as a permutation group
sage: G.is_finite()
True
sage: SymmetricGroup.is_finite = lambda x: False
sage: G.is_finite()
False

I've not found this particularly useful myself, though replacing a
member function on a particular instance can be handy (e.g. telling
Sage that Z/nZ is a field without doing a primality test on n).

This is not possible for compiled C extensions though, which is one
disadvantage of using Cython.

> Various modules  
> (reload, xreload) try to address this, but Python's design works  
> strongly against this.  For example, even if you update top-level  
> function, any module that already imported the old version retains the  
> old version.  Smalltalk and Lisp (including CLOS?) have supported this  
> feature since their inception.  Ruby too.

Depends on how the import was done. If I import math, then refer to
math.sin, a lookup happens every time and this can be updated. If,
however, I do "from math import sin" this is an assignment "import
math; sin = math.sin" and updating the math module does not remove the
handle to the original function.

- Robert

[Alex Ghitza]

On Fri, Dec 04, 2009 at 09:28:11AM -0800, Nick Alexander wrote:
>
> On 4-Dec-09, at 12:33 AM, Pierre wrote:
>
> >> I know you have other things to do, but do you think you could
> >> write a
> >> quick-start guide to sage-mode?
>
> Thanks for posting the basics, Pierre. Allow me to add a few
> interesting snippets.
>

Pierre and Nick, thanks for this. I'll give it a spin.

To answer one of Pierre's questions, I never had problems installing
the spkg and modifying my .emacs to get sage-mode going. One weird
thing is that in my emacs menu bar, there are menu headers for both
Sage and Python, but both menus are empty.

In any case, I'll play around with the features you described.

[rjf]

On Dec 4, 10:47 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> On Dec 2, 12:12 pm, Nick Alexander <ncalexan...@gmail.com> wrote:
>
> > > In the Python environment, if someone detects an error in a Python
> > > function FF, then the function can be replaced in the run-time
> > > environment, e.g. at a command line by:
>

> > (Nick) This is technically true but in practice not useful.  
...
This discussion is continued on sage-flame (same title, though
inappropriate for this topic)
in which it is apparently the case that some things cannot be changed
interactively
and require rebuilding a system.

The disadvantages of such a setup for testing changes and debugging,
compared to one in which incremental changes can be made
instantaneously are discussed. Perhaps it is inherent in the current
Sage design that the debugging cycle will typically require
rebuilding the system and then running a script up to the point of the
bug, even if that script is time consuming. Does this suggest an
alternative way of putting together Sage? Or should such comments be
consigned to flames?

Anyway, you can look in sage-flame for more.

RJF