[sage-devel] Re: Opinions needed - method names for cones and fans

[Volker Braun]

Good point! Here is a snapshot of the current documentation:

http://www.stp.dias.ie/~vbraun/Sage/html/en/reference/sage/geometry/cone.html#sage.geometry.cone.ConvexRationalPolyhedralCone.M_quotient_basis

Right now, I'm essentially using abbreviations N="spanned_lattice" and
M="spanned_lattice_dual" in the method names. If we use long method
names, should the documentation also be rewritten to not refer to N/M
lattices?

Volker

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

[sage-devel] two Singular spkg's in Sage 4.4.4

[Minh Nguyen]

Hi folks,

While preparing the release note for Sage 4.4.4, I noticed that Sage
4.4.4 has two Singular spkg's:

[1] singular-3-1-0-4-20100214.spkg
[2] singular-3.1.0.4.p6.spkg

The first one is a remnant from Sage 4.4.3, while the second was added
in Sage 4.4.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

Re: [sage-devel] Test your Python build

[Dr. David Kirkby]

On 06/24/10 01:26 AM, Alex Ghitza wrote:


Hi David,

On Wed, 23 Jun 2010 22:24:44 +0100, "Dr. David Kirkby" 
 wrote:

So far, on 3 systems where this has been tested, there are 5 failures on each,
though the 5 failures differ between systems - with one exception
(test_distutils) which seems to fail on all systems.


On:

[ghi...@artin ~]$ uname -a
Linux artin 2.6.34-ARCH #1 SMP PREEMPT Sat Jun 19 00:07:49 CEST 2010
x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux

I got the following:

1 test failed:
 test_distutils


Best,
Alex



You are doing better than most. But *everyone* gets that failure. I don't know 
how critical that is in Sage, but either the test is broken on that part of 
Python is broken in Sage.


Dave

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

Re: [sage-devel] two Singular spkg's in Sage 4.4.4

[Dr. David Kirkby]

On 06/24/10 09:07 AM, Minh Nguyen wrote:

Hi folks,

While preparing the release note for Sage 4.4.4, I noticed that Sage
4.4.4 has two Singular spkg's:

[1] singular-3-1-0-4-20100214.spkg
[2] singular-3.1.0.4.p6.spkg

The first one is a remnant from Sage 4.4.3, while the second was added
in Sage 4.4.4.



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

was a ticket of mine that added singular-3.1.0.4.p6.spkg. However, it has had 
some changes I did not make too.


As long as the time stamps of the old and new versions are ok, it should not be 
a problem, other than to add a bit of bulk.



Note, I renamed the package and put a .p6, to be consistent with the developers 
guide. I removed the date.


Previously people seemed to be incrementing the date each time the package was 
modified. I worked out it had been modified 7 times, so should have been a .p6, 
so that is why the name has changed more than usual.


Dave

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

Re: [sage-devel] two Singular spkg's in Sage 4.4.4

[William Stein]

On Thu, Jun 24, 2010 at 1:39 AM, Dr. David Kirkby
 wrote:
> On 06/24/10 09:07 AM, Minh Nguyen wrote:
>>
>> Hi folks,
>>
>> While preparing the release note for Sage 4.4.4, I noticed that Sage
>> 4.4.4 has two Singular spkg's:
>>
>> [1] singular-3-1-0-4-20100214.spkg
>> [2] singular-3.1.0.4.p6.spkg
>>
>> The first one is a remnant from Sage 4.4.3, while the second was added
>> in Sage 4.4.4.
>>
>
> http://trac.sagemath.org/sage_trac/ticket/9160
>
> was a ticket of mine that added singular-3.1.0.4.p6.spkg. However, it has
> had some changes I did not make too.
>
> As long as the time stamps of the old and new versions are ok, it should not
> be a problem, other than to add a bit of bulk.

Time stamps are irrelevant for the sage build system.  What matters is
how the files sort in alphabetical order.  In any case, the one that
does get installed is:

  singular-3.1.0.4.p6

which is the right one.

William

>
>
> Note, I renamed the package and put a .p6, to be consistent with the
> developers guide. I removed the date.
>
> Previously people seemed to be incrementing the date each time the package
> was modified. I worked out it had been modified 7 times, so should have been
> a .p6, so that is why the name has changed more than usual.
>
> 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
>



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

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

Re: [sage-devel] Test your Python build

[Dr. David Kirkby]

On 06/24/10 09:29 AM, Dr. David Kirkby wrote:

On 06/24/10 01:26 AM, Alex Ghitza wrote:



I got the following:

1 test failed:
test_distutils


Best,
Alex



You are doing better than most. But *everyone* gets that failure. I
don't know how critical that is in Sage, but either the test is broken
on that part of Python is broken in Sage.

Dave



Sorry, that did not make a lot of sense.


First, everyone who has tested that package in Sage sees that failure.

Secondly, either

* The distutils test is broken
* Distutils in Python is broken.
* One of the modifications done to Python in Sage has broken disutils.

A few failures are observed on OS X, Solaris and OpenSolaris. Those failures 
have always included test_distutils.


If I recall correctly, there are some odd comments on some tickets about 
workaround being applied because distutils is broken, though I might be 
confusing it with another aspect of Python.



I was rather hoping that Python would get merged, so everyone could test their 
Python in Sage, but unfortunately the ticket did not get merged, despite the 
positive review. So if anyone wants to check their Python build, they will need 
to download


http://boxen.math.washington.edu/home/kirkby/revised-patches/python-2.6.4.p9.spkg

Dave

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

Re: [sage-devel] Test your Python build

[Alex Ghitza]

On Thu, 24 Jun 2010 09:29:57 +0100, "Dr. David Kirkby" 
 wrote:
> On 06/24/10 01:26 AM, Alex Ghitza wrote:
> > On:
> >
> > [ghi...@artin ~]$ uname -a
> > Linux artin 2.6.34-ARCH #1 SMP PREEMPT Sat Jun 19 00:07:49 CEST 2010
> > x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
> >
> > I got the following:
> >
> > 1 test failed:
> >  test_distutils
> 
> You are doing better than most. But *everyone* gets that failure. I don't 
> know 
> how critical that is in Sage, but either the test is broken on that part of 
> Python is broken in Sage.

I was curious about this so I downloaded python-2.6.5 and built and
tested it separately.  Once again there is one test failure, but it's
not test_distutils, rather test_zlib.  This is where my curiosity ends :)


Best,
Alex

-- 
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

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

Re: [sage-devel] Test your Python build

[François Bissey]

> On 06/24/10 09:29 AM, Dr. David Kirkby wrote:
> > On 06/24/10 01:26 AM, Alex Ghitza wrote:
> >> I got the following:
> >> 
> >> 1 test failed:
> >> test_distutils
> >> 
> >> 
> >> Best,
> >> Alex
> > 
> > You are doing better than most. But *everyone* gets that failure. I
> > don't know how critical that is in Sage, but either the test is broken
> > on that part of Python is broken in Sage.
> > 
> > Dave
> 
> Sorry, that did not make a lot of sense.
> 
> 
> First, everyone who has tested that package in Sage sees that failure.
> 
> Secondly, either
> 
> * The distutils test is broken
> * Distutils in Python is broken.
> * One of the modifications done to Python in Sage has broken disutils.
> 
> A few failures are observed on OS X, Solaris and OpenSolaris. Those
> failures have always included test_distutils.
> 
> If I recall correctly, there are some odd comments on some tickets about
> workaround being applied because distutils is broken, though I might be
> confusing it with another aspect of Python.
> 
> 
Hi Dave,

>From the current python ebuild in gentoo:
# Skip all tests that fail during emerge but pass without emerge:
# (See bug #67970)
local skip_tests="distutils httpservers minidom pyexpat sax tcl"

The bug in question hasn't been touched since 2006 so it is a long standing
issue that no one has looked in a long time. 
http://bugs.gentoo.org/show_bug.cgi?id=67970
The strange thing is going manually in the concerned folder and running
make test from there works. Could you check that it is the case in sage too?

One suggestion was some failures were due the environment variable  
PYTHON_DONTCOMPILE set to 1 during the build but I am not sure that
would apply in sage.

Francois

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

Re: [sage-devel] two Singular spkg's in Sage 4.4.4

[Dr. David Kirkby]

On 06/24/10 09:50 AM, William Stein wrote:

On Thu, Jun 24, 2010 at 1:39 AM, Dr. David Kirkby
  wrote:

On 06/24/10 09:07 AM, Minh Nguyen wrote:


Hi folks,

While preparing the release note for Sage 4.4.4, I noticed that Sage
4.4.4 has two Singular spkg's:

[1] singular-3-1-0-4-20100214.spkg
[2] singular-3.1.0.4.p6.spkg

The first one is a remnant from Sage 4.4.3, while the second was added
in Sage 4.4.4.



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

was a ticket of mine that added singular-3.1.0.4.p6.spkg. However, it has
had some changes I did not make too.

As long as the time stamps of the old and new versions are ok, it should not
be a problem, other than to add a bit of bulk.


Time stamps are irrelevant for the sage build system.  What matters is
how the files sort in alphabetical order.  In any case, the one that
does get installed is:

   singular-3.1.0.4.p6

which is the right one.

William


Oh, thank you for that. I was not aware of that.

Anyway, it does not look a serious issue and should be easy to resolve next 
time. (I think there might be others who want to update Singular too next time). 
They will hopefully just make a .p7.


Dave

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

Re: [sage-devel] Re: Some Bugfixes in sage-preparse

[David Poetzsch-Heffter]

> On 6/23/10 6:05 AM, David Poetzsch-Heffter wrote:
>> Hi!
>>
>> I found (and fixed) a few Bugs in the file local/bin/sage-preparse.
>>
>> These are the things I fixed:
>>
>> * The module docstrings disappeared when preparsing because the
>> preparse_file function inserted those numeric_literals definitions
>> before
>> the docstrings.
>
> This sounds like it may cause another problem I noticed the other day.
> When doing:
>
> from __future__ import division
> 3.5/2.0
>
> in a Sage notebook cell, we get the error:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "_sage_input_6.py", line 10, in 
>  exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8
> -*-\\n" +
> _support_.preparse_worksheet_cell(base64.b64decode("ZnJvbSBfX2Z1dHVyZV9fIGltcG9ydCBkaXZpc2lvbgoKMy41LzIuMA=="),globals())+"\\n");
> execfile(os.path.abspath("___code___.py"))
>File "", line 1, in 
>
>File "/tmp/tmp89rHOA/___code___.py", line 3
>  from __future__ import division
> SyntaxError: from __future__ imports must occur at the beginning of the
> file
>
> Do you know if your patch fixes this issue?
>
>
> Thanks,
>
> Jason

No, my patch does not fix this issue. But a workarount that works fine for
me is to split the two commands into two cells.

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

[sage-devel] Did all the SAGE_PARALLEL_SPKG_BUILD code get merged in 4.4.4?

[Dr. David Kirkby]

Mitesh Patel has done a lot of work to get Sage to build .spkg files in 
parallel, which should really speed up builds on modern multi-core machines.


Did all the code get merged,

$ export SAGE_PARALLEL_SPKG_BUILD=yes

should build the packages in parallel?

I thought it was all merged, but I don't seem to be noticing packages building 
in parallel.


It would be really good to get all this code merged, if it has not already been 
done.


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

[sage-devel] Please add an spkg-check file if updating packages.

[Dr. David Kirkby]

Some (about 20%) of .spkg files in Sage have a file spkg-check, which runs a 
test suite if one runs


$ export SAGE_CHECK=yes
$ make

About 80% of Sage packages do not have an spkg-check file, which means the code 
can't be tested even if there is a test suite. I added a few spkg-check files 
which got merged in 4.4.4, but there are still tons missing, and adding them is 
really boring. But if you are updating a package, it is not so bad to spend a 
few minutes and add it.


Not all the upstream code has test code unfortunately.

A typical content would be that below. Running just 'make test' will sometimes 
fail unless the compiler flags are set correctly. On other packages, it does not 
matter, but it is safest to assume it does matter - it depends on whether or not 
'make test' or 'make check' needs anything to be compiled or not.


Of course, doc tests do perform tests in Sage, but they rarely extend to testing 
much of the packages in Sage.


Dave

--
A typical spkg-check, which needs to go into the same directory as spkg-install 
and SPKG.txt is below.


#!/usr/bin/env bash


if [ -z $SAGE_LOCAL ]; then
   echo "SAGE_LOCAL undefined ... exiting";
   echo "Maybe run 'sage -sh'?"
   exit 1
fi


# Let the user set an environment variable CFLAG64 to indicate the flag
# for the C compiler to build 64-bit code. If not set, assume it is -m64
# as that is what is used by both GCC and SunStudio, but -m64 is not used
# by IBM's compiler on AIX or HP's compiler on HP-UX

if [ -z $CFLAG64 ] ; then
  CFLAG64=-m64 # -m64 is used by gcc and SunStudio.
fi

# Likewise to build C++ code.
if [ -z $CXXFLAG64 ] ; then
  CXXFLAG64=-m64 # -m64 is used by gcc and SunStudio.
fi

if [ "x$SAGE64" = xyes ] ; then
   CFLAGS="$CFLAGS $CFLAG64" && export CFLAGS
   CXXFLAGS="$CXXFLAGS $CXXFLAG64" && export CXXFLAGS
   LDFLAGS="$LDFLAGS $CFLAG64" && export LDFLAGS
   CPPFLAGS="$CPPFLAGS $CFLAG64" && export CPPFLAGS # Very rare is CPPFLAGS nee
ded, but sometimes it is.
fi

cd src

echo "FOOBAR will now be tested"

make check # It might be 'make test' in some cases.

if [ $? -ne 0 ]; then
echo "An error occurred whilst testing FOOBAR"
exit 1
fi

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

Re: [sage-devel] Re: Opinions needed - method names for cones and fans

[Dr. David Kirkby]

On 06/23/10 11:39 PM, Volker Braun wrote:

The difference between the toric lattice computations and the root
lattices is that the (co)weight lattices are one of the main features
of interest to the end user, while the various toric lattices are
mostly of internal use for computing something else.

I don't have a strong opinion against long-style names except that
there will be some very long names to accommodate some often-used
constructions. If nobody minds

cone.spanned_lattice_dual_quotient_by_spanned_lattice_dual_basis(supercone)

then I'll be happy to change things. Right now its
cone.M_quotient_basis(supercone) which, I agree, is not as self-
explanatory. But then, this is not something that you are dying to
compute on a normal day.

Volker


I'd prefer longer names in general. The tab completion should help reduce 
excessive typing, whilst the longer name makes it clearer what it is (or it 
would to a mathematician - it means nothing to me personally)



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

[sage-devel] Re: Some Bugfixes in sage-preparse

[David Poetzsch-Heffter]

I opened a trac ticket including the patch here:

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

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

[sage-devel] Suggestion to make reporting bugs upstream MANDATORY for Positive review.

[Dr. David Kirkby]

Here's a suggestion, which I think could be useful.

If a reviewer sees that a bug on trac is an upstream bug, that they are required 
to see evidence that this has been reported upstream before the fix gets a 
positive review.


Hence

AUTHOR
MUST state he has reported the bug upstream, and if so how. Sometimes that will 
be an email, but the ticket needs to say who it was emailed to and what date.


Better still, if its a bug like in ATLAS, Python etc, where there is an online 
database, post a link to that.


REVIEWER
MUST NOT GIVE POSITIVE REVIEW unless he/she is satisfied a bug has reported 
upstream when appropriate.


This will have several advantages in the long run.

1) Everyone (not just Sage developers) will benefit if a bug gets fixed 
upstream.

2) If the upstream developers say it is not a bug, then we should investigate in 
Sage whether or not there was perhaps a mistake in the bug fix.


3) When new releases of the upstream packages are made, they should have less 
bugs that Sage needs to work around.


4) If it becomes clear that we don't know who to report the bug to, that would 
need fixing in SPKG.txt


Obviously many bugs in Sage have nothing to do with upstream packages, in which 
case this would not apply. But where the bug is clearly an upstream one, IMHO we 
make reporting it upstream a necessary condition before a positive review can be 
given.


Does anyone have any comments?

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

[sage-devel] gcc_fake in numpy - I've wasted countless hours on this!

[Dr. David Kirkby]

William said the other day he was not aware of any fake gcc's. Well numpy has a 
really dumb one, which looks like someone tried to work around 64-bit issues at 
some time in the past.



drkir...@hawk:~/sage-4.4.2/spkg/standard/numpy-1.3.0.p3$ cat gcc_fake
#!/bin/bash
/usr/bin/gcc -m64 $@


now on my machine, /usr/bin/gcc is only version 3.4.3

drkir...@hawk:~/sage-4.4.2/spkg/standard/numpy-1.3.0.p3$ /usr/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure 
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc 
--enable-shared

Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)


I can't find any trac ticket which references gcc_fake, and there is no record 
of it in SPKG.txt, but someone had the great idea of hard-coding the path to gcc 
like that.


Tracking down build problems is very difficult when there are fake gcc's and 
fake fortrans. I wish Sage could build without needing to resorting to such tricks.




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

[sage-devel] Re: Test your Python build

[Adam Webb]

Hi,

I get two test errors on Scientific Linux 5.1 (32 bit).
test_grp and test_distutils

test_grp is a normal problem on this system.

test test_grp failed -- Traceback (most recent call last):
  File "/home/math/sage/spkg/build/python-2.6.4.p9/src/Lib/test/
test_grp.py", line 32, in test_values
e2 = grp.getgrgid(e.gr_gid)
KeyError: 'getgrgid(): gid not found: -2'

This is known problem that getgrgid() does not handle negative
numbers. http://bugs.python.org/issue1465646

test_distutils passes if I use a plain python 2.6.5 tarball. This is
consistent with the problem being in Sage or at least in the
environment used for building packages.

Adam

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

[sage-devel] Re: Suggestion to make reporting bugs upstream MANDATORY for Positive review.

[Volker Braun]

Probably makes sense for bugs that produce obviously wrong results,
but what about bugs in the makesystem / autotools abuse / enabling of
shared libraries?

1) Sometimes you only have time for a quick build fix where doing
things right might require a major effort.

2) Testing, say, new autotools through a Sage release is a great way
to ensure that it builds on all platforms.

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

Re: [sage-devel] Re: Test your Python build

[Dr. David Kirkby]

On 06/24/10 04:14 PM, Adam Webb wrote:


test_distutils passes if I use a plain python 2.6.5 tarball. This is
consistent with the problem being in Sage or at least in the
environment used for building packages.

Adam



That's interesting!

So far everyone seems to see this.

* You on Scientific Linux
* Me on OpenSolaris
* Me on Solaris 10
* Alex Ghitza on what I think is probably archlinux though I'm not sure.
* Francois on Gentoo.

So perhaps there is something screwy about how Sage builds Python that causes 
this failure.


The Python package has many patches in Sage. Perhaps one of those is faulty.

Dave

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

Re: [sage-devel] Re: Suggestion to make reporting bugs upstream MANDATORY for Positive review.

[Dr. David Kirkby]

On 06/24/10 04:20 PM, Volker Braun wrote:

Probably makes sense for bugs that produce obviously wrong results,
but what about bugs in the makesystem / autotools abuse / enabling of
shared libraries?


I don't fully understand you here.

Sometimes it is difficult to really get to  the bottom of a problem, but that is 
no reason it should not be reported upstream.


I think the contact should be made with the developers of the code that presents 
the problem.


If they make use of broken version of autoconf or automake, then they should at 
least be aware the code they are distributing is broken.


If it is proved to be a compiler bug, it should be reported to the gcc list.


1) Sometimes you only have time for a quick build fix where doing
things right might require a major effort.


Unfortunately that is far too common in Sage (see my post about the gcc_fake and 
numpy. Someone's quck fix is someone elses big problem - especially when they 
don't even document their quick fix)


I think there needs to be a separation between:

1) Letting the upstream developers know there is a problem.

2) Providing the upstream developers with a fully professional patch, tested on 
a wide range of platforms.


I was only suggesting that (1) is mandatory. (2) would be nice of course, but 
that may often not be practical.


My feeling is that if you find a problem in code, fix it (however good/bad you 
do it), then the *problem* should be reported upstream. Until such time as the 
problem has been reported, a positive review should not be given.



If everyone did that, a lot more problems would be reported upstream I feel.


2) Testing, say, new autotools through a Sage release is a great way
to ensure that it builds on all platforms.


I don't really see how that is related to my post.

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

[sage-devel] Clickable OS X app for 4.4.4

[Ivan Andrus]

I don't know if there is work being done to create the clickable applications 
for OS X for this release (I know being release manager is hard enough), so I 
took the liberty of creating one, for intel at least.  I created them on my 
MacBook Pro:

Darwin parduc.home 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 
2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 i386

OS X 10.6.4
SAGE64=yes
SAGE_CHECK=yes

MacPorts installed, but removed from PATH while building sage (I hope this 
doesn't cause any problems, but it does make me a little nervous).  I'm also 
worried that they may not work on 10.5/10.4.

I created the "normal" application with sage -bdist, as well as a different dmg 
with the new "experimental" SageMenu.app.  The latter should be considered 
somewhat experimental (though much nicer IMHO).  If you don't like it or it 
doesn't work, it's easy to get the sage folder out of it, so it won't be a 
wasted download.  It would also be really great to get some feedback as to 
whether we are going down the right road  with this application.

But here's the catch, I don't have a place that I feel comfortable hosting 2 
files that are so big.  Any ideas as to where I should put them?

-Ivan

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

[sage-devel] Numpy bug / Python distutils might be related

[Dr. David Kirkby]

If you look at the thread "Test your Python build" you will see

* Everyone so far gets a test failure of "distutils" if they use my Python 
package at


http://boxen.math.washington.edu/home/kirkby/revised-patches/python-2.6.4.p9.spkg

which allows Python to be tested.

* Adam web says he does not get this failure with a plain python 2.6.5


If you then look at that thread

"gcc_fake in numpy - I've wasted countless hours on this!"

you will see I got frustrated with the gcc_fake in numpy. Reading Numpy's 
spkg-install I see this, just before the hack with the fake gcc.


# numpy's distutils is buggy and runs a conftest without
# taking CFLAGS into account. With 64 bit OSX this results
# in *boom*

*Perhaps* (and I've not looked at this yet), the reason Numpy needs a fake gcc 
is that really the distutils in python is not working in Sage.


I'm sure I've seen other things mentioned in Sage that are believed to be due to 
distutils.


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

[sage-devel] can't build PDF version of reference manual in Sage 4.4.4

[Minh Nguyen]

Hi folks,

In Sage 4.4.4, I can't build the PDF version of the reference manual,
even though the HTML version builds fine. Here is the error messsage:

Overfull \hbox (41.96407pt too wide) in paragraph at lines 73487--73489
[]\T1/pcr/m/n/10 MyClass2.__classcall__() \T1/ptm/m/n/10 should re-turn the re-
sult of \T1/pcr/m/n/10 UniqueRepresentation.__classcall__()
[890]
! TeX capacity exceeded, sorry [input stack size=5000].
\reser...@a ->\def \reser...@a
   *{\...@assign@i {...@tempskipb }}\reser...@a
l.73597 ...{UniqueRepresentation}} and unpickling}

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on reference.log.
make: *** [reference.pdf] Error 1


This is traced to ticket #9106:

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

With the current situation as is, there is no PDF version of the
reference manual on the Sage website for downloading.

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

[sage-devel] Re: Did all the SAGE_PARALLEL_SPKG_BUILD code get merged in 4.4.4?

[John H Palmieri]

On Jun 24, 2:31 am, "Dr. David Kirkby" 
wrote:
> Mitesh Patel has done a lot of work to get Sage to build .spkg files in
> parallel, which should really speed up builds on modern multi-core machines.
>
> Did all the code get merged,
>
> $ export SAGE_PARALLEL_SPKG_BUILD=yes
>
> should build the packages in parallel?
>
> I thought it was all merged, but I don't seem to be noticing packages building
> in parallel.
>
> It would be really good to get all this code merged, if it has not already 
> been
> done.

It's at



It hasn't been merged.  Several of the spkg prerequisites with
positive reviews weren't merged, but there is also one which still
needs review:



It doesn't look hard to review.

--
John


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

[sage-devel] Souvigner optional package does not exist?

[Anna Haensch]

Hello, this is my first post, and I'm very new to Sage.  I appreciate
any help anyone might offer.

The file sage/quadratic_forms/quadratic_forms_equivalence_testing.py
asks for an optional Souvigner package.  it looks like this package
might not exist.  Here's the link to the track posted about a year
ago.

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

Any suggestions?

-Anna

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

Re: [sage-devel] GLPK Package - needs extensive testing

[Robert Miller]

> I guess someone should open a ticket for this to be added as a standard
> package, then it tested extensively before being committed.

A few things should happen before we make this a standard spkg. First,
I think we should merge all the newly-positive-reviewed graph theory
tickets using LP, to make sure that they all play well together. Next
I think we should (after some testing) move your spkg to optional,
i.e. have GLPK-4.44 be optional for a short time first, to shake out
any issues that might crop up. Finally, once the dust has settled it
will be time to move the updated spkg to standard.



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

[sage-devel] Re: coverage question

[John H Palmieri]

On Jun 23, 11:41 pm, John Cremona  wrote:
> Doesn't adding
> # not tested
> work?

Yes, but I suppose this is cheating, too.  On the one hand, this
particular code is completely trivial (and it calls the method
"_open", which is doctested), so not testing it but pretending that we
do is not so bad.  On the other hand, adding "# not tested" everywhere
gives us a quick path to meaningless 100% doctest coverage :)

  John

> On 23 June 2010 13:39, John H Palmieri  wrote:
>
>
>
> > In the file misc/sagedocs.py, there are some methods which are one-
> > liners: they just open up a piece of the documentation in a web
> > browser:
>
> >    def tutorial(self):
> >        """
> >        The Sage tutorial.  To get started with Sage, start here.
> >        """
> >        self._open("tutorial")
>
> > How can this be doctested?
>
> > Is it cheating to replace it with
>
> >    tutorial = lambda self: self._open("tutorial")
>
> > so it doesn't count against coverage?  Any other ideas?
>
> > --
> > 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 
> > athttp://groups.google.com/group/sage-devel
> > URL:http://www.sagemath.org

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

[sage-devel] Re: gcc_fake in numpy - I've wasted countless hours on this!

[Ryszard Wojciechowski]

#3186 - fix 64 bit OSX build support for numpy

On 24 Cze, 16:59, "Dr. David Kirkby"  wrote:
> William said the other day he was not aware of any fake gcc's. Well numpy has 
> a
> really dumb one, which looks like someone tried to work around 64-bit issues 
> at
> some time in the past.
>
> drkir...@hawk:~/sage-4.4.2/spkg/standard/numpy-1.3.0.p3$ cat gcc_fake
> #!/bin/bash
> /usr/bin/gcc -m64 $@
>
> now on my machine, /usr/bin/gcc is only version 3.4.3
>
> drkir...@hawk:~/sage-4.4.2/spkg/standard/numpy-1.3.0.p3$ /usr/bin/gcc -v
> Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
> Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
> --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
> --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc
> --enable-shared
> Thread model: posix
> gcc version 3.4.3 (csl-sol210-3_4-20050802)
>
> I can't find any trac ticket which references gcc_fake, and there is no record
> of it in SPKG.txt, but someone had the great idea of hard-coding the path to 
> gcc
> like that.
>
> Tracking down build problems is very difficult when there are fake gcc's and
> fake fortrans. I wish Sage could build without needing to resorting to such 
> tricks.
>
> Dave

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

Re: [sage-devel] Souvigner optional package does not exist?

[Robert Miller]

Anna,

Welcome to the group!

It looks like this code comes from the following ticket:

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

in which Michael Abshoff comments:

commit 10629 is mostly the AUTO code by Bernd Souvignier - the code
has been made available under a GPL V2+ compatible license, but that
needs to be formalized. It is called via pexpect, but probably can be
called via Cython directly. It is only one file. If we keep using the
pexpect interface it should be moved into its own spkg.

You can see in the file
sage/quadratic_forms/quadratic_forms__automorphisms.py (line ~433)

## Call the Souvigner automorphism code
souvigner_auto_path = SAGE_ROOT + "/local/bin/Souvigner_AUTO"
   ## FIX THIS LATER!!!

Which echoes the ticket you mentioned. There is no Souvigner_AUTO in
local/bin, however. Some quick Googling suggests that this was in
sage-3.3.rc0, but I don't know where the source is (this file is just
a binary file).

His website is here, perhaps someone should contact him:

http://www.math.ru.nl/~souvi/

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

[sage-devel] Re: Souvigner optional package does not exist?

[kcrisman]

On Jun 24, 12:14 pm, Anna Haensch  wrote:
> Hello, this is my first post, and I'm very new to Sage.  I appreciate
> any help anyone might offer.
>
> The file sage/quadratic_forms/quadratic_forms_equivalence_testing.py
> asks for an optional Souvigner package.  it looks like this package
> might not exist.  Here's the link to the track posted about a year
> ago.
>
> http://trac.sagemath.org/sage_trac/ticket/6326
>
> Any suggestions?

See http://trac.sagemath.org/sage_trac/ticket/4470 where mabshoff
says, "Ok, everything works, but some doctests need to be marked
optional since they depend on ISOM:" and 
http://trac.sagemath.org/sage_trac/changeset/f7614d495ff0
for possible clues as to what happened.  Maybe the code is already in
Sage?  What is ISOM?  Anyway, apparently the "AUTO code by Bernd
Souvignier" never became an spkg...

I hope this helps someone track it down.

- kcrisman

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

Re: [sage-devel] Re: Did all the SAGE_PARALLEL_SPKG_BUILD code get merged in 4.4.4?

[Dr. David Kirkby]

On 06/24/10 05:05 PM, John H Palmieri wrote:

On Jun 24, 2:31 am, "Dr. David Kirkby"
wrote:

Mitesh Patel has done a lot of work to get Sage to build .spkg files in
parallel, which should really speed up builds on modern multi-core machines.

Did all the code get merged,

$ export SAGE_PARALLEL_SPKG_BUILD=yes

should build the packages in parallel?

I thought it was all merged, but I don't seem to be noticing packages building
in parallel.

It would be really good to get all this code merged, if it has not already been
done.


It's at



It hasn't been merged.  Several of the spkg prerequisites with
positive reviews weren't merged, but there is also one which still
needs review:



It doesn't look hard to review.

--
John


Thank you John. I've reviewed it, and it is fine. So that has a positive.

It would be good if Mitesh's code for building packages in parallel could be 
merged soon, as it could make a *huge* benefit to users and developers alike.


Of course, I'd like to see my OpenSolaris fixes and others would no doubt like 
to see their fixes. But Mitesh's work should benefit a *lot* of people in a big 
way. Hence I think it should be given priority - even over my own patches!



Dave

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

Re: [sage-devel] Re: gcc_fake in numpy - I've wasted countless hours on this!

[Dr. David Kirkby]

On 06/24/10 05:44 PM, Ryszard Wojciechowski wrote:

#3186 - fix 64 bit OSX build support for numpy


Thank you.

I would have to say, what an idiotic way that was to fix a problem! I don't like 
the idea of a fake gcc, but if one is going to have one, at least it should not 
have had a hard-coded path.


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

[sage-devel] Re: can't build PDF version of reference manual in Sage 4.4.4

[Minh Nguyen]

Hi,

On Fri, Jun 25, 2010 at 2:00 AM, Minh Nguyen  wrote:
> Hi folks,
>
> In Sage 4.4.4, I can't build the PDF version of the reference manual,
> even though the HTML version builds fine. Here is the error messsage:
>
> Overfull \hbox (41.96407pt too wide) in paragraph at lines 73487--73489
> []\T1/pcr/m/n/10 MyClass2.__classcall__() \T1/ptm/m/n/10 should re-turn the 
> re-
> sult of \T1/pcr/m/n/10 UniqueRepresentation.__classcall__()
> [890]
> ! TeX capacity exceeded, sorry [input stack size=5000].
> \reser...@a ->\def \reser...@a
>   *{\...@assign@i {...@tempskipb }}\reser...@a
> l.73597 ...{UniqueRepresentation}} and unpickling}
>
> !  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on reference.log.
> make: *** [reference.pdf] Error 1

The problem can be solved by avoid using "":class:" with "..
rubric::". That is, change the line

.. rubric:: Migrating classes to :class:`UniqueRepresentation` and unpickling

to

.. rubric:: Migrating classes to ``UniqueRepresentation`` and unpickling

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

Re: [sage-devel] GLPK Package - needs extensive testing

[Dr. David Kirkby]

On 06/24/10 05:28 PM, Robert Miller wrote:

I guess someone should open a ticket for this to be added as a standard
package, then it tested extensively before being committed.


A few things should happen before we make this a standard spkg. First,
I think we should merge all the newly-positive-reviewed graph theory
tickets using LP, to make sure that they all play well together. Next
I think we should (after some testing) move your spkg to optional,
i.e. have GLPK-4.44 be optional for a short time first, to shake out
any issues that might crop up. Finally, once the dust has settled it
will be time to move the updated spkg to standard.


That sounds logical.

I'm sorry I needed to make so many changes to it, but the package was seriously 
deficient - it needed a lot more than the SAGE64 sorted out.


* It did not test if the 'configure' script had failed
* If did not test if the 'make' had failed,
* It did not test if 'make install' had failed
* It did not test if 'python setup.py install'' had failed.
* There was no spkg-check to run the test suite.

etc etc.

I think it's pretty clear they were essential changes

The other changes, like linking in gmp and zlib seemed logical for performance 
reasons, as stated in the source code of the package.


Given the number of changes I made, it would seem sensible this undergoes a 
period as an optional package.


Dave

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

Re: [sage-devel] Re: gcc_fake in numpy - I've wasted countless hours on this!

[William Stein]

On Thu, Jun 24, 2010 at 10:17 AM, Dr. David Kirkby
 wrote:
> On 06/24/10 05:44 PM, Ryszard Wojciechowski wrote:
>>
>> #3186 - fix 64 bit OSX build support for numpy
>
> Thank you.
>
> I would have to say, what an idiotic way that was to fix a problem!
> Dave

Patch by Michael Abshoff, giving a positive review by Gary Furnish...

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



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

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

[sage-devel] Re: can't build PDF version of reference manual in Sage 4.4.4

[Minh Nguyen]

Hi,

On Fri, Jun 25, 2010 at 3:30 AM, Minh Nguyen  wrote:



> The problem can be solved by avoid using "":class:" with "..
> rubric::". That is, change the line
>
> .. rubric:: Migrating classes to :class:`UniqueRepresentation` and unpickling
>
> to
>
> .. rubric:: Migrating classes to ``UniqueRepresentation`` and unpickling

A patch is up at ticket #9331:

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

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

[sage-devel] trac workflow

[Robert Miller]

Hello,

I'd like to make some tweaks to the workflow on Sage's trac server, in
particular the annoying fact that you can't go from needs_work to
positive_review (in the case that someone forgets to update the status
when they post in reply to a reviewer). I'm pretty sure I have the
right permissions, but I'm not sure exactly what to do. If someone can
point me to the right file to edit, I can probably figure out the
rest.

Thanks in advance,

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

[sage-devel] Re: can't build PDF version of reference manual in Sage 4.4.4

[kcrisman]

On Jun 24, 1:30 pm, Minh Nguyen  wrote:
> Hi,
>
>
>
>
>
> On Fri, Jun 25, 2010 at 2:00 AM, Minh Nguyen  wrote:
> > Hi folks,
>
> > In Sage 4.4.4, I can't build the PDF version of the reference manual,
> > even though the HTML version builds fine. Here is the error messsage:
>
> > Overfull \hbox (41.96407pt too wide) in paragraph at lines 73487--73489
> > []\T1/pcr/m/n/10 MyClass2.__classcall__() \T1/ptm/m/n/10 should re-turn the 
> > re-
> > sult of \T1/pcr/m/n/10 UniqueRepresentation.__classcall__()
> > [890]
> > ! TeX capacity exceeded, sorry [input stack size=5000].
> > \reser...@a ->\def \reser...@a
> >                               *{\...@assign@i {...@tempskipb }}\reser...@a
> > l.73597 ...{UniqueRepresentation}} and unpickling}
>
> > !  ==> Fatal error occurred, no output PDF file produced!
> > Transcript written on reference.log.
> > make: *** [reference.pdf] Error 1
>
> The problem can be solved by avoid using "":class:" with "..
> rubric::". That is, change the line
>
> .. rubric:: Migrating classes to :class:`UniqueRepresentation` and unpickling
>
> to
>
> .. rubric:: Migrating classes to ``UniqueRepresentation`` and unpickling
>

Just out of curiosity, is that a bug that needs to be reported
upstream to Sphinx/ReST, or was that a bad use of Sphinx/ReST which
isn't documented there (so needs to be reported upstream), or just
something we didn't know about but should have (and doesn't need to be
reported upstream)?  Could this happen with other '..' commands like
warnings?

I feel like a salmon talking about this.

- kcrisman

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

Re: [sage-devel] Re: can't build PDF version of reference manual in Sage 4.4.4

[Minh Nguyen]

Hi kcrisman,

On Fri, Jun 25, 2010 at 4:09 AM, kcrisman  wrote:



> Just out of curiosity, is that a bug that needs to be reported
> upstream to Sphinx/ReST,

I have reported this issue to sphinx-dev:

https://groups.google.com/group/sphinx-dev/

But my email hasn't gone through the moderator(s) yet.

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

Re: [sage-devel] Re: Did all the SAGE_PARALLEL_SPKG_BUILD code get merged in 4.4.4?

[Robert Bradshaw]

On Jun 24, 2010, at 10:06 AM, Dr. David Kirkby wrote:


On 06/24/10 05:05 PM, John H Palmieri wrote:

On Jun 24, 2:31 am, "Dr. David Kirkby"
wrote:
Mitesh Patel has done a lot of work to get Sage to build .spkg  
files in
parallel, which should really speed up builds on modern multi-core  
machines.


Did all the code get merged,

$ export SAGE_PARALLEL_SPKG_BUILD=yes

should build the packages in parallel?

I thought it was all merged, but I don't seem to be noticing  
packages building

in parallel.

It would be really good to get all this code merged, if it has not  
already been

done.


It's at



It hasn't been merged.  Several of the spkg prerequisites with
positive reviews weren't merged, but there is also one which still
needs review:



It doesn't look hard to review.

--
John


Thank you John. I've reviewed it, and it is fine. So that has a  
positive.


It would be good if Mitesh's code for building packages in parallel  
could be merged soon, as it could make a *huge* benefit to users and  
developers alike.


Of course, I'd like to see my OpenSolaris fixes and others would no  
doubt like to see their fixes. But Mitesh's work should benefit a  
*lot* of people in a big way. Hence I think it should be given  
priority - even over my own patches!


BTW, does anyone know how (if?) it handles packages with tuning code?

- 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

Re: [sage-devel] Re: Test your Python build

[François Bissey]

> On 06/24/10 04:14 PM, Adam Webb wrote:
> > test_distutils passes if I use a plain python 2.6.5 tarball. This is
> > consistent with the problem being in Sage or at least in the
> > environment used for building packages.
> > 
> > Adam
> 
> That's interesting!
> 
> So far everyone seems to see this.
> 
> * You on Scientific Linux
> * Me on OpenSolaris
> * Me on Solaris 10
> * Alex Ghitza on what I think is probably archlinux though I'm not sure.
> * Francois on Gentoo.
> 
Just to be clear I was pointing that the test is skipped because it
is known to fail in the "system" package. The snippet I sent is part
of what is in every gentoo system regardless of whether they use
sage or not.
I was pointing out that some python tests are known to fail at the linux
distro level.

Francois

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

Re: [sage-devel] Re: coverage question

[John Cremona]

On 24 June 2010 09:33, John H Palmieri  wrote:
> On Jun 23, 11:41 pm, John Cremona  wrote:
>> Doesn't adding
>> # not tested
>> work?
>
> Yes, but I suppose this is cheating, too.  On the one hand, this
> particular code is completely trivial (and it calls the method
> "_open", which is doctested), so not testing it but pretending that we
> do is not so bad.  On the other hand, adding "# not tested" everywhere
> gives us a quick path to meaningless 100% doctest coverage :)
>

I am definitely not proposing that as a general solution!  In this
case, we could put it in, with a longer comment giving the reasons and
justification.

John



>  John
>
>> On 23 June 2010 13:39, John H Palmieri  wrote:
>>
>>
>>
>> > In the file misc/sagedocs.py, there are some methods which are one-
>> > liners: they just open up a piece of the documentation in a web
>> > browser:
>>
>> >    def tutorial(self):
>> >        """
>> >        The Sage tutorial.  To get started with Sage, start here.
>> >        """
>> >        self._open("tutorial")
>>
>> > How can this be doctested?
>>
>> > Is it cheating to replace it with
>>
>> >    tutorial = lambda self: self._open("tutorial")
>>
>> > so it doesn't count against coverage?  Any other ideas?
>>
>> > --
>> > 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 
>> > athttp://groups.google.com/group/sage-devel
>> > URL:http://www.sagemath.org
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

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

Re: [sage-devel] Re: Test your Python build

[Dr. David Kirkby]

On 06/24/10 08:45 PM, François Bissey wrote:

On 06/24/10 04:14 PM, Adam Webb wrote:

test_distutils passes if I use a plain python 2.6.5 tarball. This is
consistent with the problem being in Sage or at least in the
environment used for building packages.

Adam


That's interesting!

So far everyone seems to see this.

* You on Scientific Linux
* Me on OpenSolaris
* Me on Solaris 10
* Alex Ghitza on what I think is probably archlinux though I'm not sure.
* Francois on Gentoo.


Just to be clear I was pointing that the test is skipped because it
is known to fail in the "system" package. The snippet I sent is part
of what is in every gentoo system regardless of whether they use
sage or not.
I was pointing out that some python tests are known to fail at the linux
distro level.

Francois


I wonder if the problem is fixed in Python 2.6.5, since the test passes for Adam 
with 2.6.5.


The problem with Python in Sage is there are so many patches, that is makes it 
difficult to update. Many patches are copied over Python files - I don't know 
how carefully these changed files have been updated as python has been updated, 
but some are years old. The chances someone has screwed up during that time is 
quite high.


'hg log' shows 68 entries.

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

[sage-devel] Re: Opinions needed - method names for cones and fans

[Andrey Novoseltsev]

On Jun 24, 3:57 am, Volker Braun  wrote:
> Good point! Here is a snapshot of the current documentation:
>
> http://www.stp.dias.ie/~vbraun/Sage/html/en/reference/sage/geometry/c...
>
> Right now, I'm essentially using abbreviations N="spanned_lattice" and
> M="spanned_lattice_dual" in the method names. If we use long method
> names, should the documentation also be rewritten to not refer to N/M
> lattices?
>
> Volker

I think documentation can look like something similar to "Let \sigma
be this cone, N be its ambient lattice, and M its dual. This function
computes the saturation of the sublattice generated by \sigma, i.e.
N(\sigma)=\span(\sigma \cap N." That way the usual notation is used,
but it does not rely on any actual names outside the function.

As for names and trying to keep them reasonably short, how about
following Florent's comment and using

* cone.spanned_lattice
* cone.quotient_lattice
* cone.cospanned_lattice
* cone.coquotient_lattice

(with "_basis" added if functions return bases)? To be consistent, it
would make sense to also add a function

* cone.colattice()

which will be just another way to say cone.lattice().dual()

Andrey

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

Re: [sage-devel] Re: Did all the SAGE_PARALLEL_SPKG_BUILD code get merged in 4.4.4?

[Dr. David Kirkby]

On 06/24/10 07:58 PM, Robert Bradshaw wrote:

On Jun 24, 2010, at 10:06 AM, Dr. David Kirkby wrote:




It would be good if Mitesh's code for building packages in parallel
could be merged soon, as it could make a *huge* benefit to users and
developers alike.

Of course, I'd like to see my OpenSolaris fixes and others would no
doubt like to see their fixes. But Mitesh's work should benefit a
*lot* of people in a big way. Hence I think it should be given
priority - even over my own patches!


BTW, does anyone know how (if?) it handles packages with tuning code?

- Robert


Hi Robert.

I've not seen that addressed, but there are a lot of tickets related to this, to 
it might be mentioned on one of them.


It could get a bit tricky with code that does tuning. But then tuning code has 
the potential for going wrong if you build code on multi-user systems where the 
load can change depending on what others are doing.


Note Mitesh's changes will not affect the default behavior - that will still be 
to build the packages sequentially. One would need to set 
SAGE_PARALLEL_SPKG_BUILD=yes to get the packages to build in parallel.


Personally I think it would be good to get all his changes in at the earliest 
opportunity, so they can get a lot of testing. There's certainly a potential for 
problems, but then there is also the potential to get much faster builds done on 
modern hardware. To me at least, these more risky things are best put into an 
alpha0.


Also, given the large number of packages which needed to be changed, if these 
are not done soon, there will be a lot of rebasing work.


Of course, I'd like to see some of my own changes too - especially the zlib 
(#9008) and python (#9295) updates, but I think Mitesh's work on building 
packages in parallel has the potential to benefit a lot of people. I should 
think almost everyone here has at least two cores, and machines like sage.math 
have 24.


I don't think I'll try a parallel build on my laptop though - I think the thing 
would get red hot with both cores working flat out for a long time.


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

[sage-devel] non-QQ base rings in modular symbols

[Robert Miller]

Today I helped Matt Greenberg solve (I think) a bug in modular symbols.

His complaint was that the following does not work:

sage: M = ModularSymbols(389,2,1,GF(7))
sage: C = M.cuspidal_subspace()
sage: N = C.new_subspace()
sage: D = N.decomposition()
sage: D[1].q_eigenform(10, 'a')

After a while of poking around, the following patch made it work, but
the change does not agree with the documentation of the function. I'd
like advice on the proper way to fix this, and whether not this is
correct:

diff -r 342fcdf4b4d3 sage/modular/modsym/heilbronn.pyx
--- a/sage/modular/modsym/heilbronn.pyx Thu Jun 24 17:16:40 2010 -0700
+++ b/sage/modular/modsym/heilbronn.pyx Thu Jun 24 19:27:36 2010 -0700
@@ -534,6 +534,7 @@
 from sage.matrix.all import matrix
 from sage.rings.all import QQ
 T = matrix(QQ, len(indices), len(P1), sparse=False)
+original_base_ring = R.base_ring()
 if R.base_ring() != QQ:
 R = R.change_ring(QQ)

@@ -593,6 +594,8 @@
 sage.misc.misc.verbose("did reduction using dense multiplication",
t, level=1,
caller_name='hecke_images_gamma0_weight2')

+if original_base_ring != QQ:
+ans = ans.change_ring(original_base_ring)
 return ans



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

[sage-devel] organization hilbert symbol and legendre symbol functions

[aly.dei...@gmail.com]

Hi,
   I have written functions for the hilbert symbol and the legendre
symbol.  It seems reasonable to group them with number fields but they
do not need to be a member functions since they don't require a
reference to the number field.  Where should I put them?

Thanks,
Aly

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

Re: [sage-devel] organization hilbert symbol and legendre symbol functions

[William Stein]

On Thu, Jun 24, 2010 at 9:32 PM, aly.dei...@gmail.com
 wrote:
> Hi,
>   I have written functions for the hilbert symbol and the legendre
> symbol.  It seems reasonable to group them with number fields but they
> do not need to be a member functions since they don't require a
> reference to the number field.  Where should I put them?

Sage-4.4 *already* has top level functions called hilbert_symbol and
legendre_symbol:

sage: hilbert_symbol

sage: legendre_symbol


So it's clear where your functions go.  Just enhance the above
functions so that when they get number field inputs they do the right
thing.  Extend their domains.

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



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

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

[sage-devel] Re: Sage Days 22 / MSRI-UP 2010 T-shirts

[Jamie Weigandt]

Dear All,

Talking with the local printers, we can make Sage Days 22 T-shirts a
reality. The price will be about $11 per shirt. If you want a shirt
and you haven't emailed me already, please do so by 3pm tomorrow
(Friday) so that I can guarantee the shirts get in by the end of the
workshop.

I've gotten some input on the shirt color. Many people want a dark
shirt, and someone suggested dark green for the background, let me
know if there is major opposition to this. The theme of the workshop
is computing with elliptic curves in Sage, so the shirt should feature
this prominently. If you have any relevant ideas or images please post
theme here.

Best,

Jamie

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

Re: [sage-devel] non-QQ base rings in modular symbols

[William Stein]

On Thu, Jun 24, 2010 at 7:28 PM, Robert Miller  wrote:
> Today I helped Matt Greenberg solve (I think) a bug in modular symbols.
>
> His complaint was that the following does not work:
>
> sage: M = ModularSymbols(389,2,1,GF(7))
> sage: C = M.cuspidal_subspace()
> sage: N = C.new_subspace()
> sage: D = N.decomposition()
> sage: D[1].q_eigenform(10, 'a')
>
> After a while of poking around, the following patch made it work, but
> the change does not agree with the documentation of the function. I'd
> like advice on the proper way to fix this, and whether not this is
> correct:

I think this is a good idea.  You can make the change below *and* also
change the docstring.

I wouldn't be surprised if this does perhaps break something somewhere
else, so be sure to test it well.

 -- William

>
> diff -r 342fcdf4b4d3 sage/modular/modsym/heilbronn.pyx
> --- a/sage/modular/modsym/heilbronn.pyx Thu Jun 24 17:16:40 2010 -0700
> +++ b/sage/modular/modsym/heilbronn.pyx Thu Jun 24 19:27:36 2010 -0700
> @@ -534,6 +534,7 @@
>     from sage.matrix.all import matrix
>     from sage.rings.all import QQ
>     T = matrix(QQ, len(indices), len(P1), sparse=False)
> +    original_base_ring = R.base_ring()
>     if R.base_ring() != QQ:
>         R = R.change_ring(QQ)
>
> @@ -593,6 +594,8 @@
>         sage.misc.misc.verbose("did reduction using dense multiplication",
>                                t, level=1,
> caller_name='hecke_images_gamma0_weight2')
>
> +    if original_base_ring != QQ:
> +        ans = ans.change_ring(original_base_ring)
>     return ans
>
>
>
> --
> 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
>



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

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

[sage-devel] Re: Opinions needed - method names for cones and fans

[Volker Braun]

Ewald's book "Combinatorial convexity and algebraic geometry" defines
the cospan of a (not strictly convex) cone to be its maximal linear
subspace. I think we should stick to "dual" when it comes to lattices
since this in the standard nomenclature in toric geometry.

Volker


On Jun 25, 12:58 am, Andrey Novoseltsev  wrote:
> * cone.spanned_lattice
> * cone.quotient_lattice
> * cone.cospanned_lattice
> * cone.coquotient_lattice

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