date:20100319

Hi folks,

Sage 4.3.4 was released on March 19, 2010. It is available at

   http://www.sagemath.org/download.html

* About Sage (http://www.sagemath.org)

Sage is developed by volunteers and combines over 90 open source packages.
It is available for download from www.sagemath.org and its mirrors in
source or binary form. If you have any questions and/or problems,
please report them to the Google groups sage-devel or sage-support.
You can also drop by in #sage-devel on freenode.

Source tarball:

http://sage.math.washington.edu/home/release/sage-4.3.4/sage-4.3.4.tar

Binary for sage.math:

http://sage.math.washington.edu/home/release/sage-4.3.4/sage-4.3.4-sage.math.washington.edu-x86_64-Linux.tar.gz

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.3.4/sage-4.3.4/

Binary for t2.math will be announced in a day or two. I have started a
build of Sage 4.3.4 on t2.math and it would take over 24 hours for the
build to complete.

The following 55 people contributed to this release. Of those, 4 made
their first contribution to Sage:

 * Adam Webb
 * Alex Ghitza
 * Alexandre Blondin Massé
 * Andrey Novoseltsev
 * Anne Schilling
 * Bill Cauchois
 * Burcin Erocal
 * Chris Wuthrich
 * Craig Citro
 * Dan Drake
 * Daniel Bump
 * David Joyner
 * David Kirkby
 * David Roe
 * Florent Hivert
 * Francis Clarke
 * Franco Saliola
 * Francois Maltey [first contribution]
 * Fredrik Johansson
 * Gonzalo Tornaria
 * Harald Schilly
 * Ivan Andrus
 * Jaap Spies
 * Jason Bandlow
 * Jason Grout
 * Jennifer Balakrishnan
 * John Cremona
 * John Palmieri
 * Julien Leroy [first contribution]
 * Karl-Dieter Crisman
 * Kiran Kedlaya
 * Marc Mezzarobba
 * Marshall Hampton
 * Martin Raum
 * Mike Hansen
 * Minh Van Nguyen
 * Mitesh Patel
 * Nathann Cohen
 * Nicolas Borie
 * Nicolas M. Thiéry
 * Oscar Gerardo Lazo Arjona [first contribution]
 * Paul Zimmermann
 * Rob Beezer
 * Robert Bradshaw
 * Robert Mařík
 * Robert Miller
 * Ross Kyprianou
 * Ryan Hinton
 * Samuele Giraudo [first contribution]
 * Sebastian Pancratz
 * Sébastien Labbé
 * Tim Dumol
 * Willem Jan Palenstijn
 * William Stein
 * Yann Laigle-Chapuy

* Release managers

  * Mike Hansen
  * Minh Van Nguyen

* Major features, new spkg's, and bug fixes

 * Merged 16 tickets enhancing the combinatorics module. A big thank
you to the Sage-Combinat team for their hard work before and during
Sage Days 20 to get those tickets merged.
 * Sage now builds on SPARC Solaris 10, in particular on the machine
t2.math.washington.edu. A big thank you to David Kirkby for his
consistent hard work to get Sage to build on that machine. Please also
thank Jaap Spies and John Palmieri for their work on getting Sage to
build on t2.math.
 * New spkg: iconv-1.13.1
 * Removed spkg: pyprocessing-0.52.p0
 * Upgraded spkg's: ecl-10.2.1, mpfr-2.4.2, mpmath-0.14,
sagenb-0.7.5.3, sqlalchemy-0.5.8, sqlite-3.6.22, twisted-9.0.p2
 * Updated spkg's: atlas-3.8.3.p12, cddlib-094f.p5,
eclib-20080310.p10, flint-1.5.0.p4, python-2.6.4.p7, r-2.10.1.p0,
sagetex-2.2.3.p0, scipy-0.7.p4, zn_poly-0.9.p3

* Bug statistics

We closed 120 tickets. For details see

   http://trac.sagemath.org/sage_trac/milestone/sage-4.3.4

or check out the closed ticket section at the end of the announcement.

* Upcoming release

The upcoming major release is Sage 5.0, scheduled to be released in
early June 2010. The goals for Sage 5.0 include:
 * Resolve the high-impact tickets at
http://trac.sagemath.org/sage_trac/wiki/stab1
 * Raise the doctest coverage score to 90% by removing the notebook
from the score and writing about 1500 docstrings
 * Official 32-bit Solaris 10 support on SPARC (automatic build, all tests pass)
 * Official Cygwin support (automatic build, all tests pass)

* Doctesting coverage

To my dismay, this release of Sage actually has a decrease in doctest
coverage. For Sage 4.3.3, we had an overall weighted doctest coverage
score of 81.6%, with 24,808 functions. In Sage 4.3.4, we decreased the
doctest coverage by 0.1% and added 314 new functions. Thus for Sage 4.3.4
we now have

 * Overall weighted coverage score:  81.5%
 * Total number of functions:  25,122

* Known issues

 * Kiran Kedlaya reported that Sage can fail to compile on 64-bit
Fedora 10. This build problem occurs after we added the new iconv
spkg.

Closed tickets:

#3211: make echelon_form work over fraction fields (and hermite_form =
old echelon_form)
#4574: add notebook_object.py docs to the reference manual, and
possibly a short survey about that to notebook help (top letter)
#6932: jordan_form with transformation=true fails on a 1x1 matrix
#7932: _Complex_I undeclared - a new bug totally stops a Solaris 10 build.
#8352: Jaap Spies: twisted-8.2.0.p1 fails to build in Open Solaris x64
as 64 bit even if SAGE64=yes [Reviewed by David Kirkby]
#8463: Test failure of sage/homology/delta_complex.py

Merged in sagenb:

#8141: Mitesh Patel: Update font stacks, sans-serif and monospace, for
SageNB pages [Reviewed by Marshall Hampton; merged in sagenb

[sage-devel] Re: adds riemann mapping and complex interpolation

2010-03-19 Thread Ethan Van Andel

I believe that the TestSuite problems are largely unconnected to the
mathematics. I should be able to handle any mathematics related
problems. What I don't understand is how to manage the dumping and
restoring of the custom class objects.

Ethan

On Mar 19, 10:44 pm, Minh Nguyen  wrote:
> Hi folks,
>
> Ticket #6648 [1] is an enhancement to add Riemann mapping
> functionality to Sage. I did some refereeing, but then found myself at
> a lost because I don't understand the mathematics that the ticket
> implements and I'm clueless on how to write a TestSuite required by
> the ticket. I would appreciate if anyone would step up to help referee
> this ticket.
>
> [1]http://trac.sagemath.org/sage_trac/ticket/6648
>
> --
> 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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Exterior algebras.

2010-03-19 Thread bump

On Mar 19, 10:46 am, mmarco wrote:
> I would need to deal with exterior algebras, and as far as i have
> seen, they are not defined in sage. I could try working on
> implementing them, but i have no idea how to build the corresponding
> class in sage.
>
> What should be the appropiate aproach? Is there some documentation
> about how to build new ring classes?.

Here is an implementation of exterior algebras in sage:

http://sporadic.stanford.edu/bump/exterior.sage

This uses combinatorial_algebra.py. That has a deprecation
warning (do not use). I think that means that you should not
use it for code that is going into Sage itself, but it sure is
handy to be able to implement a ring in just a few lines.

The exterior algebra on [0, 1, 2, 3]

After attaching the file, you can do this:

sage: E = ExteriorAlgebra(4); E
sage: [x0, x1, x2, x3] = E.generators()
sage: x0*x1
x0*x1
sage: x1*x0
-x0*x1
sage: (x0+x1*x2+x3)*x0
-x0*x3 + x0*x1*x2

Daniel Bump

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] adds riemann mapping and complex interpolation

Hi folks,

Ticket #6648 [1] is an enhancement to add Riemann mapping
functionality to Sage. I did some refereeing, but then found myself at
a lost because I don't understand the mathematics that the ticket
implements and I'm clueless on how to write a TestSuite required by
the ticket. I would appreciate if anyone would step up to help referee
this ticket.

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

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] help with I and NumberFieldElement_quadratic

Hi,

I am having problems understanding how "I" (complex unit) in Sage:

sage: type(I)


somehow becomes a NumberFieldElement_quadratic and that fails to
convert to the sympy's I:

ond...@raven:~/repos/sympy(pu)$ MPMATH_NOSAGE=yes sage -python
bin/test sympy/test_external/test_sage.py --pdb
= test process starts ==
executable:   
/home/ondrej/ext/sage-4.3.3-linux-64bit-ubuntu_9.10-x86_64-Linux/local/bin/python
 (2.6.4-final-0)

sympy/test_external/test_sage.py[13] .XXX 
I
E> /home/ondrej/repos/sympy/sympy/core/sympify.py(185)_sympify()
-> raise SympifyError("%r is NOT a valid SymPy expression" % (a,))
(Pdb) a
a = I
(Pdb) type(a)




Here is the full traceback:

 sympy/test_external/test_sage.py:test_complex _
  File "/home/ondrej/repos/sympy/sympy/test_external/test_sage.py",
line 61, in test_complex
check_expression("I*y", "y")
  File "/home/ondrej/repos/sympy/sympy/test_external/test_sage.py",
line 47, in check_expression
assert sympy.S(e_sage) == e_sympy
  File "/home/ondrej/repos/sympy/sympy/core/sympify.py", line 86, in sympify
v = meth()
  File "expression.pyx", line 932, in
sage.symbolic.expression.Expression._sympy_
(sage/symbolic/expression.cpp:5466)
  File 
"/home/ondrej/ext/sage-4.3.3-linux-64bit-ubuntu_9.10-x86_64-Linux/local/lib/python2.6/site-packages/sage/symbolic/expression_conversions.py",
line 214, in __call__
return self.arithmetic(ex, operator)
  File 
"/home/ondrej/ext/sage-4.3.3-linux-64bit-ubuntu_9.10-x86_64-Linux/local/lib/python2.6/site-packages/sage/symbolic/expression_conversions.py",
line 587, in arithmetic
return sympy.Mul(*ops)
  File "/home/ondrej/repos/sympy/sympy/core/cache.py", line 85, in wrapper
func_cache_it_cache[k] = r = func(*args, **kw_args)
  File "/home/ondrej/repos/sympy/sympy/core/operations.py", line 35, in __new__
c_part, nc_part, order_symbols = cls.flatten(map(_sympify, args))
  File "/home/ondrej/repos/sympy/sympy/core/sympify.py", line 185, in _sympify
raise SympifyError("%r is NOT a valid SymPy expression" % (a,))
SympifyError: SympifyError: I is NOT a valid SymPy expression


The relevant code is in sage/symbolic/expression_conversions.py around
the line 587:

def arithmetic(self, ex, operator):
"""
EXAMPLES::

sage: from sage.symbolic.expression_conversions import
SympyConverter
sage: s = SympyConverter()
sage: f = x + 2
sage: s.arithmetic(f, f.operator())
2 + x
"""
import sympy
operator = arithmetic_operators[operator]
ops = [self(a) for a in ex.operands()]
if operator == "+":
return sympy.Add(*ops)
elif operator == "*":
return sympy.Mul(*ops)


where the "self(a)" thing converts an expression from Sage to sympy,
and thus "ops" in the line:

return sympy.Mul(*ops)

are sympy symbols and thus everything works. Inluding "I" alone, as
these tests in sympy pass just fine:

check_expression("I", "")
check_expression("23+I*4", "x")

This test fails however:

check_expression("I*y", "y")


what happens is that "ops" contains

[y, I]

where "y" is a sympy symbol (ok), but I is of a type
NumberFieldElement_quadratic and sympy then fails to convert it to a
sympy expression in Mul.

What I understood is that Sage tries to optimize this expressions
somehow using NumberFieldElement_quadratic, but I wasn't able to
reproduce it:

sage: var("y")
y
sage: type(I*y)



Does anyone understand this code in Sage? What is happening there?
Should I implement _sympy_ methods in NumberFieldElement_quadratic, or
what is the way to fix this?

Thanks,
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: Guidelines for updating standard packages

Hi John,

On Sat, Mar 20, 2010 at 12:33 PM, John H Palmieri
 wrote:



> By the way, to facilitate testing on Solaris, we should have a recent
> binary build available so people can quickly install a copy on t2.math
> (for instance) to which they have write access.  It would be great if
> there were a tar.gz file advertised in the motd on that machine.

Please see http://trac.sagemath.org/sage_trac/milestone/sage-4.3.4

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Guidelines for updating standard packages

On Mar 19, 6:21 pm, Minh Nguyen  wrote:
> Hi David,
>
> On Sat, Mar 20, 2010 at 11:46 AM, Dr. David Kirkby
>
>  wrote:
>
> 
>
> > Does anyone have any comments on those, or additions?
>
> The guidelines you listed above sound reasonable to me.

I agree, except for part of #4: "The author must provide evidence to
the reviewer".  I think we should trust the authors: if they say that
it builds on Solaris, then we should believe that they have tested
it.  They shouldn't need to provide anything except a statement.  I
would also say that the reviewer should test it themselves on as many
platforms as they have access to.

By the way, to facilitate testing on Solaris, we should have a recent
binary build available so people can quickly install a copy on t2.math
(for instance) to which they have write access.  It would be great if
there were a tar.gz file advertised in the motd on that machine.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Guidelines for updating standard packages

Hi David,

On Sat, Mar 20, 2010 at 11:46 AM, Dr. David Kirkby
 wrote:



> Does anyone have any comments on those, or additions?

The guidelines you listed above sound reasonable to me. Could you
please open a ticket and add those guidelines?

-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Guidelines for updating standard packages

I said in the thread "Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)" that I 
felt updates to .spkg files were not done sufficiently carefully. Japp agreed 
with that.


The developers guide has some guidance on how to update .spkg files

http://www.sagemath.org/doc/developer/patching_spkgs.html

which is well written and clear, but perhaps need expanding. Things that come to 
my mind, is the author should check


1) Are there any warnings about depreciated options? If so, you need to 
understand why the option was given, why it depreciated, and what you should do 
about it.


2) Are there any warnings about unrecognized options to configure scripts?

3) If there are any patches, do they need re-writing? If a source file is 
overwritten, are you sure that overwriting it is still appropriate?


4) Does it at build on Linux, OSX and Solaris? (The author must provide evidence 
to the reviewer).


Since updating .spkg files often introduces platform-specific problems, I 
personally feel an author should check these, though others might argue that is 
unreasonable. Personally, if a package is working on all platforms, then if 
anyone proposes to update it, they should check it sill builds on those platforms.


5) Are any special build instructions listed in SPKG.txt followed?

6) Read ALL the comments in SPKG.txt, to see what people have changed and why. 
Do any of them have implications for the update?


7) Are all the patches applied still necessary? Sometimes bugs may be fixed 
upstream, so a patch is not required.


8) Are there any new dependencies? Sometimes new versions of packages require 
libraries that older ones did not, or require later versions. If so, does Sage 
include those dependencies? Just because your system has the dependency, do not 
assume that everyone else will have it.


9) Have you read the release notes for the update? If not, do so, and ensure 
there is nothing that will obviously cause a problem in Sage.


10) Have you documented the trac ticket for the update in SPKG.txt? If not, do 
so. If a ticket is not open for the update, then create the ticket, and 
reference that in SPKG.txt


There's probably others, but there are 10 I can think of.

The update of R, the fallout from which is still not totally resolved, would 
have failed 2, 4, 8 and 10.


Does anyone have any comments on those, or additions?

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

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] atan2 throws "divide by zero"

On Fri, Mar 19, 2010 at 4:41 PM, G B  wrote:
> I raised this in sage-support, and am now reasonably convinced this is
> a bug.  Guidelines say the next step is to raise it here.  The full
> thread is at:
> http://groups.google.com/group/sage-support/browse_thread/thread/02f3446e68381346#
>
> but the summary is:
> ---
> atan2(3,0)   --> 1/2*pi
> atan2(-3,0)  --> -1/2*pi
> atan2(pi,0)  --> 1/2*pi
> atan2(-pi,0) -->  RuntimeError: power::eval(): division by zero

In the convention atan2(y, x):

atan2(-pi, 0) = 2*atan(-pi/pi) = -pi/2 = -1.57079...

Python agrees too:

In [1]: from math import atan2, pi

In [2]: atan2(-pi, 0)
Out[2]: -1.5707963267948966


More info here:

http://certik.github.com/theoretical-physics/book/src/math/other.html#argument-function-atan2

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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] atan2 throws "divide by zero"

2010-03-19 Thread G B

I raised this in sage-support, and am now reasonably convinced this is
a bug.  Guidelines say the next step is to raise it here.  The full
thread is at:
http://groups.google.com/group/sage-support/browse_thread/thread/02f3446e68381346#

but the summary is:
---
atan2(3,0)   --> 1/2*pi
atan2(-3,0)  --> -1/2*pi
atan2(pi,0)  --> 1/2*pi
atan2(-pi,0) -->  RuntimeError: power::eval(): division by zero


Thanks--
 Greg

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Can someone close #6788

2010-03-19 Thread Mike Hansen

On Fri, Mar 19, 2010 at 4:11 PM, Dr. David Kirkby
 wrote:
> #6788 was a doctest failure on Solaris, which was resolved when Maxima was
> updated at #7745. Hence #6788 can be closed.

Done.  You can just make a comment on the ticket, and I'll close it.

--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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Can someone close #6788

#6788 was a doctest failure on Solaris, which was resolved when Maxima was 
updated at #7745. Hence #6788 can be closed.


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

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)

2010-03-19 Thread Jaap Spies


Dr. David Kirkby wrote:

Robert Bradshaw wrote:

[snipped]

For spkgs, changes to shell scripts, etc. a it is much more important
to test on a wide variety of platforms. Fortunately, most
contributions are plain vanilla Python/Cython.

Thanks for bringing this up, this is an example of what separates (in
my mind) the "sage-build" level stuff from the "sage-devel" level stuff.

- Robert



What you say about 'most' being Python/Cython is undoubtedly true.

However, there is still a significant number of .spkg updates each release.

The recent update to R, which screwed up on Solaris, resulted in iconv
being added to Sage rather hurriedly (directly as a standard package).
Iconv seems to be the cause of some problems on Fedora building gd,
though it appears it can be solved by removing an option to gd's
configure script.


Whoever introduced this package or/and the one who gave it a positive review
should have tested this change on all supported platforms :)!?

Moreover the releasemanager should have tested it on all available machines.



IMHO, the updates to .spkg files are not being done carefully enough.


+1

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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage



On Mar 19, 2:29 pm, William Stein  wrote:
> On Fri, Mar 19, 2010 at 2:25 PM, John H Palmieri  
> wrote:
>
>
>
>
>
>
>
> > On Mar 19, 11:13 am, Robert Bradshaw 
> > wrote:
> >> On Mar 19, 2010, at 10:23 AM, Nick Alexander wrote:
>
> >> > On 19-Mar-10, at 6:53 AM, Jason Grout wrote:
>
> >> >> On 03/18/2010 10:05 PM, John H Palmieri wrote:
> >> >>> Sage uses non-standard command-line options (e.g., -notebook rather
> >> >>> than --notebook). I propose that we switch to standard ones. Here
> >> >>> are
> >> >>> two reasons:
>
> >> >> +1!
>
> >> >> When this issue came up a year or two ago, there seemed to be a
> >> >> surprising amount of opposition to typing the extra dash, so the
> >> >> interest in changing the options and parsing waned.  I would be
> >> >> very happy to see us switch to standard GNU option parsing.
>
> >> > +1.  In fact, I tried to do this years ago, but my patch broke all
> >> > over the place and was bit-bucketed quickly :(
>
> >> For 
> >> reference,http://groups.google.com/group/sage-devel/browse_thread/thread/3403d3...
>
> >> In any case, I would now be in favor of such a move. As for making the
> >> transition, I'm not a huge fan of trying to control it via environment
> >> variables (at least, once it's beyond the extremely experimental
> >> stage). Once we have the back end, lets start using it by making a
> >> substitution for a fixed list of command, e.g. '-notebook' -> '--
> >> notebook' before invoking . Down the road we can add deprecation
> >> warnings whenever such a substitution is made, and eventually get rid
> >> of this step altogether.
>
> >> Perhaps keeping the old code around and usable in some form would be
> >> worth it for a while, because bugs here could be rather debilitating.
>
> > My patch basically just creates a new file, sage-sage.py, and
> > SAGE_ROOT/sage calls it (right now depending on the value of an
> > environment variable) instead of sage-sage.  So the original parser
> > sage-sage is still there.  I've slightly modified it, adding "--merge"
> > to the existing option "-merge", for instance, but it's essentially
> > intact.
>
> Nice.  So basically it calls sage-sage, and if that doesn't parse any
> options, it then calls sage-sage.py?   In that case, "sage -gp" won't
> be any slower at all.

In the most recent patch, it does this:

1. The file SAGE_ROOT/sage calls the new shell script sage-sage-
quickstart, which runs sage-env and then checks for --gp, --hg, etc.

2. If it finds one of these options, sage-sage-quickstart runs the
corresponding program (passing the rest of the command line as
arguments).  If it doesn't find one, it runs either sage-sage (which
now no longer runs sage-env) or sage-sage.py (the new parser) to parse
the command line, depending on the value of the environment variable
SAGE_NEW_OPTIONS.  So the old sage-sage doesn't get run at all if this
variable is set.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)


Robert Bradshaw wrote:

On Mar 19, 2010, at 3:18 AM, Dima Pasechnik wrote:


Craig,
[...]


For the record, I think it's pretty unreasonable to *require* Sage
developers to test on anything but their own machine -- but I *do*
think it's very reasonable to ask them to help fix problems with their
patches that arise on other architectures, especially if we can give
them a place to ssh and try things out.


well, as soon as it it is past vanilla Python/Cython, it becomes
unclear whether
a given change will not break functionality on another platform.
So I do not see how in this case one can limit testing to one platform 
only.

E.g. I went out of my way to test an upgrade of the GAP spkg on any
platform I could get my hands on.


For spkgs, changes to shell scripts, etc. a it is much more important to 
test on a wide variety of platforms. Fortunately, most contributions are 
plain vanilla Python/Cython.


Thanks for bringing this up, this is an example of what separates (in my 
mind) the "sage-build" level stuff from the "sage-devel" level stuff.


- Robert



What you say about 'most' being Python/Cython is undoubtedly true.

However, there is still a significant number of .spkg updates each release.

The recent update to R, which screwed up on Solaris, resulted in iconv being 
added to Sage rather hurriedly (directly as a standard package). Iconv seems to 
be the cause of some problems on Fedora building gd, though it appears it can be 
solved by removing an option to gd's configure script.


IMHO, the updates to .spkg files are not being done carefully enough. R's .spkg 
had the option '--with-iconv=no'. Whatever platform you built R on, there was a 
warning of this unrecognised option, but of course it was either unnoticed or 
ignored.


In fact, I can't even find the ticket that updated R. The SPKG.txt shows:

=== r-2.10.1 (Karl-Dieter Crisman, January 15, 2010) ===
 * Readline import issue is now fixed in R
 * Re-enable recommended packages
 * Upgrade rpy2 to 2.0.8
 * FreeBSD support improved (patch by Peter Jeremy)

=== r-2.9.2 (Jason Grout, Sept 20, 2009) ===
 * Also disable aqua support on 64 bit OSX

I really believe there is too much emphasis on quantity in Sage, and too little 
on quality.


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

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage

On Mar 19, 11:06 am, William Stein  wrote:
> On Fri, Mar 19, 2010 at 9:00 AM, John H Palmieri  
> wrote:
>
> Another possibility might be to first check for "--gp", "--gap", etc.,
> and do those before doing the general option parsing.   I.e., just do
> what you already planned, but with one optimization to deal with this
> use case.

This was within my shell-scripting abilities, so I've incorporated it
into the patch at #21.  Now "sage --gp" starts as quickly as it did
before.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: proposal: standard command-line options in Sage

On Fri, Mar 19, 2010 at 2:25 PM, John H Palmieri  wrote:
>
>
> On Mar 19, 11:13 am, Robert Bradshaw 
> wrote:
>> On Mar 19, 2010, at 10:23 AM, Nick Alexander wrote:
>>
>>
>>
>>
>>
>>
>>
>> > On 19-Mar-10, at 6:53 AM, Jason Grout wrote:
>>
>> >> On 03/18/2010 10:05 PM, John H Palmieri wrote:
>> >>> Sage uses non-standard command-line options (e.g., -notebook rather
>> >>> than --notebook). I propose that we switch to standard ones. Here
>> >>> are
>> >>> two reasons:
>>
>> >> +1!
>>
>> >> When this issue came up a year or two ago, there seemed to be a
>> >> surprising amount of opposition to typing the extra dash, so the
>> >> interest in changing the options and parsing waned.  I would be
>> >> very happy to see us switch to standard GNU option parsing.
>>
>> > +1.  In fact, I tried to do this years ago, but my patch broke all
>> > over the place and was bit-bucketed quickly :(
>>
>> For 
>> reference,http://groups.google.com/group/sage-devel/browse_thread/thread/3403d3...
>>
>> In any case, I would now be in favor of such a move. As for making the
>> transition, I'm not a huge fan of trying to control it via environment
>> variables (at least, once it's beyond the extremely experimental
>> stage). Once we have the back end, lets start using it by making a
>> substitution for a fixed list of command, e.g. '-notebook' -> '--
>> notebook' before invoking . Down the road we can add deprecation
>> warnings whenever such a substitution is made, and eventually get rid
>> of this step altogether.
>>
>> Perhaps keeping the old code around and usable in some form would be
>> worth it for a while, because bugs here could be rather debilitating.
>
> My patch basically just creates a new file, sage-sage.py, and
> SAGE_ROOT/sage calls it (right now depending on the value of an
> environment variable) instead of sage-sage.  So the original parser
> sage-sage is still there.  I've slightly modified it, adding "--merge"
> to the existing option "-merge", for instance, but it's essentially
> intact.

Nice.  So basically it calls sage-sage, and if that doesn't parse any
options, it then calls sage-sage.py?   In that case, "sage -gp" won't
be any slower at all.

I think this is a great architecture, and we can get rid of most of
sage-sage, but leave a little for speed purposes.

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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage



On Mar 19, 11:13 am, Robert Bradshaw 
wrote:
> On Mar 19, 2010, at 10:23 AM, Nick Alexander wrote:
>
>
>
>
>
>
>
> > On 19-Mar-10, at 6:53 AM, Jason Grout wrote:
>
> >> On 03/18/2010 10:05 PM, John H Palmieri wrote:
> >>> Sage uses non-standard command-line options (e.g., -notebook rather
> >>> than --notebook). I propose that we switch to standard ones. Here  
> >>> are
> >>> two reasons:
>
> >> +1!
>
> >> When this issue came up a year or two ago, there seemed to be a  
> >> surprising amount of opposition to typing the extra dash, so the  
> >> interest in changing the options and parsing waned.  I would be  
> >> very happy to see us switch to standard GNU option parsing.
>
> > +1.  In fact, I tried to do this years ago, but my patch broke all  
> > over the place and was bit-bucketed quickly :(
>
> For 
> reference,http://groups.google.com/group/sage-devel/browse_thread/thread/3403d3...
>
> In any case, I would now be in favor of such a move. As for making the  
> transition, I'm not a huge fan of trying to control it via environment  
> variables (at least, once it's beyond the extremely experimental  
> stage). Once we have the back end, lets start using it by making a  
> substitution for a fixed list of command, e.g. '-notebook' -> '--
> notebook' before invoking . Down the road we can add deprecation  
> warnings whenever such a substitution is made, and eventually get rid  
> of this step altogether.
>
> Perhaps keeping the old code around and usable in some form would be  
> worth it for a while, because bugs here could be rather debilitating.

My patch basically just creates a new file, sage-sage.py, and
SAGE_ROOT/sage calls it (right now depending on the value of an
environment variable) instead of sage-sage.  So the original parser
sage-sage is still there.  I've slightly modified it, adding "--merge"
to the existing option "-merge", for instance, but it's essentially
intact.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: Exterior algebras.

2010-03-19 Thread Mike Hansen

On Fri, Mar 19, 2010 at 1:00 PM, bump  wrote:
>> I hope other people respond, too.  I would suggest looking at
>>
>> 
>>
>> and the code in sage/algebras/quatalg (for quaternion algebras): use
>> this as one model for how to implement a noncommutative algebra.
>
> Another place to look is algebras/iwahori_hecke_algebra.py,
> showing how to an algebra as a subclass of CombinatorialFreeModule.

There's also some code up at
http://trac.sagemath.org/sage_trac/ticket/4539 which has some code for
exterior algebras provided by Singular.

--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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Exterior algebras.

2010-03-19 Thread bump

> I hope other people respond, too.  I would suggest looking at
>
> 
>
> and the code in sage/algebras/quatalg (for quaternion algebras): use
> this as one model for how to implement a noncommutative algebra.

Another place to look is algebras/iwahori_hecke_algebra.py,
showing how to an algebra as a subclass of CombinatorialFreeModule.

Dan

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)



On Mar 19, 2010, at 7:59 AM, Dr. David Kirkby wrote:


Craig Citro wrote:

It would be nice to have an automatic build-farm where you can just
run tests
on all the needed platforms, and fix the results, but this would,  
for

instance, seem to
require  a central repository with a current snapshot of Sage,
something hardly
feasible in any moment, except, perhaps, shortly before a release...


Actually, our grand plan currently involves doing exactly that --
having an "autobuilder" running on sage.math, testing all tickets  
with

positive review on the build farm and reporting back to the ticket. I
think this is completely do-able given our current hardware -- it's
just a question of someone finding the time to set it up.
-cc


Which I suspect is a non-trivial amount of time. Unless someone has  
done it before, I suspect there will be a fairly large amount of  
time needed to read the relevant documents, try to set it up, sort  
out all the problems. I can easily imagine that would take 1-2 weeks  
full-time. I might be wrong of course, as I've never set one up.


I could imagine that too, but it will be 1-2 weeks full-time well  
spent, but will pay for itself in saved developer and release  
management time very shortly. It will happen--I think we've gotten to  
the point that we're hurting for not having such a system.


- 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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)


On Mar 19, 2010, at 3:18 AM, Dima Pasechnik wrote:


Craig,
[...]


For the record, I think it's pretty unreasonable to *require* Sage
developers to test on anything but their own machine -- but I *do*
think it's very reasonable to ask them to help fix problems with  
their

patches that arise on other architectures, especially if we can give
them a place to ssh and try things out.


well, as soon as it it is past vanilla Python/Cython, it becomes
unclear whether
a given change will not break functionality on another platform.
So I do not see how in this case one can limit testing to one  
platform only.

E.g. I went out of my way to test an upgrade of the GAP spkg on any
platform I could get my hands on.


For spkgs, changes to shell scripts, etc. a it is much more important  
to test on a wide variety of platforms. Fortunately, most  
contributions are plain vanilla Python/Cython.


Thanks for bringing this up, this is an example of what separates (in  
my mind) the "sage-build" level stuff from the "sage-devel" level stuff.


- 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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage

On Mar 19, 11:06 am, William Stein  wrote:
>
> I'm still concerned about slowing down all of the "sage
> -various_system" commands.  A typical use case of Sage for some
> sysadmins is to install Sage system-wide, type "sage:
> install_scripts('/usr/local/bin/')", and get scripts "gp", "gap",
> etc., in /usr/local/bin/, which just call the corresponding "sage
> -gp","sage -gap", etc.   It's really sad if all of those scripts
> become significantly slower (over twice as slow) just because of this
> switch.

I still don't think that "twice as slow" == "significantly slower": if
the difference is around 5/100 of a second,  it's slower, but is it
significant? We should test it to see if it's actually noticeable.

> I've written many interactive webpages that use cgi-bin, and for them
> it matters a lot how long "sage -gp" takes.  

This is possibly a good point, but again it needs testing.

> Also, many people will
> attest to using "sage -gp" for a quick computation instead of "sage",
> just because it is so fast.
>
> I think the tradeoff for using shflags is more reasonable, though
> obviously the OS X issue is significant.

As I said, I don't know anything about writing shell scripts, but if
someone else wants to do this, that's fine with me.  If there is an
issue on OS X, though, that's a problem, and it also suggests a lack
of portability.  (What about Solaris, for instance?)  One advantage to
working with Python is that we know what version of Python we're
using, because we actually install it.  So we ought to be able to make
a Python-based version very portable.

> Another possibility might be to first check for "--gp", "--gap", etc.,
> and do those before doing the general option parsing.   I.e., just do
> what you already planned, but with one optimization to deal with this
> use case.

That's an interesting idea.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: proposal: standard command-line options in Sage


On Mar 19, 2010, at 11:06 AM, William Stein wrote:

On Fri, Mar 19, 2010 at 9:00 AM, John H Palmieri > wrote:

On Mar 19, 1:36 am, William Stein  wrote:

On Fri, Mar 19, 2010 at 1:31 AM, Dan Drake  wrote:

On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
The main issue I see is that using getopt or optparse means that  
the
"local/bin/sage-sage" script will go from not depending on  
Python to
depending on Python.  This may cause trouble for the build  
system, and


No, it builds fine for me: I said this in the original post.  I also
just temporarily deleted my system version of Python and tried again.
It had no problems getting past building python, so I think it should
work just fine for the whole build.  (I think I also said that I
hadn't looked at any optional packages; some of them might very well
break.)

may slow down commands such as "sage -gp", since doing "sage - 
gp" now

means also starting Python, in addition to Pari.



Good point -- although Python does start very fast.


PARI starts up nearly twice as fast as Python (for me on  
boxen.math):


wst...@boxen:~$ time sage -gp  < /dev/null
real0m0.030s
user0m0.000s
sys 0m0.010s
wst...@boxen:~$ time sage -python  < /dev/null
real0m0.048s
user0m0.020s
sys 0m0.020s

Other commands such as "sage -hg" will also suddenly take 50% longer
if we make this switch using Python.


50% is one way to say it, but (on my machine) 0.06 seconds is another
way.  I don't think I'll notice the difference when running "sage --
hg".  I don't use "sage --gp", but I don't see this being a problem
for just running the command-line interpreter -- a slight delay at  
the

beginning is not a big deal.  If you are going to run "sage --gp",
passing it a single command to execute, and repeating it many times,
then there might be an issue, but then you should do "sage --sh"
first, then just use "gp" to avoid any overhead.


I'm still concerned about slowing down all of the "sage
-various_system" commands.  A typical use case of Sage for some
sysadmins is to install Sage system-wide, type "sage:
install_scripts('/usr/local/bin/')", and get scripts "gp", "gap",
etc., in /usr/local/bin/, which just call the corresponding "sage
-gp","sage -gap", etc.   It's really sad if all of those scripts
become significantly slower (over twice as slow) just because of this
switch.

I've written many interactive webpages that use cgi-bin, and for them
it matters a lot how long "sage -gp" takes.   Also, many people will
attest to using "sage -gp" for a quick computation instead of "sage",
just because it is so fast.

I think the tradeoff for using shflags is more reasonable, though
obviously the OS X issue is significant.

Another possibility might be to first check for "--gp", "--gap", etc.,
and do those before doing the general option parsing.   I.e., just do
what you already planned, but with one optimization to deal with this
use case.


That's a good point. Also, we don't want to be messing with any of the  
options that might come after sage --gap. This would probably be a  
quick optimization, if the first option is X where X is in some list,  
dispatch to X right away.


- 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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] Re: proposal: standard command-line options in Sage

On Mar 19, 2010, at 10:23 AM, Nick Alexander wrote:

On 19-Mar-10, at 6:53 AM, Jason Grout wrote:

On 03/18/2010 10:05 PM, John H Palmieri wrote:

Sage uses non-standard command-line options (e.g., -notebook rather
than --notebook). I propose that we switch to standard ones. Here
are

two reasons:

+1!

When this issue came up a year or two ago, there seemed to be a
surprising amount of opposition to typing the extra dash, so the
interest in changing the options and parsing waned. I would be
very happy to see us switch to standard GNU option parsing.

+1. In fact, I tried to do this years ago, but my patch broke all
over the place and was bit-bucketed quickly :(

For reference,
http://groups.google.com/group/sage-devel/browse_thread/thread/3403d3cbd24be221/3b4ab29f1e115961

In any case, I would now be in favor of such a move. As for making the
transition, I'm not a huge fan of trying to control it via environment
variables (at least, once it's beyond the extremely experimental
stage). Once we have the back end, lets start using it by making a
substitution for a fixed list of command, e.g. '-notebook' -> '--
notebook' before invoking . Down the road we can add deprecation
warnings whenever such a substitution is made, and eventually get rid
of this step altogether.

Perhaps keeping the old code around and usable in some form would be
worth it for a while, because bugs here could be rather debilitating.

- 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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] Re: proposal: standard command-line options in Sage

On Fri, Mar 19, 2010 at 9:00 AM, John H Palmieri  wrote:
> On Mar 19, 1:36 am, William Stein  wrote:
>> On Fri, Mar 19, 2010 at 1:31 AM, Dan Drake  wrote:
>> > On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
>> >> The main issue I see is that using getopt or optparse means that the
>> >> "local/bin/sage-sage" script will go from not depending on Python to
>> >> depending on Python.  This may cause trouble for the build system, and
>
> No, it builds fine for me: I said this in the original post.  I also
> just temporarily deleted my system version of Python and tried again.
> It had no problems getting past building python, so I think it should
> work just fine for the whole build.  (I think I also said that I
> hadn't looked at any optional packages; some of them might very well
> break.)
>
>> >> may slow down commands such as "sage -gp", since doing "sage -gp" now
>> >> means also starting Python, in addition to Pari.
>>
>> > Good point -- although Python does start very fast.
>>
>> PARI starts up nearly twice as fast as Python (for me on boxen.math):
>>
>> wst...@boxen:~$ time sage -gp  < /dev/null
>> real    0m0.030s
>> user    0m0.000s
>> sys     0m0.010s
>> wst...@boxen:~$ time sage -python  < /dev/null
>> real    0m0.048s
>> user    0m0.020s
>> sys     0m0.020s
>>
>> Other commands such as "sage -hg" will also suddenly take 50% longer
>> if we make this switch using Python.
>
> 50% is one way to say it, but (on my machine) 0.06 seconds is another
> way.  I don't think I'll notice the difference when running "sage --
> hg".  I don't use "sage --gp", but I don't see this being a problem
> for just running the command-line interpreter -- a slight delay at the
> beginning is not a big deal.  If you are going to run "sage --gp",
> passing it a single command to execute, and repeating it many times,
> then there might be an issue, but then you should do "sage --sh"
> first, then just use "gp" to avoid any overhead.

I'm still concerned about slowing down all of the "sage
-various_system" commands.  A typical use case of Sage for some
sysadmins is to install Sage system-wide, type "sage:
install_scripts('/usr/local/bin/')", and get scripts "gp", "gap",
etc., in /usr/local/bin/, which just call the corresponding "sage
-gp","sage -gap", etc.   It's really sad if all of those scripts
become significantly slower (over twice as slow) just because of this
switch.

I've written many interactive webpages that use cgi-bin, and for them
it matters a lot how long "sage -gp" takes.   Also, many people will
attest to using "sage -gp" for a quick computation instead of "sage",
just because it is so fast.

I think the tradeoff for using shflags is more reasonable, though
obviously the OS X issue is significant.

Another possibility might be to first check for "--gp", "--gap", etc.,
and do those before doing the general option parsing.   I.e., just do
what you already planned, but with one optimization to deal with this
use case.

 -- 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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Exterior algebras.

On Mar 19, 10:46 am, mmarco  wrote:
> I would need to deal with exterior algebras, and as far as i have
> seen, they are not defined in sage. I could try working on
> implementing them, but i have no idea how to build the corresponding
> class in sage.
>
> What should be the appropiate aproach? Is there some documentation
> about how to build new ring classes?.

I hope other people respond, too.  I would suggest looking at

and the code in sage/algebras/quatalg (for quaternion algebras): use
this as one model for how to implement a noncommutative algebra.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Exterior algebras.

2010-03-19 Thread mmarco

I would need to deal with exterior algebras, and as far as i have
seen, they are not defined in sage. I could try working on
implementing them, but i have no idea how to build the corresponding
class in sage.

What should be the appropiate aproach? Is there some documentation
about how to build new ring classes?.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] improvements to FEMhub with regards to Sage

Hi William!

On Thu, Mar 18, 2010 at 4:34 PM, William Stein  wrote:
> 2010/2/22 Ondrej Certik :
>> Hi,
>>
>> some FEMhub users are confused by seeing the name "Sage" in
>> warnings and error messages, and in various installation scripts
>> and messages. They are there because FEMhub uses some
>> functionality of Sage (as Ubuntu uses some functionality of
>> Debian). However, the word "Debian" does not appear in
>> Ubuntu (for a normal user). We would like to design a similar model,
>> acknowledge
>> Sage for using their functionality, but limit the occurrence of
>> the word "Sage" for FEMhub users. Here are a few ideas how
>> we would like to do it, please feel free to comment:
>>
>>
>> The best model to learn from is Debian vs Ubuntu. If you take any
>
> Hi,
>
> I agree that Debian vs Ubuntu is an excellent model.  I also agree
> with all of your other comments in this thread, and strongly support
> your branding efforts.  I also hope you can share your experiences
> with how they go, and ideas for making something like this more
> generically possible.  I would be thrilled if someday there were
> dozens of rebranded specialized Sage-based distributions out there.
> It's good to make this as easy as possible, and also ensuring that
> people understand that it is their right to do so.   I think that's
> the best thing to do to maximize the chances of us working together as
> a community instead of competing.

Thanks for this answer an the "official" blessing of our efforts. :)
And also Nick and Minh for the tips.

Currently we just have a femhub git repository[0], that contains all
sage code and the unpacked sage-scripts spkg, and we simply rename all
Sage to FEMhub and have the commits in the git, so that we can keep
synchronized with the latest Sage (I think I synchronized this only
twice so far), we did roughly 6 or 7 releases of femhub, but hopefully
we'll do it more often in the future. Then we have a download_packages
script[1], that just downloads a combination of Sage (unmodified) and
our packages. Everything else is the same.

The sagenb package is renamed to femhub_notebook, and again,
everything is in git, we have a "sagenb" branch, that is identical to
the mercurial sagenb repository (synchronized from time to time, by
hand, simply by copying the files using "cp") and the "master" branch
then contains all our modifications. So far Sameer renames everything
by hand, but we want to write a simple script that does this for us,
and hopefully in the future we'll figure out some better way and
submit some improvements patches to sagenb. We also change the front
screen and some other things.

As to which notebook to use for our online lab (e.g. we have some
specific demans, like a mesh editor, we would like to have login free
functionality etc.), currently the sage notebook is the most usable,
so we use that, we are also experimenting a bit with codenode and my
demo code [2], but we don't have much time for this now, so we'll just
use the sagenb for now, it's good enough.

Ondrej

[0] http://github.com/certik/femhub
[1] http://github.com/certik/femhub/blob/master/spkg/standard/download_packages
[2] http://gamma.sympy.org/nb/

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: proposal: standard command-line options in Sage

2010-03-19 Thread Nick Alexander



On 19-Mar-10, at 6:53 AM, Jason Grout wrote:


On 03/18/2010 10:05 PM, John H Palmieri wrote:

Sage uses non-standard command-line options (e.g., -notebook rather
than --notebook). I propose that we switch to standard ones. Here are
two reasons:



+1!

When this issue came up a year or two ago, there seemed to be a  
surprising amount of opposition to typing the extra dash, so the  
interest in changing the options and parsing waned.  I would be very  
happy to see us switch to standard GNU option parsing.


+1.  In fact, I tried to do this years ago, but my patch broke all  
over the place and was bit-bucketed quickly :(


Nick

--
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 unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] Re: presentation at Jr. Science and Humanities Symposium in Reno

Hi,

On Thu, Mar 18, 2010 at 3:34 PM, Ondrej Certik  wrote:
> Hi,
>
> at 6pm today we'll be giving a presentation about FEMhub[0] at the
> 2010 Northern California Western Nevada
> Jr. Science and Humanities Symposium[1, 2].
>
> I'll talk about sympy as part of it for about 10 minutes. I've
> prepared a worksheet:
>
> http://nb.femhub.org/home/pub/16/
>
> with all kinds of sympy demos (I am attaching it too, just to be
> sure). Let me know if you have some other cool stuff that can go in.
> I've put our latest git sympy into femhub (e.g. new polys). I've also
> discovered a new bug [3] in the polys.
>
> Ondrej
>
>
> [0] http://femhub.org/
> [1] http://lawrencehallofscience.org/jshs/
> [2] http://www.jshs.org/
> [3] http://code.google.com/p/sympy/issues/detail?id=1863
>

So there were about 160 people, I asked how many of them can do
programming, I think roughly 30 people raised hands and then I asked
how many of them know Python and about the same amount of people
raised hands, which was very interesting to me.

I run over all the cells in the worksheet, everything went smoothly.
Except for one cell, that holded the long polynomial expression,
didn't resize well and I couldn't make it resize, this was annoying.
But otherwise the notebook worked pretty well. Previously, when giving
some demo/tutorials about sympy, I prepared a .py file and copy&pasted
things into the terminal, but from now on I'll be using the web
notebook --- it's way more convenient, as I have better granularity in
determining if some cell goes wrong (the .py file just raises an
exception and ends, while in the notebook just this one cell fails), I
like that I can use the text cells (headings/titles) so that the
worksheet has some structure etc. I *love* that I can output html, so
my (actually Fredrik's:) demo code that produces the
integrals/derivatives table just works in the notebook and it looked
really nice in Firefox, using the unicode pretty printing.

I need to figure out how to use the jsmath more easily, and also the
pretty printing in sympy is tailored to 80 characters terminal width,
but the notebook trims it earlier, so it looks ugly if the expression
is long.

But overall, I am sold for the web notebook/online lab, couple years
ago I was very skeptical, as I really love just a terminal. But for
these kinds of presentations, the notebook is better than a terminal.

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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)

2010-03-19 Thread Dima Pasechnik

about 10 years ago I worked full-time on CGAL (www.cgal.org) for a
while, and we had a kind
of (semi)automatic testing suite that pulled a snapshot from a CVS
server, ran tests on a number
of platforms, and reported results on a webpage.

Dima


On Mar 19, 10:59 pm, "Dr. David Kirkby" 
wrote:
> Craig Citro wrote:
> >> It would be nice to have an automatic build-farm where you can just
> >> run tests
> >> on all the needed platforms, and fix the results, but this would, for
> >> instance, seem to
> >> require  a central repository with a current snapshot of Sage,
> >> something hardly
> >> feasible in any moment, except, perhaps, shortly before a release...
>
> > Actually, our grand plan currently involves doing exactly that --
> > having an "autobuilder" running on sage.math, testing all tickets with
> > positive review on the build farm and reporting back to the ticket. I
> > think this is completely do-able given our current hardware -- it's
> > just a question of someone finding the time to set it up.
>
> > -cc
>
> Which I suspect is a non-trivial amount of time. Unless someone has done it
> before, I suspect there will be a fairly large amount of time needed to read 
> the
> relevant documents, try to set it up, sort out all the problems. I can easily
> imagine that would take 1-2 weeks full-time. I might be wrong of course, as 
> I've
> never set one up.
>
> 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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage

On Mar 19, 6:52 am, Martin Albrecht 
wrote:
> > - how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
>
> I find these incredibly useful!

Great!  I thought someone had said that they were broken, so I'm happy
that they're not.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage

On Mar 19, 1:36 am, William Stein  wrote:
> On Fri, Mar 19, 2010 at 1:31 AM, Dan Drake  wrote:
> > On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
> >> The main issue I see is that using getopt or optparse means that the
> >> "local/bin/sage-sage" script will go from not depending on Python to
> >> depending on Python.  This may cause trouble for the build system, and

No, it builds fine for me: I said this in the original post.  I also
just temporarily deleted my system version of Python and tried again.
It had no problems getting past building python, so I think it should
work just fine for the whole build.  (I think I also said that I
hadn't looked at any optional packages; some of them might very well
break.)

> >> may slow down commands such as "sage -gp", since doing "sage -gp" now
> >> means also starting Python, in addition to Pari.
>
> > Good point -- although Python does start very fast.
>
> PARI starts up nearly twice as fast as Python (for me on boxen.math):
>
> wst...@boxen:~$ time sage -gp  < /dev/null
> real    0m0.030s
> user    0m0.000s
> sys     0m0.010s
> wst...@boxen:~$ time sage -python  < /dev/null
> real    0m0.048s
> user    0m0.020s
> sys     0m0.020s
>
> Other commands such as "sage -hg" will also suddenly take 50% longer
> if we make this switch using Python.

50% is one way to say it, but (on my machine) 0.06 seconds is another
way.  I don't think I'll notice the difference when running "sage --
hg".  I don't use "sage --gp", but I don't see this being a problem
for just running the command-line interpreter -- a slight delay at the
beginning is not a big deal.  If you are going to run "sage --gp",
passing it a single command to execute, and repeating it many times,
then there might be an issue, but then you should do "sage --sh"
first, then just use "gp" to avoid any overhead.

> > I see that bash has
> > a "getopts" builtin, although it doesn't do --style arguments. I
> > downloaded shflags, which Tim suggested, and using it amounts to sourcing a
> > 31KB shell library, which seems like a pretty reasonable, uh, option --
> > check outhttp://code.google.com/p/shflags/wiki/Documentation10x
>
> How long does it take?

This may be an option (but Dan Drake's post suggests otherwise?), but
not written by me: I don't know how to write shell scripts.  If
someone else wants to do this, please go ahead.

Meanwhile, I've posted a Python/optparse version at

  .

This deletes the "sage --darcs" option but keeps all of the others.

--
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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)


Craig Citro wrote:

It would be nice to have an automatic build-farm where you can just
run tests
on all the needed platforms, and fix the results, but this would, for
instance, seem to
require  a central repository with a current snapshot of Sage,
something hardly
feasible in any moment, except, perhaps, shortly before a release...



Actually, our grand plan currently involves doing exactly that --
having an "autobuilder" running on sage.math, testing all tickets with
positive review on the build farm and reporting back to the ticket. I
think this is completely do-able given our current hardware -- it's
just a question of someone finding the time to set it up.

-cc



Which I suspect is a non-trivial amount of time. Unless someone has done it 
before, I suspect there will be a fairly large amount of time needed to read the 
relevant documents, try to set it up, sort out all the problems. I can easily 
imagine that would take 1-2 weeks full-time. I might be wrong of course, as I've 
never set one up.


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

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] proposal: standard command-line options in Sage

2010-03-19 Thread Tim Joseph Dumol

On Fri, Mar 19, 2010 at 3:52 PM, William Stein  wrote:

> On Fri, Mar 19, 2010 at 12:47 AM, Dan Drake  wrote:
> > On Thu, 18 Mar 2010 at 09:05PM -0700, John H Palmieri wrote:
> >> Sage uses non-standard command-line options (e.g., -notebook rather
> >> than --notebook). I propose that we switch to standard ones. Here are
> >> two reasons:
> >
> > A big +1 here. No need to reinvent the wheel; we are manually parsing
> > command-line options, and should instead take advantage of the getopt or
> > optparse modules.
>
> The main issue I see is that using getopt or optparse means that the
> "local/bin/sage-sage" script will go from not depending on Python to
> depending on Python.  This may cause trouble for the build system, and
> may slow down commands such as "sage -gp", since doing "sage -gp" now
> means also starting Python, in addition to Pari.
>
>
This code does the requisite parsing in pure shell script:
http://code.google.com/p/shflags/, which I think removes the only negative
:-)


> Other than that, I can't see any negatives.
>
> The sage-sage file parsed like 2 or 3 options when I first wrote it,
> and I planned to redo it "right", but then it kept getting longer...
>
> > Your implementation plan sounds good, and should let us shake out bugs
> > without making Sage unusable for anyone.
> >
> >> By the way, while investigating this, I came up with some questions:
> >>
> >> - What should "sage blah.spkg" do? It looks like it's supposed to
> >> install the spkg, although this isn't documented anywhere that I can
> >> see. Should we keep this behavior, or just make the user type "sage -i
> >> blah.spkg"?
> >
> > Off the top of my head, I think "sage blah.spkg" should ask you if you
> > want to install the spkg and just exit if you say no.
> >
> >> -  "sage -log" seems to be broken: it tries to write to the
> >> nonexistent file SAGE_ROOT/changelog.txt. Should we remove it or fix
> >> it?
> >
> > (Again off the top of my head...) I say remove this. It's doesn't seem
> > relevant to our current development procedures.
>
> +1
>
> >
> >> - what is "sage -darcs" supposed to do? I don't know what "darcs" is,
> >> and I don't see any packages which seem relevant.
>
> Delete it.
>
> >>
> >> - what about "sage -axiom"? What package installs axiom?  Fricas?
>
> Fricas.
>
> >>
> >> - does anyone use "sage -crap"? "sage -min"? "sage -inotebook"?
>
> I use "sage -inotebook" and have used "sage -crap".   I wrote "sage
> -min" to satisfy complaints from David Harvey...
>
> >> - how about "sage -gthread" and friends?
>
> I don't know what that is.
>
> >> - how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
> >> etc.?
>
> That should stay.  And somebody should really be using it again :-).
>
> 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 unsubscribe from this group, send email to sage-devel+
> unsubscribegooglegroups.com or reply to this email with the words "REMOVE
> ME" as the subject.
>



-- 
Tim Joseph Dumol 
http://timdumol.com

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)

2010-03-19 Thread Craig Citro

> It would be nice to have an automatic build-farm where you can just
> run tests
> on all the needed platforms, and fix the results, but this would, for
> instance, seem to
> require  a central repository with a current snapshot of Sage,
> something hardly
> feasible in any moment, except, perhaps, shortly before a release...
>

Actually, our grand plan currently involves doing exactly that --
having an "autobuilder" running on sage.math, testing all tickets with
positive review on the build farm and reporting back to the ticket. I
think this is completely do-able given our current hardware -- it's
just a question of someone finding the time to set it up.

-cc

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage

2010-03-19 Thread Jason Grout


On 03/18/2010 10:05 PM, John H Palmieri wrote:

Sage uses non-standard command-line options (e.g., -notebook rather
than --notebook). I propose that we switch to standard ones. Here are
two reasons:



+1!

When this issue came up a year or two ago, there seemed to be a 
surprising amount of opposition to typing the extra dash, so the 
interest in changing the options and parsing waned.  I would be very 
happy to see us switch to standard GNU option parsing.


Thanks,

Jason


--
Jason Grout

--
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 unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] proposal: standard command-line options in Sage

2010-03-19 Thread Martin Albrecht

> - how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",

I find these incredibly useful!

Martin

-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinralbre...@jabber.ccc.de

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: NTL-5.5.2 and gf2x

2010-03-19 Thread Martin Albrecht

On Friday 19 March 2010, YannLC wrote:
> Hi François,
> I have no problem building Sage from scratch with NTL 5.5.2 and gf2x.
> As I said, I have myself available spkgs (and patches) doing them job
> (modifiy spkg-install, remove or modify the patches to NTL, update
> spkg/standard/deps etc).
> My problem is that the policy is to make new spkg optional during some
> time before inclusion as standard. I would like to be able to install
> gf2x with 'sage -i gf2x-0.9.6' and this seems more difficult to me.

How about a "ntl-5.5.2-gf2x-0.96" optional SPKG which replaces the NTL SPKG 
when installed? That is, one gets an SPKG of NTL with GF2X included. All code 
in Sage dependent on NTL *should* rebuild after NTL was reinstalled when 
issuing "sage -b". I'm sure not everything does, but these are bugs we need to 
take care of anyway (i.e. adding the appropriate dependency in the 
module_list.py)

Cheers,
Martin

PS: +1 for gettng GF2X in Sage!

-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinralbre...@jabber.ccc.de

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] proposal: standard command-line options in Sage

2010-03-19 Thread Dan Drake

On Fri, 19 Mar 2010 at 01:36AM -0700, William Stein wrote:
> PARI starts up nearly twice as fast as Python (for me on boxen.math):
> 
> wst...@boxen:~$ time sage -gp  < /dev/null
> real0m0.030s
> user0m0.000s
> sys 0m0.010s
> wst...@boxen:~$ time sage -python  < /dev/null
> real0m0.048s
> user0m0.020s
> sys 0m0.020s

On my computer, I get a "real" time of 0.30 s for pari and 0.40 s for
python, using your test. For shflags, this is what I get:

dr...@klee:/tmp/shflags-1.0.3/src$ time /bin/bash <  /dev/null

real0m0.003s
user0m0.000s
sys 0m0.002s
 
dr...@klee:/tmp/shflags-1.0.3/src$ time /bin/bash -c '. ./shflags'

real0m0.015s
user0m0.009s
sys 0m0.006s

So, way faster. And on Linuxen that use dash for /bin/sh (like Ubuntu),
we can get faster still if we write strictly POSIX-compliant scripts:

dr...@klee:/tmp/shflags-1.0.3/src$ time /bin/sh <  /dev/null

real0m0.001s
user0m0.000s
sys 0m0.002s
dr...@klee:/tmp/shflags-1.0.3/src$ time /bin/sh -c '. ./shflags' 

real0m0.007s
user0m0.004s
sys 0m0.004s

One potentially big problem is that shflags doesn't do -- options on OS
X since bash there is only version 3.2 and doesn't have some of the
builtin getopt stuff:

dr...@bsd:~/shflags-1.0.3/examples$ ./hello_world.sh --name foo
flags:WARN getopt: illegal option -- -
 -n ame -- foo
 flags:FATAL unable to parse provided options with getopt.

It looks like among fast, portable, and easy to use, we can choose any
two. :)

Dan

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


signature.asc
Description: Digital signature

[sage-devel] Re: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)

2010-03-19 Thread Dima Pasechnik

Craig,
[...]

> For the record, I think it's pretty unreasonable to *require* Sage
> developers to test on anything but their own machine -- but I *do*
> think it's very reasonable to ask them to help fix problems with their
> patches that arise on other architectures, especially if we can give
> them a place to ssh and try things out.

well, as soon as it it is past vanilla Python/Cython, it becomes
unclear whether
a given change will not break functionality on another platform.
So I do not see how in this case one can limit testing to one platform
only.
E.g. I went out of my way to test an upgrade of the GAP spkg on any
platform
I could get my hands on.

It would be nice to have an automatic build-farm where you can just
run tests
on all the needed platforms, and fix the results, but this would, for
instance, seem to
require  a central repository with a current snapshot of Sage,
something hardly
feasible in any moment, except, perhaps, shortly before a release...

Dmitrii

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Latest Magma fails to load

2010-03-19 Thread David Kohel

Hi,

I solved this problem by changing the Magma script to not search
in the DYLD_LIBRARY_PATH (in $ROOT/magma):

#DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$ROOT # original line
DYLD_LIBRARY_PATH=$ROOT # hard code to use libgmp.3.dylib in $ROOT

Similarly, if you want to use another libgmp3 (version 9.0.0 or later
according to Magma' error message), then change this line or make
a symbolic link here.

I was of mixed opinion whether this was a bug in Sage or Magma,
and decided that it was better to solve it in Magma.

--David

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Latest Magma fails to load

2010-03-19 Thread Kwankyu Lee

This is now Ticket #8560

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


Kwankyu

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] ZZ and QQ, p-adic valuations

2010-03-19 Thread John Cremona

I forwarded this to sage-nt as being a better place for the discussion!

John

On 18 March 2010 22:53, Robert Miller  wrote:
> Does anyone see a reason why there should be two function names?
>
> sage: QQ(7).valuation(7)
> 1
> sage: ZZ(7).ord(7)
> 1
>
> Any opinions on which is better? I myself use N.ord(p) a lot, and I
> was surprised that I hadn't run across this before.
>
> --
> Robert L. Miller
> http://www.rlmiller.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
>
> To unsubscribe from this group, send email to 
> sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
> "REMOVE ME" as the subject.
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: Latest Magma fails to load

On Fri, Mar 19, 2010 at 1:42 AM, Kwankyu Lee  wrote:
> Hi William,
>
> That works. Thank you. If you don't, I will open a ticket for this.
>
> Kwankyu

Please open a ticket.  Thanks!

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 unsubscribe from this group, send email to 
> sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
> "REMOVE ME" as the subject.
>



-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Latest Magma fails to load

2010-03-19 Thread Kwankyu Lee

Hi William,

That works. Thank you. If you don't, I will open a ticket for this.

Kwankyu

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] proposal: standard command-line options in Sage

On Fri, Mar 19, 2010 at 1:31 AM, Dan Drake  wrote:
> On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
>> The main issue I see is that using getopt or optparse means that the
>> "local/bin/sage-sage" script will go from not depending on Python to
>> depending on Python.  This may cause trouble for the build system, and
>> may slow down commands such as "sage -gp", since doing "sage -gp" now
>> means also starting Python, in addition to Pari.
>
> Good point -- although Python does start very fast.

PARI starts up nearly twice as fast as Python (for me on boxen.math):

wst...@boxen:~$ time sage -gp  < /dev/null
real0m0.030s
user0m0.000s
sys 0m0.010s
wst...@boxen:~$ time sage -python  < /dev/null
real0m0.048s
user0m0.020s
sys 0m0.020s

Other commands such as "sage -hg" will also suddenly take 50% longer
if we make this switch using Python.

> I see that bash has
> a "getopts" builtin, although it doesn't do --style arguments. I
> downloaded shflags, which Tim suggested, and using it amounts to sourcing a
> 31KB shell library, which seems like a pretty reasonable, uh, option --
> check out http://code.google.com/p/shflags/wiki/Documentation10x

How long does it take?

 --William

>
>
>
> Dan
>
> --
> ---  Dan Drake
> -  http://mathsci.kaist.ac.kr/~drake
> ---
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkujNlAACgkQr4V8SljC5LoUiQCgkwOwvkXA2/jvQxNdO80S6fzQ
> pXcAnAxhDUcw7q48nfezS1kQDgddk9ll
> =B0xF
> -END PGP SIGNATURE-
>
>



-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Latest Magma fails to load

On Fri, Mar 19, 2010 at 1:29 AM, Kwankyu Lee  wrote:
> Hi,
>
> In Mac OS, latest Magma v2.16-6 fails to load under Sage 4.3.3, with
> the following error message:
>
> sage: magma_console()
> dyld: Library not loaded: @executable_path/libgmp.3.dylib
>  Referenced from: /Applications/Magma/bin/magma.exe
>  Reason: Incompatible library version: magma.exe requires version
> 9.0.0 or later, but libgmp.3.dylib provides version 8.0.0
> /usr/bin/magma: line 72: 16880 Trace/BPT trap          "${ROOT}/bin/
> magma.exe" $*
>
> I investigated this issue a bit. The reason of the failure is that
> Sage defines the variable DYLD_LIBRARY_PATH when it executes Magma. If
> you undefine it or define it to point to the right place, then there
> is no problem, as you see below.
>
> sage subshell$ magma
> dyld: Library not loaded: @executable_path/libgmp.3.dylib
>  Referenced from: /Applications/Magma/bin/magma.exe
>  Reason: Incompatible library version: magma.exe requires version
> 9.0.0 or later, but libgmp.3.dylib provides version 8.0.0
> /usr/bin/magma: line 72: 36373 Trace/BPT trap          "${ROOT}/bin/
> magma.exe" $*
>
> sage subshell$ echo $DYLD_LIBRARY_PATH
> /Users/Kwankyu/Sage/local/lib/R/lib:/Users/Kwankyu/Sage/local/lib/
> openmpi:/Users/Kwankyu/Sage/local/lib/:::/Users/Kwankyu/Sage/local/lib/
> R/lib
>
> sage subshell$ DYLD_LIBRARY_PATH=""
>
> sage subshell$ magma
> Magma V2.16-6     Fri Mar 19 2010 17:22:06 on athena   [Seed =
> 216298470]
> Type ? for help.  Type -D to quit.
>
> Loading startup file "/Users/Kwankyu/.magmarc"
>
>>
>
>
> I wonder what should be done to solve this problem.
>
>
> Kwankyu
>

magma_console() should be changed to use sage-native-execute.

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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] proposal: standard command-line options in Sage

2010-03-19 Thread Dan Drake

On Fri, 19 Mar 2010 at 12:52AM -0700, William Stein wrote:
> The main issue I see is that using getopt or optparse means that the
> "local/bin/sage-sage" script will go from not depending on Python to
> depending on Python.  This may cause trouble for the build system, and
> may slow down commands such as "sage -gp", since doing "sage -gp" now
> means also starting Python, in addition to Pari.

Good point -- although Python does start very fast. I see that bash has
a "getopts" builtin, although it doesn't do --style arguments. I
downloaded shflags, which Tim suggested, and using it amounts to sourcing a
31KB shell library, which seems like a pretty reasonable, uh, option --
check out http://code.google.com/p/shflags/wiki/Documentation10x

Dan

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

signature.asc
Description: Digital signature

[sage-devel] Latest Magma fails to load

2010-03-19 Thread Kwankyu Lee

Hi,

In Mac OS, latest Magma v2.16-6 fails to load under Sage 4.3.3, with
the following error message:

sage: magma_console()
dyld: Library not loaded: @executable_path/libgmp.3.dylib
  Referenced from: /Applications/Magma/bin/magma.exe
  Reason: Incompatible library version: magma.exe requires version
9.0.0 or later, but libgmp.3.dylib provides version 8.0.0
/usr/bin/magma: line 72: 16880 Trace/BPT trap  "${ROOT}/bin/
magma.exe" $*

I investigated this issue a bit. The reason of the failure is that
Sage defines the variable DYLD_LIBRARY_PATH when it executes Magma. If
you undefine it or define it to point to the right place, then there
is no problem, as you see below.

sage subshell$ magma
dyld: Library not loaded: @executable_path/libgmp.3.dylib
  Referenced from: /Applications/Magma/bin/magma.exe
  Reason: Incompatible library version: magma.exe requires version
9.0.0 or later, but libgmp.3.dylib provides version 8.0.0
/usr/bin/magma: line 72: 36373 Trace/BPT trap  "${ROOT}/bin/
magma.exe" $*

sage subshell$ echo $DYLD_LIBRARY_PATH
/Users/Kwankyu/Sage/local/lib/R/lib:/Users/Kwankyu/Sage/local/lib/
openmpi:/Users/Kwankyu/Sage/local/lib/:::/Users/Kwankyu/Sage/local/lib/
R/lib

sage subshell$ DYLD_LIBRARY_PATH=""

sage subshell$ magma
Magma V2.16-6 Fri Mar 19 2010 17:22:06 on athena   [Seed =
216298470]
Type ? for help.  Type -D to quit.

Loading startup file "/Users/Kwankyu/.magmarc"

>


I wonder what should be done to solve this problem.


Kwankyu



-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: f95 in cvxopt --- still needed? f77blas?

2010-03-19 Thread Dima Pasechnik

Thanks.
A related question: is it possible to get rid of f77blas dependency?
It seems that its functionality is not needed, as it can be replaced
by
other libraries that come with Sage.

Dima

On Mar 19, 1:41 pm, William Stein  wrote:
> 2010/3/18 Dima Pasechnik :
>
> > I am preparing cvxopt-1.1.2 spkg upgrade, and see that the current
> > cvxopt (0.9) has some special hooks to work with f95.
> > Can these be ignored and removed now, as gfortran is there anyway?
>
> On some platforms g95 is still installed, though not for most.  E.g.,
> I just checked my latest OS X 10.5 PPC build, and it has g95.
> Probably the only platforms that get g95 are older OS X.
>
> William
>
> > If not, please tell me how (and where --- if it's not possible under
> > usual Linux, or, as a last resort, MacOSX PPC or sola...@t2) I can
> > test with f95.
> > Thanks,
> > Dima
>
> > --
> > 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 
> > athttp://groups.google.com/group/sage-devel
> > URL:http://www.sagemath.org
>
> > To unsubscribe from this group, send email to 
> > sage-devel+unsubscribegooglegroups.com or reply to this email with the 
> > words "REMOVE ME" as the subject.
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] Re: proposal: standard command-line options in Sage

On Fri, Mar 19, 2010 at 12:54 AM, Adam Webb  wrote:
>
>
> On Mar 19, 5:05 am, John H Palmieri  wrote:
>> Sage uses non-standard command-line options (e.g., -notebook rather
>> than --notebook). I propose that we switch to standard ones. Here are
>> two reasons:
>>
>> 1. They're standard, and standards are good. People used to Unix-type
>> systems will expect our options to work this way.  I think if we
>> decide to continue not using the standard format, we should have a
>> good reason.
>>
>> 2. If we use standard command-line options, we can use an existing
>> command-line parser, like Python's optparse, instead of having our own
>> home-grown version (in SAGE_ROOT/local/bin/sage-sage). A standard
>> Python library package is likely to be more robust than something home-
>> grown. For example, we can solve trac ticket #21 (and the related
>> ticket #180) this way. For another example, note that "sage -merge"
>> works but "sage --merge" doesn't; this sort of thing can be fixed on a
>> case-by-case basis, but it's harder to even introduce such
>> inconsistencies with optparse.
>>
>
> I think it is a great idea.
>
>>
>> - what is "sage -darcs" supposed to do? I don't know what "darcs" is,
>> and I don't see any packages which seem relevant.
>>
>
> I assume this refers to the distributed source code management.
> (http://darcs.net/) Perhaps someone was thinking of it as an
> alternative to mercurial. It does have an interesting theory of
> patches.

It was included in Sage and we used it for everything from about Feb
2006 to sometime in 2007.
In 2006, Mercurial wasn't mature enough.

>> - what about "sage -axiom"? What package installs axiom?  Fricas?
>>
>
> This is leftover from when fricas used to use the name axiom as a
> synonym. This is no longer the case. If axiom is installed globally it
> will be used. There is no spkg for it but there are optional tests
> that assume the presence of axiom.
>
> Adam
>
>> For any of these, we have several choices: (1) delete them, (2) keep
>> them, (3) keep them but don't document them (don't list them when you
>> type "sage --advanced"), (4) ??
>>
>> --
>> 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
>
> To unsubscribe from this group, send email to 
> sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
> "REMOVE ME" as the subject.
>



-- 
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+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: proposal: standard command-line options in Sage

2010-03-19 Thread Adam Webb



On Mar 19, 5:05 am, John H Palmieri  wrote:
> Sage uses non-standard command-line options (e.g., -notebook rather
> than --notebook). I propose that we switch to standard ones. Here are
> two reasons:
>
> 1. They're standard, and standards are good. People used to Unix-type
> systems will expect our options to work this way.  I think if we
> decide to continue not using the standard format, we should have a
> good reason.
>
> 2. If we use standard command-line options, we can use an existing
> command-line parser, like Python's optparse, instead of having our own
> home-grown version (in SAGE_ROOT/local/bin/sage-sage). A standard
> Python library package is likely to be more robust than something home-
> grown. For example, we can solve trac ticket #21 (and the related
> ticket #180) this way. For another example, note that "sage -merge"
> works but "sage --merge" doesn't; this sort of thing can be fixed on a
> case-by-case basis, but it's harder to even introduce such
> inconsistencies with optparse.
>

I think it is a great idea.

>
> - what is "sage -darcs" supposed to do? I don't know what "darcs" is,
> and I don't see any packages which seem relevant.
>

I assume this refers to the distributed source code management.
(http://darcs.net/) Perhaps someone was thinking of it as an
alternative to mercurial. It does have an interesting theory of
patches.

> - what about "sage -axiom"? What package installs axiom?  Fricas?
>

This is leftover from when fricas used to use the name axiom as a
synonym. This is no longer the case. If axiom is installed globally it
will be used. There is no spkg for it but there are optional tests
that assume the presence of axiom.

Adam

> For any of these, we have several choices: (1) delete them, (2) keep
> them, (3) keep them but don't document them (don't list them when you
> type "sage --advanced"), (4) ??
>
> --
> 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

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [sage-devel] proposal: standard command-line options in Sage