[sage-devel] Re: new paper on sage by myself and Burcin Erocal
"Sage interfaces to the above math software", and the table is just below :-) 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage prerequisites (bzip2)
On Thu, Jun 3, 2010 at 9:21 PM, William Stein wrote: > On Thu, Jun 3, 2010 at 9:07 PM, Ondrej Certik wrote: >> Hi, >> >> On Thu, Jun 3, 2010 at 8:44 PM, William Stein wrote: >>> On Thu, Jun 3, 2010 at 5:09 PM, Ondrej Certik wrote: Hi, we are revisiting prerequisites for FEMhub (currently based on the Sage system) and we are thinking of doing the following changes: * make Python a build dependency (Python will still be built and used as the python in FEMhub) >>> >>> So there has to be a system-wide Python, but you'll still build your >>> own. I personally >>> think that is a great idea. >>> * make bzip2 a build dependency (I checked and it seems to be on the Mac by default now too) >>> >>> Sage has this as a dependency for at least two reasons: >>> >>> (1) to get the bunzip2 binary, so we can extract spkg's. >>> >>> (2) for libbz2 and corresponding header files, so that we get the >>> bz2 Python module, which we use for compressing our "sobj" files >>> (which are just bz2 compressed Python pickles). >> >> Yes, >> >>> >>> I don't know of any other way in which we use bzip2. For FEMHUB (2) >>> might not matter. I suspect regarding (1) that the bunzip2 is a very >>> reasonable prerequisite to assume is installed on your user's >>> computers. >> >> The only question that I am actually asking is whether: >> >> a) bzip2 should be shipped and build with Sage >> >> or >> >> b) bzip2 should be a prerequisite just like m4/gcc/perl >> >> In either case, both 1) and 2) would work. Unless I am missing something. > > You are missing something. There is a difference between having the > bzip2 (and bunzip2) binaries on a system, and having the development > headers and libraries available. I don't want to make the bzip2-dev > headers a prerequisite for building sage. Ah, I didn't realize that I need bzip2-dev too. In this case I think I'll create a bzip2 spkg package (with the headers), that I will install before Python (as any other package in Sage/FEMhub) and things should just work (as long as bzip2 binary is available on the system). Ondrej > * create a simple (order matters) list with packages to be installed, and the Python build system would install it one by one (sequentially) using "femhub -i". >>> >>> This would avoid having to use the makefile system we use. We can't >>> do this with Sage because it would make inplace upgrades of Sage more >>> difficult, right? Maybe you don't support this with FEMHUB, so it >>> doesn't matter? >> >> Yes, we don't support this. >> >>> >>> I actually wrote the first version of the Sage build system entirely >>> to support in-place upgrades, because David Kohel in Australia had >>> very limited bandwidth. (It used to be really bad in Australia.) >> >> I actually totally forgot about this possibility. I guess that in >> principle the (Python based) buildsystem can support this too somehow, >> but it would make it more complex, that's for sure. > > You could certainly implement dependency checking in Python, and get rid of > the makefiles (deps). I used make initially only because it was > available and easy. > >> >>> * simplify spkg/base, remove spkg/install, spkg/default/dep >>> >>> That's basically the previous step. >>> So I wanted to ask, if bzip2 should still be shipped with Sage, or if it can be made a prerequisite, just like m4, gcc and perl. >>> >>> We will continue to ship it with Sage. However, I can certainly see >>> you removing it from FEMHUB. >> >> Originally I wanted to have it so that Sage can use it too, but as I >> see it now, here is my plan: >> >> * remove the Sage buildsystem completely (all makefiles, install, >> dep), as well as the spkg/base dir >> * keep sage-spkg and sage-env, possibly modify it so that it still >> works (maybe some more scripts need to be kept) >> * ./femhub (the equivalent of ./sage) would call either the systemwide >> Python (during installation) or the builtin Python (after >> installation) >> * write a Python based buildsystem that uses sage-spkg to install a package >> >> So the only thing that will remain compatible with Sage are the actual >> packages, so if I provide the list of packages in Sage instead, it >> should build Sage just fine. > > -- A big +1 to remaining compatible with the spkg format. > >> >> After this is done, I'll see how it goes (and if we like it) and we >> can think again, if it's possible to extend it so that it could be >> used in Sage itself. If not, I think it will not be a problem for us >> to maintain this buildsystem separately. > > That sounds good to me. > > -- William > >> >> Ondrej >> >> -- >> To post to this group, send an email to sage-devel@googlegroups.com >> To unsubscribe from this group, send an email to >> sage-devel+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org >> > > > > -- > William Stein
[sage-devel] Re: AMS symbols in PDF, HTML documentation
In amssymb.sty, I find:
\RequirePackage{amsfonts}[1995/01/01]
\DeclareMathSymbol{\leqslant} {\mathrel}{AMSa}{"36}
so if I understand right, modifying the preamble string in conf.py to
replace \usepackage{amsfonts} by \usepackage{amssymb} will still pull
in the amsfonts package, plus add some new macros for other symbols.
This seems to work fine in limited testing (including handling
\leqslant properly) and I'll run some full-scale tests (including
trashing macros.tex) on a fresh install.
Rob
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Sage prerequisites (bzip2)
On Thu, Jun 3, 2010 at 9:07 PM, Ondrej Certik wrote: > Hi, > > On Thu, Jun 3, 2010 at 8:44 PM, William Stein wrote: >> On Thu, Jun 3, 2010 at 5:09 PM, Ondrej Certik wrote: >>> Hi, >>> >>> we are revisiting prerequisites for FEMhub (currently based on the >>> Sage system) and we are thinking of doing the following changes: >>> >>> * make Python a build dependency (Python will still be built and used >>> as the python in FEMhub) >> >> So there has to be a system-wide Python, but you'll still build your >> own. I personally >> think that is a great idea. >> >>> * make bzip2 a build dependency (I checked and it seems to be on the >>> Mac by default now too) >> >> Sage has this as a dependency for at least two reasons: >> >> (1) to get the bunzip2 binary, so we can extract spkg's. >> >> (2) for libbz2 and corresponding header files, so that we get the >> bz2 Python module, which we use for compressing our "sobj" files >> (which are just bz2 compressed Python pickles). > > Yes, > >> >> I don't know of any other way in which we use bzip2. For FEMHUB (2) >> might not matter. I suspect regarding (1) that the bunzip2 is a very >> reasonable prerequisite to assume is installed on your user's >> computers. > > The only question that I am actually asking is whether: > > a) bzip2 should be shipped and build with Sage > > or > > b) bzip2 should be a prerequisite just like m4/gcc/perl > > In either case, both 1) and 2) would work. Unless I am missing something. You are missing something. There is a difference between having the bzip2 (and bunzip2) binaries on a system, and having the development headers and libraries available. I don't want to make the bzip2-dev headers a prerequisite for building sage. >>> * create a simple (order matters) list with packages to be installed, >>> and the Python build system would install it one by one (sequentially) >>> using "femhub -i". >> >> This would avoid having to use the makefile system we use. We can't >> do this with Sage because it would make inplace upgrades of Sage more >> difficult, right? Maybe you don't support this with FEMHUB, so it >> doesn't matter? > > Yes, we don't support this. > >> >> I actually wrote the first version of the Sage build system entirely >> to support in-place upgrades, because David Kohel in Australia had >> very limited bandwidth. (It used to be really bad in Australia.) > > I actually totally forgot about this possibility. I guess that in > principle the (Python based) buildsystem can support this too somehow, > but it would make it more complex, that's for sure. You could certainly implement dependency checking in Python, and get rid of the makefiles (deps). I used make initially only because it was available and easy. > >> >>> * simplify spkg/base, remove spkg/install, spkg/default/dep >> >> That's basically the previous step. >> >>> So I wanted to ask, if bzip2 should still be shipped with Sage, or if >>> it can be made a prerequisite, just like m4, gcc and perl. >> >> We will continue to ship it with Sage. However, I can certainly see >> you removing it from FEMHUB. > > Originally I wanted to have it so that Sage can use it too, but as I > see it now, here is my plan: > > * remove the Sage buildsystem completely (all makefiles, install, > dep), as well as the spkg/base dir > * keep sage-spkg and sage-env, possibly modify it so that it still > works (maybe some more scripts need to be kept) > * ./femhub (the equivalent of ./sage) would call either the systemwide > Python (during installation) or the builtin Python (after > installation) > * write a Python based buildsystem that uses sage-spkg to install a package > > So the only thing that will remain compatible with Sage are the actual > packages, so if I provide the list of packages in Sage instead, it > should build Sage just fine. -- A big +1 to remaining compatible with the spkg format. > > After this is done, I'll see how it goes (and if we like it) and we > can think again, if it's possible to extend it so that it could be > used in Sage itself. If not, I think it will not be a problem for us > to maintain this buildsystem separately. That sounds good to me. -- William > > Ondrej > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage prerequisites (bzip2)
Hi, On Thu, Jun 3, 2010 at 8:44 PM, William Stein wrote: > On Thu, Jun 3, 2010 at 5:09 PM, Ondrej Certik wrote: >> Hi, >> >> we are revisiting prerequisites for FEMhub (currently based on the >> Sage system) and we are thinking of doing the following changes: >> >> * make Python a build dependency (Python will still be built and used >> as the python in FEMhub) > > So there has to be a system-wide Python, but you'll still build your > own. I personally > think that is a great idea. > >> * make bzip2 a build dependency (I checked and it seems to be on the >> Mac by default now too) > > Sage has this as a dependency for at least two reasons: > > (1) to get the bunzip2 binary, so we can extract spkg's. > > (2) for libbz2 and corresponding header files, so that we get the > bz2 Python module, which we use for compressing our "sobj" files > (which are just bz2 compressed Python pickles). Yes, > > I don't know of any other way in which we use bzip2. For FEMHUB (2) > might not matter. I suspect regarding (1) that the bunzip2 is a very > reasonable prerequisite to assume is installed on your user's > computers. The only question that I am actually asking is whether: a) bzip2 should be shipped and build with Sage or b) bzip2 should be a prerequisite just like m4/gcc/perl In either case, both 1) and 2) would work. Unless I am missing something. > >> * create a simple (order matters) list with packages to be installed, >> and the Python build system would install it one by one (sequentially) >> using "femhub -i". > > This would avoid having to use the makefile system we use. We can't > do this with Sage because it would make inplace upgrades of Sage more > difficult, right? Maybe you don't support this with FEMHUB, so it > doesn't matter? Yes, we don't support this. > > I actually wrote the first version of the Sage build system entirely > to support in-place upgrades, because David Kohel in Australia had > very limited bandwidth. (It used to be really bad in Australia.) I actually totally forgot about this possibility. I guess that in principle the (Python based) buildsystem can support this too somehow, but it would make it more complex, that's for sure. > >> * simplify spkg/base, remove spkg/install, spkg/default/dep > > That's basically the previous step. > >> So I wanted to ask, if bzip2 should still be shipped with Sage, or if >> it can be made a prerequisite, just like m4, gcc and perl. > > We will continue to ship it with Sage. However, I can certainly see > you removing it from FEMHUB. Originally I wanted to have it so that Sage can use it too, but as I see it now, here is my plan: * remove the Sage buildsystem completely (all makefiles, install, dep), as well as the spkg/base dir * keep sage-spkg and sage-env, possibly modify it so that it still works (maybe some more scripts need to be kept) * ./femhub (the equivalent of ./sage) would call either the systemwide Python (during installation) or the builtin Python (after installation) * write a Python based buildsystem that uses sage-spkg to install a package So the only thing that will remain compatible with Sage are the actual packages, so if I provide the list of packages in Sage instead, it should build Sage just fine. After this is done, I'll see how it goes (and if we like it) and we can think again, if it's possible to extend it so that it could be used in Sage itself. If not, I think it will not be a problem for us to maintain this buildsystem separately. Ondrej -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage prerequisites (bzip2)
On Thu, Jun 3, 2010 at 5:09 PM, Ondrej Certik wrote: > Hi, > > we are revisiting prerequisites for FEMhub (currently based on the > Sage system) and we are thinking of doing the following changes: > > * make Python a build dependency (Python will still be built and used > as the python in FEMhub) So there has to be a system-wide Python, but you'll still build your own. I personally think that is a great idea. > * make bzip2 a build dependency (I checked and it seems to be on the > Mac by default now too) Sage has this as a dependency for at least two reasons: (1) to get the bunzip2 binary, so we can extract spkg's. (2) for libbz2 and corresponding header files, so that we get the bz2 Python module, which we use for compressing our "sobj" files (which are just bz2 compressed Python pickles). I don't know of any other way in which we use bzip2. For FEMHUB (2) might not matter. I suspect regarding (1) that the bunzip2 is a very reasonable prerequisite to assume is installed on your user's computers. > * create a simple (order matters) list with packages to be installed, > and the Python build system would install it one by one (sequentially) > using "femhub -i". This would avoid having to use the makefile system we use. We can't do this with Sage because it would make inplace upgrades of Sage more difficult, right?Maybe you don't support this with FEMHUB, so it doesn't matter? I actually wrote the first version of the Sage build system entirely to support in-place upgrades, because David Kohel in Australia had very limited bandwidth. (It used to be really bad in Australia.) > * simplify spkg/base, remove spkg/install, spkg/default/dep That's basically the previous step. > So I wanted to ask, if bzip2 should still be shipped with Sage, or if > it can be made a prerequisite, just like m4, gcc and perl. We will continue to ship it with Sage. However, I can certainly see you removing it from FEMHUB. -- William > > Ondrej > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sage prerequisites (bzip2)
Hi, we are revisiting prerequisites for FEMhub (currently based on the Sage system) and we are thinking of doing the following changes: * make Python a build dependency (Python will still be built and used as the python in FEMhub) * make bzip2 a build dependency (I checked and it seems to be on the Mac by default now too) * create a simple (order matters) list with packages to be installed, and the Python build system would install it one by one (sequentially) using "femhub -i". * simplify spkg/base, remove spkg/install, spkg/default/dep So I wanted to ask, if bzip2 should still be shipped with Sage, or if it can be made a prerequisite, just like m4, gcc and perl. Ondrej -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: AMS symbols in PDF, HTML documentation
John and Jason,
Thanks for all the advice and clarifications. I'll run the suggested
experiments and report a ticket number here once its up.
Rob
On Jun 3, 4:45 pm, John H Palmieri wrote:
> On Jun 3, 1:04 pm, Rob Beezer wrote:
>
> > Mitesh Patel discovered that the tex macro "\leqslant" (a slanted
> > inequality) breaks the PDF reference manual, while it survives just
> > fine in the HTML version. (Introduced at Trac #8030, which is merged,
> > fixed at Trac #9102, awaiting review.) This symbol seems to be
> > provided by the AMS packages amssymb and/or amsfonts. On my tex
> > installation, both are provided in texmf-texlive/tex/latex/amsfonts/,
> > so I think these are fairly standard packages to expect a user/
> > developer to have.
>
> > Limited poking around shows:
>
> > (1) In doc/common/macros.tex, there is the line
>
> As far as I know, the file macros.tex is unused. See below. (I think
> it is still around because it has occasionally been useful to know
> what macros used to be included in the documentation. Perhaps it has
> served its purpose and should die a graceful death...)
>
> > \usepackage{amsmath}
>
> > but this file makes no mention of amssymb or amsfonts
>
> > (2) In doc/common/conf.py (which looks Sphinx-specific?) there is the
> > line
>
> > latex_elements['preamble'] = '\usepackage{amsmath}\n
> > \usepackage{amsfonts}\n'
>
> This should be the relevant line.
>
> You can test this: prepare the pdf (or the latex) documentation, for
> example
>
> sage -docbuild tutorial latex (or pdf)
>
> and look at the file in SAGE_ROOT/devel/sage/doc/output/latex/en/
> tutorial/. Its preamble should include the lines from
> latex_elements['preamble'], along with various macros imported from
> sage/misc/latex_macros.py, but should not include anything from
> macros.tex.
>
> > Questions:
>
> > (a) Is the distinction conscious, or is this an omission of AMS
> > symbols on the PDF side?
>
> The distinction is irrelevant, because the file macros.tex is unused.
>
> > (b) If in need of fixing, is macros.tex the place to add?
>
> No.
>
> > (c) And if so, is amsfonts superior to amssymb, or vice versa (or
> > both?)? I always have good luck with amssymb only. I would assume we
> > want the same macros available for both HTML and PDF versions of the
> > docs?
>
> If I make a test file which just includes $\leqslant$, it bombs if I
> use the amsfonts package, but if works if I use amssymb. So that's
> what I would try.
>
> --
> John
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: AMS symbols in PDF, HTML documentation
On Jun 3, 4:45 pm, John H Palmieri wrote: > If I make a test file which just includes $\leqslant$, it bombs if I > use the amsfonts package, but if works if I use amssymb. So that's > what I would try. By "that's what I would try", I mean "that's the package I would add to latex_elements['preamble']". -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: AMS symbols in PDF, HTML documentation
On Jun 3, 1:04 pm, Rob Beezer wrote:
> Mitesh Patel discovered that the tex macro "\leqslant" (a slanted
> inequality) breaks the PDF reference manual, while it survives just
> fine in the HTML version. (Introduced at Trac #8030, which is merged,
> fixed at Trac #9102, awaiting review.) This symbol seems to be
> provided by the AMS packages amssymb and/or amsfonts. On my tex
> installation, both are provided in texmf-texlive/tex/latex/amsfonts/,
> so I think these are fairly standard packages to expect a user/
> developer to have.
>
> Limited poking around shows:
>
> (1) In doc/common/macros.tex, there is the line
As far as I know, the file macros.tex is unused. See below. (I think
it is still around because it has occasionally been useful to know
what macros used to be included in the documentation. Perhaps it has
served its purpose and should die a graceful death...)
> \usepackage{amsmath}
>
> but this file makes no mention of amssymb or amsfonts
>
> (2) In doc/common/conf.py (which looks Sphinx-specific?) there is the
> line
>
> latex_elements['preamble'] = '\usepackage{amsmath}\n
> \usepackage{amsfonts}\n'
This should be the relevant line.
You can test this: prepare the pdf (or the latex) documentation, for
example
sage -docbuild tutorial latex (or pdf)
and look at the file in SAGE_ROOT/devel/sage/doc/output/latex/en/
tutorial/. Its preamble should include the lines from
latex_elements['preamble'], along with various macros imported from
sage/misc/latex_macros.py, but should not include anything from
macros.tex.
> Questions:
>
> (a) Is the distinction conscious, or is this an omission of AMS
> symbols on the PDF side?
The distinction is irrelevant, because the file macros.tex is unused.
> (b) If in need of fixing, is macros.tex the place to add?
No.
> (c) And if so, is amsfonts superior to amssymb, or vice versa (or
> both?)? I always have good luck with amssymb only. I would assume we
> want the same macros available for both HTML and PDF versions of the
> docs?
If I make a test file which just includes $\leqslant$, it bombs if I
use the amsfonts package, but if works if I use amssymb. So that's
what I would try.
--
John
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: new paper on sage by myself and Burcin Erocal
On Thursday, June 3, 2010, Tim Daly wrote:
> I was commenting on the version of Axiom shown in your note. :-)
>
> Axiom prints a banner on startup containing 2 pieces of information.
> The second line is the release version of the system (September 2005)
> The third line is the date this version was built (December 2006)
>
> That's quite amusing given the Sage discussion about release schedules
> and user-update frequency. The latest version of Axiom is May 2010.
This is the standard version installed systemwide in Ubuntu 8.10lts,
which is what we run on our main development server.
Nobody has complained about this, so we haven't upgraded it
>
> AXIOM Computer Algebra System
>
> Version: Axiom 3.9 (September 2005)
> Timestamp: Saturday December 2, 2006 at 09:30:31
>
>
>
>
>
> William Stein wrote:
>
> On Wed, Jun 2, 2010 at 6:10 AM, Tim Daly wrote:
>
>
> You have Axiom from 2005?
> You do realize it is updated every 2 months :-)
>
> Tim
>
>
>
> Huh? I can't figure out what you're referring to above.
>
> William
>
>
>
> William Stein wrote:
>
>
> On Tue, Jun 1, 2010 at 11:31 PM, Martin Rubey
> wrote:
>
>
>
> William Stein writes:
>
>
>
>
> Hi,
>
> Burcin Erocal and I wrote a paper
>
> "The Sage Project: Unifying Free Mathematical Software to Create a
> Viable Alternative to Magma, Maple, Mathematica and Matlab"
>
> for http://www.math.kobe-u.ac.jp/icms2010/index.html
>
> Here it is:
>
> http://wstein.org/papers/icms/icms_2010.pdf
>
>
>
> A tiny correction to the list on 6, Table 2: as far as I know, sage does
> not communicate with axiom, but rather with fricas. But I admit, I am
> not 100% certain, what the default installation does. Please correct
> me, if I'm mistaken.
>
> Martin
>
>
>
> Thanks for raising this point. I remember Tim Daly complaining at
> some point that I should rename the "axiom" command in sage to
> "fricas". So this is worth looking into, which I just did. The result
> is that the Sage interface called "axiom" really is an interface to
> Axiom, as claimed.
>
>
> I think the Sage interface that is called "axiom" does in fact work
> fine with Axiom. On my computer, I don't have fricas installed, but
> I do have axiom:
>
> wst...@sage:~$ which fricas
> wst...@sage:~$ which axiom
> /usr/bin/axiom
>
> This is the read-deal axiom, from Debian I think:
>
> wst...@sage:~$ axiom
> GCL (GNU Common Lisp) 2.6.7 CLtL1 Nov 10 2006 14:25:02
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/
> AXIOM Computer Algebra System
> Version: Axiom 3.9 (September 2005)
> Timestamp: Saturday December 2, 2006 at 09:30:31
>
> -
> Issue )copyright to view copyright notices.
> Issue )summary for a summary of useful system commands.
> Issue )quit to leave AXIOM and return to shell.
>
> -
>
> Re-reading compress.daase Re-reading interp.daase
> Re-reading operation.daase
> Re-reading category.daase
> Re-reading browse.daase
> (1) -> )quit
>
>
> Now I run Sage, and verify that it doesn't know about any "fricas"
> command, only Axiom, which is the systemwide "genuine" axiom:
>
> wst...@sage:~$ sage
> --
> | Sage Version 4.4.1, Release Date: 2010-05-02 |
> | Type notebook() for the GUI, and license() for information. |
> --
> sage: !which axiom
> /usr/bin/axiom
> sage: !which fricas
>
> And now I run a command, which calls Axiom:
>
> sage: axiom('2 + 3')
> 5
>
> Consulting the source shows that the command that Sage runs when the
> axiom interface is invoked is "axiom -nox -noclef":
>
> sage: axiom.__init__??
> ...
> Source:
> def __init__(self, name='axiom', command='axiom -nox -noclef',
> script_subdirectory=None, logfile=None,
> server=None, server_tmpdir=None,
> init_code=[')lisp (si::readline-off)']):
>
>
>
> See
--
William Stein
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+unsubscr...@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 paper on sage by myself and Burcin Erocal
I was commenting on the version of Axiom shown in your note. :-)
Axiom prints a banner on startup containing 2 pieces of information.
The second line is the release version of the system (September 2005)
The third line is the date this version was built (December 2006)
That's quite amusing given the Sage discussion about release schedules
and user-update frequency. The latest version of Axiom is May 2010.
AXIOM Computer Algebra System
Version: Axiom 3.9 (September 2005)
Timestamp: Saturday December 2, 2006 at 09:30:31
William Stein wrote:
On Wed, Jun 2, 2010 at 6:10 AM, Tim Daly wrote:
You have Axiom from 2005?
You do realize it is updated every 2 months :-)
Tim
Huh? I can't figure out what you're referring to above.
William
William Stein wrote:
On Tue, Jun 1, 2010 at 11:31 PM, Martin Rubey
wrote:
William Stein writes:
Hi,
Burcin Erocal and I wrote a paper
"The Sage Project: Unifying Free Mathematical Software to Create a
Viable Alternative to Magma, Maple, Mathematica and Matlab"
for http://www.math.kobe-u.ac.jp/icms2010/index.html
Here it is:
http://wstein.org/papers/icms/icms_2010.pdf
A tiny correction to the list on 6, Table 2: as far as I know, sage does
not communicate with axiom, but rather with fricas. But I admit, I am
not 100% certain, what the default installation does. Please correct
me, if I'm mistaken.
Martin
Thanks for raising this point. I remember Tim Daly complaining at
some point that I should rename the "axiom" command in sage to
"fricas". So this is worth looking into, which I just did. The result
is that the Sage interface called "axiom" really is an interface to
Axiom, as claimed.
I think the Sage interface that is called "axiom" does in fact work
fine with Axiom. On my computer, I don't have fricas installed, but
I do have axiom:
wst...@sage:~$ which fricas
wst...@sage:~$ which axiom
/usr/bin/axiom
This is the read-deal axiom, from Debian I think:
wst...@sage:~$ axiom
GCL (GNU Common Lisp) 2.6.7 CLtL1Nov 10 2006 14:25:02
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
AXIOM Computer Algebra System
Version: Axiom 3.9 (September 2005)
Timestamp: Saturday December 2, 2006 at 09:30:31
-
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave AXIOM and return to shell.
-
Re-reading compress.daase Re-reading interp.daase
Re-reading operation.daase
Re-reading category.daase
Re-reading browse.daase
(1) -> )quit
Now I run Sage, and verify that it doesn't know about any "fricas"
command, only Axiom, which is the systemwide "genuine" axiom:
wst...@sage:~$ sage
--
| Sage Version 4.4.1, Release Date: 2010-05-02 |
| Type notebook() for the GUI, and license() for information.|
--
sage: !which axiom
/usr/bin/axiom
sage: !which fricas
And now I run a command, which calls Axiom:
sage: axiom('2 + 3')
5
Consulting the source shows that the command that Sage runs when the
axiom interface is invoked is "axiom -nox -noclef":
sage: axiom.__init__??
...
Source:
def __init__(self, name='axiom', command='axiom -nox -noclef',
script_subdirectory=None, logfile=None,
server=None, server_tmpdir=None,
init_code=[')lisp (si::readline-off)']):
See http://trac.sagemath.org/sage_trac/ticket/5111
There is a *separate* fricas interface:
sage: fricas.__init__??
Definition: fricas.__init__(self, name='fricas', command='fricas
-nox -noclef', script_subdirectory=None, logfile=None, server=None,
server_tmpdir=None, init_code=[')lisp (si::readline-off)'])
Source:
def __init__(self, name='fricas', command='fricas -nox -noclef',
The upshot is that maybe I should list both fricas and axiom in the
interfaces table?
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+unsubscr...@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+
Re: [sage-devel] Re: Sphinx target search...
Hi, > As a note, the very first thing that $SAGE_LOCAL/bin/sphinx-build does > is import sage.all. Importing it again within Sphinx afterwards just > becomes a dictionary lookup. Thanks for the tip ! I just uploaded a new patch at http://trac.sagemath.org/sage_trac/ticket/9128 and put a needs-review on it, though I'm not sure it is finished. I have no idea how to improve it but I asked for some advice on sphinx-users and got no answer for the moment. This is maybe only that I don't feel expert enough to play with Sphinx. If a Sphinx expert (Mike ?) could have a look at it... Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] [a...@math.ucdavis.edu: Re: [sage-combinat-devel] Unpickling of crystals]
On Wed, Jun 02, 2010 at 02:55:39PM -0700, William Stein wrote: > On Wed, Jun 2, 2010 at 1:18 PM, Nicolas M. Thiery > wrote: > > There is consensus that no-one cares about oldish crystal pickles, > > and it would make the inclusion of #8911 technically easier if we > > could drop them. > > > > Hence my question: what's the official procedure for updating the > > pickle jar? > > I propose the following official position: > > "Don't do it, unless there is a consensus that doing so won't > cause serious concern. Moreover, any change in pickling that replaces > a pickling system by a new one, should be *designed* to be backwards > compatible, in case future changes are proposed. See, e.g., the > matrix and vector code, where the pickling is all designed from the > start to allow for new pickling formats without breaking old ones." Sounds good to me. > Regarding your changes, have you re-architected the code so your new > pickling model is backwards compatible? Yup, that's one of the benefit we got from switching to UniqueRepresentation; and that's precisely this switch that broke backward compatibility (not that it was infeasible, but it would have taken some work). All of this essentially boils down to the fact that the crystal code was the first one we wrote in Sage, and we did not have the proper infrastructure at that time. So now, from a technical point of view, what's the procedure for updating the pickle jar? Should I use the SAGE_PICKLE_JAR feature advertised in sage_object, run the tests on sage/combinat/crystals, update /extcode/pickle_jar/pickle_jar.tar.bz2 with the new pickles, and post this on the #8911 ticket? Speaking of the pickle jar. I did not get comments on my e-mail about #9075. It suggests that quite a few objects in the pickle jar might actually be broken, even if they don't raise an error upon unpickling (that was the case for our crystals). Best, Nicolas -- Nicolas M. Thiéry "Isil" 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+unsubscr...@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: [sage-combinat-devel] Sage 4.4.3
Hi, > By the way, there is a good risk that Nicolas won't be able to > answer his e-mail before this evening. So don't expect more > feedback. Yup; just back from a day of driving around! On Thu, Jun 03, 2010 at 09:07:45AM +0200, Florent hivert wrote: > > It would make great sense to have another Sage release before June 14. > > I don't want to be the one to make it. If you really want one that > > definitely has the combinat stuff correctly merged in, perhaps you > > could be that release manager, taking the 4.4.3 release as a start? > ... Well, yes, Florent and I are quite overloaded already, but that's still a fair question to ask. There definitely is strong virtue in rotating the load of this exhausting task on as many people as possible. And I appreciate that William took on the task several times recently, when he sure has as loaded an agenda as we have. So yes, I several times considered managing one release. However, thinking twice about it, I ended up to the conclusion that I should focus on the Sage-Combinat queue, because that's where I am most useful and efficient to the Sage community. A good part of what we are doing there is really prerelease management: early integration tests and conflict resolutions, so as to get stacks of conflict-free patches ready for merging. Which should me as much load taken off the release manager. Well, actually we just failed in doing so: > Unfortunately #8881 was bumped because the dependency on #9104 was > not mentioned. Let's analyze what happened and see how we can improve our process to prevent this from occurring again. Since a couple weeks, with Florent and a couple others, we are using a script (available upon request) that makes it a breeze to launch all tests on our build host (massena) with all Sage-Combinat patches up to a given one. I just type on my own machine: sage-combinat-test 8811 and 10 minutes later I receive by e-mail a summary of the full Sage test results, with all patches applied up to trac_8811_reduced_word_of_translations-nt.patch; the full log are posted on the web. Well, it's really just a trivial shell script not worth bragging about. But it literally changed our life by finally making it possible to review patches at about the same rate as we produce them. Automatizing the "all test pass" check is *the* key to solving the current patch review bottleneck in the Sage workflow, and this little script is more or less doing the job for us. There is an issue though in our workflow: it is possible, but currently not trivial, to only apply a couple selected patches; this means that, more often than not, we run the tests not only on the chosen patch, but also on all the ones that are before in the queue (which currently means those 25 that already have a positive review!). The consequence is that we don't easily detect dependencies like the one above. Ideally, we should add a feature to the script so that we could do: sage-combinat-test 9104 8811 and have the test run with only those patches applied. In the mean time, I propose the following: when we run the tests before setting a positive review on `trac_..._blah.patch`, we should run the tests up to exactly this patch in the queue, and then systematically post on trac a comment of the form: All tests passed on massena with the following patches applied: trac_8500_transitive_groups-final.patch trac_8549_cycle_enumerator-nb.patch ... trac_..._blah.patch This should give the release manager a good hint on the order the patches should be applied in. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] AMS symbols in PDF, HTML documentation
I should be more clear. I'd try including \usepackage{amssymb} in macros.tex
and see if you can build to HTML without errors. If errors occur, then try
limiting the include to non-HTML output. It is curious that other symbols
are rendering perfectly given this lack of inclusion for amssymb... but this
may have to do with the loading of OT2?
Jason
On Thu, Jun 3, 2010 at 2:52 PM, Jason B Hill wrote:
>
> amssymb is a subset of amsfonts, and is only required when the font used
> isn't otherwise defined as a math-capable font. So, it isn't surprising that
> this is working fine when building to HTML... although I'm not as familiar
> with the latex -> html process.
>
> amsfonts/amssymb should most likely only be included when building to PDF
> is my guess. If you reference symbol paths multiple times, latex gets
> unhappy. I.e.,
>
> \usepackage{amssymb}
> \usepackage[T1]{fontenc}
> \usepackage[bitstream-charter]{mathdesign}
>
> will return an error, since then \leqslant, for instance, is defined twice.
>
>
>
>
> On Thu, Jun 3, 2010 at 2:04 PM, Rob Beezer wrote:
>
>> Mitesh Patel discovered that the tex macro "\leqslant" (a slanted
>> inequality) breaks the PDF reference manual, while it survives just
>> fine in the HTML version. (Introduced at Trac #8030, which is merged,
>> fixed at Trac #9102, awaiting review.) This symbol seems to be
>> provided by the AMS packages amssymb and/or amsfonts. On my tex
>> installation, both are provided in texmf-texlive/tex/latex/amsfonts/,
>> so I think these are fairly standard packages to expect a user/
>> developer to have.
>>
>> Limited poking around shows:
>>
>> (1) In doc/common/macros.tex, there is the line
>>
>> \usepackage{amsmath}
>>
>> but this file makes no mention of amssymb or amsfonts
>>
>>
>> (2) In doc/common/conf.py (which looks Sphinx-specific?) there is the
>> line
>>
>> latex_elements['preamble'] = '\usepackage{amsmath}\n
>> \usepackage{amsfonts}\n'
>>
>> Questions:
>>
>> (a) Is the distinction conscious, or is this an omission of AMS
>> symbols on the PDF side?
>>
>> (b) If in need of fixing, is macros.tex the place to add?
>>
>> (c) And if so, is amsfonts superior to amssymb, or vice versa (or
>> both?)? I always have good luck with amssymb only. I would assume we
>> want the same macros available for both HTML and PDF versions of the
>> docs?
>>
>> Thanks for any history, input, advice.
>>
>> Rob
>>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to
>> sage-devel+unsubscr...@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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] AMS symbols in PDF, HTML documentation
amssymb is a subset of amsfonts, and is only required when the font used
isn't otherwise defined as a math-capable font. So, it isn't surprising that
this is working fine when building to HTML... although I'm not as familiar
with the latex -> html process.
amsfonts/amssymb should most likely only be included when building to PDF is
my guess. If you reference symbol paths multiple times, latex gets unhappy.
I.e.,
\usepackage{amssymb}
\usepackage[T1]{fontenc}
\usepackage[bitstream-charter]{mathdesign}
will return an error, since then \leqslant, for instance, is defined twice.
On Thu, Jun 3, 2010 at 2:04 PM, Rob Beezer wrote:
> Mitesh Patel discovered that the tex macro "\leqslant" (a slanted
> inequality) breaks the PDF reference manual, while it survives just
> fine in the HTML version. (Introduced at Trac #8030, which is merged,
> fixed at Trac #9102, awaiting review.) This symbol seems to be
> provided by the AMS packages amssymb and/or amsfonts. On my tex
> installation, both are provided in texmf-texlive/tex/latex/amsfonts/,
> so I think these are fairly standard packages to expect a user/
> developer to have.
>
> Limited poking around shows:
>
> (1) In doc/common/macros.tex, there is the line
>
> \usepackage{amsmath}
>
> but this file makes no mention of amssymb or amsfonts
>
>
> (2) In doc/common/conf.py (which looks Sphinx-specific?) there is the
> line
>
> latex_elements['preamble'] = '\usepackage{amsmath}\n
> \usepackage{amsfonts}\n'
>
> Questions:
>
> (a) Is the distinction conscious, or is this an omission of AMS
> symbols on the PDF side?
>
> (b) If in need of fixing, is macros.tex the place to add?
>
> (c) And if so, is amsfonts superior to amssymb, or vice versa (or
> both?)? I always have good luck with amssymb only. I would assume we
> want the same macros available for both HTML and PDF versions of the
> docs?
>
> Thanks for any history, input, advice.
>
> Rob
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@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+unsubscr...@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: Fwd: [sage-combinat-devel] permutation group perspectives
Sorry, I was in the mountains for a bit and missed some conversation. Mike H: Do you want any assistance in your current task? Robert B: In response to your question after my last e-mail, assuming I understand it correctly, I am under the assumption that only points declared explicitly in the generators are considered. (And perhaps fixed points should be declared with 1-cycle generators?) I realize this may not be backwards compatible, and so I'm wondering what the best course of action here is. Someone asked me a great question a couple of days ago that made me realize that something should be emphasized here, even if it is a bit basic. A permutation group as defined in Sage (and GAP) is three objects: a set, an action/representation, and an underlying group. Unfortunately, the best way to define a permutation group is usually to instead define the corresponding action/representation. Of course, this gives a group and it also brings along more structure (transitivity, primitivity, etc.). But, technically, it is not "a group" and is more appropriately "an action." GAP blurs this difference, but always maintains the action as the primary structure (as Rob's recent example illustrates), even if its primary purpose is to examine the underlying group and even if it calls the structure "a group". Traditionally, the set on which the action acts is a formal object (formal in the mathematical sense, it has no underlying structure). This is true in GAP, although the domain of an action is limited to natural numbers (although there is no underlying structure or order that is assumed). In Sage, this isn't true, and the underlying set is assumed to be well-ordered (the natural numbers as a set plus the structure of order). At least, this is true in Sage currently before an arbitrary action set is implemented. Rob: In response to your question about a coset class.. We have discussed briefly the idea of a PermutationSubgroup class which would inherit certain information from a parent group/action, and I think the idea of a method for a complete list of coset reps, or transversal reps, etc., fits well into such a class. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] AMS symbols in PDF, HTML documentation
Mitesh Patel discovered that the tex macro "\leqslant" (a slanted
inequality) breaks the PDF reference manual, while it survives just
fine in the HTML version. (Introduced at Trac #8030, which is merged,
fixed at Trac #9102, awaiting review.) This symbol seems to be
provided by the AMS packages amssymb and/or amsfonts. On my tex
installation, both are provided in texmf-texlive/tex/latex/amsfonts/,
so I think these are fairly standard packages to expect a user/
developer to have.
Limited poking around shows:
(1) In doc/common/macros.tex, there is the line
\usepackage{amsmath}
but this file makes no mention of amssymb or amsfonts
(2) In doc/common/conf.py (which looks Sphinx-specific?) there is the
line
latex_elements['preamble'] = '\usepackage{amsmath}\n
\usepackage{amsfonts}\n'
Questions:
(a) Is the distinction conscious, or is this an omission of AMS
symbols on the PDF side?
(b) If in need of fixing, is macros.tex the place to add?
(c) And if so, is amsfonts superior to amssymb, or vice versa (or
both?)? I always have good luck with amssymb only. I would assume we
want the same macros available for both HTML and PDF versions of the
docs?
Thanks for any history, input, advice.
Rob
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Tab completion finds methods that don't seem to exist
Hi all, I'm getting the following behavior on my local sage-4.4.2 and on sagenb.org: sage: R. = QQ[] sage: R.su R.sum R.summation R.summation_from_element_class_add sage: R.sum? Object `R.sum` not found. sage: R.sum() --- AttributeErrorTraceback (most recent call last) /usr/local/src/sage/sage-4.4.2/devel/sage-trac/sage/rings/polynomial/ in () /usr/local/src/sage/sage-4.4.2/local/lib/python2.6/site-packages/sage/structure/parent.so in sage.structure.parent.Parent.__getattr__ (sage/structure/parent.c:5264)() /usr/local/src/sage/sage-4.4.2/local/lib/python2.6/site-packages/sage/structure/parent.so in sage.structure.parent.raise_attribute_error (sage/structure/parent.c:2622)() AttributeError: 'PolynomialRing_field' object has no attribute 'sum' The same thing happens with `summation` and `summation_from_element_class_add`, and various other methods (for instance `R.addition_table`). It also happens for both single variable and multi-variable polynomial rings. Is this behavior known, or should I open a ticket? Thanks, Jason Bandlow -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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 paper on sage by myself and Burcin Erocal
On Thu, Jun 3, 2010 at 12:05 PM, Mike Hansen wrote: > On Thu, Jun 3, 2010 at 12:01 PM, William Stein wrote: >> http://mupad-combinat.sourceforge.net/#sage_days_7 >> >> at the sage days 7 site just times out > > I just checked and was able to access the site. Thanks - I got it now. I guess sourceforge was just being flakie. William > > --Mike > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein 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+unsubscr...@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 paper on sage by myself and Burcin Erocal
On Wed, Jun 2, 2010 at 2:03 AM, Florent Hivert wrote: > Hi William and Burcin, > > This is a very nice presentation of Sage, drawing a very good overall picture > of what is Sage ! I'd like to thank you for the afterword... > > Just a little remark citation [Des06] only present a very specific part of > what was MuPAD-Combinat (ie: Symmetric Functions). You probably want to add > the older but more representative: > > Florent Hivert and Nicolas M. Thiéry, > "MuPAD-Combinat, an Open-Source Package for Research in > Algebraic Combinatorics", > Séminaire Lotharingien de Combinatoire *51*, (2004), > article B51z, 70 pp (electronic). > > The "Séminaire Lotharingien de Combinatoire" is a *free* European mathematical > review, as a consequence the paper is freely accessible at > http://www.emis.de/journals/SLC/wpapers/s51thiery.html > > Sorry for this shameless advertisement. And thanks a lot, > It's also interesting how the paper says on page 54 that MuPAD "promised to remain relatively open..." and "They also have promised to release the code source of the library under a well known open-source license, some day." I guess selling out to Mathworks pretty dramatically broke that promise... 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+unsubscr...@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 paper on sage by myself and Burcin Erocal
On Thu, Jun 3, 2010 at 12:01 PM, William Stein wrote: > http://mupad-combinat.sourceforge.net/#sage_days_7 > > at the sage days 7 site just times out I just checked and was able to access the site. --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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 paper on sage by myself and Burcin Erocal
On Wed, Jun 2, 2010 at 2:03 AM, Florent Hivert wrote: > Hi William and Burcin, > > This is a very nice presentation of Sage, drawing a very good overall picture > of what is Sage ! I'd like to thank you for the afterword... > > Just a little remark citation [Des06] only present a very specific part of > what was MuPAD-Combinat (ie: Symmetric Functions). You probably want to add > the older but more representative: > > Florent Hivert and Nicolas M. Thiéry, > "MuPAD-Combinat, an Open-Source Package for Research in > Algebraic Combinatorics", > Séminaire Lotharingien de Combinatoire *51*, (2004), > article B51z, 70 pp (electronic). > I just looked at that, and wanted to see the updated version of the table on page 53, which Nicolas Thiéry presented at Sage Days 7. Unfortunately, the link http://mupad-combinat.sourceforge.net/#sage_days_7 at the sage days 7 site just times out (http://wiki.sagemath.org/days7/schedule). William > The "Séminaire Lotharingien de Combinatoire" is a *free* European mathematical > review, as a consequence the paper is freely accessible at > http://www.emis.de/journals/SLC/wpapers/s51thiery.html Big +1. > > Sorry for this shameless advertisement. And thanks a lot, > > Florent > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein 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+unsubscr...@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: Sphinx target search...
On Thu, Jun 3, 2010 at 11:04 AM, leif wrote: >> > Does not really address my question. Think of a single file, what's >> > the price/latency of importing sage.all to resolve not fully qualified >> > targets (perhaps just a single one)? >> >> If you look at my new patch on trac I don't import sage.all though I search >> into it. > > Ok, your patch at #9128 obsoleted my question... > http://trac.sagemath.org/sage_trac/ticket/9128 > (I was just fearing importing sage.all takes a lot of time, at least > on older systems.) As a note, the very first thing that $SAGE_LOCAL/bin/sphinx-build does is import sage.all. Importing it again within Sphinx afterwards just becomes a dictionary lookup. --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sphinx target search...
On 3 Jun., 18:58, Florent Hivert wrote: > > On 3 Jun., 15:20, Florent Hivert wrote: > > > On Wed, Jun 02, 2010 at 05:34:06PM -0700, leif wrote: > > > > Any measures of the slow down to Sphinx? > > > Does not really address my question. Think of a single file, what's > > the price/latency of importing sage.all to resolve not fully qualified > > targets (perhaps just a single one)? > > If you look at my new patch on trac I don't import sage.all though I search > into it. ;-) Ok, your patch at #9128 obsoleted my question... http://trac.sagemath.org/sage_trac/ticket/9128 (I was just fearing importing sage.all takes a lot of time, at least on older systems.) -Leif > Here are the result for a single file: > > Without: > sage -docbuild reference html 11,63s user 0,94s system 98% cpu 12,799 total > sage -docbuild reference html 11,70s user 0,90s system 98% cpu 12,776 total > sage -docbuild reference html 11,82s user 0,84s system 98% cpu 12,834 total > > With: > sage -docbuild reference html 11,67s user 0,96s system 98% cpu 12,815 total > sage -docbuild reference html 11,59s user 0,96s system 98% cpu 12,679 total > sage -docbuild reference html 11,78s user 0,87s system 98% cpu 12,793 total > > I see nothing very significative... Note that the things worked since I got > the message: > > Searching sage.combinat.partition.Partitions from sage.combinat.integer_list > WARNING: undefined symbol :mod:`sage.combinat.partition.Partitions` in module > sage.combinat.integer_list > > Cheers, > > Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: new paper on sage by myself and Burcin Erocal
Hi I've made all the changes suggested in this thread and posted a new version at http://wstein.org/papers/icms/ On Wed, Jun 2, 2010 at 8:49 AM, Rob Beezer wrote: > On Jun 2, 7:43 am, Martin Albrecht > wrote: >> """ >> Awesome singular, pynac, maxima (in progress), gap (in progress) >> """ > > I think "Awesome" might be a new brand name for super-duper > interfaces, as in Awesome (tm)*. > > Rob > > * All trademarks are copyright by their respective holders. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein 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+unsubscr...@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 paper on sage by myself and Burcin Erocal
On Wed, Jun 2, 2010 at 6:10 AM, Tim Daly wrote:
> You have Axiom from 2005?
> You do realize it is updated every 2 months :-)
>
> Tim
Huh? I can't figure out what you're referring to above.
William
>
>
> William Stein wrote:
>>
>> On Tue, Jun 1, 2010 at 11:31 PM, Martin Rubey
>> wrote:
>>
>>>
>>> William Stein writes:
>>>
>>>
Hi,
Burcin Erocal and I wrote a paper
"The Sage Project: Unifying Free Mathematical Software to Create a
Viable Alternative to Magma, Maple, Mathematica and Matlab"
for http://www.math.kobe-u.ac.jp/icms2010/index.html
Here it is:
http://wstein.org/papers/icms/icms_2010.pdf
>>>
>>> A tiny correction to the list on 6, Table 2: as far as I know, sage does
>>> not communicate with axiom, but rather with fricas. But I admit, I am
>>> not 100% certain, what the default installation does. Please correct
>>> me, if I'm mistaken.
>>>
>>> Martin
>>>
>>
>> Thanks for raising this point. I remember Tim Daly complaining at
>> some point that I should rename the "axiom" command in sage to
>> "fricas". So this is worth looking into, which I just did. The result
>> is that the Sage interface called "axiom" really is an interface to
>> Axiom, as claimed.
>>
>>
>> I think the Sage interface that is called "axiom" does in fact work
>> fine with Axiom. On my computer, I don't have fricas installed, but
>> I do have axiom:
>>
>> wst...@sage:~$ which fricas
>> wst...@sage:~$ which axiom
>> /usr/bin/axiom
>>
>> This is the read-deal axiom, from Debian I think:
>>
>> wst...@sage:~$ axiom
>> GCL (GNU Common Lisp) 2.6.7 CLtL1 Nov 10 2006 14:25:02
>> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
>> Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
>> Modifications of this banner must retain notice of a compatible license
>> Dedicated to the memory of W. Schelter
>>
>> Use (help) to get some basic information on how to use GCL.
>> Temporary directory for compiler files set to /tmp/
>> AXIOM Computer Algebra System
>> Version: Axiom 3.9 (September 2005)
>> Timestamp: Saturday December 2, 2006 at 09:30:31
>>
>> -
>> Issue )copyright to view copyright notices.
>> Issue )summary for a summary of useful system commands.
>> Issue )quit to leave AXIOM and return to shell.
>>
>> -
>>
>> Re-reading compress.daase Re-reading interp.daase
>> Re-reading operation.daase
>> Re-reading category.daase
>> Re-reading browse.daase
>> (1) -> )quit
>>
>>
>> Now I run Sage, and verify that it doesn't know about any "fricas"
>> command, only Axiom, which is the systemwide "genuine" axiom:
>>
>> wst...@sage:~$ sage
>> --
>> | Sage Version 4.4.1, Release Date: 2010-05-02 |
>> | Type notebook() for the GUI, and license() for information. |
>> --
>> sage: !which axiom
>> /usr/bin/axiom
>> sage: !which fricas
>>
>> And now I run a command, which calls Axiom:
>>
>> sage: axiom('2 + 3')
>> 5
>>
>> Consulting the source shows that the command that Sage runs when the
>> axiom interface is invoked is "axiom -nox -noclef":
>>
>> sage: axiom.__init__??
>> ...
>> Source:
>> def __init__(self, name='axiom', command='axiom -nox -noclef',
>> script_subdirectory=None, logfile=None,
>> server=None, server_tmpdir=None,
>> init_code=[')lisp (si::readline-off)']):
>>
>>
>>
>> See http://trac.sagemath.org/sage_trac/ticket/5111
>>
>> There is a *separate* fricas interface:
>>
>> sage: fricas.__init__??
>> Definition: fricas.__init__(self, name='fricas', command='fricas
>> -nox -noclef', script_subdirectory=None, logfile=None, server=None,
>> server_tmpdir=None, init_code=[')lisp (si::readline-off)'])
>> Source:
>> def __init__(self, name='fricas', command='fricas -nox -noclef',
>>
>>
>>
>> The upshot is that maybe I should list both fricas and axiom in the
>> interfaces table?
>>
>> 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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
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+unsubscr...@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: Sphinx target search...
Hi Andrey, > > - Should we search the link in all.py or in the local module ? In the latter > > solution we can only link what is imported in the current module, keeping > > the > > doc coherent with the module. > I think it would be better to search all.py and then imports in the > local module. One of them is probably not sufficient, since there may > be imports that are not exposed by all.py. That is indeed the case from my experiments. > On the other hand, in the module there may be imports through all.py and as > I understand for the final documentation we need to have the exact path to > the module where things are defined. That is not a problem: even if things are imported through all.py, once I found a sage object obj, I can finds its actual module using obj.__module__. > Looking at the module alone may not be enough > because potentially docstrings may include something like "See > also ... if you need ..." to reference things which are relevant, but > are not used in the module itself. > > - I can also take the chance to raise warning for really dangling links if > > needed. Maybe this should be configurable by an environment variable, say > > SAGE_DOC_WARN_DANGLING_LINKS. > > > > That would be wonderful! I was actually surprised that it is not the > case by default, since I recently made some typos in the documentation > and caught them after going over the result, but with warnings it > would be much easier and more reliable. I can tell you that if you do that by default, there will be a really huge bunch of warning... > I think these warnings are of higher priority than "document is not included > into any toc-tree" or something like that which I had to read again and > again if I was popping out some of the queue patches to work on the middle > ones. Yes ! I don't know how but I would be very happy to have a way to get rid of those without having to nuke doc/output and rebuild the whole doc. Note That I don't know either how to have warning with a higher priority. The good news it that the "document is not included into any toc-tree" occur during the "checking consistency..." phase whereas "dangling links" will occur during the "writing output..." phase. So they won't mix up. Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: Sphinx target search...
Hi leif, > On 3 Jun., 15:20, Florent Hivert wrote: > > On Wed, Jun 02, 2010 at 05:34:06PM -0700, leif wrote: > > > Any measures of the slow down to Sphinx? > > > > I don't think it would be very measurable: Here is a comparison after > > issuing > > # touch *.py && sage -b && time sage -docbuild reference html > > > > without: > > sage -docbuild reference html 46,81s user 1,06s system 98% cpu 48,604 total > > sage -docbuild reference html 46,61s user 1,10s system 98% cpu 48,279 total > > > > with: > > sage -docbuild reference html 46,19s user 1,25s system 96% cpu 49,228 total > > sage -docbuild reference html 46,37s user 1,11s system 98% cpu 48,182 total > > Does not really address my question. Think of a single file, what's > the price/latency of importing sage.all to resolve not fully qualified > targets (perhaps just a single one)? If you look at my new patch on trac I don't import sage.all though I search into it. Here are the result for a single file: Without: sage -docbuild reference html 11,63s user 0,94s system 98% cpu 12,799 total sage -docbuild reference html 11,70s user 0,90s system 98% cpu 12,776 total sage -docbuild reference html 11,82s user 0,84s system 98% cpu 12,834 total With: sage -docbuild reference html 11,67s user 0,96s system 98% cpu 12,815 total sage -docbuild reference html 11,59s user 0,96s system 98% cpu 12,679 total sage -docbuild reference html 11,78s user 0,87s system 98% cpu 12,793 total I see nothing very significative... Note that the things worked since I got the message: Searching sage.combinat.partition.Partitions from sage.combinat.integer_list WARNING: undefined symbol :mod:`sage.combinat.partition.Partitions` in module sage.combinat.integer_list Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sphinx target search...
On 3 Jun., 15:20, Florent Hivert wrote: > On Wed, Jun 02, 2010 at 05:34:06PM -0700, leif wrote: > > Any measures of the slow down to Sphinx? > > I don't think it would be very measurable: Here is a comparison after issuing > # touch *.py && sage -b && time sage -docbuild reference html > > without: > sage -docbuild reference html 46,81s user 1,06s system 98% cpu 48,604 total > sage -docbuild reference html 46,61s user 1,10s system 98% cpu 48,279 total > > with: > sage -docbuild reference html 46,19s user 1,25s system 96% cpu 49,228 total > sage -docbuild reference html 46,37s user 1,11s system 98% cpu 48,182 total Does not really address my question. Think of a single file, what's the price/latency of importing sage.all to resolve not fully qualified targets (perhaps just a single one)? -Leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: sets/set.py failing - Primes() < Set(QQ) Expected True, Got False
> On Thu, Jun 3, 2010 at 7:29 AM, Dr. David Kirkby > wrote: > > On 06/ 3/10 02:18 PM, cschwan wrote: > >> > >> There are actually two: > >> > >> http://trac.sagemath.org/sage_trac/ticket/9121 > >> http://trac.sagemath.org/sage_trac/ticket/9004 > >> > > > > > > Thank you. In that case I will not create a new ticket for it. > > There's now a patch at #9121 for review. It's merged into alpha3 > too, so will need to be reviewed > so I can make the release. All the patch does is fix the obvious > mistake in the code, and make a test > random, and explain in the docstring twice that this set comparison is > pretty much random and meaningless > anyways. I'm reviewing it if nobody beats me. Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: sets/set.py failing - Primes() < Set(QQ) Expected True, Got False
On Thu, Jun 3, 2010 at 7:29 AM, Dr. David Kirkby wrote: > On 06/ 3/10 02:18 PM, cschwan wrote: >> >> There are actually two: >> >> http://trac.sagemath.org/sage_trac/ticket/9121 >> http://trac.sagemath.org/sage_trac/ticket/9004 >> > > > Thank you. In that case I will not create a new ticket for it. There's now a patch at #9121 for review. It's merged into alpha3 too, so will need to be reviewed so I can make the release. All the patch does is fix the obvious mistake in the code, and make a test random, and explain in the docstring twice that this set comparison is pretty much random and meaningless anyways. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sphinx target search...
On Jun 3, 6:02 am, Florent Hivert wrote: > - Should we search the link in all.py or in the local module ? In the latter > solution we can only link what is imported in the current module, keeping the > doc coherent with the module. Hi Florent, I think it would be better to search all.py and then imports in the local module. One of them is probably not sufficient, since there may be imports that are not exposed by all.py. On the other hand, in the module there may be imports through all.py and as I understand for the final documentation we need to have the exact path to the module where things are defined. Looking at the module alone may not be enough because potentially docstrings may include something like "See also ... if you need ..." to reference things which are relevant, but are not used in the module itself. > - I can also take the chance to raise warning for really dangling links if > needed. Maybe this should be configurable by an environment variable, say > SAGE_DOC_WARN_DANGLING_LINKS. > That would be wonderful! I was actually surprised that it is not the case by default, since I recently made some typos in the documentation and caught them after going over the result, but with warnings it would be much easier and more reliable. I think these warnings are of higher priority than "document is not included into any toc-tree" or something like that which I had to read again and again if I was popping out some of the queue patches to work on the middle ones. Thank you for working on this! Andrey -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: [sage-combinat-devel] Sage 4.4.3
On Thu, Jun 3, 2010 at 12:07 AM, Florent Hivert wrote: > Hi William, > >> > One possibility would be to test/stabilize the current 4.4.3.alpha* >> > (i.e., fix the fallout from the cygwin >> > related tickets), include those 25 patches (all to the sage library), >> > and release 4.4.3 on Saturday. >> > If you like that, then make a clean sage-4.4.2, apply all 25 patches, >> > test it, and I can just pull those >> > changes in, and that will be 4.4.3. >> >> Hi, >> >> I didn't get any feedback on this proposal, and now I've decided to >> just do a feature freeze on 4.4.3, since I applied all the >> critical/blocker fixes listed on trac, fixed the bugs mentioned before >> (with sets and pynac), and just want to release something after going >> through the build checklist. > > Hum ! Isn't it a little short to expect feedback from France (Your e-mail > arrived here at 00:02:10 this morning and it's now 08:31:50)... Unfortunately > you bumped away #8881 because I forgot to mention that it depends on #9104. > >> It would make great sense to have another Sage release before June 14. >> I don't want to be the one to make it. If you really want one that >> definitely has the combinat stuff correctly merged in, perhaps you >> could be that release manager, taking the 4.4.3 release as a start? > > I'm sorry to say that but this isn't very realistic and helpful either to > suggest that Nicolas or I could be a release manager while we are struggling > reducing the queue, organizing a sage meeting in two weeks, answering request > for documentation and help on categories on sage-algebra and sage-combinat and > at the same time, closing the academic year in our respective department (Exam > to prepare and grade -- no T.A. for that here -- student which are making > summer experience in private companies to visit, evaluations to > prepare, etc)... I also forgot to add giving two talks (one next Tuesday, one > next Friday) in some research seminar about sage and its use in our research. > > Also, since we are at it, I've no idea how big is the work of a sage release > manager, but I can tell you that keeping the combinat queue in line against > several sage release, testing the patch on it and rebasing it at each release > is a work I feel close (though certainly much lighter) to be the one of a > release manager. Nicolas and I keep doing it without any allowed break. > > I'm sorry for the negative tone of this e-mail but when I said we are > struggling I meant it. By the way, there is a good risk that Nicolas won't be > able to answer his e-mail before this evening. So don't expect more feedback. > I'm sorry, but sage-4.4.3 is now in feature freeze, since (1) it is already going to be difficult to release as is, (2) nobody is helping me, (3) I don't have much time to work on sage releases right now. Here's how it will go down: a. I will do whatever it takes to release sage-4.4.3. b. I post to sage-release asking for somebody to be release manager for sage-4.4.4. -- 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+unsubscr...@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: sets/set.py failing - Primes() < Set(QQ) Expected True, Got False
On 06/ 3/10 02:18 PM, cschwan wrote: There are actually two: http://trac.sagemath.org/sage_trac/ticket/9121 http://trac.sagemath.org/sage_trac/ticket/9004 Thank you. In that case I will not create a new ticket for it. 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+unsubscr...@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: Sphinx target search...
On Wed, Jun 02, 2010 at 05:34:06PM -0700, leif wrote: > On 3 Jun., 00:06, Florent Hivert wrote: > > It seems that this is more or less easily feasible. I've a prototype patch > > to > > sphinx which only works for objects (eg: Parent). It won't work on thing > > like > > "Parent.rename". I'd like to know if it is a desired feature before > > polishing > > it further (and asking on sphinx-user for the good way to do this)... Also > > my > > solution involve hacking directly into sphinx. Any suggestion for a better > > way > > is welcome. > > > > So if anyone has a comment. Please answer. > > Any measures of the slow down to Sphinx? I don't think it would be very measurable: Here is a comparison after issuing # touch *.py && sage -b && time sage -docbuild reference html without: sage -docbuild reference html 46,81s user 1,06s system 98% cpu 48,604 total sage -docbuild reference html 46,61s user 1,10s system 98% cpu 48,279 total with: sage -docbuild reference html 46,19s user 1,25s system 96% cpu 49,228 total sage -docbuild reference html 46,37s user 1,11s system 98% cpu 48,182 total > Could the use of macros be an alternative? Can you elaborate a little more ? Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sets/set.py failing - Primes() < Set(QQ) Expected True, Got False
There are actually two: http://trac.sagemath.org/sage_trac/ticket/9121 http://trac.sagemath.org/sage_trac/ticket/9004 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: Sphinx target search...
Hi Andrey, On Wed, Jun 02, 2010 at 05:05:51PM -0700, Andrey Novoseltsev wrote: > While I have no ideas/suggestions on how to implement it, I think that > it is highly desirable to have such a functionality. In addition to > simplifying life of those who write doctests with links, it will help > to make documentation more stable - if some classes/functions were > moved around modules but were still exported through all.py, all > references would remain accurate with automatic search rather than > hardcoded direct links. This is now #9128 where I just uploaded a much better prototype. It makes use of the missing-reference API so there is no need to change sphinx itself. On the contrary I only patch the file "conf.py". I've however a few design question: - Should we search the link in all.py or in the local module ? In the latter solution we can only link what is imported in the current module, keeping the doc coherent with the module. - I can also take the chance to raise warning for really dangling links if needed. Maybe this should be configurable by an environment variable, say SAGE_DOC_WARN_DANGLING_LINKS. Any ideas or suggestions ? Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] sets/set.py failing - Primes() < Set(QQ) Expected True, Got False
With sage-4.4.3.alpha1 on Solaris 10 SPARC. sage -t -long "devel/sage/sage/sets/set.py" ** File "/export/home/drkirkby/sage-4.4.3.alpha1/devel/sage/sage/sets/set.py", line 316: sage: Primes() < Set(QQ) Expected: True Got: False ** 1 items had failures: 1 of 7 in __main__.example_10 ***Test Failed*** 1 failures. For whitespace errors, see the file /export/home/drkirkby/.sage//tmp/.doctest_set.py [40.3 s] -- The following tests failed: sage -t -long "devel/sage/sage/sets/set.py" Total time for all tests: 40.3 seconds Is this one known about? Should I create a ticket for it? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@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: [sage-combinat-devel] Sage 4.4.3
Hi William, > > One possibility would be to test/stabilize the current 4.4.3.alpha* > > (i.e., fix the fallout from the cygwin > > related tickets), include those 25 patches (all to the sage library), > > and release 4.4.3 on Saturday. > > If you like that, then make a clean sage-4.4.2, apply all 25 patches, > > test it, and I can just pull those > > changes in, and that will be 4.4.3. > > Hi, > > I didn't get any feedback on this proposal, and now I've decided to > just do a feature freeze on 4.4.3, since I applied all the > critical/blocker fixes listed on trac, fixed the bugs mentioned before > (with sets and pynac), and just want to release something after going > through the build checklist. Hum ! Isn't it a little short to expect feedback from France (Your e-mail arrived here at 00:02:10 this morning and it's now 08:31:50)... Unfortunately you bumped away #8881 because I forgot to mention that it depends on #9104. > It would make great sense to have another Sage release before June 14. > I don't want to be the one to make it. If you really want one that > definitely has the combinat stuff correctly merged in, perhaps you > could be that release manager, taking the 4.4.3 release as a start? I'm sorry to say that but this isn't very realistic and helpful either to suggest that Nicolas or I could be a release manager while we are struggling reducing the queue, organizing a sage meeting in two weeks, answering request for documentation and help on categories on sage-algebra and sage-combinat and at the same time, closing the academic year in our respective department (Exam to prepare and grade -- no T.A. for that here -- student which are making summer experience in private companies to visit, evaluations to prepare, etc)... I also forgot to add giving two talks (one next Tuesday, one next Friday) in some research seminar about sage and its use in our research. Also, since we are at it, I've no idea how big is the work of a sage release manager, but I can tell you that keeping the combinat queue in line against several sage release, testing the patch on it and rebasing it at each release is a work I feel close (though certainly much lighter) to be the one of a release manager. Nicolas and I keep doing it without any allowed break. I'm sorry for the negative tone of this e-mail but when I said we are struggling I meant it. By the way, there is a good risk that Nicolas won't be able to answer his e-mail before this evening. So don't expect more feedback. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
