วันจันทร์ที่ 30 พฤศจิกายน พ.ศ. 2552

Re: [sage-devel] Re: Printing...

On Mon, Nov 30, 2009 at 11:16 AM, Nicolas M. Thiery <Nicolas.Thiery@u-psud.fr> wrote:
For the record: there is a patch of mine on trac with sage
-fixdoctests improvements, in particular for multiline output (sorry,
I am in the train, and unable to look up the ticket number). By
accident it did not get merged earlier, but will definitely be in sage
4.3. Feedback and further improvements are most welcome!


That's awesome!! I found your patch (#6354), and conveniently enough its been merged in sage-4.3.alpha0. I tested it out on matrix2.pyx, which as you might expect is one of the files most affected by the displayhook, and the script worked perfectly -- matrix2.pyx.out passed all its doctests. I did however notice a typo in the help text from sage -advanced that you modified: "-fixdoctest" should be "-fixdoctests". I took the liberty of opening a ticket and uploading a patch; this is now #7567.

I'm going to do sage -testall tonight and then it should be a simple matter to run fixdoctests on every file that failed. The hard part will be manually reviewing the changes, just to make sure. Thanks for your work on this Nicolas, I feel like finishing #1918 is finally feasible!

And thank you Florent for renewing interest in this ticket. If you manage to break anything, please let me know. When I finish fixing the doctests, I could definitely use a second pair of eyes to review the automatic changes too :).

-- Bill

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Suggestion to run all MPFR tests each time

Isn't there an option to set to run all the spkg internal tests?

- Robert

On Nov 29, 2009, at 2:16 AM, David Kirkby wrote:

> I was just looking at
>
> http://trac.sagemath.org/sage_trac/ticket/7095
>
> "os x 10.6 port -- numerous mysterious errors caused by weird 'abort
> trap' issue"
>
> and see discussion about problems with different gcc versions.
>
> I've noticed that the MPFR test suite seems to have a habbit of
> picking up compiler bugs.
>
> * It was an MPFR test failure which found the memset() bug on Solaris
> http://trac.sagemath.org/sage_trac/ticket/6453
>
> * When I got a test failure of MPFR on HP-UX, and reported it, I was
> told it was a known compiler bug of gcc 4.4.0, which an MPFR developer
> had reported, and has since been fixed.
>
> Reading the MPFR lists, you get the feeling they really do care about
> quality of code. Compiler warnings are rare, and any I have reported
> have been investigated and discounted.
>
> Although the tests take a bit of time (I think there are 148 of them
> last time I counted), it might be time well spent. Given the total
> time it takes to build Sage, I would estimate enabling the MPFR tests
> would add less than 1% to the build time of Sage
>
> Dave
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Implementation of Graphs, c_graphs, and NetworkX

On Nov 29, 2009, at 8:27 AM, Nathann Cohen wrote:

> HMmmm...
>
> I started creating new modules, and I wanted to split it piece by
> piece, with time. Ticket #7365 creates a module named
> graph_decomposition which I intend to fill ( but I will begin to write
> these functions when this patch will be merged and the file
> created ).
>
> Is it possible in Python to create a module containing a function X,
> then to write in the body of the graph class "from my_module import X"
> so that the X function can be used as any method in the graph class ?
> I am asking this question because I thought it was possible, but I was
> not able to do it with several functions defined in graph_coloring,
> perhaps because of a cyclic dependance. This would enable us to split
> this file efficiently, and to avoid having to copy docstrings and
> create useless wrappers as it is the case for the moment with
> coloring functions.

I think something like this is possible, but it does make it harder to
figure out how to navigate the source. Big files are a pain, but so
are classes that get split among a dozen small files.

> I also created ticket #7369 but it was refused as a blocker and I do
> not really know how to produce such a patch without wiping out all the
> other modifications. If you know how to write it, plllleaaaaaase tell
> me :-)

Look up hg copy and hg rename. This works if you patch is merged with
the other changes (not just applied on top). The criteria for a
blocker is really high (like giving blatantly wrong answers or not
starting up).

> If I can help you with your book, I'd gladly do it !!! I plan great
> things for Graphs in Sage, but these days I am really stuck with
> reviews... Just look at the state of this section on the Trac
> Server !

If you're having trouble to getting patches reviewed fast enough, one
trick is to try to get people to reciprocate after reviewing some of
theirs.

> Even though, most of this is not really "urgent" for Sage ( short of
> the two LP tickets.. I madly need them to be in the standard Sage by
> the end of december )
>
> and can easily wait. The most important thing
> for the graph library, methinks, is to be rewritten efficiently in C
> so that I will be able to rewrite the most useful functions from
> Python to Cython and speed up the rest of them...
>
> For the degree sequence, I think g.degree() should do :-)
>
> Nathann
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Sparse numerical matrices

On Nov 29, 2009, at 2:26 PM, Paul C. Leopardi wrote:

> GluCat ( http://glucat.sf.net ) currently uses uBLAS, which is part
> of Boost.
> I'm looking at Eigen (
> http://www.macresearch.org/interview-eigen-matrix-library
> http://eigen.tuxfamily.org/
> http://eigen.tuxfamily.org/index.php?title=Benchmark ) as a possible
> replacement. For GluCat integration into Sage, it would be nice to
> have a
> library which used C++ templates, had interfaces to BLAS, LAPACK and
> ATLAS
> for speed, supported sparse matrices, and supported multi-precision
> (DD, QD)
> and arbitrary precision (MPFR) real and complex floating point.
> Support for
> integers, rationals and finite fields would be a bonus, as would
> comaptibility with NumPy/SciPy.
> Best, Paul

That's a long wishlist. You might want to check out linbox http://www.linalg.org/
(shipped with Sage, but only partially exposed to the Python level).

- Robert


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Implementation of Graphs, c_graphs, and NetworkX

On Nov 29, 2009, at 5:22 AM, Minh Nguyen wrote:

> Hi Nathann,
>
> On Sat, Nov 28, 2009 at 1:57 AM, Nathann Cohen <nathann.cohen@gmail.com
> > wrote:
>
> <SNIP>
>
>> If I make no mistake, Robert Miller rewrote the Graph class in C,
>> which sounds like we are trying to remove networkX from Sage and use
>> our own version of graphs instead. If this is the case, we will
>> have a
>> C class for graphs, meaning that some Graph functions will be written
>> in C instead of Python, thus gaining a lot of speed in Sage. At this
>> point, what should we do ? Rewrite the Python implementation of the
>> Floyd Marshall algorithm in C ( or whatever was written in NetworkX
>> if
>> more efficient ), just call NetworkX, something different ?

I think the basic idea was that one could write a faster (sparse and
dense) graph "core," and then run all the NetworkX algorithms on top
of it as long as it supported the interface (for manipulating and
querying vertices and edges). If some code was still too slow then it
would be moved down to C (hopefully it would be sufficient to declare
the graphs as c-graphs and compile with Cython to remove all the
Python function call overhead). I don't know how well this works at
the moment.

>> I think Sage's graph class needs to be rewritten to be a bit more
>> efficient..... Efficiency is a problem I have sometimes in Sage, on
>> instances for which this should not be a problem.... So I expect a
>> lot
>> from the c_graphs that are currently somewhere in Sage ( are they
>> used
>> ? How, when ? )

They are used for graph isomorphism, for example.

>> In the end : What is going on with the C graphs in Sage, can we
>> expect
>> them to eb available soon ?

You can use them right now. They're just not as feature full.

>> What are we trying to do with NetworkX (leave it, keep it, nothing
>> special ? )

We're certainly keeping it for the time being, but there's a limit to
speed if one sticks with pure Python. I don't think there's any goal
to replace NetworkX altogether. It could be like a lot of other things
were we handle some things ourselves (where we needed absolute speed)
and call off to NetworkX for the rest.

> I share some of your concerns as expressed above. In the last few
> days, I started writing an introductory chapter for a book on
> algorithmic graph theory using Sage. In doing so, I found that Sage
> lacks some basic features. For example, I have been unable to find a
> function/method to compute the degree sequence of a graph.

Though much could be added of course, I'm sure something this basic is
a lack of documentation rather than functionality.

> What is required is a statement from Robert Miller, or people involved
> in the development of C graph, about the current state of C graph. The
> statement should include the state where C graph is at in terms of
> development, other things that need to be implemented, as well as how
> to navigate around the graph theory module.

That would be helpful, but it's not needed. Robert Miller is busy
studying p-descent and other BSD related topics for his thesis right
now, not graphs, so I'd imagine that there's not much going on
development wise with them unless you want to take up the banner.

> I was reading through graph.py only to discover that it's very, very
> long. Can that module be split up and organized along topical lines?

As a first pass, the Graph and DiGraph class could be split out into
their own files.

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: sage start-up errors

I've resurrected this post because I have some indication of the
source of the subject start-up errors. The sage version is 4.2.1, my
architecture is amd64 running Gentoo and my gcc info is:

gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)

Building sage with the usual "make" results in a sage that passes all
tests. The CFLAGS are unset when sage is built in this fashion.
However, when I build sage with custom CFLAGS as

CFLAGS="-march=opteron -O2 -pipe" CXXFLAGS="-march=opteron -O2 -pipe"
make

everything is built except the documentation. The documentation fails
completely with

sphinx-build -b html -d /local/sage_test/sage-4.2.1/devel/sage/doc/
output/doctrees/en/tutorial /local/sage_test/sage-4.2.1/devel/sage/
doc/en/tutorial /local/sage_test/sage-4.2.1/devel/sage/doc
/output/html/en/tutorial
Traceback (most recent call last):
File "/local/sage_test/sage-4.2.1/local/bin/sphinx-build", line 6,
in <module>
import sage.all
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/all.py", line 64, in <module>
from sage.misc.all import * # takes a while
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/misc/all.py", line 70, in <module>
from sage_input import sage_input
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/misc/sage_input.py", line 163, in <module>
from sage.misc.functional import parent
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/misc/functional.py", line 37, in <module>
from sage.rings.complex_double import CDF
File "complex_double.pyx", line 88, in sage.rings.complex_double
(sage/rings/complex_double.c:13818)
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/rings/complex_field.py", line 86, in ComplexField
C = ComplexField_class(prec)
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/rings/complex_field.py", line 177, in __init__
self._populate_coercion_lists_(coerce_list=[complex_number.RRtoCC
(self._real_field(), self)])
File "complex_number.pyx", line 2004, in
sage.rings.complex_number.RRtoCC.__init__ (sage/rings/complex_number.c:
13046)
File "complex_number.pyx", line 153, in
sage.rings.complex_number.ComplexNumber.__init__ (sage/rings/
complex_number.c:3183)
File "parent.pyx", line 380, in
sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4241)
File "map.pyx", line 173, in sage.categories.map.Map._call_ (sage/
categories/map.c:3481)
NotImplementedError: <type 'sage.rings.real_mpfr.int_toRR'>
Build finished. The built documents can be found in /local/sage_test/
sage-4.2.1/devel/sage/doc/output/html/en/tutorial
Traceback (most recent call last):
File "/local/sage_test/sage-4.2.1/devel/sage/doc/common/builder.py",
line 1009, in <module>
getattr(get_builder(name), type)()
File "/local/sage_test/sage-4.2.1/devel/sage/doc/common/builder.py",
line 260, in _wrapper
getattr(get_builder(document), name)(*args, **kwds)
File "/local/sage_test/sage-4.2.1/devel/sage/doc/common/builder.py",
line 360, in _wrapper
self.write_auto_rest_file(module_name)
File "/local/sage_test/sage-4.2.1/devel/sage/doc/common/builder.py",
line 569, in write_auto_rest_file
title = self.get_module_docstring_title(module_name)
File "/local/sage_test/sage-4.2.1/devel/sage/doc/common/builder.py",
line 539, in get_module_docstring_title
import sage.all
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/all.py", line 64, in <module>
from sage.misc.all import * # takes a while
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/misc/all.py", line 70, in <module>
from sage_input import sage_input
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/misc/sage_input.py", line 163, in <module>
from sage.misc.functional import parent
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/misc/functional.py", line 37, in <module>
from sage.rings.complex_double import CDF
File "complex_double.pyx", line 88, in sage.rings.complex_double
(sage/rings/complex_double.c:13818)
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/rings/complex_field.py", line 86, in ComplexField
C = ComplexField_class(prec)
File "/local/sage_test/sage-4.2.1/local/lib/python2.6/site-packages/
sage/rings/complex_field.py", line 177, in __init__
self._populate_coercion_lists_(coerce_list=[complex_number.RRtoCC
(self._real_field(), self)])
File "complex_number.pyx", line 2004, in
sage.rings.complex_number.RRtoCC.__init__ (sage/rings/complex_number.c:
13046)
File "complex_number.pyx", line 153, in
sage.rings.complex_number.ComplexNumber.__init__ (sage/rings/
complex_number.c:3183)
File "parent.pyx", line 380, in
sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4241)
File "map.pyx", line 173, in sage.categories.map.Map._call_ (sage/
categories/map.c:3481)
NotImplementedError: <type 'sage.rings.real_mpfr.int_toRR'>

Moreover, when I issue 'sage -c quit' I get the same errors listed
under the first post of this thread. These CFLAGS are the flags used
in building every package on my Gentoo machine whenever a package will
allow them. Now when I unpack the sage-4.2.1.spkg tarball and insert

unset CFLAGS
unset CXXFLAGS

near the top of the spkg-install script, repackage the tarball and
issue the above 'make' with custom CFLAGS; both sage and the
documentation build and 'sage -c quit' returns no errors. By altering
spkg-install in the above fashion every package in sage is exposed to
the custom CFLAGS with the exception of sage-4.2.1.spkg. A similar
hack to unset CFLAGS for the amd64 architecture
is utilized by Christopher Schwan and Francois Bissey (http://
github.com/cschwan/sage-on-gentoo) to build a partially split sage. It
would appear that these custom amd64 flags cannot be used to
successfully build the sage-4.2.1.spkg tarball. Is there any known
reason why these custom CFLAGS cannot be used? Gentoo custom flags for
32 bit architectures do not seem to have this build problem. On an
amd64 laptop I have, the CFLAGS setting

CFLAGS="-march=k8 -O2 -pipe"

also results in a sage that fails.

Steve

On Nov 5, 2:32 pm, strogdon <strog...@d.umn.edu> wrote:
> I'm building sage 4.2 on an amd64 machine running gentoo using a
> provided ebuild. There are no obvious errors in install.log. However,
> sage does not startup cleanly. When 'sage -c quit' is issued the
> following results:
>
> Traceback (most recent call last):
> File "/opt/sage/local/bin/sage-eval", line 4, in <module>
> from sage.all import *
> File "/opt/sage/local/lib/python2.6/site-packages/sage/all.py", line
> 64, in <module>
> from sage.misc.all import * # takes a while
> File "/opt/sage/local/lib/python2.6/site-packages/sage/misc/all.py",
> line 70, in <module>
> from sage_input import sage_input
> File "/opt/sage/local/lib/python2.6/site-packages/sage/misc/
> sage_input.py", line 163, in <module>
> from sage.misc.functional import parent
> File "/opt/sage/local/lib/python2.6/site-packages/sage/misc/
> functional.py", line 37, in <module>
> from sage.rings.complex_double import CDF
> File "complex_double.pyx", line 88, in sage.rings.complex_double
> (sage/rings/complex_double.c:13818)
> File "/opt/sage/local/lib/python2.6/site-packages/sage/rings/
> complex_field.py", line 86, in ComplexField
> C = ComplexField_class(prec)
> File "/opt/sage/local/lib/python2.6/site-packages/sage/rings/
> complex_field.py", line 177, in __init__
> self._populate_coercion_lists_(coerce_list=[complex_number.RRtoCC
> (self._real_field(), self)])
> File "complex_number.pyx", line 2004, in
> sage.rings.complex_number.RRtoCC.__init__ (sage/rings/complex_number.c:
> 13046)
> File "complex_number.pyx", line 153, in
> sage.rings.complex_number.ComplexNumber.__init__ (sage/rings/
> complex_number.c:3183)
> File "parent.pyx", line 380, in
> sage.structure.parent.Parent.__call__ (sage/structure/parent.c:4241)
> File "map.pyx", line 173, in sage.categories.map.Map._call_ (sage/
> categories/map.c:3481)
> NotImplementedError: <type 'sage.rings.real_mpfr.int_toRR'>
>
> Others have reported this same type of error on amd64 machines but
> relative to building sage in the "usual" way with the sage-provided
> makefile. When I do this sage builds, all tests pass and the above
> errors are not present. Is it possible that this is an amd64-related
> bug that the gentoo package managing system is discovering?

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: trac component ownership

Oh, I thought 'tbd' was 'the benevolent dictator' :)

-Marshall

On Nov 30, 3:52 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
> William Stein wrote:
> > Hi,
>
> > Here are the trac components with who "owns" each. It's possible that
> > many of these are dated/wrong/silly at this point. If anybody would
> > like to suggest changes, volunteer to own a component, etc., just
> > respond in this thread. Don't ask me exactly what it "means" to own a
> > component in trac though...
>
> > Name Owner
> > -----------------------------------
> > algebra tbd
> > algebraic geometry was
>
> Is there any way I can list these? There have been several changes, and it would
> be nice to see what the current status is. Are there still some 'tbd', which I
> assume is 'to be determined' but perhaps I am wrong.
>
> dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Error building a binary ??? cp: cannot access *.sage

William Stein wrote:
> On Mon, Nov 30, 2009 at 1:30 PM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> You may recall some discussion recently about ./sage -bdist was not working on
>> Solaris, due to a GNUism (the non-POSIX option -a to 'cp').
>>
>> I've attempted to fix this, by using more appropiate options for systems other
>> than Linux. There are basically two changes
>>
>> I am however getting this message
>>
>> drkirkby@kestrel:~/sage-4.2$ ./sage -bdist Solaris10
>> Sage works!
>> Copying files over to tmp directory
>> cp: cannot access *.sage
>> Copying Sage library over
>> Making empty spkg's
>> Creating tar.gz
>> sage-Solaris10-sun4u-SunOS/
>> sage-Solaris10-sun4u-SunOS/examples/
>> <snip>
>> Moving final distribution file to /export/home/drkirkby/sage-4.2/dist
>>
>> I need to remake the tar file anyway, as I forgot to put the version number in
>> the tar file name, and also it has been upgraded to 4.2.1.
>>
>> My updated build script to make the binary is at
>>
>> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/sage-bdist/
>>
>> I will add this to trac
>>
>> http://trac.sagemath.org/sage_trac/ticket/7407
>>
>> but I'm not going to do that if there's a problem with it.
>>
>> The binary is 735M. Does that seem about right ? I've no idea how I'm going to
>> upload that to 't2'!! It will take ages on my network, which is only 256 kB/s
>
> That is nearly twice the size of all the other binaries:
> http://wstein.org/home/wstein/binaries/
>
> William
>

One possibility is files rather than links are being copied. The options to 'cp'
for Solaris are different from those for Linux and OS X. I have not changed
those, but needed to for Solaris, to avoid this '-a' option for 'cp'.

For OS's apart from Linux and OS X, I've just assumed POSIX support. I've made
no attempt to work around any limitions on HP-UX, but issued a warning on that
and several other older platforms.

If you can take a look at
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/sage-bdist/

I'd welcome any comments. I was going to add that to the trac item for review,
but perhaps I need to look at it more carefully first.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Error building a binary ??? cp: cannot access *.sage

On Mon, Nov 30, 2009 at 1:30 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> You may recall some discussion recently about ./sage -bdist  was not working on
> Solaris, due to a GNUism (the non-POSIX option -a to 'cp').
>
> I've attempted to fix this, by using more appropiate options for systems other
> than Linux. There are basically two changes
>
> I am however getting this message
>
> drkirkby@kestrel:~/sage-4.2$ ./sage -bdist Solaris10
> Sage works!
> Copying files over to tmp directory
> cp: cannot access *.sage
> Copying Sage library over
> Making empty spkg's
> Creating tar.gz
> sage-Solaris10-sun4u-SunOS/
> sage-Solaris10-sun4u-SunOS/examples/
> <snip>
> Moving final distribution file to /export/home/drkirkby/sage-4.2/dist
>
> I need to remake the tar file anyway, as I forgot to put the version number in
> the tar file name, and also it has been upgraded to 4.2.1.
>
> My updated build script to make the binary is at
>
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/sage-bdist/
>
> I will add this to trac
>
> http://trac.sagemath.org/sage_trac/ticket/7407
>
> but I'm not going to do that if there's a problem with it.
>
> The binary is 735M. Does that seem about right ? I've no idea how I'm going to
> upload that to 't2'!! It will take ages on my network, which is only 256 kB/s

That is nearly twice the size of all the other binaries:
http://wstein.org/home/wstein/binaries/

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] trac component ownership

On Mon, Nov 30, 2009 at 1:52 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> William Stein wrote:
>> Hi,
>>
>> Here are the trac components with who "owns" each.  It's possible that
>> many of these are dated/wrong/silly at this point.  If anybody would
>> like to suggest changes, volunteer to own a component, etc., just
>> respond in this thread.    Don't ask me exactly what it "means" to own a
>> component in trac though...
>>
>> Name                  Owner
>> -----------------------------------
>> algebra               tbd
>> algebraic geometry    was
>
> Is there any way I can list these? There have been several changes, and it would
> be nice to see what the current status is. Are there still some 'tbd', which I
> assume is 'to be determined' but perhaps I am wrong.
>
> dave

Here's the latest list:

algebra AlexGhitza
algebraic geometry AlexGhitza
algebraic topology jhpalmieri
basic arithmetic AlexGhitza
build tbd
calculus burcin
categories nthiery
coding theory wdj
coercion robertwb
combinatorics sage-combinat
commutative algebra malb
cryptography mvngu
cygwin tbd
debian-package tbd
distribution tbd
doctest tbd
documentation mvngu
dsage tbd
elliptic curves cremona
experimental package tbd
factorization tbd
finance was
freebsd pjeremy
geometry mhampton
givaro cpernet
graphics was
graph theory rlm
group_theory joyner
interact itolkov
interfaces was
linbox cpernet
linear algebra was
memleak tbd
misc tbd
modular forms craigcitro
msvc tbd
notebook was
number fields davidloeffler
number theory was
numerical jkantor
optional packages tbd
packages tbd
padics roed
performance tbd
pickling was
porting drkirkby
quadratic forms justin
relocation tdb
sage-mode ncalexan
solaris drkirkby
spkg-check tbd
statistics amhou
symbolics burcin
user interface was
website/wiki schilly

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] trac component ownership

On Mon, Nov 30, 2009 at 1:43 PM, Nicolas M. Thiery
<Nicolas.Thiery@u-psud.fr> wrote:
> On Sun, Nov 29, 2009 at 12:22:36AM +0100, Florent hivert wrote:
>> > I volunteer for combinatorics if Mike wants to get out of it.
>> >
>> > Alternatively, would it make sense to make sage-combinat the owner,
>> > meaning in practice we would share the work between Florent, Mike,
>> > myself, for a better 24/24 7/7 service?
>>
>> Does that mean that one of us has to move to Vladivostok, Pekin or Sidney ?
>
> We should get Dan to join. I mean: Dan Bump if Mike is still in
> Malaysia, and Dan Drake otherwise. Actually probably both :-)
>
>> By the way they are 7 patch to review concerning
>> combinatorics... Should'nt we make an ad on sage-combinat-devel ?
>
> Go ahead!
>
>> And finally speaking about the combinat upstream teem, on trac, there is this
>> sage-combinat milestone. I don't know exactly what it is for ? Is there any
>> use for it ? Right now it only looks like a combinat wishlist. Especially
>> since any finished ticket is moved to the relevant sage version. Is it really
>> used ?  should we keep it ? Isn't it redundant with the component ?
>
> Probably redundant indeed. William: can you kill the beast?

Done. All 19 tickets assigned to that milestone are now assigned to
the sage-4.3 milestone.

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Readme not very accurate about installing a binary distribution

2009/11/30 Minh Nguyen <nguyenminh2@gmail.com>:
> Hi David,
>
> On Tue, Dec 1, 2009 at 9:29 AM, David Kirkby <david.kirkby@onetel.net> wrote:
>> I just built a Sage binary on one machine (Netra T1, Solaris 10
>> 03/2005) and move it to a faster machine (Blade 2000) running the
>> latest version of Solaris. I installed it as root, in a different
>> location from where it was built on the first machine. I then tried to
>> run it as a normal user, and get
>
> My two-cent, but you probably know already: Say as root, you build
> Sage and then move the resulting binary to a different directory.
> After moving the whole Sage (binary) directory, you need to start up
> Sage as root at least once before you use Sage as another user.
>
> --
> Regards
> Minh Van Nguyen

Yes, but not only that, assuming you logged in as a normal user and
used su to root, you need to then remove the root owned files in that
users $HOME/.sage directory, otherwise he can't use Sage (see my other
post). Every other user could use it though.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Readme not very accurate about installing a binary distribution

Hi Simon,

On Tue, Dec 1, 2009 at 9:48 AM, Simon King <simon.king@nuigalway.ie> wrote:

<SNIP>

> I guess David's point was that this information should be stated more
> clearly in the Readme text.

See ticket #7565 [1] for a newer README.txt file. I hope the newer
README.txt is much clearer about the concern David raised.

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

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Issues installing a binary distribution of 4.2.1 on Solaris

I build Sage 4.2.0 on a machine with the first release of Solaris 10.
(A painfully slow process, as the machine is only 500 MHz). I
upgraded that to 4.2.1, which went without a hitch.

As you will gather from a previous email or two, I've created a
Solaris binary using

./sage -bdist

on the slow SPARC (call it 'buildhost') with an old version of Solaris
10, and tried to move the SPARC binary distribution to another
machine, which I'll call 'target'

Another couple of problems I hit are.

1) There is a complaint on the target that 'ranlib' is not installed.
I've no idea why that might be needed on a binary distribution. (In
any case, it is, but just not in the path). I ingored this message.

2) There is a error message on the target that libgcc_s.so.1 could not
be opened. This is perfectly understandable. If Sage is built on the
buildhost against a GCC library, then that library needs to be on the
target system. So I think it will be necessary to copy libgcc_s.so.1
and probably the Fortran library too. The script for building the
binary distribution did not do that.

That probably means we need to save the location of the libraries
during the build process, so they can be copied over. Perhaps using
'ldd' and see what the binaries links against would be a sensible way
of doing this. Then copy the non-system libraries over. (If be just
build with 'gcc' rather than /path/to/gcc, then knowing the location
of the libraries will not be so easy.

(There might be an issue if gcc is GPL3, as it would require copying
the binaries created with GPL 3 code. But perhaps that is permitted,
but I am not so sure.)

3) Since I had gcc installed on the target system, I set
LD_LIBRARY_PATH to include the lib directory of the gcc install. This
could have been a problem, as the buildhost had gcc 4.4.2 but the
nearest version on the target was 4.4.1. But that seemed to work ok.
But more importantly, there was no reason to have gcc installed on the
target. Had I not had a recent gcc on the target machine, I do not
believe Sage would have worked.

4) Having logged in as 'drkirkby', and used 'su' to get to root, when
I run Sage, it rebuild all the necessary files, but stuck some data in
/export/home/drkirkby/.sage but owned by root.

I could then run Sage ok as root.

5) Having seen sage run ok as root, I tried it as user 'drkirkby'. But
this time I got an error that /export/home/drkirkby/.sage could not be
written to. The fact I had used su to switch user, meant that running
Sage as root created the files own by root in drkirkby's directory.
Then drkirkby could not write to them, so he could not run Sage.

6) I then switched user to root, and removed the root-owned files from
drkirkby's directory.

# rm -rf /export/home/drkirkby/.sage

7) Then run Sage as user drkirkby. It gave a couple of warning, but
does work. In fact the GUI worked too. The Sage server was running at
localhost on port 8000.

So it seems there a few issues with the sage-bdist script on Solaris.
The major ones being the GNUism with the -a option to 'cp', and the
fact the gcc libraries are not copied when the binary distribution is
created.


Here's Sage, running on a different system, installed as root, but run
as a normal user.


drkirkby@swan:[~] $ /usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/sage
----------------------------------------------------------------------
| Sage Version 4.2, Release Date: 2009-10-24 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Setting permissions of DOT_SAGE directory so only you can read and write it.
sage: notebook()
The notebook files are stored in: sage_notebook.sagenb

Please choose a new password for the Sage Notebook 'admin' user.
Do _not_ choose a stupid password, since anybody who could guess your password
and connect to your machine could access or delete your files.
NOTE: Only the md5 hash of the password you type is stored by Sage.
You can change your password by typing notebook(reset=True).

Enter new password: *****
Retype new password: *****

Please login to the notebook with the username 'admin' and the above password.
Password changed for user 'admin'.
**************************************************
* *
* Open your web browser to http://localhost:8000 *
* *
**************************************************
/usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/local/lib/python2.6/site-packages/twisted/persisted/sob.py:12:
DeprecationWarning: the md5 module is deprecated; use hashlib instead
import os, md5, sys
2009-11-30 23:05:19+0000 [-] Log opened.
2009-11-30 23:05:19+0000 [-] twistd 8.2.0
(/usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/local/bin/python
2.6.2) starting up.
2009-11-30 23:05:19+0000 [-] reactor class:
twisted.internet.selectreactor.SelectReactor.
2009-11-30 23:05:19+0000 [-] twisted.web2.channel.http.HTTPFactory
starting on 8000
/usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/local/bin/sage-native-execute:
xdg-open: not found
2009-11-30 23:05:19+0000 [-] Starting factory
<twisted.web2.channel.http.HTTPFactory instance at 0x3c98b48>

But at that point Sage works - including the GUI.

So I have managed to build Sage 4.2.0, upgrade it to 4.2.1, and move
the distribution from an old version of Solaris to a very recent
version. Install it as root, and run as a normal user. But it was far
from a trivial process.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] trac component ownership

On Mon, 30 Nov 2009 at 10:43PM +0100, Nicolas M. Thiery wrote:
> > Does that mean that one of us has to move to Vladivostok, Pekin or
> > Sidney ?
>
> We should get Dan to join. I mean: Dan Bump if Mike is still in
> Malaysia, and Dan Drake otherwise. Actually probably both :-)

I was going to mention that Sydney, Vladivostok, and Beijing are all
within two hours of my time zone. :)

Dan

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

[sage-devel] Re: Readme not very accurate about installing a binary distribution

Simon King wrote:
> Hi Minh
>
> On 30 Nov., 23:44, Minh Nguyen <nguyenmi...@gmail.com> wrote:
> ....
>> My two-cent, but you probably know already: Say as root, you build
>> Sage and then move the resulting binary to a different directory.
>> After moving the whole Sage (binary) directory, you need to start up
>> Sage as root at least once before you use Sage as another user.
>
> I guess David's point was that this information should be stated more
> clearly in the Readme text.
>

+1

Jaap


> Cheers
> Simon
>

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Readme not very accurate about installing a binary distribution

Minh Nguyen wrote:
> Hi David,
>
> On Tue, Dec 1, 2009 at 9:29 AM, David Kirkby <david.kirkby@onetel.net> wrote:
>> I just built a Sage binary on one machine (Netra T1, Solaris 10
>> 03/2005) and move it to a faster machine (Blade 2000) running the
>> latest version of Solaris. I installed it as root, in a different
>> location from where it was built on the first machine. I then tried to
>> run it as a normal user, and get
>
> My two-cent, but you probably know already: Say as root, you build
> Sage and then move the resulting binary to a different directory.
> After moving the whole Sage (binary) directory, you need to start up
> Sage as root at least once before you use Sage as another user.
>

And I do as root:

chmod a+rX -R "path/to/sage"


Another two cents.

Jaap

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Readme not very accurate about installing a binary distribution

Hi Minh

On 30 Nov., 23:44, Minh Nguyen <nguyenmi...@gmail.com> wrote:
...
> My two-cent, but you probably know already: Say as root, you build
> Sage and then move the resulting binary to a different directory.
> After moving the whole Sage (binary) directory, you need to start up
> Sage as root at least once before you use Sage as another user.

I guess David's point was that this information should be stated more
clearly in the Readme text.

Cheers
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Readme not very accurate about installing a binary distribution

Hi David,

On Tue, Dec 1, 2009 at 9:29 AM, David Kirkby <david.kirkby@onetel.net> wrote:
> I just built a Sage binary on one machine (Netra T1, Solaris 10
> 03/2005) and move it to a faster machine (Blade 2000) running the
> latest version of Solaris. I installed it as root, in a different
> location from where it was built on the first machine. I then tried to
> run it as a normal user, and get

My two-cent, but you probably know already: Say as root, you build
Sage and then move the resulting binary to a different directory.
After moving the whole Sage (binary) directory, you need to start up
Sage as root at least once before you use Sage as another user.

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Error building a binary ??? cp: cannot access *.sage

> cp: cannot access *.sage

In short: that does not seem to be a new problem.

I've seen this line before (I think I get it every time I build a
bdist on my Macs), and I admit, that I never cared. The files ending
in *.sage are supposed to be loadable/attachable scripts (in)to Sage
sessions, see e.g. the examples spkg/subdir, but the copy command for
them while creating a bdist is most probably a historical leftover,
and not needed. It should be easy to remove. If you wish so, open a
(another?!?) ticket and put me in Cc. Or add a "cleaned up" version to
trac #7407.

Cheers,
Georg

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Readme not very accurate about installing a binary distribution

I just built a Sage binary on one machine (Netra T1, Solaris 10
03/2005) and move it to a faster machine (Blade 2000) running the
latest version of Solaris. I installed it as root, in a different
location from where it was built on the first machine. I then tried to
run it as a normal user, and get

drkirkby@swan:[~] $ /usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/sage
----------------------------------------------------------------------
| Sage Version 4.2, Release Date: 2009-10-24 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
The Sage install tree may have moved.
Regenerating Python.pyo and .pyc files that hardcode the install PATH
(please wait at most a few minutes)...
Do not interrupt this.
Traceback (most recent call last):
File "/usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/local/bin/sage-location",
line 180, in <module>
update_library_files(R)
File "/usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/local/bin/sage-location",
line 128, in update_library_files
open(LIB + F,'w').write(H)
IOError: [Errno 13] Permission denied:
'/usr/local/sage-4.2-Solaris-10-SPARC-sun4u-SunOS/local/lib/libsqlite3.la'


If files need to be rebuilt, it is worth stating these need to be done
by a user with privileges to write to file in the distribution. I
assume if I log in as root, I will get this message.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] How to doc test tab completion?

Hi!

At #6854 (ready for review, I think), I implemented introspection and
tab completion for elements of Infinite Polynomial Rings. This became
necessary since they have a __getattr__ method that allows to use
methods of the underlying *finite* polynomial (e.g., _latex_) in an
easy way, to the expence of leaving these "pseudo-inherited" methods
invisible for introspection and tab completion.

It is clear how to doc test introspection: use dir() on an instance of
the class.

But how to doc test tab completion? Is there a better way than to call
the relevant underscore method (here: _getAttributeNames) directly?

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] trac component ownership

William Stein wrote:
> Hi,
>
> Here are the trac components with who "owns" each. It's possible that
> many of these are dated/wrong/silly at this point. If anybody would
> like to suggest changes, volunteer to own a component, etc., just
> respond in this thread. Don't ask me exactly what it "means" to own a
> component in trac though...
>
> Name Owner
> -----------------------------------
> algebra tbd
> algebraic geometry was

Is there any way I can list these? There have been several changes, and it would
be nice to see what the current status is. Are there still some 'tbd', which I
assume is 'to be determined' but perhaps I am wrong.

dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Implementation of Graphs, c_graphs, and NetworkX

Hi kcrisman,

On Mon, Nov 30, 2009 at 10:42 AM, kcrisman <kcrisman@gmail.com> wrote:

<SNIP>

> That is odd; I am pretty sure there used to be such a method, maybe
> two years ago?

Ticket #7564 [1] improves the documentation of the method
GenericGraph.degree() by adding two examples showing how one could use
that method to obtain the degree sequence of a graph. The ticket needs
some reviewing love :-)

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

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] trac component ownership

On Sun, Nov 29, 2009 at 12:22:36AM +0100, Florent hivert wrote:
> > I volunteer for combinatorics if Mike wants to get out of it.
> >
> > Alternatively, would it make sense to make sage-combinat the owner,
> > meaning in practice we would share the work between Florent, Mike,
> > myself, for a better 24/24 7/7 service?
>
> Does that mean that one of us has to move to Vladivostok, Pekin or Sidney ?

We should get Dan to join. I mean: Dan Bump if Mike is still in
Malaysia, and Dan Drake otherwise. Actually probably both :-)

> By the way they are 7 patch to review concerning
> combinatorics... Should'nt we make an ad on sage-combinat-devel ?

Go ahead!

> And finally speaking about the combinat upstream teem, on trac, there is this
> sage-combinat milestone. I don't know exactly what it is for ? Is there any
> use for it ? Right now it only looks like a combinat wishlist. Especially
> since any finished ticket is moved to the relevant sage version. Is it really
> used ? should we keep it ? Isn't it redundant with the component ?

Probably redundant indeed. William: can you kill the beast?

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthiery@users.sf.net>
http://Nicolas.Thiery.name/

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Error building a binary ??? cp: cannot access *.sage

You may recall some discussion recently about ./sage -bdist was not working on
Solaris, due to a GNUism (the non-POSIX option -a to 'cp').

I've attempted to fix this, by using more appropiate options for systems other
than Linux. There are basically two changes

I am however getting this message

drkirkby@kestrel:~/sage-4.2$ ./sage -bdist Solaris10
Sage works!
Copying files over to tmp directory
cp: cannot access *.sage
Copying Sage library over
Making empty spkg's
Creating tar.gz
sage-Solaris10-sun4u-SunOS/
sage-Solaris10-sun4u-SunOS/examples/
<snip>
Moving final distribution file to /export/home/drkirkby/sage-4.2/dist

I need to remake the tar file anyway, as I forgot to put the version number in
the tar file name, and also it has been upgraded to 4.2.1.

My updated build script to make the binary is at

http://sage.math.washington.edu/home/kirkby/Solaris-fixes/sage-bdist/

I will add this to trac

http://trac.sagemath.org/sage_trac/ticket/7407

but I'm not going to do that if there's a problem with it.

The binary is 735M. Does that seem about right ? I've no idea how I'm going to
upload that to 't2'!! It will take ages on my network, which is only 256 kB/s
upload. But it was build on the first release of Solaris 10, so should hopefully
(fingers crossed) run on any Solaris 10 release.

Dave

Dave


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: deprecation policy

On Mon, Nov 23, 2009 at 02:19:14AM +0100, Florent hivert wrote:
> 1 - Add an option called ``version`` do deprecation where you can put the
> information on since which version of sage this thing was deprecated:
>
> sage: def bar():
> ... sage.misc.misc.deprecation("The function bar is removed.",
> ... 'Sage Version 4.2, Release Date: 2009-10-24')
> sage: bar()
> doctest:...: DeprecationWarning: (Since Sage Version 4.2, Release Date: 2009-10-24) The function bar is removed.
>
> Note: This does noting than gluing the two strings, but this prompt the writer
> of the function to insert this information at the right place. For backward
> compatibility, This is only optional.

Thanks! I would even make the call shorter:

sage.misc.misc.deprecation("The function bar is removed.", version = "4.2")

This will help ensure consistency in the output, and makes it trivial
for deprecation to parse the version info (say to make a date lookup
after, as was suggested elsewhere).

> 2 - When renaming a function or method, you can use deprecated_function_alias
> or deprecated_method_alias to keep the function under the old name:
>
> sage: from sage.misc.misc import deprecated_method_alias
> sage: class cls(object):
> ... def new_meth(self): return 42
> ... old_meth = deprecated_method_alias(new_meth,
> ... 'Sage Version 42.132, Release Date: 5123-04-01')
> sage: cls().old_meth()
> doctest:...: DeprecationWarning: (Since Sage Version 42.132, Release Date: 5123-04-01) old_meth is deprecated. Please use new_meth instead.
> 42

Great!

Of course, same version="4.2" suggestion.

This opens the door for instrumenting deprecated_*_aliases, in order
to automatically build a list of deprecated functions, etc.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthiery@users.sf.net>
http://Nicolas.Thiery.name/

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Printing...

On Sat, Nov 28, 2009 at 02:38:35PM -0800, William Cauchois wrote:
> Original author of the patch here. I took some time to look at this
> today and found that the doctesting bug was due to reading the value
> of sys.stdout only once in install(); during doctesting, sys.stdout is
> reset some time after install() is called, presumably to redirect
> output back to the doctesting mechanism.
>
> I fixed this bug and restructured the code by moving it out of a class
> (since the single instance variable was no longer needed) in a new
> patch which I've uploaded to #1918. Unless we find any more bugs with
> the displayhook, the only problem that remains is that of updating the
> doctests where a list of matrices is output.

As said Florent: THANKS! That's one of those little things that have a
big practical impact.

> Back when I was working on this, my approach to fixing the doctests
> relied upon an automatic solution. William had told me about this
> nifty little tool called sage -fixdoctests that looked at the output
> of a test run and spliced the output from the "Expected:" section back
> into the original source code so that it would pass the doctest. The
> problem was, sage -fixdoctests couldn't handle multiline output from a
> test case, which are exactly the types of outputs that will be
> affected by the displayhook. I spent some time writing a tool that
> could handle multiline outputs based on sage -fixdoctests, but even
> though it should be really simple I kept making off by one errors :).
>
> As soon as I get back home to my external HD, I can post the source of
> that incomplete tool. I will take a look and see if I can fix it,
> because I think that a fixed sage -fixdoctests would be a valuable
> resource to the Sage community.

For the record: there is a patch of mine on trac with sage
-fixdoctests improvements, in particular for multiline output (sorry,
I am in the train, and unable to look up the ticket number). By
accident it did not get merged earlier, but will definitely be in sage
4.3. Feedback and further improvements are most welcome!

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthiery@users.sf.net>
http://Nicolas.Thiery.name/

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] problem building Sage on Fedora

Hello,

Singular does not build properly on a Fedora system (4 processors
Intel Xeon). The end of the log is copied at the end of this message
and the complete log can be accessed from :
http://iml.univ-mrs.fr/~delecroi/install.log.tar.gz

I will try the binary solution unless you have a solution...

[...]

tgb_internal.h:555: error: parse error in template argument list
tgb_internal.h:1730: error: parse error in template argument list
make[4]: *** [tgb.o] Error 1
make[4]: Leaving directory `/home/users/sage/sage-4.2.1/spkg/build/
singular-3-1-0-4-20090818.p1/src/kernel'
make[3]: *** [install] Error 1
make[3]: Leaving directory `/home/users/sage/sage-4.2.1/spkg/build/
singular-3-1-0-4-20090818.p1/src'
make[2]: *** [/home/users/sage/sage-4.2.1/local/bin/Singular-3-1-0]
Error 2
make[2]: Leaving directory `/home/users/sage/sage-4.2.1/spkg/build/
singular-3-1-0-4-20090818.p1/src'
Unable to build Singular.

[...]

sage: An error occurred while installing singular-3-1-0-4-20090818.p1

[...]

Vincent

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Why Is It Essential To Keep An Updated Resume!!!!!!!!!!!!!!!!!!!

I've just banned this person. I can't find the message, so I guess
another moderator deleted it already.

Sorry for the spam.

On Mon, Nov 30, 2009 at 10:28 AM, Shoaib Khan <shoaibk16@gmail.com> wrote:
> Why Is It Essential To Keep An Updated Resume!!!!!!!!!!!!!!!!!!!
> Just check it out guys.
> http://highbrains.com/?page_id=1124
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: buggy binomial

I confirm this in 4.2.1. This is now #7562.

- kcrisman

On Nov 30, 12:19 pm, Henryk Trappmann <bo198...@googlemail.com> wrote:
> The binomial is buggy again (sage 4.2):
>
> In [143]: [binomial(1,1),binomial(1,2),binomial(1,3),binomial(1,4)]
> Out[143]: [1, 0, 0, 0]
>
> In [144]: [binomial(1.0,1),binomial(1.0,2),binomial(1.0,3),binomial
> (1.0,4)]
> Out[144]: [1.00000000000000, 0.000000000000000, NaN, NaN]

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Implementation of Graphs, c_graphs, and NetworkX

> sage: sorted(g.degree(), reverse=True)
> [4, 4, 3, 3, 2, 2, 2]

This is probably what I was thinking of; I didn't see sample code.
Probably in the situations I used, I just used g.degree() all by its
lonesome self, unsorted, because the cases I needed could be done "by
hand".

- kcrisman

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] buggy binomial

The binomial is buggy again (sage 4.2):

In [143]: [binomial(1,1),binomial(1,2),binomial(1,3),binomial(1,4)]
Out[143]: [1, 0, 0, 0]

In [144]: [binomial(1.0,1),binomial(1.0,2),binomial(1.0,3),binomial
(1.0,4)]
Out[144]: [1.00000000000000, 0.000000000000000, NaN, NaN]

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Why Is It Essential To Keep An Updated Resume!!!!!!!!!!!!!!!!!!!

Why Is It Essential To Keep An Updated Resume!!!!!!!!!!!!!!!!!!!
Just check it out guys.
http://highbrains.com/?page_id=1124


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] new version of compmath proposal

On Mon, Nov 30, 2009 at 02:28:57AM -0800, William Stein wrote:
> Hi,
>
> I've posted a new version of the compmath proposal here:
>
> http://wstein.org/grants/compmath09/project_summary.pdf
> http://wstein.org/grants/compmath09/project_description.pdf
> http://wstein.org/grants/compmath09/references_cited.pdf
>
> This is basically the final version, though I could probably fix some
> typos. So if you read it and see typos, let me know. If you see
> anything technically seriously wrong/stupid, also let me know.
>

I have a couple of comments on the topology section.

1. I don't understand the first sentence: "Sage currently has fairly
sophisticated support for topology, and we would like to push both
further." What does "both" refer to? Both Sage and topology? It
sounds weird.

2. "homotopy theorists only care about 1-dimensional formal group
laws". This is true to some extent due to the applications they have
in mind, but I think that recent work by Mark Behrens and others on
topological automorphic forms involves higher-dimensional fgl's.

3. "In general, we intend to implement free modules, projective
modules, and injective modules over arbitrary rings, and we intend to
implement resolutions and derived functors. Where possible, we also
intend to implement methods of computing resolutions"
my comment here: excellent!!! this will also be great to have for
improving the algebraic geometry functionality!


Good luck!
Alex

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

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] new version of compmath proposal

On Mon, Nov 30, 2009 at 06:26:55AM -0500, Tim Daly wrote:
> William Stein wrote:
> > Hi,
> >
> > I've posted a new version of the compmath proposal here:
> >
> > http://wstein.org/grants/compmath09/project_summary.pdf
> > http://wstein.org/grants/compmath09/project_description.pdf
> > http://wstein.org/grants/compmath09/references_cited.pdf
> >
> > This is basically the final version, though I could probably fix some
> > typos. So if you read it and see typos, let me know. If you see
> > anything technically seriously wrong/stupid, also let me know.
> >
> > Thanks,
> >
> > -- William
> >
> >
> I'm not on the NSF committee to review this but it appears that
> you are asking for funding for Sage days. One of the "innovative"
> Sage days listed for funding is a "Bug Smash" day. So one of the
> four days of funding is for debugging work.

Sorry, but this doesn't make any sense. What do you mean by "one of
four days of funding"?

As far as I can tell, the proposal asks for funding for 4 workshops
per year for 3 years. The themes for the workshops are described in
sections 3-10, and none of these mention bug smash days.

The only place "bug smash" occurs is on pages 3-4 of the proposal, in
the list of past and near future workshops. I believe that all the
workshops listed there already have funding secured, so they would not
need NSF funds. Moreover, the only "bug smash day" that's in the
future is in January 2010, and since this proposal is going to be
submitted to the NSF *now*, any funds from the proposal will only
appear toward the second half of 2010.

> Am I misreading the proposal?

I think so. Maybe one of the authors can confirm this.


Best,
Alex


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

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] new version of compmath proposal

William Stein wrote:
> Hi,
>
> I've posted a new version of the compmath proposal here:
>
> http://wstein.org/grants/compmath09/project_summary.pdf
> http://wstein.org/grants/compmath09/project_description.pdf
> http://wstein.org/grants/compmath09/references_cited.pdf
>
> This is basically the final version, though I could probably fix some
> typos. So if you read it and see typos, let me know. If you see
> anything technically seriously wrong/stupid, also let me know.
>
> Thanks,
>
> -- William
>
>
I'm not on the NSF committee to review this but it appears that
you are asking for funding for Sage days. One of the "innovative"
Sage days listed for funding is a "Bug Smash" day. So one of the
four days of funding is for debugging work.

Am I misreading the proposal? Is a "Bug Smash" day "innovative"?

If nothing else, you might retitle the day to something else.

Believe me, I understand the critical importance of bug smashing
to the progress and success of the project. I'm just not sure that
the committee might not consider it worth funding. I see a lot of
words, like the S-Dyer proposal but I couldn't get funding at CCNY
to work on the Andrews-Curtis conjecture from Infinite Group Theory
(see http://daly.axiom-developer.org in the bottom right corner)

Magnus is the largest Infinite Group Theory project and was
originally created through NSF funding. At one point, the funding
dried up, about the time I became lead developer, although I'm
not sure that correlation implies causation in this case.

Tim

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] new version of compmath proposal

Hi,

I've posted a new version of the compmath proposal here:

http://wstein.org/grants/compmath09/project_summary.pdf
http://wstein.org/grants/compmath09/project_description.pdf
http://wstein.org/grants/compmath09/references_cited.pdf

This is basically the final version, though I could probably fix some
typos. So if you read it and see typos, let me know. If you see
anything technically seriously wrong/stupid, also let me know.

Thanks,

-- William

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันอาทิตย์ที่ 29 พฤศจิกายน พ.ศ. 2552

Re: [sage-devel] Re: Portability issue - GNU specific options sent to non-GNU compiler

Dr. David Kirkby wrote:
>
> I tried it, but simply hard-coding the flag in custom.py (no checking what
> compiler it is). It still fails to build, though the previous error message has
> gone, there are still other error messages. See below.
>
> Not knowing C++, I can't really comment on this.
>
> One thing I did note, is that if library=stlport4 is added as an option in one
> file, then it needs to be done in them all. So clearly this is something that
> needs to be set globally as a CFLAG, and not implemented just in PolyBoRi.
>
> Dave

The compiler option -library=stlport4 should obviously go as a CXXFLAG, not a
CFLAG.


The couple of scripts I wrote on this ticket,

http://trac.sagemath.org/sage_trac/ticket/7505

which needs reviewing, determine the C and C++ compilers based purely on what
macros are defined.

The script will return one of the following, to indicate the C compiler and C++
compilers (there are scipts called testcc.sh and testcxx.sh - one for C, the
other C++)

GCC - For gcc or a gcc-like C compiler on any platform
Sun_Studio - For Sun Studio or earlier Sun C compiler
HP_on_Tru64 - For a C compiler produced by HP/Compaq for Tru64
HP_on_HP-UX - For a C compiler produced by HP/Compaq for HP-UX
IBM_on_AIX - For a C compiler produced by IBM for AIX
HP_on_Alpha_Linux - For a C compiler produced by HP for Alpha linux
(This script has not been tested on Alpha Linux,
but is based on HP's documentation)
Unknown - If the C compiler type is unknown

Implementing something like this for Fortran is nowhere near as easy.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Sage at the joint meetings in San Francisco

After thinking about it some, I'm leaning against my original idea of
an "ask me about sage" shirt. I wouldn't ordinarily want to wear it.
But I am thinking of printing another one of the shirts I made for the
raffle last year. All you need to do to get one from cafepress.com is
to upload

http://sage.math.washington.edu/home/mhampton/sageshirt.png

to your favorite shirt type. Or just make your own, the cafepress
process is really easy.

-Marshall

On Nov 29, 5:36 pm, Dan Drake <dr...@kaist.edu> wrote:
> On Sun, 29 Nov 2009 at 09:32AM -0800, Simon King wrote:
> > On Nov 29, 4:37 pm, mhampton <hampto...@gmail.com> wrote:
> > > OK, I've ordered 500 business cards. I was thinking that perhaps it
> > > would be fun to make a t-shirt that said "Ask me about Sage!". If
> > > anyone else is interested I could order a few, although I don't want
> > > to front a lot of money for it.
>
> I'll be at the Joint Meetings and would be happy to take some and help
> distribute them. If the t-shirt idea goes through, I'd likely order one.
>
> Dan
>
> --
> --- Dan Drake
> ----- http://mathsci.kaist.ac.kr/~drake
> -------
>
> signature.asc
> < 1KViewDownload

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Implementation of Graphs, c_graphs, and NetworkX

Hi kcrisman,

On Mon, Nov 30, 2009 at 10:42 AM, kcrisman <kcrisman@gmail.com> wrote:

<SNIP>

> That is odd; I am pretty sure there used to be such a method, maybe
> two years ago?

It turns out there is such a function. One could use
Graph.degree_iterator() as suggested by mhansen, or Graph.degree() as
suggested by ncohen. But the result must be sorted in non-increasing
order:

[mvngu@sage ~]$ sage
----------------------------------------------------------------------
| Sage Version 4.2.1, Release Date: 2009-11-14 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: g = Graph({"a": ["b", "e"], "b": ["a", "g", "e", "c"], \
....: "c": ["b", "e", "d"], "d": ["c", "f"], "e": ["f", "a", "b", "c"], \
....: "f": ["g", "d", "e"], "g": ["b", "f"]})
sage: sorted(g.degree(), reverse=True)
[4, 4, 3, 3, 2, 2, 2]
sage: sorted(g.degree_iterator(), reverse=True)
[4, 4, 3, 3, 2, 2, 2]

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Portability issue - GNU specific options sent to non-GNU compiler

Alexander Dreyer wrote:
> Dear Dave,
>> The C++ compiler supports the ISO standard for C++, ISO IS 14882:1998,
>> Programming Language C++. The following list describes requirements in the
>> standard that are not supported in this release:
>> * The export model of template compilation
>> * Some functionality of the C++ library is not implemented in the default
>> libCstd to preserve binary compatibility between the current and earlier
>> releases of the C++ compiler. For more information, check the C++ FAQ. I can't
>> see anything relevant looking in the FAQ.
> From
> http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html
> I read, that one might have to build with -library=stlport4 .
>
> I'll try it out.
>
> Best regards,
> Alexander
>

I tried it, but simply hard-coding the flag in custom.py (no checking what
compiler it is). It still fails to build, though the previous error message has
gone, there are still other error messages. See below.

Not knowing C++, I can't really comment on this.

One thing I did note, is that if library=stlport4 is added as an option in one
file, then it needs to be done in them all. So clearly this is something that
needs to be set globally as a CFLAG, and not implemented just in PolyBoRi.

Dave


/opt/xxxsunstudio12.1/bin/CC -o polybori/src/BoolePolyRing.o -c -O3 -g -fPIC -g
-fPIC -library=stlport4 -O3 -g -fPIC -DNDEBUG -DHAVE_GD -DPACKED -DHAVE_M4RI
-DHAVE_GD -DHAVE_IEEE_754 -DBSD
-I/export/home/drkirkby/sage-4.3.alpha0-sun-compiler/spkg/build/polybori-0.6.3-20090827.p0/src/boost_1_34_1.cropped
-I/export/home/drkirkby/sage-4.3.alpha0-sun-compiler/local/include
-I/export/home/drkirkby/sage-4.3.alpha0-sun-compiler/local/include/python2.6
-Ipolybori/include -IM4RI -ICudd/obj -ICudd/util -ICudd/cudd -ICudd/mtr
-ICudd/st -ICudd/epd polybori/src/BoolePolyRing.cc
CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise
"polybori/include/CDDManager.h", line 103: Warning: Last line in file
"polybori/include/cacheopts.h" is not terminated with a newline.
"polybori/include/CCuddZDD.h", line 308: Warning (Anachronism): Formal argument
func of type DdNode*(*)(DdManager*,DdNode*,int) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::apply(DdNode*(*)(DdManager*,DdNode*,int),
int) const is being passed extern "C" DdNode*(*)(DdManager*,DdNode*,int).
"polybori/include/CCuddZDD.h", line 308: Warning (Anachronism): Formal argument
func of type DdNode*(*)(DdManager*,DdNode*,int) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::apply(DdNode*(*)(DdManager*,DdNode*,int),
int) const is being passed extern "C" DdNode*(*)(DdManager*,DdNode*,int).
"polybori/include/CCuddZDD.h", line 308: Warning (Anachronism): Formal argument
func of type DdNode*(*)(DdManager*,DdNode*,int) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::apply(DdNode*(*)(DdManager*,DdNode*,int),
int) const is being passed extern "C" DdNode*(*)(DdManager*,DdNode*,int).
"polybori/include/CCuddZDD.h", line 313: Warning (Anachronism): Formal argument
func of type DdNode*(*)(DdManager*,DdNode*,DdNode*,DdNode*) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::apply(DdNode*(*)(DdManager*,DdNode*,DdNode*,DdNode*),
const polybori::CCuddZDD&, const polybori::CCuddZDD&) const is being passed
extern "C" DdNode*(*)(DdManager*,DdNode*,DdNode*,DdNode*).
"polybori/include/CCuddZDD.h", line 322: Warning (Anachronism): Formal argument
func of type int(*)(DdManager*,DdNode*) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::apply(int(*)(DdManager*,DdNode*))
const is being passed extern "C" int(*)(DdManager*,DdNode*).
"polybori/include/CCuddZDD.h", line 323: Warning (Anachronism): Formal argument
func of type int(*)(DdManager*,DdNode*) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::apply(int(*)(DdManager*,DdNode*))
const is being passed extern "C" int(*)(DdManager*,DdNode*).
"polybori/include/CCuddZDD.h", line 327: Warning (Anachronism): Formal argument
func of type int(*)(DdManager*,DdNode*) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::memApply<int>(int(*)(DdManager*,DdNode*))
const is being passed extern "C" int(*)(DdManager*,DdNode*).
"polybori/include/CCuddZDD.h", line 330: Warning (Anachronism): Formal argument
func of type double(*)(DdManager*,DdNode*) in call to
polybori::CCuddDDBase<polybori::CCuddZDD>::memApply<double>(double(*)(DdManager*,DdNode*))
const is being passed extern "C" double(*)(DdManager*,DdNode*).
"polybori/include/CCuddInterface.h", line 192: Warning (Anachronism): Formal
argument func of type DdNode*(*)(DdManager*,int) in call to
polybori::CCuddInterface::apply(DdNode*(*)(DdManager*,int), int) const is being
passed extern "C" DdNode*(*)(DdManager*,int).
"polybori/include/CCuddInterface.h", line 195: Warning (Anachronism): Formal
argument func of type DdNode*(*)(DdManager*,int) in call to
polybori::CCuddInterface::apply(DdNode*(*)(DdManager*,int), int) const is being
passed extern "C" DdNode*(*)(DdManager*,int).
"polybori/include/CCuddInterface.h", line 198: Warning (Anachronism): Formal
argument func of type DdNode*(*)(DdManager*) in call to
polybori::CCuddInterface::apply(DdNode*(*)(DdManager*)) const is being passed
extern "C" DdNode*(*)(DdManager*).
"polybori/include/BooleEnv.h", line 119: Error: The type
"polybori::BoolePolyRing" is incomplete.
"polybori/include/CTermGenerator.h", line 86: Error: TermType is not defined.
"polybori/include/CTermGenerator.h", line 259: Error: The base
"polybori::CTermGeneratorBase<polybori::BooleMonomial, int>" must be a
previously defined class or struct.
"polybori/include/CTermGenerator.h", line 86: Error: TermType is not defined.
"polybori/include/CTermGenerator.h", line 263: Error: data_type is not a member
of polybori::CTermGeneratorBase<polybori::BooleMonomial, int>.
"polybori/include/CTermGenerator.h", line 265: Error:
polybori::CTermGenerator<polybori::BooleMonomial>::base is not a direct base
class of polybori::CTermGenerator<polybori::BooleMonomial>.
"polybori/include/CTermGenerator.h", line 266: Error:
polybori::CTermGenerator<polybori::BooleMonomial>::base is not a direct base
class of polybori::CTermGenerator<polybori::BooleMonomial>.
"polybori/include/CTermGenerator.h", line 267: Error:
polybori::CTermGenerator<polybori::BooleMonomial>::base is not a direct base
class of polybori::CTermGenerator<polybori::BooleMonomial>.
"polybori/include/BlockDegLexOrder.h", line 143: Warning:
polybori::BlockDegLexOrder::appendBlock hides the virtual function
polybori::COrderBase::appendBlock(int) const.
"polybori/include/BlockDegLexOrder.h", line 143: Warning:
polybori::BlockDegLexOrder::clearBlocks hides the virtual function
polybori::COrderBase::clearBlocks() const.
"polybori/include/BlockDegRevLexAscOrder.h", line 152: Warning:
polybori::BlockDegRevLexAscOrder::appendBlock hides the virtual function
polybori::COrderBase::appendBlock(int) const.
"polybori/include/BlockDegRevLexAscOrder.h", line 152: Warning:
polybori::BlockDegRevLexAscOrder::clearBlocks hides the virtual function
polybori::COrderBase::clearBlocks() const.
8 Error(s) and 16 Warning(s) detected.
scons: *** [polybori/src/BoolePolyRing.o] Error 8
scons: building terminated because of errors.
Error building PolyBoRi.


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org