[sage-devel] Re: SAGE 3.0alpha6 Debian package issues

[tabbott]

It turns out the singular problem was that /usr/lib/libsingular.so has
to be marked as executable for Singular to load it.

The LinBox problem went away when I upgraded to 3.0.1alpha1.

-Tim Abbott

On Apr 26, 9:28 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Apr 27, 2:57 am, Timothy G Abbott <[EMAIL PROTECTED]> wrote:
>
> > I seem to have two major problems with my SAGE 3.0alpha6 Debian packages.
> > One seems to be difficulty finding the expanded executable for singular,
> > and the other seems to be a double free somewhere in linbox.
>
> I have an idea what could cause the LinBox problem since the gcc 4.3
> fix caused some of LinBox's internal tests to fail with an odd free at
> exit. But the code in Sage itself valgrinds clean, so I doubt that is
> it. Can you try 3.0.final to see if the problem is still there?
>
> One issue we fixed is that we link the PolyBoRi extension statically
> since linking all three libs dynamically causes double frees. See
> #2822 for details. I fixed that in Sage by deleting all the dynamic
> PolyBoRi libs, but that barely qualifies as a fix, more as a cheap
> workaround. The problem does also no occur in PolyBoRi proper since
> they also just link all the code statically in once big extension. But
> the problem needs to be fixed on our end properly anyway since once we
> have more than one extension using PolyBoRi the "static link fix" will
> not work any more.
>
> > Do either of these sound familiar?
>
> > -Tim Abbott
>
> > // ***dError: Bug reported: Could not get expanded executable from
> > /usr/lib/sagemath/local/lib/libsingular.so
> >   occured at feResource.cc,434
> >   occured at:
>
> I suspect the above could be the same as #2983 - but I have no lead
> there. I did valgrind it and all other Singular code we ran, but
> nothing popped up. So leads on that one are *really* appreciated ;)
>
> > sage: 1+2
> > 3
>
> 
>
> Cheers,
>
> Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[elflapper]

This builds without error on Archlinux (3.0 didn't build with just
'make')!!!

On May 2, 11:43 pm, mabshoff <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This is the end of the 3.0.1 release cycle. The build was  announced
> in IRC about eight hours ago, but since I took a  long nap in the
> meantime I never posted to sage-devel ;)
>
> Gary's pbuild has been improved and three bugs have been  fixed.
> Please try it out again for feedback. To use pbuild
>
> export SAGE_PBUILD=yes
>
> before building Sage. The number of threads used during  the build of
> the Sage library is set via SAGE_BUILD_THREADS,  i.e.
>
> export SAGE_BUILD_THREADS=8
>
> for eight threads. Switching between pbuild and normal build is not
> possible in all cases, so in case of problems nuke the build directory
> on devel/sage.
>
> Things should "just work" in this release [famous last  words], but
> there are some reported oddities with pexpect behaving badly. We have
> so far been unable to reproduce  and of those issue on a local system
> [Gary claims testdoc.py hangs for him on sage.math - but it doesn't
> for me], so  if you see anything please let us know.
>
> Sources and binaries are in the usual place:
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.1/sa...
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.1/sa...
>
> This is the end of the release cycle. A handful more patches are
> planned for 3.0.1.final. Anything non-blocker will be  considered for
> 3.0.2.
>
> Cheers,
>
> Michael
>
> Merged in rc0:
>
> #2755: Andrey Novoseltsev: lattice_polytope.py update
> #3060: Marshall Hampton, Michael Abshoff: update optional biopython
> package to 1.45 release
> #3062: Timothy Clemans: implement __oct__ special method for the
> integers
> #3070: Robert Miller: bug in SymmetricGroup(1).cayley_graph()
> #3071: Gary Furnish: Using pbuild does not create site-packages sage
> symlink
> #3072: Willem Jan Palenstijn: sage -i numeric-24.2 (and all other
> experimental packages) fails
> #3074: Robert Bradshaw: update Cyton to the 0.9.6.14 release
> #3076: Michael Abshoff: spkg-debian in extcode spkg not executable
> #3077: Gary Furnish: pbuild does not return properly on failure
> #3078: Willem Jan Palenstijn: sage's spkg-install doesn't return
> failure if build failed
> #3082: William Stein: sage-3.0.1.alpha1: a twist.py doctest failure

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Computing large Bernoulli numbers

[Bill Hart]

I think I nearly understand what Pari does.

The value of B_k is given by zeta(n)*(2*n!)/(2^n pi^n). However,
zeta(n) is *very* close to 1 for large n. So one starts by computing
zeta to a precision given by the size of (2*n!)/(2^n pi^n) (which is
basically the size of B_k) with 3 added to the precision to take care
of small values of n.

To compute how large (2*n!)/(2^n pi^n) can be, one uses Stirling's
formula for n!, i.e. n! ~ sqrt(2n*pi)*n^n*e^(-n). The log of this
expression is never more than 0.1 of the log of n!. Taking the log of
the expression one gets when plugging in Stirling's approximation, one
gets that the log of B_k does not exceed (n + 0.5) * log(n) -
n*(1+log2PI) + log(2*sqrt(2*Pi)) + 0.1 except for very small n (for
which it is sufficient to add 3 to the precision).

Now we need to know how big the numerator can be in B_k. But we can
compute the denominator precisely using the Clausen-von Staudt
formula. Pari does this and calls the denominator d.

Now the log of the numerator is no bigger than t = log(d) + (n + 0.5)
* log(n) - n*(1+log2PI) + log(2*sqrt(2*Pi)) + 0.1 = log(d ) + (n +
0.5) * log(n) - n*(1+log2PI) + 1.712086.

If this is how big the numerator of B_k is, we only need to compute it
to half a part in e^t. Thus we only need to compute 1/zeta(n) to half
a part in e^t. This is done by computing the inverse of the Euler
product for sufficiently many primes. Suppose we compute this for
primes up to p. Then the error in the inverse of the zeta function is
less than sum 1/p^n + 1/(p+1)^n +. Consider this sum p terms at a
time. The first p are <= 1/p^n, the second p terms are <= 1/(2p)^n,
etc. Thus the error is quite a bit less than zeta(n) * p/p^n ~ 1/
p^(n-1).

Thus if we want this error to be less than half a part in e^t we need
to choose p to be about exp(t)^(1/(n-1)). Pari uses exp((t -
log(n-1)) / (n-1)) and I'm not sure where the extra log(n-1) comes
from, but either they use a slightly better approximation than me, or
they perhaps note that one doesn't need the first 1/p^n in the
approximation.

Pari could be improved by noting that one does not need the last few
terms of the numerator, as they can be recovered from Clausen-von
Staudt, which actually gives the fractional part of B_k. But for large
n, this is not a significant saving.

Bill.

On 3 May, 01:21, Bill Hart <[EMAIL PROTECTED]> wrote:
> Actually, it might be n/log(n) steps, so the time might be something
> like n^2 though there are other terms involved.
>
> Bill.
>
> On 3 May, 00:30, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > The theoretical complexity of all the algorithms that rely on
> > recurrences is supposed to be n^2. But this doesn't take into account
> > the size of the numbers themselves. When you do this they are all
> > about n^3 as far as I can see. You can use Ramanujan identities, the
> > Akiyama-Tanigawa algorithm, the identity used by Lovelace, but all are
> > n^3 or so.
>
> > The theoretical complexity of the version using the zeta function
> > looks something like n log n steps at precision n log n, i.e. time n^2
> > (log n)^2.
>
> > Bill.
>
> > On 2 May, 21:24, David Harvey <[EMAIL PROTECTED]> wrote:
>
> > > One more data point (2.6GHz opteron):
>
> > > sage: time x = bernoulli(6)
> > > Wall time: 3.79
>
> > > sage: time x = bernoulli(12)
> > > Wall time: 16.97
>
> > > sage: time x = bernoulli(24)
> > > Wall time: 118.24
>
> > > sage: time x = bernoulli(48)
> > > Wall time: 540.25
>
> > > sage: time x = bernoulli(96)
> > > Wall time: 2436.06
>
> > > The ratios between successive times are:
>
> > > 4.47757255936675
> > > 6.96758986446671
> > > 4.56909675236806
> > > 4.50913465987969
>
> > > If we guess that it's "really" 4.5, then the complexity is N^(log
> > > (4.5) / log(2)) = N^2.17. This is puzzling; I thought the algorithm  
> > > was supposed to be better than quadratic. Does anyone know what the  
> > > theoretical complexity is supposed to be?
>
> > > Anyway, extrapolating gives about 4.5 days, pretty much the same as  
> > > what Tom estimates. I'm going to start it running now.
>
> > > david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Computing large Bernoulli numbers

[Bill Hart]

Sorry, this:

The log of this expression is never more than 0.1 of the log of n!.

should read:

The log of this expression is always within 0.1 of the log of n!.

Bill.

On 3 May, 13:12, Bill Hart <[EMAIL PROTECTED]> wrote:
> I think I nearly understand what Pari does.
>
> The value of B_k is given by zeta(n)*(2*n!)/(2^n pi^n). However,
> zeta(n) is *very* close to 1 for large n. So one starts by computing
> zeta to a precision given by the size of (2*n!)/(2^n pi^n) (which is
> basically the size of B_k) with 3 added to the precision to take care
> of small values of n.
>
> To compute how large (2*n!)/(2^n pi^n) can be, one uses Stirling's
> formula for n!, i.e. n! ~ sqrt(2n*pi)*n^n*e^(-n). The log of this
> expression is never more than 0.1 of the log of n!. Taking the log of
> the expression one gets when plugging in Stirling's approximation, one
> gets that the log of B_k does not exceed (n + 0.5) * log(n) -
> n*(1+log2PI) + log(2*sqrt(2*Pi)) + 0.1 except for very small n (for
> which it is sufficient to add 3 to the precision).
>
> Now we need to know how big the numerator can be in B_k. But we can
> compute the denominator precisely using the Clausen-von Staudt
> formula. Pari does this and calls the denominator d.
>
> Now the log of the numerator is no bigger than t = log(d) + (n + 0.5)
> * log(n) - n*(1+log2PI) + log(2*sqrt(2*Pi)) + 0.1 = log(d ) + (n +
> 0.5) * log(n) - n*(1+log2PI) + 1.712086.
>
> If this is how big the numerator of B_k is, we only need to compute it
> to half a part in e^t. Thus we only need to compute 1/zeta(n) to half
> a part in e^t. This is done by computing the inverse of the Euler
> product for sufficiently many primes. Suppose we compute this for
> primes up to p. Then the error in the inverse of the zeta function is
> less than sum 1/p^n + 1/(p+1)^n +. Consider this sum p terms at a
> time. The first p are <= 1/p^n, the second p terms are <= 1/(2p)^n,
> etc. Thus the error is quite a bit less than zeta(n) * p/p^n ~ 1/
> p^(n-1).
>
> Thus if we want this error to be less than half a part in e^t we need
> to choose p to be about exp(t)^(1/(n-1)). Pari uses exp((t -
> log(n-1)) / (n-1)) and I'm not sure where the extra log(n-1) comes
> from, but either they use a slightly better approximation than me, or
> they perhaps note that one doesn't need the first 1/p^n in the
> approximation.
>
> Pari could be improved by noting that one does not need the last few
> terms of the numerator, as they can be recovered from Clausen-von
> Staudt, which actually gives the fractional part of B_k. But for large
> n, this is not a significant saving.
>
> Bill.
>
> On 3 May, 01:21, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > Actually, it might be n/log(n) steps, so the time might be something
> > like n^2 though there are other terms involved.
>
> > Bill.
>
> > On 3 May, 00:30, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > The theoretical complexity of all the algorithms that rely on
> > > recurrences is supposed to be n^2. But this doesn't take into account
> > > the size of the numbers themselves. When you do this they are all
> > > about n^3 as far as I can see. You can use Ramanujan identities, the
> > > Akiyama-Tanigawa algorithm, the identity used by Lovelace, but all are
> > > n^3 or so.
>
> > > The theoretical complexity of the version using the zeta function
> > > looks something like n log n steps at precision n log n, i.e. time n^2
> > > (log n)^2.
>
> > > Bill.
>
> > > On 2 May, 21:24, David Harvey <[EMAIL PROTECTED]> wrote:
>
> > > > One more data point (2.6GHz opteron):
>
> > > > sage: time x = bernoulli(6)
> > > > Wall time: 3.79
>
> > > > sage: time x = bernoulli(12)
> > > > Wall time: 16.97
>
> > > > sage: time x = bernoulli(24)
> > > > Wall time: 118.24
>
> > > > sage: time x = bernoulli(48)
> > > > Wall time: 540.25
>
> > > > sage: time x = bernoulli(96)
> > > > Wall time: 2436.06
>
> > > > The ratios between successive times are:
>
> > > > 4.47757255936675
> > > > 6.96758986446671
> > > > 4.56909675236806
> > > > 4.50913465987969
>
> > > > If we guess that it's "really" 4.5, then the complexity is N^(log
> > > > (4.5) / log(2)) = N^2.17. This is puzzling; I thought the algorithm  
> > > > was supposed to be better than quadratic. Does anyone know what the  
> > > > theoretical complexity is supposed to be?
>
> > > > Anyway, extrapolating gives about 4.5 days, pretty much the same as  
> > > > what Tom estimates. I'm going to start it running now.
>
> > > > david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[John Cremona]

Two successful builds of rc0 (32 and 64 bit linux).   The 64-bit one
seems to have stalled doing testall at this point:

sage -t  devel/sage/sage/dsage/dist_functions/all.py
 [1.3 s]
sage -t  devel/sage/sage/dsage/scripts/nodoctest.py (skipping) --
nodoctest.py file in directory
sage -t  devel/sage/sage/dsage/scripts/dsage_worker.py (skipping) --
nodoctest.py file in directory
sage -t  devel/sage/sage/dsage/scripts/__init__.py (skipping) --
nodoctest.py file in directory
sage -t  devel/sage/sage/dsage/scripts/dsage_setup.py (skipping) --
nodoctest.py file in directory
sage -t  devel/sage/sage/dsage/web/web_server.py
 [1.3 s]
sage -t  devel/sage/sage/dsage/tests/testdoc.py

which has not moved for at least haf an hour.

Switching do a different window on the same machine, "ps -ax" shows this:

[EMAIL PROTECTED] ux
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
jec  10107  0.0  0.0 150936  3832 ?SApr10   0:00
python /home/jec/sage-3.0.alpha3/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid --log
jec  17257  0.0  0.0 144636  3976 ?SApr15   0:00
python /home/jec/sage-3.0.alpha5/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid --log
jec   9518  0.0  0.0 144648  3848 ?SApr19   0:00
python /home/jec/sage-3.0.alpha6/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid --log
jec   2656  0.0  0.0 144672  3956 ?SApr20   0:00
python /home/jec/sage-3.0.rc0/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid --logfil
jec  31253  0.0  0.0 151016  3864 ?SApr21   0:00
python /home/jec/sage-3.0.rc1/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid --logfil
jec  20989  0.0  0.0 144724  3916 ?SApr21   0:00
python /home/jec/sage-3.0.rc1/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid --logfil
jec  24920  0.0  0.0 151008  3860 ?SApr22   0:00
python /home/jec/sage-3.0/local/bin/twistd -d /home/jec/.sage/dsage
--pidfile=server.pid --logfile=/h
jec  12580  0.0  0.1 144708 24364 ?SMay01   0:00
python /home/jec/sage-3.0/local/bin/twistd -d /home/jec/.sage/dsage
--pidfile=server.pid --logfile=/h
jec  17881  0.0  0.0  87884  2172 ?S10:09   0:04 sshd: [EMAIL 
PROTECTED]/1
jec  17882  0.0  0.0  17696  2644 pts/1Ss   10:09   0:00 -bash
jec  25047  0.0  0.0  15808  1680 pts/1S+   12:39   0:00 bash
./sage --testall
jec  25054  0.0  0.0  15944  1776 pts/1S+   12:39   0:00 bash
/home/jec/sage-3.0.1.rc0/local/bin/sage-sage --testall
jec  25066  0.0  0.0  15816  1696 pts/1S+   12:39   0:00 bash
/home/jec/sage-3.0.1.rc0/local/bin/sage-maketest
jec  25406  0.0  0.0  15816  1696 pts/1S+   12:39   0:00 bash
/home/jec/sage-3.0.1.rc0/sage -t
/home/jec/sage-3.0.1.rc0/devel/sage/sage
jec  25407  0.0  0.0   4004   652 pts/1S+   12:39   0:00 tee
-a /home/jec/sage-3.0.1.rc0/tmp/test.log
jec  25414  0.0  0.0  15944  1788 pts/1S+   12:39   0:00 bash
/home/jec/sage-3.0.1.rc0/local/bin/sage-sage -t
/home/jec/sage-3.0.1.rc0/devel/sage/sage
jec  25426  0.0  0.0  17708  3708 pts/1S+   12:39   0:00
python /home/jec/sage-3.0.1.rc0/local/bin/sage-test
/home/jec/sage-3.0.1.rc0/devel/sage/sage
jec  10364  0.0  0.0  85816  2056 ?S12:54   0:00 sshd: [EMAIL 
PROTECTED]/4
jec  10365  0.0  0.0  17692  2608 pts/4Ss   12:54   0:00 -bash
jec  19763  0.0  0.0  32952  4400 pts/1S+   13:02   0:00
python /home/jec/sage-3.0.1.rc0/local/bin/sage-doctest
/home/jec/sage-3.0.1.rc0/devel/sage/sage/dsage
jec  19764  0.0  0.0  15812  1636 pts/1S+   13:02   0:00 sh -c
/home/jec/sage-3.0.1.rc0/local/bin/python
/home/jec/sage-3.0.1.rc0/tmp/.doctest_testdoc.py 1>/t
jec  19765  0.0  0.5 664996 89580 pts/1S+   13:02   0:01
/home/jec/sage-3.0.1.rc0/local/bin/python
/home/jec/sage-3.0.1.rc0/tmp/.doctest_testdoc.py
jec  19805  0.0  0.0  0 0 pts/1Z+   13:02   0:00
[python] 
jec  19932  0.0  0.0   4600   868 pts/4R+   14:00   0:00 ps ux

which reveals that as well as the stalled run I knew about, there are
8 other sage processes stuck in limbo.  Before I kkill these jobs
(which I certainly will -- it is not even my own machine) -- is there
anything I can do to help diagnose the problem?

John

2008/5/3 elflapper <[EMAIL PROTECTED]>:
>
>  This builds without error on Archlinux (3.0 didn't build with just
>  'make')!!!
>
>
>  On May 2, 11:43 pm, mabshoff <[EMAIL PROTECTED]> wrote:
>  > Hello,
>  >
>  > This is the end of the 3.0.1 release cycle. The build was  announced
>  > in IRC about eight hours ago, but since I took a  long nap in the
>  > meantime I never posted to sage-devel ;)
>  >
>  > Gary's pbuild has been improved and three bugs have been  fixed.
>  > Please try it out again for feedback. To use pbuild
>  >
>  > export SAGE_PBUILD=yes
>  >
>  > before building Sage. The number of threads used d

[sage-devel] Re: RFC: article for OpenWetWare

[mhampton]

Feel free to point others to it now.  I improved it (hopefully) a
little bit, and I am now posting about it on my blog (which should get
fed into Planet Sage).  I can always change it if there are errors/
omissions.

Thanks for the feedback.

M. Hampton

On May 2, 6:02 pm, Simon King <[EMAIL PROTECTED]> wrote:
> Hi!
>
> On May 2, 10:17 pm, mhampton <[EMAIL PROTECTED]> wrote:
>
> > I am more or less done my draft of a Sage/Cython article for
> > OpenWetWare.  I think this is a good minor opportunity to expose a
> > different community to Sage.  The bioinformatics community is already
> > fairly pro-open-source, and OpenWetWare readers are self-selected to
> > be more so.  Before it is made "live" and linked to, I would be
> > interested in comments:
>
> >http://openwetware.org/wiki/User:Marshall_Hampton/Sage
>
> I like this article! Obviously you took into account what audience
> you'll have. This is a wise thing to do.
>
> In the reddit-blog on William's ISSAC-abstract, some commentors seem
> to have the impression that Sage mainly is algebra, hence, not a good
> tool for engineers. Perhaps one may point them to your article.
>
> Yours
>   Simon
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mhampton]

All tests passed on my intel mac pro, running OS X 10.4.11.

-M. Hampton

On May 3, 8:07 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
> Two successful builds of rc0 (32 and 64 bit linux).   The 64-bit one
> seems to have stalled doing testall at this point:
>
> sage -t  devel/sage/sage/dsage/dist_functions/all.py
>  [1.3 s]
> sage -t  devel/sage/sage/dsage/scripts/nodoctest.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/scripts/dsage_worker.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/scripts/__init__.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/scripts/dsage_setup.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/web/web_server.py
>  [1.3 s]
> sage -t  devel/sage/sage/dsage/tests/testdoc.py
>
> which has not moved for at least haf an hour.
>
> Switching do a different window on the same machine, "ps -ax" shows this:
>
> [EMAIL PROTECTED] ux
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> jec  10107  0.0  0.0 150936  3832 ?SApr10   0:00
> python /home/jec/sage-3.0.alpha3/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid --log
> jec  17257  0.0  0.0 144636  3976 ?SApr15   0:00
> python /home/jec/sage-3.0.alpha5/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid --log
> jec   9518  0.0  0.0 144648  3848 ?SApr19   0:00
> python /home/jec/sage-3.0.alpha6/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid --log
> jec   2656  0.0  0.0 144672  3956 ?SApr20   0:00
> python /home/jec/sage-3.0.rc0/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid --logfil
> jec  31253  0.0  0.0 151016  3864 ?SApr21   0:00
> python /home/jec/sage-3.0.rc1/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid --logfil
> jec  20989  0.0  0.0 144724  3916 ?SApr21   0:00
> python /home/jec/sage-3.0.rc1/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid --logfil
> jec  24920  0.0  0.0 151008  3860 ?SApr22   0:00
> python /home/jec/sage-3.0/local/bin/twistd -d /home/jec/.sage/dsage
> --pidfile=server.pid --logfile=/h
> jec  12580  0.0  0.1 144708 24364 ?SMay01   0:00
> python /home/jec/sage-3.0/local/bin/twistd -d /home/jec/.sage/dsage
> --pidfile=server.pid --logfile=/h
> jec  17881  0.0  0.0  87884  2172 ?S10:09   0:04 sshd: [EMAIL 
> PROTECTED]/1
> jec  17882  0.0  0.0  17696  2644 pts/1Ss   10:09   0:00 -bash
> jec  25047  0.0  0.0  15808  1680 pts/1S+   12:39   0:00 bash
> ./sage --testall
> jec  25054  0.0  0.0  15944  1776 pts/1S+   12:39   0:00 bash
> /home/jec/sage-3.0.1.rc0/local/bin/sage-sage --testall
> jec  25066  0.0  0.0  15816  1696 pts/1S+   12:39   0:00 bash
> /home/jec/sage-3.0.1.rc0/local/bin/sage-maketest
> jec  25406  0.0  0.0  15816  1696 pts/1S+   12:39   0:00 bash
> /home/jec/sage-3.0.1.rc0/sage -t
> /home/jec/sage-3.0.1.rc0/devel/sage/sage
> jec  25407  0.0  0.0   4004   652 pts/1S+   12:39   0:00 tee
> -a /home/jec/sage-3.0.1.rc0/tmp/test.log
> jec  25414  0.0  0.0  15944  1788 pts/1S+   12:39   0:00 bash
> /home/jec/sage-3.0.1.rc0/local/bin/sage-sage -t
> /home/jec/sage-3.0.1.rc0/devel/sage/sage
> jec  25426  0.0  0.0  17708  3708 pts/1S+   12:39   0:00
> python /home/jec/sage-3.0.1.rc0/local/bin/sage-test
> /home/jec/sage-3.0.1.rc0/devel/sage/sage
> jec  10364  0.0  0.0  85816  2056 ?S12:54   0:00 sshd: [EMAIL 
> PROTECTED]/4
> jec  10365  0.0  0.0  17692  2608 pts/4Ss   12:54   0:00 -bash
> jec  19763  0.0  0.0  32952  4400 pts/1S+   13:02   0:00
> python /home/jec/sage-3.0.1.rc0/local/bin/sage-doctest
> /home/jec/sage-3.0.1.rc0/devel/sage/sage/dsage
> jec  19764  0.0  0.0  15812  1636 pts/1S+   13:02   0:00 sh -c
> /home/jec/sage-3.0.1.rc0/local/bin/python
> /home/jec/sage-3.0.1.rc0/tmp/.doctest_testdoc.py 1>/t
> jec  19765  0.0  0.5 664996 89580 pts/1S+   13:02   0:01
> /home/jec/sage-3.0.1.rc0/local/bin/python
> /home/jec/sage-3.0.1.rc0/tmp/.doctest_testdoc.py
> jec  19805  0.0  0.0  0 0 pts/1Z+   13:02   0:00
> [python] 
> jec  19932  0.0  0.0   4600   868 pts/4R+   14:00   0:00 ps ux
>
> which reveals that as well as the stalled run I knew about, there are
> 8 other sage processes stuck in limbo.  Before I kkill these jobs
> (which I certainly will -- it is not even my own machine) -- is there
> anything I can do to help diagnose the problem?
>
> John
>
> 2008/5/3 elflapper <[EMAIL PROTECTED]>:
>
>
>
> >  This builds without error on Archlinux (3.0 didn't build with just
> >  'make')!!!
>
> >  On May 2, 11:43 pm, mabshoff <[EMAIL PROTECTED]> wrote:
> >  > Hello,
>
> >  > This is the end of the 3.0.1 release cycle. The build was  announced
> >  > in IRC about eig

[sage-devel] Re: Sage 3.0.1.rc0 released!

[John Cremona]

All ok on my 32-bit machine:

All tests passed!
Total time for all tests: 4034.3 seconds
Please see /home/jec/sage-3.0.1.rc0/tmp/test.log for the complete log
from this test.
[EMAIL PROTECTED] -a
Linux fermat 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008
i686 GNU/Linux


2008/5/3 John Cremona <[EMAIL PROTECTED]>:
> Two successful builds of rc0 (32 and 64 bit linux).   The 64-bit one
>  seems to have stalled doing testall at this point:
>
>  sage -t  devel/sage/sage/dsage/dist_functions/all.py
>  [1.3 s]
>  sage -t  devel/sage/sage/dsage/scripts/nodoctest.py (skipping) --
>  nodoctest.py file in directory
>  sage -t  devel/sage/sage/dsage/scripts/dsage_worker.py (skipping) --
>  nodoctest.py file in directory
>  sage -t  devel/sage/sage/dsage/scripts/__init__.py (skipping) --
>  nodoctest.py file in directory
>  sage -t  devel/sage/sage/dsage/scripts/dsage_setup.py (skipping) --
>  nodoctest.py file in directory
>  sage -t  devel/sage/sage/dsage/web/web_server.py
>  [1.3 s]
>  sage -t  devel/sage/sage/dsage/tests/testdoc.py
>
>  which has not moved for at least haf an hour.
>
>  Switching do a different window on the same machine, "ps -ax" shows this:
>
>  [EMAIL PROTECTED] ux
>  USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
>  jec  10107  0.0  0.0 150936  3832 ?SApr10   0:00
>  python /home/jec/sage-3.0.alpha3/local/bin/twistd -d
>  /home/jec/.sage/dsage --pidfile=server.pid --log
>  jec  17257  0.0  0.0 144636  3976 ?SApr15   0:00
>  python /home/jec/sage-3.0.alpha5/local/bin/twistd -d
>  /home/jec/.sage/dsage --pidfile=server.pid --log
>  jec   9518  0.0  0.0 144648  3848 ?SApr19   0:00
>  python /home/jec/sage-3.0.alpha6/local/bin/twistd -d
>  /home/jec/.sage/dsage --pidfile=server.pid --log
>  jec   2656  0.0  0.0 144672  3956 ?SApr20   0:00
>  python /home/jec/sage-3.0.rc0/local/bin/twistd -d
>  /home/jec/.sage/dsage --pidfile=server.pid --logfil
>  jec  31253  0.0  0.0 151016  3864 ?SApr21   0:00
>  python /home/jec/sage-3.0.rc1/local/bin/twistd -d
>  /home/jec/.sage/dsage --pidfile=server.pid --logfil
>  jec  20989  0.0  0.0 144724  3916 ?SApr21   0:00
>  python /home/jec/sage-3.0.rc1/local/bin/twistd -d
>  /home/jec/.sage/dsage --pidfile=server.pid --logfil
>  jec  24920  0.0  0.0 151008  3860 ?SApr22   0:00
>  python /home/jec/sage-3.0/local/bin/twistd -d /home/jec/.sage/dsage
>  --pidfile=server.pid --logfile=/h
>  jec  12580  0.0  0.1 144708 24364 ?SMay01   0:00
>  python /home/jec/sage-3.0/local/bin/twistd -d /home/jec/.sage/dsage
>  --pidfile=server.pid --logfile=/h
>  jec  17881  0.0  0.0  87884  2172 ?S10:09   0:04 sshd: 
> [EMAIL PROTECTED]/1
>  jec  17882  0.0  0.0  17696  2644 pts/1Ss   10:09   0:00 -bash
>  jec  25047  0.0  0.0  15808  1680 pts/1S+   12:39   0:00 bash
>  ./sage --testall
>  jec  25054  0.0  0.0  15944  1776 pts/1S+   12:39   0:00 bash
>  /home/jec/sage-3.0.1.rc0/local/bin/sage-sage --testall
>  jec  25066  0.0  0.0  15816  1696 pts/1S+   12:39   0:00 bash
>  /home/jec/sage-3.0.1.rc0/local/bin/sage-maketest
>  jec  25406  0.0  0.0  15816  1696 pts/1S+   12:39   0:00 bash
>  /home/jec/sage-3.0.1.rc0/sage -t
>  /home/jec/sage-3.0.1.rc0/devel/sage/sage
>  jec  25407  0.0  0.0   4004   652 pts/1S+   12:39   0:00 tee
>  -a /home/jec/sage-3.0.1.rc0/tmp/test.log
>  jec  25414  0.0  0.0  15944  1788 pts/1S+   12:39   0:00 bash
>  /home/jec/sage-3.0.1.rc0/local/bin/sage-sage -t
>  /home/jec/sage-3.0.1.rc0/devel/sage/sage
>  jec  25426  0.0  0.0  17708  3708 pts/1S+   12:39   0:00
>  python /home/jec/sage-3.0.1.rc0/local/bin/sage-test
>  /home/jec/sage-3.0.1.rc0/devel/sage/sage
>  jec  10364  0.0  0.0  85816  2056 ?S12:54   0:00 sshd: 
> [EMAIL PROTECTED]/4
>  jec  10365  0.0  0.0  17692  2608 pts/4Ss   12:54   0:00 -bash
>  jec  19763  0.0  0.0  32952  4400 pts/1S+   13:02   0:00
>  python /home/jec/sage-3.0.1.rc0/local/bin/sage-doctest
>  /home/jec/sage-3.0.1.rc0/devel/sage/sage/dsage
>  jec  19764  0.0  0.0  15812  1636 pts/1S+   13:02   0:00 sh -c
>  /home/jec/sage-3.0.1.rc0/local/bin/python
>  /home/jec/sage-3.0.1.rc0/tmp/.doctest_testdoc.py 1>/t
>  jec  19765  0.0  0.5 664996 89580 pts/1S+   13:02   0:01
>  /home/jec/sage-3.0.1.rc0/local/bin/python
>  /home/jec/sage-3.0.1.rc0/tmp/.doctest_testdoc.py
>  jec  19805  0.0  0.0  0 0 pts/1Z+   13:02   0:00
>  [python] 
>  jec  19932  0.0  0.0   4600   868 pts/4R+   14:00   0:00 ps ux
>
>  which reveals that as well as the stalled run I knew about, there are
>  8 other sage processes stuck in limbo.  Before I kkill these jobs
>  (which I certainly will -- it is not even my own machine) -- is there
>  anything I can do to help diagnose the problem?
>
>  John
>
>  2008/5/3 elflapper <[EMAIL PROTECTED]>:
>
>
>

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 3:07 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
> Two successful builds of rc0 (32 and 64 bit linux).   The 64-bit one
> seems to have stalled doing testall at this point:
>
> sage -t  devel/sage/sage/dsage/dist_functions/all.py
>          [1.3 s]
> sage -t  devel/sage/sage/dsage/scripts/nodoctest.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/scripts/dsage_worker.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/scripts/__init__.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/scripts/dsage_setup.py (skipping) --
> nodoctest.py file in directory
> sage -t  devel/sage/sage/dsage/web/web_server.py
>          [1.3 s]
> sage -t  devel/sage/sage/dsage/tests/testdoc.py
>
> which has not moved for at least haf an hour.
>
> Switching do a different window on the same machine, "ps -ax" shows this:
>

>
> which reveals that as well as the stalled run I knew about, there are
> 8 other sage processes stuck in limbo.  Before I kkill these jobs
> (which I certainly will -- it is not even my own machine) -- is there
> anything I can do to help diagnose the problem?

Fortunately wjp figured it out:

[15:04]  ah, I think I see why dsage is behaving strangely
[15:04]  nice.
[15:04]  if you have a clue that is usually it.
[15:04]  why is dsage behaving strangely
[15:04]  in my alpha1 install, there's no local/dsage, and no
local/bin/dsage_worker.py
[15:04]  ok
[15:04]  (while in my 3.0.rc0 where the doctest works fine, both
exist)
[15:04]  somebody who understands dsage may be able to say if
that is relevant :-)
[15:05]  But they were not removed in 3.0 or anywhere else.
[15:05]  File a bug report for pbuild.
[15:05]  So, you guys used pbuild both?
[15:05]  That would explain it :)
[15:05]  I'm guessing he did.
[15:05]  I did, yes
[15:05]  I think Cremona did, too.
[15:05]  Excellent.
[15:05]  actually I think both of those need to be
fixed in the installer
[15:05]  In the rc0 announcement I had a sentence I took
out:
[15:06]  I think you should just mkdir local/dsage and
manually install the local/bin/dsage_worker.py
[15:06]  "If pbuild causes any trouble Gary will be taken to
a damp basement room and beaten with reeds"
[15:06]  and add it to the scripts repo
[15:06]  gfurnish|away: please see if that fixes the issue.
[15:06]  where is dsage_worker.py?
[15:07]  ./local/bin/dsage_worker.py
[15:07]  ./devel/sage-main/sage/dsage/scripts/
dsage_worker.py
[15:07]  doing a diff on the contents of local/bin, I see
dsage_setup.py is also missing
[15:07]  ./devel/sage-main/build/sage/dsage/scripts/
dsage_worker.py
[15:08]  wjp: with "hg status" ?
[15:08]  (and a +SbuildHack.pm, -spkg-debian-maybe, but those may
not be relevant)
[15:08]  ok.
[15:08]  no, just ls > /tmp/blah in both directories
[15:08]  Both of those are taken care of by setup.py
[15:09]  check out the end of setup.py:
[15:09]scripts = ['sage/dsage/scripts/
dsage_worker.py',
[15:09]   'sage/dsage/scripts/
dsage_setup.py',
[15:09]   'spkg-debian-maybe',
[15:09]  ],
[15:09]  local/dsage is the dir thats missing?
[15:10]  it contains index.html and a static subdirectory
[15:10]  yeah I see it but it doesn't seem to fix it...
[15:10]  ah so there are files too?
[15:10]  um, sorry, web/index.html and a web/static subdir
[15:10]  where do the files come from?
[15:10]  devel/sage-main/sage/dsage/
[15:10]  well maybe I can convince you to make the
patch ;)
[15:10]  we should just symlink the files

> John

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Computing large Bernoulli numbers

[Bill Hart]

I probably also mean:

Then the error in the the zeta function

not:

Then the error in the inverse of the zeta function

Bill.

On 3 May, 13:12, Bill Hart <[EMAIL PROTECTED]> wrote:
> I think I nearly understand what Pari does.
>
> The value of B_k is given by zeta(n)*(2*n!)/(2^n pi^n). However,
> zeta(n) is *very* close to 1 for large n. So one starts by computing
> zeta to a precision given by the size of (2*n!)/(2^n pi^n) (which is
> basically the size of B_k) with 3 added to the precision to take care
> of small values of n.
>
> To compute how large (2*n!)/(2^n pi^n) can be, one uses Stirling's
> formula for n!, i.e. n! ~ sqrt(2n*pi)*n^n*e^(-n). The log of this
> expression is never more than 0.1 of the log of n!. Taking the log of
> the expression one gets when plugging in Stirling's approximation, one
> gets that the log of B_k does not exceed (n + 0.5) * log(n) -
> n*(1+log2PI) + log(2*sqrt(2*Pi)) + 0.1 except for very small n (for
> which it is sufficient to add 3 to the precision).
>
> Now we need to know how big the numerator can be in B_k. But we can
> compute the denominator precisely using the Clausen-von Staudt
> formula. Pari does this and calls the denominator d.
>
> Now the log of the numerator is no bigger than t = log(d) + (n + 0.5)
> * log(n) - n*(1+log2PI) + log(2*sqrt(2*Pi)) + 0.1 = log(d ) + (n +
> 0.5) * log(n) - n*(1+log2PI) + 1.712086.
>
> If this is how big the numerator of B_k is, we only need to compute it
> to half a part in e^t. Thus we only need to compute 1/zeta(n) to half
> a part in e^t. This is done by computing the inverse of the Euler
> product for sufficiently many primes. Suppose we compute this for
> primes up to p. Then the error in the inverse of the zeta function is
> less than sum 1/p^n + 1/(p+1)^n +. Consider this sum p terms at a
> time. The first p are <= 1/p^n, the second p terms are <= 1/(2p)^n,
> etc. Thus the error is quite a bit less than zeta(n) * p/p^n ~ 1/
> p^(n-1).
>
> Thus if we want this error to be less than half a part in e^t we need
> to choose p to be about exp(t)^(1/(n-1)). Pari uses exp((t -
> log(n-1)) / (n-1)) and I'm not sure where the extra log(n-1) comes
> from, but either they use a slightly better approximation than me, or
> they perhaps note that one doesn't need the first 1/p^n in the
> approximation.
>
> Pari could be improved by noting that one does not need the last few
> terms of the numerator, as they can be recovered from Clausen-von
> Staudt, which actually gives the fractional part of B_k. But for large
> n, this is not a significant saving.
>
> Bill.
>
> On 3 May, 01:21, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > Actually, it might be n/log(n) steps, so the time might be something
> > like n^2 though there are other terms involved.
>
> > Bill.
>
> > On 3 May, 00:30, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > The theoretical complexity of all the algorithms that rely on
> > > recurrences is supposed to be n^2. But this doesn't take into account
> > > the size of the numbers themselves. When you do this they are all
> > > about n^3 as far as I can see. You can use Ramanujan identities, the
> > > Akiyama-Tanigawa algorithm, the identity used by Lovelace, but all are
> > > n^3 or so.
>
> > > The theoretical complexity of the version using the zeta function
> > > looks something like n log n steps at precision n log n, i.e. time n^2
> > > (log n)^2.
>
> > > Bill.
>
> > > On 2 May, 21:24, David Harvey <[EMAIL PROTECTED]> wrote:
>
> > > > One more data point (2.6GHz opteron):
>
> > > > sage: time x = bernoulli(6)
> > > > Wall time: 3.79
>
> > > > sage: time x = bernoulli(12)
> > > > Wall time: 16.97
>
> > > > sage: time x = bernoulli(24)
> > > > Wall time: 118.24
>
> > > > sage: time x = bernoulli(48)
> > > > Wall time: 540.25
>
> > > > sage: time x = bernoulli(96)
> > > > Wall time: 2436.06
>
> > > > The ratios between successive times are:
>
> > > > 4.47757255936675
> > > > 6.96758986446671
> > > > 4.56909675236806
> > > > 4.50913465987969
>
> > > > If we guess that it's "really" 4.5, then the complexity is N^(log
> > > > (4.5) / log(2)) = N^2.17. This is puzzling; I thought the algorithm  
> > > > was supposed to be better than quadratic. Does anyone know what the  
> > > > theoretical complexity is supposed to be?
>
> > > > Anyway, extrapolating gives about 4.5 days, pretty much the same as  
> > > > what Tom estimates. I'm going to start it running now.
>
> > > > david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[John Cremona]

ok , I thought I should have been listening in on IRC when sage-devel
went quiet!

This doesn't actually tell me what I should do.  (You were right that
this is with PBUILD, by the way).  But I killed the --testall.

Any ideas on the 8 rogue sage processes I have goung back to April 10?
 In full they all look rather like this

jec  10107  0.0  0.0 150936  3832 ?SApr10   0:00
python /home/jec/sage-3.0.alpha3/local/bin/twistd -d
/home/jec/.sage/dsage --pidfile=server.pid
--logfile=/home/jec/.sage/dsage/server.log -y dsage_server.tac

so it is also something to do wuth dsage.  I don't consciously use
dsage, but these might all be left from --testall runs.  Should I just
kill them?

John

2008/5/3 mabshoff <[EMAIL PROTECTED]>:
>
>
>
>  On May 3, 3:07 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
>  > Two successful builds of rc0 (32 and 64 bit linux).   The 64-bit one
>  > seems to have stalled doing testall at this point:
>  >
>  > sage -t  devel/sage/sage/dsage/dist_functions/all.py
>  >  [1.3 s]
>  > sage -t  devel/sage/sage/dsage/scripts/nodoctest.py (skipping) --
>  > nodoctest.py file in directory
>  > sage -t  devel/sage/sage/dsage/scripts/dsage_worker.py (skipping) --
>  > nodoctest.py file in directory
>  > sage -t  devel/sage/sage/dsage/scripts/__init__.py (skipping) --
>  > nodoctest.py file in directory
>  > sage -t  devel/sage/sage/dsage/scripts/dsage_setup.py (skipping) --
>  > nodoctest.py file in directory
>  > sage -t  devel/sage/sage/dsage/web/web_server.py
>  >  [1.3 s]
>  > sage -t  devel/sage/sage/dsage/tests/testdoc.py
>  >
>  > which has not moved for at least haf an hour.
>  >
>  > Switching do a different window on the same machine, "ps -ax" shows this:
>  >
>  
>
> >
>  > which reveals that as well as the stalled run I knew about, there are
>  > 8 other sage processes stuck in limbo.  Before I kkill these jobs
>  > (which I certainly will -- it is not even my own machine) -- is there
>  > anything I can do to help diagnose the problem?
>
>  Fortunately wjp figured it out:
>
>  [15:04]  ah, I think I see why dsage is behaving strangely
>  [15:04]  nice.
>  [15:04]  if you have a clue that is usually it.
>  [15:04]  why is dsage behaving strangely
>  [15:04]  in my alpha1 install, there's no local/dsage, and no
>  local/bin/dsage_worker.py
>  [15:04]  ok
>  [15:04]  (while in my 3.0.rc0 where the doctest works fine, both
>  exist)
>  [15:04]  somebody who understands dsage may be able to say if
>  that is relevant :-)
>  [15:05]  But they were not removed in 3.0 or anywhere else.
>  [15:05]  File a bug report for pbuild.
>  [15:05]  So, you guys used pbuild both?
>  [15:05]  That would explain it :)
>  [15:05]  I'm guessing he did.
>  [15:05]  I did, yes
>  [15:05]  I think Cremona did, too.
>  [15:05]  Excellent.
>  [15:05]  actually I think both of those need to be
>  fixed in the installer
>  [15:05]  In the rc0 announcement I had a sentence I took
>  out:
>  [15:06]  I think you should just mkdir local/dsage and
>  manually install the local/bin/dsage_worker.py
>  [15:06]  "If pbuild causes any trouble Gary will be taken to
>  a damp basement room and beaten with reeds"
>  [15:06]  and add it to the scripts repo
>  [15:06]  gfurnish|away: please see if that fixes the issue.
>  [15:06]  where is dsage_worker.py?
>  [15:07]  ./local/bin/dsage_worker.py
>  [15:07]  ./devel/sage-main/sage/dsage/scripts/
>  dsage_worker.py
>  [15:07]  doing a diff on the contents of local/bin, I see
>  dsage_setup.py is also missing
>  [15:07]  ./devel/sage-main/build/sage/dsage/scripts/
>  dsage_worker.py
>  [15:08]  wjp: with "hg status" ?
>  [15:08]  (and a +SbuildHack.pm, -spkg-debian-maybe, but those may
>  not be relevant)
>  [15:08]  ok.
>  [15:08]  no, just ls > /tmp/blah in both directories
>  [15:08]  Both of those are taken care of by setup.py
>  [15:09]  check out the end of setup.py:
>  [15:09]scripts = ['sage/dsage/scripts/
>  dsage_worker.py',
>  [15:09]   'sage/dsage/scripts/
>  dsage_setup.py',
>  [15:09]   'spkg-debian-maybe',
>  [15:09]  ],
>  [15:09]  local/dsage is the dir thats missing?
>  [15:10]  it contains index.html and a static subdirectory
>  [15:10]  yeah I see it but it doesn't seem to fix it...
>  [15:10]  ah so there are files too?
>  [15:10]  um, sorry, web/index.html and a web/static subdir
>  [15:10]  where do the files come from?
>  [15:10]  devel/sage-main/sage/dsage/
>  [15:10]  well maybe I can convince you to make the
>  patch ;)
>  [15:10]  we should just symlink the files
>
>  > John
>
>  Cheers,
>
>  Michael
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 4:14 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:

Hi John,

> ok , I thought I should have been listening in on IRC when sage-devel
> went quiet!

Yes, #sage-devel is often the place to get quick answers, especially
to debug problems.

> This doesn't actually tell me what I should do.  (You were right that
> this is with PBUILD, by the way).  But I killed the --testall.

Ok, that should certainly settle the cause.

> Any ideas on the 8 rogue sage processes I have goung back to April 10?
>  In full they all look rather like this
>
> jec      10107  0.0  0.0 150936  3832 ?        S    Apr10   0:00
> python /home/jec/sage-3.0.alpha3/local/bin/twistd -d
> /home/jec/.sage/dsage --pidfile=server.pid
> --logfile=/home/jec/.sage/dsage/server.log -y dsage_server.tac
>
> so it is also something to do wuth dsage.  I don't consciously use
> dsage, but these might all be left from --testall runs.  Should I just
> kill them?

It should be left-overs from various --testall runs. Just kill them.

> John

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[Andrzej Giniewicz]

Hi,

built and tested on Arch 32, only one failure (were 3 for alpha)...
same as with 3.0.0:

sage -t  3.0.1.rc0/devel/sage/sage/rings/complex_double.pyx
**
File "/opt/sage/tmp/complex_double.py", line 1659:
sage: z^2 - z + 1
Expected:
2.22044604925e-16 + ...e-16*I
Got:
2.22044604925e-16
**
1 items had failures:
   1 of   7 in __main__.example_93
***Test Failed*** 1 failures.
For whitespace errors, see the file /opt/sage/
tmp/.doctest_complex_double.py
 [21.5 s]
exit code: 1024

cheers,
Andrzej.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 5:26 pm, Andrzej Giniewicz <[EMAIL PROTECTED]> wrote:
> Hi,

Hi Andrzej,

> built and tested on Arch 32, only one failure (were 3 for alpha)...
> same as with 3.0.0:
>
> sage -t  3.0.1.rc0/devel/sage/sage/rings/complex_double.pyx
> **
> File "/opt/sage/tmp/complex_double.py", line 1659:
>     sage: z^2 - z + 1
> Expected:
>     2.22044604925e-16 + ...e-16*I
> Got:
>     2.22044604925e-16
> **
> 1 items had failures:
>    1 of   7 in __main__.example_93
> ***Test Failed*** 1 failures.
> For whitespace errors, see the file /opt/sage/
> tmp/.doctest_complex_double.py
>          [21.5 s]
> exit code: 1024

This is #3010 and I just made it a blocker for 3.0.1. I will have a
patch ready for you to test in about 15 minutes. Just watch the
ticket.

> cheers,
> Andrzej.

Thanks for testing and reporting the issue.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[David Joyner]

Possibly strange results on an ubuntu 7.10amd64 machine. (It is a
rather old machine
though, so many this is not something to worry about.)

export SAGE_PBUILD=yes
export SAGE_BUILD_THREADS=2
make

Build went fine. However, sage -testall started messing up almost immediately.
Here is some of it:

Testing SAGE documentation
Testing SAGE tutorial
sage -t  devel/doc/tut/tut.tex  Traceback
(most recent call last):
  File "/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/tmp/.doctest_tut.py",
line 2, in 
from sage.all_cmdline import *;
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all_cmdline.py",
line 14, in 
from sage.all import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all.py",
line 62, in 
from sage.libs.all   import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/all.py",
line 12, in 
from sage.libs.mwrank.all  import (mwrank_EllipticCurve, mwrank_MordellWeil,
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/all.py",
line 10, in 
from mwrank import initprimes as mwrank_initprimes
ImportError: 
/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/mwrank.so:
undefined symbol: mw_del

 [9.0 s]
exit code: 1024

--
The following tests failed:


sage -t  devel/doc/tut/tut.tex
Total time for all tests: 9.0 seconds
Testing SAGE programming guide
sage -t  devel/doc/prog/prog.texTraceback
(most recent call last):
  File "/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/tmp/.doctest_prog.py",
line 2, in 
from sage.all_cmdline import *;
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all_cmdline.py",
line 14, in 
from sage.all import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all.py",
line 62, in 
from sage.libs.all   import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/all.py",
line 12, in 
from sage.libs.mwrank.all  import (mwrank_EllipticCurve, mwrank_MordellWeil,
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/all.py",
line 10, in 
from mwrank import initprimes as mwrank_initprimes
ImportError: 
/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/mwrank.so:
undefined symbol: mw_del

 [1.2 s]
exit code: 1024

--
The following tests failed:


sage -t  devel/doc/prog/prog.tex
Total time for all tests: 1.2 seconds
Testing SAGE constructions guide
sage -t  devel/doc/const/const.tex  Traceback
(most recent call last):
  File "/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/tmp/.doctest_const.py",
line 2, in 
from sage.all_cmdline import *;
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all_cmdline.py",
line 14, in 
from sage.all import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all.py",
line 62, in 
from sage.libs.all   import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/all.py",
line 12, in 
from sage.libs.mwrank.all  import (mwrank_EllipticCurve, mwrank_MordellWeil,
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/all.py",
line 10, in 
from mwrank import initprimes as mwrank_initprimes
ImportError: 
/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/mwrank.so:
undefined symbol: mw_del

 [1.1 s]
exit code: 1024

--
The following tests failed:


sage -t  devel/doc/const/const.tex
Total time for all tests: 1.1 seconds
sage -t  devel/sage/sage/stats/r.py Traceback
(most recent call last):
  File "/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/tmp/.doctest_r.py",
line 2, in 
from sage.all_cmdline import *;
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all_cmdline.py",
line 14, in 
from sage.all import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/all.py",
line 62, in 
from sage.libs.all   import *
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/all.py",
line 12, in 
from sage.libs.mwrank.all  import (mwrank_EllipticCurve, mwrank_MordellWeil,
  File 
"/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-packages/sage/libs/mwrank/all.py",
line 10, in 
from mwrank import initprimes as mwrank_initprimes
ImportError: 
/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib/python/site-package

[sage-devel] Re: ISSAC abstract

[root]

>>> I can try to build a Sage binary on Fedora 3 if you wish
>>> but I'm not optimistic. I know that my Fedora 5 could not
>>> build Sage because the compiler was too old.
>>
>>The compiler wasn't too old, it was *borken*, i.e. "internal compiler
>>error". IIRC it was some gcc 4.1.0 and as well all know a ".0" release
>>is just an extended beta test. FC5's rpm repo offers some gcc 4.1.1
>>that will likely build Sage just fine.
>>
>>> Fedora 3 likely has the same issue.
>>
>>Nope, it ships gcc 3.4.3 which is C99 compliant. I didn't use it
>>recently, but it is quite reliable and any issue with Sage and gcc 3.4
>>will likely be fixed quickly.
>
>Ok. I'll try a fedora 3 build.

Sage failed to build in fedora 3

The log is at


Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[mabshoff]

On May 3, 7:50 pm, root <[EMAIL PROTECTED]> wrote:


> >Ok. I'll try a fedora 3 build.
>
> Sage failed to build in fedora 3
>
> The log is at
> 
>
> Tim

Hi Tim,

R fails to build since it picks up the system's readline. We have some
similar issue with R picking the wrong libpng and now have a ticket
open to update to R 2.7 anyway. I will hopefully fix those two issues
when updating to R 2.7, so it is likely too late for Sage 3.0.1.

Thanks for the error report. I will add this issue to the ticket
#3086. We should definitely keep an eye on this and I will look around
for some VMWare image of FC3 to do regular build testing so Alfredo
isn't duped the week before ISSAC when Sage magically breaks on FC3
again :(

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 6:33 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:

Hi David,

> Possibly strange results on an ubuntu 7.10amd64 machine. (It is a
> rather old machine
> though, so many this is not something to worry about.)

Yes, it is ;)

> export SAGE_PBUILD=yes
> export SAGE_BUILD_THREADS=2
> make
>
> Build went fine. However, sage -testall started messing up almost immediately.
> Here is some of it:



Can you post a link to the build log? This is very likely related to
pbuild's different linker flags. We should be able to hunt this down
since we will hopefully switch to pbuild sooner rather than later.

Cheers,

Michael


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Sage-2.11 compilation problem under Irix

[Oskar45]

Hi everyone,

am trying to get sage-2.11 running under the officially unsupported
[!!!]
Irix 6.5.30 with MipsPro 7.4.4 [my box is an SGI Fuel/R16000]. Up to
now,
after battling a few inconsistencies, I got GMP, PARI and NTL
installed.
However, I now got stuck with the compilation of .
As
Michael had suggested to me in private conversation, I'm posting to
the list
nevertheless hoping someone has a clue regarding my problem so I can
continue:

cc-1262 CC: ERROR File = /usr/include/CC/complex, Line = 55
  No instance of constructor "NTL::RR::RR" matches the argument list.

The argument types are:  (int).
  : _M_re(__x), _M_im(0) {}
  ^
  detected during instantiation of
"std::complex::complex(const
std::complex::value_type &)" at line 172
of
"cubic.cc"

1 error detected in the compilation of "cubic.cc".
gmake[1]: *** [cubic_n.o] Error 2
gmake[1]: Leaving directory `/disk03/mephisto/source/sage-2.11/spkg/
build/eclib-20080310.p0/src/procs'

All your help is certainly appreciated.

Best regards,
/oskar



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] IRIX compilation problem...

[Oskar45]

Hi everyone,

am trying to get sage-2.11 running under the officially unsupported
[!!!]
Irix 6.5.30 with MipsPro 7.4.4 [my box is an SGI Fuel/R16000]. Up to
now,
after battling a few inconsistencies, I got GMP, PARI and NTL
installed.
However, I now got stuck with the compilation of .
As
Michael had suggested to me in private conversation, I'm posting to
the list
nevertheless hoping someone has a clue regarding my problem so I can
continue:

cc-1262 CC: ERROR File = /usr/include/CC/complex, Line = 55
  No instance of constructor "NTL::RR::RR" matches the argument list.

The argument types are:  (int).
  : _M_re(__x), _M_im(0) {}
  ^
  detected during instantiation of
"std::complex::complex(const
std::complex::value_type &)" at line 172
of
"cubic.cc"

1 error detected in the compilation of "cubic.cc".
gmake[1]: *** [cubic_n.o] Error 2
gmake[1]: Leaving directory `/disk03/mephisto/source/sage-2.11/spkg/
build/eclib-20080310.p0/src/procs'

All your help is certainly appreciated.

Best regards,
/oskar



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage-2.11 compilation problem under Irix

[mabshoff]

On May 3, 6:35 pm, Oskar45 <[EMAIL PROTECTED]> wrote:
> Hi everyone,

Hi Oskar,

> am trying to get sage-2.11 running under the officially unsupported
> [!!!]
> Irix 6.5.30 with MipsPro 7.4.4 [my box is an SGI Fuel/R16000]. Up to
> now,
> after battling a few inconsistencies, I got GMP, PARI and NTL
> installed.
> However, I now got stuck with the compilation of .
> As
> Michael had suggested to me in private conversation, I'm posting to
> the list
> nevertheless hoping someone has a clue regarding my problem so I can
> continue:
>
> cc-1262 CC: ERROR File = /usr/include/CC/complex, Line = 55
>   No instance of constructor "NTL::RR::RR" matches the argument list.
>
>             The argument types are:  (int).
>       : _M_re(__x), _M_im(0) {}
>                           ^
>           detected during instantiation of
>                     "std::complex::complex(const
>                     std::complex::value_type &)" at line 172
> of
>                     "cubic.cc"
>
> 1 error detected in the compilation of "cubic.cc".
> gmake[1]: *** [cubic_n.o] Error 2
> gmake[1]: Leaving directory `/disk03/mephisto/source/sage-2.11/spkg/
> build/eclib-20080310.p0/src/procs'
>
> All your help is certainly appreciated.

No clue yet why this is borken, but you can bypass the build of eclib,
by running

 touch spkg/installed/eclib-20080310.p1

from $SAGE_ROOT. Building the Sage library down the road will still be
broken, but at least you can probably fix some more issues while we
are trying to figure out what is broken with eclib+IRIX's CC.

If anybody has a shell account on an IRIX box with that compiler for
me I can certainly help poking around.

> Best regards,
> /oskar

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[David Joyner]

On Sat, May 3, 2008 at 12:55 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>  On May 3, 6:33 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:
>
>  Hi David,
>
>
>  > Possibly strange results on an ubuntu 7.10amd64 machine. (It is a
>  > rather old machine
>  > though, so many this is not something to worry about.)
>
>  Yes, it is ;)
>
>
>  > export SAGE_PBUILD=yes
>  > export SAGE_BUILD_THREADS=2
>  > make
>  >
>  > Build went fine. However, sage -testall started messing up almost 
> immediately.
>  > Here is some of it:
>
>  
>
>  Can you post a link to the build log? This is very likely related to
>  pbuild's different linker flags. We should be able to hunt this down
>  since we will hopefully switch to pbuild sooner rather than later.

I killed the job since it seemed to be repeating very similar errors
for each of the files. Hopefully, what is there will help:
http://sage.math.washington.edu/home/wdj/patches/test.log

>
>  Cheers,
>
>  Michael
>
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 7:14 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:
> On Sat, May 3, 2008 at 12:55 PM, mabshoff <[EMAIL PROTECTED]> wrote:



Hi David,

> >  Can you post a link to the build log? This is very likely related to
> >  pbuild's different linker flags. We should be able to hunt this down
> >  since we will hopefully switch to pbuild sooner rather than later.
>
> I killed the job since it seemed to be repeating very similar errors
> for each of the files. Hopefully, what is there will 
> help:http://sage.math.washington.edu/home/wdj/patches/test.log
>

You must have misread. I asked for the build log, i.e. install.log ;).
I know what is wrong, I just don't know why yet.

Cheers,

Michael


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[David Joyner]

On Sat, May 3, 2008 at 1:19 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
>  On May 3, 7:14 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:
>  > On Sat, May 3, 2008 at 12:55 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>  
>
>  Hi David,
>
>
>  > >  Can you post a link to the build log? This is very likely related to
>  > >  pbuild's different linker flags. We should be able to hunt this down
>  > >  since we will hopefully switch to pbuild sooner rather than later.
>  >
>  > I killed the job since it seemed to be repeating very similar errors
>  > for each of the files. Hopefully, what is there will 
> help:http://sage.math.washington.edu/home/wdj/patches/test.log
>  >
>
>  You must have misread. I asked for the build log, i.e. install.log ;).
>  I know what is wrong, I just don't know why yet.

Sorry. Here it is
http://sage.math.washington.edu/home/wdj/patches/install.log
(or will be in a few minutes - it's still uploading).

>
>
>
>  Cheers,
>
>  Michael
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[Alex Ghitza]

Built fine on

Linux sillyname 2.6.22-gentoo-r5 #2 SMP Tue Aug 28 23:46:12 UTC 2007
i686 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux

Doing 'make test', got stuck at dsage/tests/testdoc.py so I had to kill
it.  I've put the build log at

http://bayes.colby.edu/~ghitza/install.log

Best,
Alex


mabshoff wrote:
> Hello,
> 
> This is the end of the 3.0.1 release cycle. The build was  announced
> in IRC about eight hours ago, but since I took a  long nap in the
> meantime I never posted to sage-devel ;)
> 
> Gary's pbuild has been improved and three bugs have been  fixed.
> Please try it out again for feedback. To use pbuild
> 
> export SAGE_PBUILD=yes
> 
> before building Sage. The number of threads used during  the build of
> the Sage library is set via SAGE_BUILD_THREADS,  i.e.
> 
> export SAGE_BUILD_THREADS=8
> 
> for eight threads. Switching between pbuild and normal build is not
> possible in all cases, so in case of problems nuke the build directory
> on devel/sage.
> 
> Things should "just work" in this release [famous last  words], but
> there are some reported oddities with pexpect behaving badly. We have
> so far been unable to reproduce  and of those issue on a local system
> [Gary claims testdoc.py hangs for him on sage.math - but it doesn't
> for me], so  if you see anything please let us know.
> 
> Sources and binaries are in the usual place:
> 
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.1/sage-3.0.1.rc0.tar
> 
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.1/sage-3.0.1.rc0-sage.math-only-x86_64-Linux.tar.gz
> 
> This is the end of the release cycle. A handful more patches are
> planned for 3.0.1.final. Anything non-blocker will be  considered for
> 3.0.2.
> 
> Cheers,
> 
> Michael
> 
> Merged in rc0:
> 
> #2755: Andrey Novoseltsev: lattice_polytope.py update
> #3060: Marshall Hampton, Michael Abshoff: update optional biopython
> package to 1.45 release
> #3062: Timothy Clemans: implement __oct__ special method for the
> integers
> #3070: Robert Miller: bug in SymmetricGroup(1).cayley_graph()
> #3071: Gary Furnish: Using pbuild does not create site-packages sage
> symlink
> #3072: Willem Jan Palenstijn: sage -i numeric-24.2 (and all other
> experimental packages) fails
> #3074: Robert Bradshaw: update Cyton to the 0.9.6.14 release
> #3076: Michael Abshoff: spkg-debian in extcode spkg not executable
> #3077: Gary Furnish: pbuild does not return properly on failure
> #3078: Willem Jan Palenstijn: sage's spkg-install doesn't return
> failure if build failed
> #3082: William Stein: sage-3.0.1.alpha1: a twist.py doctest failure
> 
> > 
> 


-- 
Alexandru Ghitza
Assistant Professor
Department of Mathematics
Colby College
Waterville, ME 04901
http://bayes.colby.edu/~ghitza/

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 7:37 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:

Hi David,

> Sorry. Here it ishttp://sage.math.washington.edu/home/wdj/patches/install.log
> (or will be in a few minutes - it's still uploading).

I think I found it: The working version of mwrank.so is compiled with g
++, while the non-working version is compiled with gcc. I would guess
on Gary's and many other systems gcc does the right thing, but on your
system it doesn't link to the C++ code of eclib. mwrank.c is a pure C
wrapper for eclib's C++ code, so I guess in the end the linker is the
key player here. Switching the mwrank.so extension to be build with C+
+ should fix the issue.

Working:

g++ -pthread -shared build/temp.linux-x86_64-2.5/sage/libs/mwrank/
mwrank.o build/temp.linux-x86_64-2.5/sage/libs/mwrank/wrap
.o -L/scratch/mabshoff/release-cycle/sage-3.0.1.final/local//lib -
lcsage -lcurvesntl -lg0nntl -ljcntl -lrankntl -lntl -lgmp
-lgmpxx -lstdc++ -lm -lpari -lstdc++ -lntl -o build/lib.linux-
x86_64-2.5/sage/libs/mwrank/mwrank.so

Non-working:

gcc -O3 -g -fwrapv -shared -fno-strict-aliasing /mnt/drive_hda1/
sagefiles/sage-3.0.1.rc0/devel/sage/build/temp/sage/libs/mwr
ank/mwrank.o -L/home/wdj/wdj/sagefiles/sage-3.0.1.rc0/local/lib  -
lcsage  -lcurvesntl  -lg0nntl  -ljcntl  -lrankntl  -lntl
-lgmp  -lgmpxx  -lstdc++  -lm  -lpari  -lstdc++  -lntl  -o /mnt/
drive_hda1/sagefiles/sage-3.0.1.rc0/devel/sage-main/build/sa
ge/libs/mwrank/mwrank.so

Gary?

Cheers,

Michael

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 4:18 pm, Alex Ghitza <[EMAIL PROTECTED]> wrote:
> Built fine on

Hi Alex,

> Linux sillyname 2.6.22-gentoo-r5 #2 SMP Tue Aug 28 23:46:12 UTC 2007
> i686 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux
>
> Doing 'make test', got stuck at dsage/tests/testdoc.py so I had to kill
> it.  I've put the build log at
>
>        http://bayes.colby.edu/~ghitza/install.log

Assuming you build with pbuild this is #3097. We understand why it is
broken and it will be fixed before 3.0.1.final.

> Best,
> Alex

Thanks for the build & bug report.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[William Stein]

Build testing of sage-3.0.1.rc0:

Powerpc OS X 10.5:
sage -t  devel/sage/sage/dsage/tests/testdoc.py
sage -t  devel/sage/sage/modular/abvar/abvar.py
sage -t  devel/sage/sage/modular/abvar/homspace.py
sage -t  devel/sage/sage/server/simple/twist.py
Total time for all tests: 22484.4 seconds

WOW, that took a long time to test!Basically all the above
failures are timeout-ish issues.  The poor machine in question
has a runaway process by another user...  Another OS X PPc
machine has almost the same failures.

Arch Linux 32-bit:

sage -t  devel/sage/sage/rings/polynomial/pbori.pyx
sage -t  devel/sage/sage/rings/ring.pyx


Ubuntu and Debian 32-bit and 64-bit Linux:The following tests failed:
sage -t  devel/sage/sage/rings/ring.pyx

The error is:
sage -t  devel/sage/sage/rings/ring.pyx
*
*
File "/home/was/build/sage-3.0.1.rc0/tmp/ring.py", line 879:
sage: S. = R.quotient_ring((x^2, y))
Exception raised:
Traceback (most recent call last):
  File "/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/doctest.py",
line 1228, in __runcompileflags, 1) in test.globs  File
"", line 1, in S =
R.quotient_ring((x**Integer(2), y),names=('a', 'b')); (a, b,) =
S._first_ngens(Integer(2))###line 879:sage: S. =
R.quotient_ring((x^2, y))  File "parent_gens.pyx", line 200, in
sage.structure.parent_gens.ParentWithGens._first_ngens
(sage/structure/parent_gens.c:1377)
  File "parent_gens.pyx", line 283, in
sage.structure.parent_gens.ParentWithGens.gens
(sage/structure/parent_gens.c:1916)  File
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/quotient_ring.py",
line 496,
in gen  return self(self.__R.gen(i))  File
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/quotient_ring.py",
line 404,
in __call__return
quotient_ring_element.QuotientRingElement(self, x)  File
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/quotient_ring_element.py",
li
ne 74, in __init__self._reduce_()  File
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/quotient_ring_element.py",
li
ne 78, in _reduce_ self.__rep = I.reduce(self.__rep)  File
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/polynomial/multi_polynomial_i
deal.py", line 1919, in reducegb = self.groebner_basis()
File 
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/polynomial/multi_polynomial_i
deal.py", line 1835, in groebner_basisgb =
self._groebner_basis_using_singular("groebner", *args, **kwds)
File 
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/polynomial/multi_polynomial_i
deal.py", line 326, in wrapperreturn func(*args, **kwds)
File 
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/rings/polynomial/multi_polynomial_i
deal.py", line 312, in __exit__
self.singular.option("set",self.o)  File
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/interfaces/singular.py",
line 803,
in option
self.eval("option(set,%s)"%val.name())
  File 
"/home/was/build/sage-3.0.1.rc0/local/lib/python2.5/site-packages/sage/interfaces/singular.py",
line 423,
in eval
raise RuntimeError, 'Singular error:\n%s'%s
RuntimeError: Singular error:
   ? unknown option `set`
   ? unknown option `sage33`
   ? error occurred in STDIN line 3: `option(set,sage33);`

-

OS X 10.5 Intel,  sage.math, RHEL 5 32-bit, :
everything passes

sagemath.org (opteron ubuntu):
  sage -t  devel/sage/sage/server/simple/twist.py
Total time for all tests: 3208.3 seconds

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[mabshoff]

On May 3, 8:44 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> Build testing of sage-3.0.1.rc0:

Hi,

> Powerpc OS X 10.5:
>         sage -t  devel/sage/sage/dsage/tests/testdoc.py
>         sage -t  devel/sage/sage/modular/abvar/abvar.py
>         sage -t  devel/sage/sage/modular/abvar/homspace.py
>         sage -t  devel/sage/sage/server/simple/twist.py
> Total time for all tests: 22484.4 seconds
>
> WOW, that took a long time to test!    Basically all the above
> failures are timeout-ish issues.  The poor machine in question
> has a runaway process by another user...  Another OS X PPc
> machine has almost the same failures.

:) - at least it didn't fail.

> Arch Linux 32-bit:
>
>         sage -t  devel/sage/sage/rings/polynomial/pbori.pyx

Out of memory.

>         sage -t  devel/sage/sage/rings/ring.pyx

know issue. Track ticket should be up shortly. Singular related.

> Ubuntu and Debian 32-bit and 64-bit Linux:The following tests failed:
>         sage -t  devel/sage/sage/rings/ring.pyx

know issue. Track ticket should be up shortly. Singular related.



>
> OS X 10.5 Intel,  sage.math, RHEL 5 32-bit, :
>     everything passes

No surprises :)

> sagemath.org (opteron ubuntu):
>           sage -t  devel/sage/sage/server/simple/twist.py
> Total time for all tests: 3208.3 seconds

No ticket yet, I haven't been able to hit that. Only rarely I see it,
so if anybody can give us some lead let us know.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[William Stein]

On Sat, May 3, 2008 at 11:57 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>  On May 3, 8:44 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>  > Build testing of sage-3.0.1.rc0:
>
>  Hi,
>
>
>  > Powerpc OS X 10.5:
>  > sage -t  devel/sage/sage/dsage/tests/testdoc.py
>  > sage -t  devel/sage/sage/modular/abvar/abvar.py
>  > sage -t  devel/sage/sage/modular/abvar/homspace.py
>  > sage -t  devel/sage/sage/server/simple/twist.py
>  > Total time for all tests: 22484.4 seconds
>  >
>  > WOW, that took a long time to test!Basically all the above
>  > failures are timeout-ish issues.  The poor machine in question
>  > has a runaway process by another user...  Another OS X PPc
>  > machine has almost the same failures.
>
>  :) - at least it didn't fail.
>
>
>  > Arch Linux 32-bit:
>  >
>  > sage -t  devel/sage/sage/rings/polynomial/pbori.pyx
>
>  Out of memory.
>
>
>  > sage -t  devel/sage/sage/rings/ring.pyx
>
>  know issue. Track ticket should be up shortly. Singular related.
>
>
>  > Ubuntu and Debian 32-bit and 64-bit Linux:The following tests failed:
>  > sage -t  devel/sage/sage/rings/ring.pyx
>
>  know issue. Track ticket should be up shortly. Singular related.
>
>  
>
>
>  >
>  > OS X 10.5 Intel,  sage.math, RHEL 5 32-bit, :
>  > everything passes
>
>  No surprises :)
>
>
>  > sagemath.org (opteron ubuntu):
>  >   sage -t  devel/sage/sage/server/simple/twist.py
>  > Total time for all tests: 3208.3 seconds
>
>  No ticket yet, I haven't been able to hit that. Only rarely I see it,
>  so if anybody can give us some lead let us know.
>
>

I think it is related to the fact that that machine is running
a bunch of servers on a whole bunch of different ports, and
those overlap with ports used in doctests.  Maybe the doctests
should use hire ports...

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[Willem Jan Palenstijn]

On Sat, May 03, 2008 at 11:57:00AM -0700, mabshoff wrote:
> On May 3, 8:44?pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > ? ? ? ? sage -t ?devel/sage/sage/rings/ring.pyx
> know issue. Track ticket should be up shortly. Singular related.

This is now #3098.

It is caused by a rather subtle problem:
An expect._synchronize is being called while _another_ expect._synchronize
is still running. This caused the outer _synchronize to miss its trigger
and time-out.

The inner one was called through the garbage collector calling
ExpectElement.__del__ calling clear() calling eval() calling
_synchronize(). 

Any ideas on how we should properly handle this? The three options I can
think of are either disabling the gc during any pexpect 'conversations'
(which doesn't seem right to me), removing the eval() from the
ExpectElement destructor (possibly using some form of delayed-evaluation
list), or finding and removing the cyclic dependency that the GC is
collecting here. I'm not entirely sure which one would be "right", if
any.

-Willem Jan

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: IRIX compilation problem...

[John Cremona]

Well, as the author of eclib I hope I can help.  It is a C++ library.
It uses the NTL library, whcih includes a multiprecision real number
type called RR.  MTL does not have multiprecision complexes, so
implement those using RR for the real and imaginary parts, and a
standard C++ library template fto get a complex type;  that needs
some additional functionality which is provided in eclib.

Before Sage, I had only even compiled any of this using gcc.  My guess
is that whatever templates your system provides for complexes is not
working properly, or something else to do with template classes.

Maybey mabshoff or someone else has some ideas on how to proceed

John Cremona.

2008/5/3 Oskar45 <[EMAIL PROTECTED]>:
>
>  Hi everyone,
>
>  am trying to get sage-2.11 running under the officially unsupported
>  [!!!]
>  Irix 6.5.30 with MipsPro 7.4.4 [my box is an SGI Fuel/R16000]. Up to
>  now,
>  after battling a few inconsistencies, I got GMP, PARI and NTL
>  installed.
>  However, I now got stuck with the compilation of .
>  As
>  Michael had suggested to me in private conversation, I'm posting to
>  the list
>  nevertheless hoping someone has a clue regarding my problem so I can
>  continue:
>
>  cc-1262 CC: ERROR File = /usr/include/CC/complex, Line = 55
>   No instance of constructor "NTL::RR::RR" matches the argument list.
>
> The argument types are:  (int).
>   : _M_re(__x), _M_im(0) {}
>   ^
>   detected during instantiation of
> "std::complex::complex(const
> std::complex::value_type &)" at line 172
>  of
> "cubic.cc"
>
>  1 error detected in the compilation of "cubic.cc".
>  gmake[1]: *** [cubic_n.o] Error 2
>  gmake[1]: Leaving directory `/disk03/mephisto/source/sage-2.11/spkg/
>  build/eclib-20080310.p0/src/procs'
>
>  All your help is certainly appreciated.
>
>  Best regards,
>  /oskar
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[William Stein]

On Sat, May 3, 2008 at 1:24 PM, Willem Jan Palenstijn <[EMAIL PROTECTED]> wrote:
>
>  On Sat, May 03, 2008 at 11:57:00AM -0700, mabshoff wrote:
>  > On May 3, 8:44?pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>  > > ? ? ? ? sage -t ?devel/sage/sage/rings/ring.pyx
>
> > know issue. Track ticket should be up shortly. Singular related.
>
>  This is now #3098.
>
>  It is caused by a rather subtle problem:
>  An expect._synchronize is being called while _another_ expect._synchronize
>  is still running. This caused the outer _synchronize to miss its trigger
>  and time-out.
>
>  The inner one was called through the garbage collector calling
>  ExpectElement.__del__ calling clear() calling eval() calling
>  _synchronize().
>
>  Any ideas on how we should properly handle this? The three options I can
>  think of are either disabling the gc during any pexpect 'conversations'
>  (which doesn't seem right to me), removing the eval() from the
>  ExpectElement destructor (possibly using some form of delayed-evaluation
>  list), or finding and removing the cyclic dependency that the GC is
>  collecting here. I'm not entirely sure which one would be "right", if
>  any.
>  =

Another option is for clear (which is called by __del__)
to simply not call _synchronize.  It's really not necessary --
we just want to tell singular to kill the temp variable; it doesn't
matter whether the io stream is synchronized when we do this.

I tried this out and it works.  I've posted a patch to trac.  Please
referee it.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[elflapper]

I just ran the test:
The following tests failed:


sage -t  devel/sage/sage/rings/polynomial/pbori.pyx
sage -t  devel/sage/sage/rings/complex_double.pyx
Total time for all tests: 5126.3 seconds

On Archlinux x86

On May 3, 12:17 am, elflapper <[EMAIL PROTECTED]> wrote:
> This builds without error on Archlinux (3.0 didn't build with just
> 'make')!!!
>
> On May 2, 11:43 pm, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > This is the end of the 3.0.1 release cycle. The build was  announced
> > in IRC about eight hours ago, but since I took a  long nap in the
> > meantime I never posted to sage-devel ;)
>
> > Gary's pbuild has been improved and three bugs have been  fixed.
> > Please try it out again for feedback. To use pbuild
>
> > export SAGE_PBUILD=yes
>
> > before building Sage. The number of threads used during  the build of
> > the Sage library is set via SAGE_BUILD_THREADS,  i.e.
>
> > export SAGE_BUILD_THREADS=8
>
> > for eight threads. Switching between pbuild and normal build is not
> > possible in all cases, so in case of problems nuke the build directory
> > on devel/sage.
>
> > Things should "just work" in this release [famous last  words], but
> > there are some reported oddities with pexpect behaving badly. We have
> > so far been unable to reproduce  and of those issue on a local system
> > [Gary claims testdoc.py hangs for him on sage.math - but it doesn't
> > for me], so  if you see anything please let us know.
>
> > Sources and binaries are in the usual place:
>
> >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.1/sa...
>
> >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.1/sa...
>
> > This is the end of the release cycle. A handful more patches are
> > planned for 3.0.1.final. Anything non-blocker will be  considered for
> > 3.0.2.
>
> > Cheers,
>
> > Michael
>
> > Merged in rc0:
>
> > #2755: Andrey Novoseltsev: lattice_polytope.py update
> > #3060: Marshall Hampton, Michael Abshoff: update optional biopython
> > package to 1.45 release
> > #3062: Timothy Clemans: implement __oct__ special method for the
> > integers
> > #3070: Robert Miller: bug in SymmetricGroup(1).cayley_graph()
> > #3071: Gary Furnish: Using pbuild does not create site-packages sage
> > symlink
> > #3072: Willem Jan Palenstijn: sage -i numeric-24.2 (and all other
> > experimental packages) fails
> > #3074: Robert Bradshaw: update Cyton to the 0.9.6.14 release
> > #3076: Michael Abshoff: spkg-debian in extcode spkg not executable
> > #3077: Gary Furnish: pbuild does not return properly on failure
> > #3078: Willem Jan Palenstijn: sage's spkg-install doesn't return
> > failure if build failed
> > #3082: William Stein: sage-3.0.1.alpha1: a twist.py doctest failure
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[William Stein]

On Sat, May 3, 2008 at 7:53 PM, elflapper <[EMAIL PROTECTED]> wrote:
>
>  I just ran the test:
>  The following tests failed:
>
>
> sage -t  devel/sage/sage/rings/polynomial/pbori.pyx
> sage -t  devel/sage/sage/rings/complex_double.pyx
>  Total time for all tests: 5126.3 seconds
>
>  On Archlinux x86

Could you remind me how much RAM you have on that machine?

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: RFC: article for OpenWetWare

[tkeller]

Just to throw a few thoughts in, I think sage is excellently
positioned to have a big impact for empiricists and theoreticians
within the biological sciences as well as bio-informatics.  I haven't
trudged through much of openwetware yet, but it might be useful to
expand/make another page that shows how easy it is to do bread&butter
population-genetic analysis, such as equilibria, invasability,
stability plots, etc.  It'd be easy to adapt some examples from Otto &
Day 2007 as they used mathematica to do most everything including
plots.  An obvious conclusion to this would be the really clever
coalescent simulator that you've designed.  I'm still quite new to
sage and python, but I'm happy to help in some fashion with this. On
the empiricist side, it might be good to show the benefits of wrapping
R into sage with a simple data set (I think this has been done already
to some extent), combining sage utility with R functionality.  If I
remember correctly many of the the examples highlighted that you could
use R within sage, not how the combination would be useful. I've
become really excited about this project in the last month since I've
become aware of it, because I think it can already replace most of the
functionality that matlab/mathematica provides for many biologists.
For what it's worth, I'm a second year graduate student in
evolutionary biology at the university of texas.
Regards,
Thomas

On May 3, 8:11 am, mhampton <[EMAIL PROTECTED]> wrote:
> Feel free to point others to it now.  I improved it (hopefully) a
> little bit, and I am now posting about it on my blog (which should get
> fed into Planet Sage).  I can always change it if there are errors/
> omissions.
>
> Thanks for the feedback.
>
> M. Hampton
>
> On May 2, 6:02 pm, Simon King <[EMAIL PROTECTED]> wrote:
>
> > Hi!
>
> > On May 2, 10:17 pm, mhampton <[EMAIL PROTECTED]> wrote:
>
> > > I am more or less done my draft of a Sage/Cython article for
> > > OpenWetWare.  I think this is a good minor opportunity to expose a
> > > different community to Sage.  The bioinformatics community is already
> > > fairly pro-open-source, and OpenWetWare readers are self-selected to
> > > be more so.  Before it is made "live" and linked to, I would be
> > > interested in comments:
>
> > >http://openwetware.org/wiki/User:Marshall_Hampton/Sage
>
> > I like this article! Obviously you took into account what audience
> > you'll have. This is a wise thing to do.
>
> > In the reddit-blog on William's ISSAC-abstract, some commentors seem
> > to have the impression that Sage mainly is algebra, hence, not a good
> > tool for engineers. Perhaps one may point them to your article.
>
> > Yours
> >   Simon

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.1.rc0 released!

[elflapper]

512 mb
I think these are relevant part I forgot to post.
--copy and paste---
sage -t  devel/sage/sage/rings/polynomial/pbori.pyx

**
File "/mnt/documents/sage-3.0.1.rc0/tmp/pbori.py", line 2512:
sage: f(x=var('a'),y=var('b'),z=var('c'))
Exception raised:
Traceback (most recent call last):
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/
doctest.py", line
1228, in __run
compileflags, 1) in test.globs
  File "", line 1, in 
f(x=var('a'),y=var('b'),z=var('c'))###line 2512:
sage: f(x=var('a'),y=var('b'),z=var('c'))
  File "sage_object.pyx", line 92, in
sage.structure.sage_object.SageObject.
__repr__ (sage/structure/sage_object.c:618)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/calculus/calculus.py", line 4910, in _repr_
return self.simplify()._repr_(simplify=False)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/calculus/calculus.py", line 3223, in simplify
S =
evaled_symbolic_expression_from_maxima_string(self._maxima_init_())
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/calculus/calculus.py", line 8297, in
evaled_symbolic_expression_from_maxima_str
ing
return symbolic_expression_from_maxima_string(maxima.eval(x))
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/expect.py", line 917, in eval
return '\n'.join([self._eval_line(L, **kwds) for L in
code.split('\n') i
f L != ''])
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 561, in _eval_line
self._sendline(line)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 432, in _sendline
self._sendstr(str)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 437, in _sendstr
self._start()
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 422, in _start
Expect._start(self)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/expect.py", line 450, in _start
self.__name, cmd, self._install_hints())
RuntimeError: Unable to start maxima because the command 'maxima -
p "/mnt/do
cuments/sage-3.0.1.rc0/local/bin/sage-maxima.lisp"' failed.

**
File "/mnt/documents/sage-3.0.1.rc0/tmp/pbori.py", line 2514:
sage: f(var('a'),var('b'),1)
Exception raised:
Traceback (most recent call last):
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/
doctest.py", line
1228, in __run
compileflags, 1) in test.globs
  File "", line 1, in 
f(var('a'),var('b'),Integer(1))###line 2514:
sage: f(var('a'),var('b'),1)
  File "sage_object.pyx", line 92, in
sage.structure.sage_object.SageObject.
__repr__ (sage/structure/sage_object.c:618)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/calculus/calculus.py", line 4910, in _repr_
return self.simplify()._repr_(simplify=False)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/calculus/calculus.py", line 3223, in simplify
S =
evaled_symbolic_expression_from_maxima_string(self._maxima_init_())
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/calculus/calculus.py", line 8297, in
evaled_symbolic_expression_from_maxima_str
ing
return symbolic_expression_from_maxima_string(maxima.eval(x))
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/expect.py", line 917, in eval
return '\n'.join([self._eval_line(L, **kwds) for L in
code.split('\n') i
f L != ''])
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 561, in _eval_line
self._sendline(line)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 432, in _sendline
self._sendstr(str)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 437, in _sendstr
self._start()
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/maxima.py", line 422, in _start
Expect._start(self)
  File "/mnt/documents/sage-3.0.1.rc0/local/lib/python2.5/site-
packages/sage
/interfaces/expect.py", line 450, in _start
self.__name, cmd, self._install_hints())
RuntimeError: Unable to start maxima because the command 'maxima -
p "/mnt/do
cuments/sage-3.0.1.rc0/local/bin/sage-maxima.lisp"' failed.

**
File 

[sage-devel] Status update on 3.0.1.final

[mabshoff]

Hi,

3.0.1.final will not happpen tonight, i.e. Saturday. We are down to
one blocker, i.e. the ring.pyx failure in Singular [#3098]. We have
some patches but they need some more fine tuning.

Other than that there are two pbuild tickets that might make it if
patches are posted:

#3097: the missing DSage bits need to be copied for doctests to work
#3101: mwrank.so needs to be compiled as a C++ extension

Both are fairly straight forward to resolve, but somebody needs to
post a patch. Since pbuild isn't a blocker for 3.0.1. [in trac they
are ;)] we will release 3.0.1.final once #3098 is resolved regardless
of the status of the two pbuild tickets. It would be nice to resolve
them for 3.0.1, but there is always 3.0.2.

Cheers,

Michael

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---