[sage-devel] Help us test Cython?

[Craig Citro]

Hi all,

So we're currently working on a long-overdue release of Cython with
all kinds of snazzy new features. However, our automated testing
system seems to keep turning up sporadic segfaults when running the
sage doctest suite. This is obviously bad, but we're having a hard
time reproducing this -- they seem to be *very* occasional failures
while starting up sage, and thus far the only consistent appearance
has been *within* our automated testing system (hudson). We've got a
pile of dumped cores, which have mostly led us to the conclusions that
(1) the problem occurs at a seemingly random point, so we should
suspect some sort of memory corruption, and (2) sage does a *whole*
lot of stuff when it starts up. ;)

So we'd love to see if other people see these same failures. Anyone
want to try out the new cython? You can grab all the files you need
here:

  http://sage.math.washington.edu/home/craigcitro/cython-0.13-beta/

There's a new spkg and 6 patches against the sage library. You can add
the patches, sage -i the spkg, and then do a sage -ba, and voila! you
should have a sage running the bleeding edge cython. (If that doesn't
build, it means I forgot some patch somewhere -- there's a working
sage-4.4.4 with the new cython in /scratch/craigcitro/cy-work/fcubed
on sage.math if anyone wants to root around.)

After that, run the full test suite as many times as you're willing,
hopefully with and without parallel doctesting (i.e. sage -tp). Then
let us know what you turn up -- lots of random failures, or does
everything pass? Points for machines we can ssh into and generated
core files (ulimit -c unlimited), and even more points for anyone
seeing consistent/repeatable failures. I'd also be very interested of
reports that you've run the test suite N times with no failures.

-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

[sage-devel] Nasty arithmetic bug for polynomials over non-prime finite fields

[Craig Citro]

Hi all,

I just hit this zinger:

{{{
sage: polygen(GF(49, 'a')) ; polygen(GF(9, 'a'))
x
x
sage: x = polygen(GF(49, 'a'))
sage: -x
2*x
sage: x + 0
x
sage: -x
6*x
}}}

This is definitely still present in sage-4.5 (at least, William tried
it on his laptop and said he hit it). The underlying issue is one of
NTL context restoration -- I posted the details (at least as far as I
had time to check them) to this ticket:

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

I'll try and look at this, but unfortunately it won't be soon. If
Martin or Robert (who hg blame tells me wrote the polynomial_template
stuff) want to take a look, that would be good. In particular, if you
go into sage/libs/ntl/ntl_ZZ_pEX.pyx, there's a clear description in
__cinit__ of what you *don't* want to do (thank you David Roe!).
Unfortunately, the generated code from sage/rings/polynomial_zz_pex
(which uses polynomial_template.pxi) does exactly what David says to
avoid. I'm not sure what the best fix is -- maybe a second template
that uses a _new-based object creation pattern instead of a PY_NEW-
based one? (Having never actually looked at the polynomial_template
code, I'm clearly just spitballing.)

For the curious, this was the last bug I hit in getting Sage-4.4.4 to
build, run, and pass all doctests against cython-closures tip. Cython
0.13 with closures, here we come.

-cc

(PS I generally only read this list via the web interface -- feel free
to keep me cc'd on this thread.)

-- 
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: final projects for undergrad sage course

[Craig Citro]

> > [1]  http://wiki.wstein.org/10/480b
> > [2]  http://wstein.org/edu/2010/480b/projects/
>
> Thanks.
> What distribution license is used for the lecture notes and projects?
>

As far as the notes/assignments/anything else I wrote up there, it's
cc-by-sa.

-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

[sage-devel] Re: icc

[Craig Citro]

> Please let us know if you run into *any* examples of this--our goal is  
> to always produce standard compliant C89 or C++ code (or C99 if the  
> user has requested C99 complex support). Of course most Cython users  
> are using gcc or MSVC.
>

And just as important -- make sure to post some performance numbers if/
when you get the code running. ;)

-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

[sage-devel] Re: OS X 10.6 port

[Craig Citro]

> I can see now:
>
> === python-2.6.4.p4 (Craig Citro, Jan 17, 2010) ===
> * Move MACOSX_DEPLOYMENT_TARGET fix to sage-env, so that it's
>   used for all python-related spkgs. (This was leading to a
>   build issue with numpy and scipy on 10.4.)
>
> we use very ancient build system in femhub, so we don't have this fix.
> I just ported the fix from the latest sage and I am testing it no on
> bsd.math.
>

How'd this work out? I was too lazy to download and test on my
machine, but I can if that didn't fix it. ;)

-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, reply using "remove me" as the subject.

[sage-devel] Re: OS X 10.6 port

[Craig Citro]

Hi Ondrej,

> Let me know if you have any hints what to try.
>

For sage, the issue was that Python was getting built with
MACOSX_DEPLOYMENT_TARGET set to 10.4, which is no longer valid in
10.6. This was leading to some issues with version mismatch issues
between libraries -- in particular, it was font-handling libraries
IIRC. You seem to have a newer python spkg, though -- is there a
machine I can log into and try this out? Or a tarball I can download
and try? Is it a build from scratch? It could also potentially be an
issue with something finding a system-wide python instead of the one
getting built with femhub. Can you try the following in your fem-local
python:

>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var('MACOSX_DEPLOYMENT_TARGET')

-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, reply using "remove me" as the subject.

[sage-devel] Re: Serious bug in cyclotomic matrix multiplication

[Craig Citro]

> And I'll fix this this weekend if nobody else does.  It is probably a
> problem doing a multi modular matrix multiply and not having enough
> primes.   I designed and mostly implemented the cycle linalg
> algorithms in sage, so this is my fault, probably.
>

... and a fix is up. Robert Bradshaw pointed out that the bound is
just wrong -- we need an extra factor of 2 to deal with the sign. I've
created a ticket and posted a patch:

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

Probably wouldn't hurt if someone wanted to do some speed tests; I'd
expect the factor of 2 wouldn't hurt us, but those are famous last
words ...

-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

[sage-devel] Re: Serious bug in cyclotomic matrix multiplication

[Craig Citro]

> And I'll fix this this weekend if nobody else does.  It is probably a
> problem doing a multi modular matrix multiply and not having enough
> primes.   I designed and mostly implemented the cycle linalg
> algorithms in sage, so this is my fault, probably.
>

I helped with the cyclo linalg code, so I took a quick look -- it
looks like this is an honest problem with the code for matrices over
ZZ:

sage: from sage.matrix.matrix_integer_dense import _lift_crt
sage: _lift_crt(matrix(ZZ,2,1), [matrix(Integers(46337),2,1,[23250,
0])])
[-23087]
[ 0]

Obviously there's just an issue with which residue is getting
returned, because 23087 + 23250 = 46337. Probably a mishandled corner
case in _lift_crt -- I glanced at mpz_crt_vec in sage/ext/
multi_modular.pyx, and lo, and behold! There's a comment that's
telling us what's going on -- around line 589:

# normalize to be between -prod/2 and prod/2.
if mpz_cmp(z[j], self.half_product) > 0:
mpz_sub(z[j], z[j], self.product)

Indeed, that's where the residue is getting changed. So we just need
to change which normalization we return -- or document what _lift_crt
does better, and change the way we use it in cyclotomic matrix
multiply.

> It is very fast.   It gets the wrong answer faster than magma.
>

:)

-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, reply using "remove me" as the subject.

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

[Craig Citro]

> Thank you for the very long email.
>
> I got an email off-list from someone else, which I believe rather put
> your email into perspective.
>

I'm really sorry if anything in my email was offensive -- I knew the
thread was already fairly heated, and definitely didn't want to add to
that. (And I still don't.)

> And in the time that people have taken to complain about excess
> Solaris related emails to sage-devel, they could have written a
> trivial filter in gmail/procmail/whatever to pipe them to somewhere
> else. People are weird.
>

Yes, it's easy to set up a filter. That said, a mailing list where
many of the subscribers feel the need to filter the traffic doesn't
strike me as a healthy mailing list. Maybe I'm just weird.

-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: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)

[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: Sage 4.3.4.rc0 builds ok on Solaris 10 (SPARC)

[Craig Citro]

Hi David,

As one of the people William mentioned who'd complained about the
volume of Solaris email on sage-devel, I thought I should weigh in.
For reference, I actually stopped getting email from sage-devel and
switched to reading on the web because I felt like I couldn't handle
the volume. Mind you, there are probably other factors in my life that
influenced that, too, but I've been active on sage-devel for a long
time, and switching to only reading on the web was a clear step
towards "less active."

> It's up to William really. I don't feel sage-solaris sends the right messages,
> and will certainly make it more difficult to keep Sage building on Solaris.

I think we're really conflating three separate issues here:

1) having Sage build out of the box on Solaris,
2) keeping it that way as Sage development continues, and
3) some people (like me!) feeling like sage-devel has become sage-
solaris-devel.

As to (1): If it were really just "up to William," we'd already have a
Solaris port -- I strongly believe that William desperately wants
Solaris to be a supported platform for Sage. I don't think many people
appreciate the huge volume of Sage-related emails and requests that
William gets ... I think I probably get less than 1% of the volume he
does, and I barely keep up with responding to the emails -- nevermind
actually fulfilling any of the requests! I think William tries to
offer lots of encouragement about the Solaris port -- his last 10 or
so emails on sage-devel about it have all had a strongly positive
tone, I think -- but he probably just doesn't have time to do much
else. You've been doing a fantastic job of wading through all kinds of
issues to get Sage building on Solaris, which is what it really takes
to make (1) happen -- someone doing the heavy lifting.

For (2), the *only* way that we're going to keep Sage building on
Solaris is by having regular testing as part of the Sage release
process (i.e. the build farm). It's how we do it for every other
platform we support, and it seems to be working fine. I think there
are machines we have access to that we can use for this -- but until
recently, it hasn't been relevant, because Sage hasn't built on
Solaris. Now that it does, we just need to make sure those machines
get included -- and problems will get automatically reported as part
of the release process, just like they do now for other architectures.

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. Remember, a large number of
Sage developers are mathematicians or students looking to contribute
-- not software developers. Once we have a windows port up and
running, I'm betting there will be a huge number that had never used a
command line before downloading Cygwin to use Sage ...

Now, (3) seems to be what's causing the most grief here, though I
agree with Wililam's assessment that it's really just the straw that
broke the camel's back. I think you're taking the creation of a sage-
solaris group as a statement that no one values your contributions,
and we want you to go sit in the corner so we don't notice you. I
don't think that's it at all: I think it's a chance for you to have a
better venue to talk about Solaris-specific issues at length. I
actually imagined the sage-solaris group as something you'd enjoy: any
time an issue came up on sage-devel, and it became clear that it was a
Solaris-specific issue, the conversation could be diverted to sage-
solaris while the details get hashed out. Once the root cause is
discovered, the thread might come back to sage-devel with a summary,
and probably a pointer to a trac ticket, or a new question for further
discussion. For people like you, who are happy to read the volume of
sage-devel, you could just be subscribed to both and it's all the
same. On the other hand, I bet there are a lot of people who use
Solaris, might be interested in hearing about sage-related issues on
Solaris, but aren't willing to drink from the firehose that is sage-
devel. In that case, they could subscribe to sage-solaris. And if you
(or anyone else) posted to sage-solaris and were stumped, or no one
responded, you could always try again on sage-devel and say "I tried
this on sage-solaris, but no one came up with anything ..." It would
also mean that those of us who aren't interested or don't have time to
work on the Solaris port ourselves would just get the highlights.

I think this is probably compounded by the fact that there just aren't
a huge number of Solaris users on sage-devel -- especially since it
hasn't built until recently. So in my case, at least, it's not that I
don't appreciate your contributions -- but I don't think you'd be
excited to peruse a huge volume of messages about modular forms any
more than

[sage-devel] Re: Small bug in trac e-mail report

[Craig Citro]

> The author should be nthiery and not newvalueoldvalue. You can find other
> instance of this bug in eg. in [2],[3]. Is it known ? Should it be reported
> somewhere ? Should I open a ticket about it ? Any idea where it is coming
> from ? Is is sufficiently harmless so that it should be ignored ?
>

FWIW, I've seen this and complained in my head about it probably a
million times. I keep putting it off until I have time to sit down and
figure out whether it's us or trac itself, so I haven't done anything
about it -- but yes, it's known, yes, it's annoying, and yes, it
should be fixed. Maybe open a trac ticket saying someone should
determine the cause (us or trac) and fix it/file a more precise bug
report. Okay, I guess I'm not *quite* that lazy:

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

-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

[sage-devel] Re: element_wrapper.py: Sage 4.3.2.alpha1 segfault on Mac OS X 10.6.2

[Craig Citro]

> If this is confirmed, I don't mind using a more sane parent for the
> tests. On the other hand, getting a segfault with an (admittedly ill)
> piece of pure Python code is not good. Could any expert of the arcanes
> of Integer comparison have a look?
>

Yep, using ZZ as a parent for something which isn't of class
sage.rings.integer.Integer is what was causing the segfault here.
There's actually a bit more to the story -- in particular, one should
wonder why it only segfaulted on OSX. I'll make some comments about
what was going on below; more importantly, though, is what we should
do about fixing it. In general, there are a lot of parents that assume
that elements with that parent are of some fixed type; breaking this
rule would be bad on two counts: (1) we'd pay the price by having to
do a bunch of typechecks everywhere, which is no good, and (2) the
logic that depends on this isn't clearly defined -- it's just an
*implicit* assumption in lots of code all over the place.

So how should we fix it? Robert Bradshaw pointed out that there should
probably be a corresponding ParentWrapper, that one could use to
create wrapped parents for the wrapped elements. In fact, I think we
should go one step further -- I don't see why you should be able to
end up with an ElementWrapper without the corresponding ParentWrapper.
So passing parent=P should probably just create a wrapper out of P, if
it isn't one already. In general, being able to just choose your
parent out of the blue is a dangerous thing ... this might be a
reasonably controlled way to do so.

In the short term, someone needs to change up the docstrings in
element_wrapper.py, and at the very least, put a big warning in about
the dangers of getting to choose your parents. (There's surely a good
joke I'm missing here.) Nicolas, it might make the most sense for you
to modify the docstrings, if you have time ...

Now for the interesting part: what was going on? Well, the example on
the ticket creates an integer wrapper object, and then calls into the
integer comparison code with it. Since the two have identical parents,
the code lets it in, and passes it off to a function that implicitly
assumes both inputs are of type sage.rings.integer.Integer. Once that
code (_cmp_c_impl) gets its hands on them, it calls off to the gmp
mpz_cmp function to do a comparison on the two underlying mpz_ts.
However, the second argument was some other random Python object --
so, on OS X, it ends up taking some random chunk of the object, and
dereferencing it ... boom.

But why only on OSX? The sage.rings.integer.Integer object stores just
a bit of information and an mpz_t; the mpz_t is the number of
allocated limbs, the number of used limbs, and a pointer to the limbs.
I just ended up printing out the relevant bytes on my laptop and
sage.math ... on my laptop, both of the first two entries were just
large numbers. However, on sage.math, it happens that in the same
situation, the second entry happened to be all zeros. That means that
when mpz_cmp looks at the number, it decides that it's just zero, and
does the comparison without ever trying to actually access the limbs
-- so it works, except that it pretends the number is 0. (Indeed, 0 ==
a will return True on sage.math, for a as in the description on
#8177.) I just chatted with Robert Bradshaw, and at least in one
example on my laptop, creating a weakref will "fix" the problem -- no
more segfault. But then, you've still got a nonsense value it found
elsewhere in memory. (Interestingly, on his machine, he has the
opposite behavior -- a acts like 0 before the weakref, and segfaults
once it's there.)

-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

Re: [sage-devel] Problem with libpng 12.0.dylib when running Sphinx on Mac OS 10.6

[Craig Citro]

Hi Alexandre,

> The problem is that I get the following messages (repeated about a
> thousand of times) :
>
> WARNING: display latex u'{\\rm SL}_2(\\ZZ)': latex exited with error:
> [stderr]
> dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib
>  Referenced from: /opt/local/bin/latex
>  Reason: Incompatible library version: latex requires version 39.0.0
> or later, but libpng12.0.dylib provides version 36.0.0
>

I had that same problem on my machine. In my case, I made sure to
remove /usr/X11/lib from LD_LIBRARY_PATH and DYLD_LIBRARY_PATH,
because it was finding my system-wide libpng, and that was causing
trouble. (Sage builds its own libpng, so it should be finding that
one.) It looks like yours is in /opt/local -- I'd try removing that
from your path and then running Sage. (I can send you my edits to do
that as part of sage startup, if you'd like.) If that doesn't fix it,
let me know and I'll think harder. ;)

-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

Re: [mpir-devel] Re: [sage-devel] MPIR 1.3.0 released (at last)

[Craig Citro]

> So it can't find libmpir.so.8. But I don't see why.
>
> echo $LD_LIBRARY_PATH
> /usr/lib/sparcv9:/home/wbhart/mpir-1.3.0/.libs
>

Total random guess: could it be that you need this to be in your
DYLD_LIBRARY_PATH, too?

-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

Re: [sage-devel] Re: Wiki question

[Craig Citro]

> I'm sure there are many ways that this problem could be solved if
> somebody who knows MoinMoin well (or can learn it) would be willing to
> put in some time.    That someone isn't me.  If it's you, let me know,
> and I'll make a backup and give you access to it :-).
>

I'll look into this at some point soon if no one beats me to it. But
as an off-the-cuff idea, couldn't we just make the "new account" page
restricted to a limited set of people, and set up a google group with
small circulation to have people send new account requests to? (Maybe
there's something obviously wrong with this.)

-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

Re: [sage-devel] Re: Wiki question

[Craig Citro]

> I'm happy to change the question to something easier once people agree
> on a reasonable question.
> Does anybody know what sort of math a typical spammer would know?  I
> don't personally know any spammers :-)
>

How many wiki accounts are there? Could we switch to just having a
pool of people who can approve accounts, i.e. what we do for all the
google groups? Because I'd *much* prefer that to never seeing another
captcha, but then, I've already got an account. :)

-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

Re: [sage-devel] spam content has got through to the Sage wiki

[Craig Citro]

> The single bad account can be deleted. Our text captcha system seems to work
> well enough--the above doesn't seems to happen very often. It would be nice
> if it was on account creation rather than every edit.
>

+1. (I accidentally typed '+21' at first -- which is probably closer
to my real opinion. :) )

-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

Re: [sage-devel] proposal to remove dsage from sage

[Craig Citro]

>    [X] Yes, I don't use DSage (don't even know what it is...), and
> think it should be removed from Sage.
>

I'm in this group, but I do know one (possibly the only?) DSage user
-- John Voight. Does anyone know if he still uses it?

-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

Re: [sage-devel] A new problem on Solaris 10 SPARC has emerged.

[Craig Citro]

So the error seems to be coming from this command:

> building 'sage.schemes.elliptic_curves.descent_two_isogeny' extension
> /usr/local/gcc-4.4.1-sun-linker/bin/gcc -fno-strict-aliasing -DNDEBUG -g -O3
> -Wall -Wstrict-prototypes -fPIC
> -I/export/home/drkirkby/sage-4.3.1.rc0/local/include/FLINT/
> -I/export/home/drkirkby/sage-4.3.1.rc0/local//include
> -I/export/home/drkirkby/sage-4.3.1.rc0/local//include/csage
> -I/export/home/drkirkby/sage-4.3.1.rc0/devel//sage/sage/ext
> -I/export/home/drkirkby/sage-4.3.1.rc0/local/include/python2.6 -c
> sage/schemes/elliptic_curves/descent_two_isogeny.c -o
> build/temp.solaris-2.10-sun4u-2.6/sage/schemes/elliptic_curves/descent_two_isogeny.o
> -std=c99

And it's an explicit #error in a header file:

> In file included from /usr/include/limits.h:18,
>                 from
> /usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/limits.h:122,
>                 from
> /usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/syslimits.h:7,
>                 from
> /usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/limits.h:11,
>                 from
> /export/home/drkirkby/sage-4.3.1.rc0/local/include/python2.6/Python.h:19,
>                 from sage/schemes/elliptic_curves/descent_two_isogeny.c:4:
> /usr/local/gcc-4.4.1-sun-linker/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.1/include-fixed/sys/feature_tests.h:341:2:
> error: #error "Compiler or options invalid for pre-UNIX 03 X/Open
> applications    and pre-2001 POSIX applications"
>

Can you look in that header file, and see what preprocessor tests are
being done that cause it to get included? (Was this on a machine that
we have access to, like t2?)

-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

Re: [sage-devel] Re: weirdness in simplifying a symbolic expression

[Craig Citro]

> Well, I think there is a neater way to go about it, which is
> to exploit the Lisp package (i.e. namespace) machinery.
> In summary, one can define groups of symbols at run time.

To quote the Zen of Python:

Namespaces are one honking great idea -- let's do more of those!

-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

Re: [sage-devel] Re: weirdness in simplifying a symbolic expression

[Craig Citro]

>>  (2) making the
>> assume() command available at top-level point to
>> sage.calculus.calculus.maxima.assume *would* make it so that the user
>> could easily compute the integral that's frustrating them.
>
> Again, (2) *was* the case since the beginning, and if it isn't now, it
> is because somebody screwed stuff up and introduced a *huge* bug into
> Sage recently.
>

So if things were designed to work this way, then I'm definitely
strongly in favor of just finding this bug and fixing it. The user
that wants to fiddle with the Maxima session that's doing the calculus
can do it the same way I did, if they really need to ...

Now, back to the original issue we were talking about in this thread.
:) I'm still in favor of William's idea of prefixing variables, and
doing a check to make sure they're unbound. Is there a simpler/better
way to do it, though?

-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

Re: [sage-devel] Re: weirdness in simplifying a symbolic expression

[Craig Citro]

> I think we do. Maxima sessions can have so much state that it's nice to keep
> them separate to ensure consistency of the calculus modules. Also, that
> means you won't be accidently clobbering your calculus variables, functions,
> etc.
>

I think I agree in principle, but maybe not in practice. For the user
who knows nothing about Maxima, they're definitely not going to try to
do anything via maxima("...") themselves, so I think it doesn't matter
for them. On the other hand, our use of Maxima clearly isn't perfect
-- if someone knows enough about Maxima to be able to fix the problem
they're having on the Maxima side, it would be nice if that were a
little easier. Since integrate() and friends often comes back with an
error message talking about what we need to tell Maxima first, it'd be
nice if it were easier to do that. I guess I'm saying that I think the
benefits outweigh the dangers -- someone making calls via
maxima("...") probably realizes the prospect of clobbering variables,
unless maybe they were just copy-pasting someone else's code that does
it.

> Eventually (if not already) assumptions and the like will need to be
> recorded and used at a higher level than the maxima interpreter process, so
> I don't think we could always count on the above working.
>

I agree -- ultimately the user should never need to know that we're
using Maxima, and in theory we could one day be using some completely
different backend for integrals. But right now, lots of integrals end
in tracebacks like this:

TypeError: Computation failed since Maxima requested additional
constraints (try the command 'assume(sin(x+%pi/3)>0)' before integral
or limit evaluation, for example):
Is  sin(x+%pi/3)  positive, negative, or zero?

Using assume or maxima.assume doesn't help, but using
sage.calculus.calculus.maxima.assume *does* fix it. I just tested, and
the first three problems on sage-support about maxima and assume I
looked at were all fixed by using sage.calculus.calculus.maxima.assume
instead. I agree that it's not the solution we want in the long term,
but either (1) unifying the two maxima sessions or (2) making the
assume() command available at top-level point to
sage.calculus.calculus.maxima.assume *would* make it so that the user
could easily compute the integral that's frustrating them. (I know
that the one time I've run into this, I tried an integral, got a
traceback about assume, tried maxima("assume(...)"), which didn't fix
it -- so I gave up and just did the integral by hand.)

-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

Re: [sage-devel] Sage build hangs on fplll

[Craig Citro]

>> 1) Kill the -O3, and see if the file compiles. If so, start bumping it
>> back up until you see the hang.
>
> With -O2, it compiles fine. With -O3, it seems to hang.
>

Well, this means we've got an easy workaround for the time being.
Glancing at the two sets of warning messages below, I don't see much
difference -- it looks like the second one is longer, which may
suggest that the hang is happening between when the first and second
sets of messages are generated. At this point, I think we just need to
take the file and start bisecting compiler flags and chunks of code to
see if we can pin it down. (I'm happy to play with this soon.) From
the warnings, it looks like they're doing some crazy pointer trickery
-- maybe it's confusing the compiler enough that some optimization is
hanging?

I think bumping it down to -O2 for now will make your life easier,
though, right? ;) File a ticket to investigate and assign it to me.

-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

Re: [sage-devel] Re: weirdness in simplifying a symbolic expression

[Craig Citro]

> As to Craig's point, yes you can make another Maxima session, but in
> general all internal Maxima use either uses _maxima_(), which calls
> the "calculus" copy, or directly uses the "calculus" copy of Maxima.
> For instance for assumptions we really want to only be using one
> Maxima session.
>

Actually, that's not what I was saying. The point that I was making
(too briefly, apparently -- I was typing on my Droid :) ) is that we
already have two default sessions of maxima floating around: one in
sage.interfaces.maxima, which is what a call to maxima() from the
command line uses, and sage.calculus.calculus.maxima, which is what
gets used by the symbolics behind the scenes. So I have two questions:

1) Do we have two maxima sessions floating around on purpose? That is,
do we *want* the session we use for symbolic simplification to be a
different session than the one the user has access to from the command
line? (I could see an argument for doing this, but I'm not clear as to
whether it was on purpose or by accident.)

2) We start them with different options, which is why maxima("d2")
just returns d2, but sage.calculus.calculus.maxima("d2") returns the
factorial business that started this thread. Do we want to have some
of the options used to start sage.calculus.calculus.maxima also used
in sage.interfaces.maxima?

I also want to point out something that other people may have
realized, but has confused me before: if you're trying to do a
symbolic simplification, and maxima asks you a question, if you do
maxima("assume(x>0)") and try again, it will fail -- because it's
getting sent to the wrong maxima session:

sage: sqrt(x^2)
sqrt(x^2)
sage: sqrt(x^2).simplify()
sqrt(x^2)
sage: maxima.assume("x>0")
[x>0]
sage: sqrt(x^2).simplify()
sqrt(x^2)
sage: sage.calculus.calculus.maxima.assume("x>0")
[x>0]
sage: sqrt(x^2).simplify()
x

Do other people find this confusing?

-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

Re: [sage-devel] Re: weirdness in simplifying a symbolic expression

[Craig Citro]

> This could all be avoided if before changing a variable to maxima we
> prepended it with _sage_var_ (say), and stripped those off when moving
> from maxima back to Sage.  This is worth considering...
>

I think we'll have to do something along these lines.

> Basically, right now, any time that one makes a symbolic variables
> that just *happens* to be the same as the name of a function defined
> in maxima's large global namespace, any symbolic calls to maxima
> involving that variable break.   One could imagine e.g., writing code
> that works and uses an innocent sounding variable like x2 (say),
> upgrading maxima in a few months, and finding that the code suddenly
> doesn't work in arbitrarily confusing ways (since x2 could be defined
> in Maxima to be something entirely weird/crazy like "factorial(k + 3*n
> - 1)/factorial(2*k + 6*n)").
>

Yep, this is definitely worrisome. Actually, thanks to the command
that RJF mentioned, it would be easy enough to check for collisions
when creating a variable -- however, this still doesn't solve the
issue that what variables are legal may change from one version of
maxima to another. (Heck, they could happen to pick _sage_var_x as a
variable in their namespace at some point ...)

Interestingly, though, this isn't what's happening in the example
below -- there's a second thing we have to worry about:

> sage: factorial = var('factorial')
> sage: factorial^3 + factorial/7 - 1
> factorial^3 + 1/7*factorial - 1
> sage: (factorial^3 + factorial/7 - 1).simplify()
> BOOM!
>

Here, the issue isn't that we're hitting the "factorial" in the maxima
namespace. It's that we're hitting factorial when we try to recreate a
sage symbolic expression from it. e.simplify() just does
SR(e._maxima_()), so let's do it in steps:

sage: factorial = var("factorial")
sage: e = factorial^3 + factorial/7 - 1
sage: e._maxima_()
factorial^3+factorial/7-1
sage: SR(e._maxima_())
BOOM!

> Thoughts?
>

I think we should rename variables when we move them over to maxima,
as you mentioned above, but also do a check when we first start a
maxima session to make sure that no entries that start with whatever
our prefix is pop up in their namespace. I think this will solve both
of the obvious issues -- but I'm sure there are more I'm not thinking
of. :)

-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

Re: [sage-devel] Sage build hangs on fplll

[Craig Citro]

So I have no idea what's causing this, but here are at least some
reasonable things to try:

> building 'sage.libs.fplll.fplll' extension
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wall -g -Wall -g -fPIC -
> I/mnt/usb1/scratch/rlm/sage-4.3.1.alpha3/local/include/fplll -I/mnt/
> usb1/scratch/rlm/sage-4.3.1.alpha3/local//include -I/mnt/usb1/scratch/
> rlm/sage-4.3.1.alpha3/local//include/csage -I/mnt/usb1/scratch/rlm/
> sage-4.3.1.alpha3/devel//sage/sage/ext -I/mnt/usb1/scratch/rlm/
> sage-4.3.1.alpha3/local/include/python2.6 -c sage/libs/fplll/fplll.cpp
> -o build/temp.linux-x86_64-2.6/sage/libs/fplll/fplll.o -w
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid
> for Ada/C/ObjC but not for C++
> ..
>

1) Kill the -O3, and see if the file compiles. If so, start bumping it
back up until you see the hang.

2) Kill the -w at the end, so you can at least see some commentary
from the compiler. (-w suppresses all warnings.)

3) Diff this with an install.log from when it worked, see if anything
jumps out at you.

-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

Re: [sage-devel] Re: weirdness in simplifying a symbolic expression

[Craig Citro]

Actually, I think it is, even though I agree it shouldn't be. For example:

[boxen ~] $ sage
--
| Sage Version 4.3, Release Date: 2009-12-24 |
| Type notebook() for the GUI, and license() for information.|
--
sage: maxima(5)
5
sage: exit
Exiting SAGE (CPU time 0m0.07s, Wall time 0m16.09s).
Exiting spawned Maxima process.
[boxen ~] $ sage
--
| Sage Version 4.3, Release Date: 2009-12-24 |
| Type notebook() for the GUI, and license() for information.|
--
sage: maxima(5)
5
sage: sage.calculus.calculus.maxima(5)
5
sage: exit
Exiting SAGE (CPU time 0m0.08s, Wall time 1m5.56s).
Exiting spawned Maxima process.
Exiting spawned Maxima process.
[boxen ~] $

Notice the two spawned Maxima processes in the second one ...

-cc

On Jan 14, 2010 9:56 PM, "kcrisman"  wrote:

On Jan 15, 12:14 am, Craig Citro  wrote: > Yeah, this
is wacky. I can tell y...
There aren't multiple Maxima sessions in general.  But if you needed
one you could get it.  symbolic_sum is in there so that (surprise)
symbolic sums work.  sorry for the brief reply, hopefully more time
later.

- 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
-- 
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] weirdness in simplifying a symbolic expression

[Craig Citro]

Yeah, this is wacky. I can tell you why it's happening, though someone
who's ever used Maxima before should really think about the right fix.
Here's the issue: in sage.calculus.calculus, there's an instance of
Maxima that gets created and passed the argument 'load(simplify_sum)'.
This causes the expression 'd2' to get simplified to
(3*n+k-1)!/(6*n+2*k)!. Here's a sample session illustrating the issue:

sage: maxima("d2")
d2
sage: sage.calculus.calculus.maxima("d2")
(3*n+k-1)!/(6*n+2*k)!
sage: Maxima(init_code=['load(simplify_sum)', 'display2d:false'])("d2")
(3*n+k-1)!/(6*n+2*k)!

Maybe someone who knows Maxima better could point us in the right direction?

As far as a workaround, in sage.symbolic.expression, the
Expression._maxima_ method imports maxima from sage.calculus.calculus
(which is initialized with the simplify_sum option). We could switch
that to the maxima session in sage.interfaces.maxima, but this is just
skirting the issue -- someone probably put simplify_sum there for a
reason, and I'd like to know what it is before changing it. Or, for
that matter, why do we have multiple maxima sessions running around?

-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

[sage-devel] OSX 10.6 bug = dead

[Craig Citro]

Hey all,

Just wanted to mention that I'm pretty sure I've managed to stomp that
pesky OSX 10.6 bug (the "Abort trap" one). I'll mention more details
on the ticket (#7095), but the long and the short of it is that we
were having issues where we were confusing which system libraries were
getting linked in on 10.6, so we had entries for the wrong functions
in the symbol tables of some objects. I need to clean up a few patches
(like removing some now-unneeded warnings), and I'll post everything
in the morning, but I wanted to mention this in case anyone decided to
start working on it in the morning. I also want to thank John Palmieri
-- even though he doesn't even know it, he posted several examples
that made hunting this down *much* easier. (Also, John, I'm using your
new 2.6.4 spkg, which I'll review in the morning -- it's working
great!)

-cc

PS William suggested it might be worth me talking about this bug for a
little bit (~15-20 minutes) on Saturday at the bug days, if there's
interest. It's surprisingly interesting ...
-- 
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] Question about pickle in python

[Craig Citro]

> If you work on getting this merged upstream as a bug that's a good
> selling point for us. We can produce a patched ebuild and possibly
> get it accepted.
> Do you have a bug tracking number of some kind for it?
>

I just submitted the bug:

http://bugs.python.org/issue7689

I'll let you know as I hear anything. (I know one of the core Python
devs has a standing offer that he'll review a patch if you review 5 of
his; if I don't hear anything in a week or so, I'll just bite the
bullet and get this reviewed that way.)

-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

Re: [sage-devel] Re: Unsetting MAKE - a better way to do it.

[Craig Citro]

> basename does the trick, doesn't it?
>

Yep, seems like exactly what we want. The man page also tells me about
dirname, which seems to be the complementary utility we'd want in some
situations.

-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

Re: [sage-devel] Re: Unsetting MAKE - a better way to do it.

[Craig Citro]

> Having thought about it more, there could be a problem with my original
> approach. IF someone typed
>
> $ export MAKE=/my/favorite/make -j 200
> $ make
>
> then my approach, and your suggestion for sage-env would work.
>

You've also got trouble if they do

$ export MAKE='/my/favorite/path with spaces/make -j 100'

because that awk command just prints the first space-delimited token.
The only way I can think of to get around that would be to use a
regexp to take everything after the last / to find the path, then use
something like the awk command above to get the command name, and
append them back together. Is there a more clever way to do it?

Also, presumably you could even have a situation like this:

$ export FOO='/my/favorite/path to make/"make with a space"'

That one's even less fun ...

-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

Re: [sage-devel] Reorganisation of graph methods

[Craig Citro]

>>> Why is that too many? I like being able to type g. and see every
>>> single
>>> method that is available. If one is interested in trees,
>>> g.tree[]
>>> gives a smaller subset. Or read the documentation.
>>

I'm +.9 on this, because I do have one caveat: most of the sage
objects with half a million methods have little in the way of naming
conventions. So the three related methods you're looking for on an
object could be called self.pari_foo, self.foo_using_pari, and
self._construct_a_foo_from_self_via_pari. This isn't the end of the
world, and the self.*foo* business helps a lot, but it would be nice
to try instituting *some* naming conventions, at least on several of
these objects (elliptic curves, graphs, matrices, and number fields
come to mind). Maybe that's a topic for another thread?

-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

Re: [sage-devel] Question about pickle in python

[Craig Citro]

Hi Francois,

> While Carl Witty mentions that python shouldn't be patched directly
> as it would make it harder to package sage for distros, Craig Citro
> went ahead and did just that.
> I couldn't find a ticket or a thread describing the why of this
> decision.

Basically, the thought was that this patch was a legit bug in python,
and we could get this patch pushed upstream in the long run. I hadn't
gotten around to doing that, but I'll start taking care of that today.

The real objection Carl raised was to another patch which was *not*
merged, as I recall. Ultimately we didn't think such a patch would get
upstreamed ever, which is why we ultimately worked around that.

That said, I agree that it's frustrating for distro packaging. I'll
try and get this patch merged, but I don't know how long that will
take. That said, I think there are several patches in our Python spkg
-- is this the only one that's causing trouble, or just the only one
you've run into because it causes doctest failures?

-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

Re: [sage-devel] Pari builds 64-bit objects, but then links as 32-bit.

[Craig Citro]

> Any ideas?
>

Totally just spitballing here, but should this line:

> /opt/sunstudio12.1/bin/cc  -o libpari-gmp.so.2.3.3 -G -h libpari-gmp.so.2
> mp.o mpinl.o Flx.o Qfb.o RgX.o alglin1.o alglin2.o arith1.o arith2.o base1.o
> base2.o base3.o base4.o base5.o bibli1.o bibli2.o buch1.o buch2.o buch3.o
> buch4.o galconj.o gen1.o gen2.o gen3.o ifactor1.o perm.o polarit1.o
> polarit2.o polarit3.o rootpol.o subcyclo.o subgroup.o trans1.o trans2.o
> trans3.o anal.o compat.o default.o errmsg.o es.o init.o intnum.o members.o
> sumiter.o aprcl.o elldata.o elliptic.o galois.o groupid.o kummer.o mpqs.o
> nffactor.o part.o stark.o subfield.o thue.o -lc -lm
> -L/export/home/drkirkby/sage-4.3.1.alpha0/local/lib -lgmp
>

have a -m64 in it somewhere? All the previous lines do ... I'm just
wildly guessing.

-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

Re: [sage-devel] Questions and proposals for matrices

[Craig Citro]

> I did think through whether these things should be cached or not and am
> prepared to write down my reasons for wanting them cached if anybody asks.
>

Putting at least some notes about this in docstrings/comments while
it's still in your head would probably be a good idea. (I haven't
looked at the patch -- ignore me if you've already done this.)

-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

Re: [sage-devel] problem using %timeit

[Craig Citro]

> OK, so there's a python (or ipython) source code file which causes
> problems when running ipython on some machines.  Should that be
> reported as a bug to the python people?
>

This could probably go upstream to IPython -- I've been meaning to do
it once I sit down and figure out whether it's just my configuration,
Sage's configuration, or IPython itself. The fact that you're running
into it too means it's not the first category. ;)

-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

Re: [sage-devel] problem using %timeit

[Craig Citro]

> Hi John -- the offending character is the mu for microseconds. There are
> probably classier fixes, but I edit the ipython source file in my sage
> install. It's one of the ones in the traceback -- I'm on my phone and can't
> look right now.
>

Line 1778 of $SAGE_ROOT/local/lib/python2.6/site-packages/IPython/Magic.py
is what I changed.

I'd love to hear that someone has a smarter fix ...

-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

Re: [sage-devel] problem using %timeit

[Craig Citro]

Hi John -- the offending character is the mu for microseconds. There are
probably classier fixes, but I edit the ipython source file in my sage
install. It's one of the ones in the traceback -- I'm on my phone and can't
look right now.

-cc

On Dec 16, 2009 10:36 AM, "John Cremona"  wrote:

I have defined a function in external .sage file which I load.  Then I
test it using %timeit.  But an error is raised:

UnicodeEncodeErrorTraceback (most recent call last)

/home/jec/.sage/temp/selmer/11222/_home_jec_agm_sage_3.py in ()

/home/jec/sage-4.3.rc0/local/lib/python2.6/site-packages/IPython/iplib.pyc
in ipmagic(self, arg_s)
   951 else:
   952 magic_args = self.var_expand(magic_args,1)
--> 953 return fn(magic_args)
   954
   955 def ipalias(self,arg_s):

/home/jec/sage-4.3.rc0/local/lib/python2.6/site-packages/IPython/Magic.pyc
in magic_timeit(self, parameter_s)
  1828   precision,
  1829   best
* scaling[order],
-> 1830
units[order])
  1831 if tc > tc_min:
  1832 print "Compiler time: %.2f s" % tc

UnicodeEncodeError: 'ascii' codec can't encode character u'\xb5' in
position 27: ordinal not in range(128)

I cannot see any strange characters in the file -- is the information
above any help in seeing what it might be?  The function defined in
the file does not seem to contain any unusual characters.  Also,
making the file into a .py made no difference.

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

[Craig Citro]

>> What do you guys think about doing something similar for new standard
>> spkg's for Sage?   I think 5 years is too long, given how new Sage is.
>>  1 year or 2 years might be more reasonable, given the youth of Sage.
>
> +1 to SageTex
>
> +1 to 2 year maintenance commitment for new packages, though I think
> this should be discussed in another thread
>

I'm also +1 on both of these, and on this general policy being
discussed in a new thread.

Dan Drake seems like the natural choice for this -- Dan, you willing?

-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

Re: [sage-devel] Sage 4.3.alpha0 released!

[Craig Citro]

Hi David,

First, I want to thank you for all the work you've been doing to get
Sage to play nicely on Sun and HP-UX recently. I think that's really
helpful, and in particular, I think some of the comments you make
below are definitely things that will help Mike (or anyone else) make
lcalc better.

That said, I think you're often extremely rude in the way you phrase
things, either on purpose or by accident. For instance:

> I have been less than impressed with lcalc itself.
>

Really? Have you used it to compute any zeros of L-functions? Have you
found that it's slow at computing values of L(s,f) for certain modular
forms? Are you unhappy with Mike's code involving the approximate
functional equation? Or are you just unhappy that it's failing to
build on your particular OS/hardware configuration? Mike doesn't seem
to keep a list of "supported platforms" on the lcalc webpage anywhere;
maybe he's part of the vast majority of people who don't use a Solaris
machine as one of his development platforms.

In short, I think "builds on a variety of hard-to-find Unix systems"
is a metric that's much less important than "performs some interesting
mathematical computation correctly."

I'd say that maybe this was a one-off thing, but you've had strong
negative comments for most of the packages you've looked at -- I
remember PolyBoRi in specific, but I know there were others. I'm *not*
saying you shouldn't report these bugs -- I think it's extremely
helpful that you're taking the time to test all the components of Sage
on other Unixes. I'm just asking that you be a little more polite when
you report them. For instance, you could have started this email by
saying "I've run into a few problems trying to build lcalc on this
hardware configuration." Remember, the people writing these pieces of
software aren't hardened software developers or system administrators
-- they're mathematicians who happen to enjoy writing software. Seeing
their name show up in an angry sage-devel or sage-support email isn't
going to bring us into their good graces.

-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

[sage-devel] Re: sage releases

[Craig Citro]

>> And, let's be honest, no
>> release cycle is really going to be much shorter than that.
>
> Are you sure?   I personally did 100% of the releases for 3 years with
> an average of 1-week for the release cycle.
>

Who knows -- maybe I'm wrong? Do you want to test it? Try doing
sage-4.2 in a week. Or even two. I don't know -- maybe this will be
easy? Maybe it will be impossible? Maybe you can do it, but you won't
get anything else done in those two weeks? (My money's on that last
one, with it coming in right at two weeks at best.)

Is there a table somewhere of Sage versions and release dates?

I don't know that I said this explicitly in my last email -- I like
our system of shorter release cycles in general. That said, I don't
think we need to say "we must have a release every three weeks!" We
should say "three months is too long!" All in all, I don't think
there's a need to rush -- it should be up to the release manager to
say "okay, we've merged a bunch of stuff, and the other big stuff on
the horizon is still at least a week or two off -- let's
feature-freeze and start cleaning up the current build/doctest
failures."

In short, I guess I'm saying that I don't think there's anything
*wrong* with the system as it currently stands. I think the only
weakness is that there aren't enough people who have the time and
energy volunteering to be release manager right now. As I mentioned
above, I think part of the problem is the time commitment
(*especially* for your first release), but maybe not.

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

[sage-devel] Re: sage, sage-sage, sage-env and the like

[Craig Citro]

> I wonder if it would also be good to archive bdists for one specific
> Linux release, e.g., 32-bit x86 Ubuntu 8.04 LTS? Since then one can
> easily get a virtual machine and drop our binary in it.
>

I think this would be a really good idea -- tar xjf on sage.math is a
*much* lower barrier to testing something on sage.math than actually
rebuilding a whole copy of Sage. :)

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

[sage-devel] Re: sage releases

[Craig Citro]

> The question is what, exactly, makes actually
> getting releases out so difficult? Is most of the time spent getting
> things working on uncommon (presumably little-tested) systems? Are the
> obstructions typically due to patches that were not actually ready to
> go in (despite positive reviews) or changes in the target platforms
> (e.g. gcc version bumps)? Essentially I'm asking what makes release
> management hard before trying to figure out if there a way to better
> distribute the load?
>

Honestly, I think the only thing that makes it hard is that we don't
have enough people available to do it. It's not that it's so hard, but
you need to be able to make release management one of your main
priorities for the whole release (in my limited experience, anyway).
You have to merge the outstanding patches, work out the obvious kinks
on sage.math, then pass it off to two build farms, wait for logs from
those machines and other bugs on sage-devel ... I think it's hard to
find people who can actually make that commitment -- we all have
babies, teaching, etc. that keep us busy enough, on top of whatever
other work/research we're supposed to be doing. I wrote that sage
-merge code when I was release manager in the hopes that it would
entice more people to jump in, but I don't know that it helped so
much.

The last time this topic came up, I proposed having one "main" release
manager in charge of a release, but having people rotate through being
release manager for even just a single alpha or rc. I don't think
anyone else liked the idea, but I still think it could be really
useful -- it's much easier to find people who can focus on being
release manager for a week than a month. And, let's be honest, no
release cycle is really going to be much shorter than that. What's
happened lately is that someone starts with the aim of a "quick
release" and the best of intentions, and then some weird
bug/issue/build failure pops up, and while it's getting resolved, they
have other things in life that need their attention. Then they hand
the reins to William, who happily takes over and finishes off the
release. :) This works, but I don't think it makes people excited
about jumping back into the fray -- I know I was left with the feeling
that I really need to be able to "clear my schedule" for a bit to do
it. (FWIW, I'm planning on doing it again in January, once I'm done
with teaching ...)

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

[sage-devel] Re: upcoming sage days

[Craig Citro]

Hey Jason,

>> This one is likely to be funded by the NSA:
>>  * (tentative!) [[daysbug2|Sage Days 19]] -- Seattle, WA (TBA); theme:
>> fixing bugs
>
> Are the dates for this one totally open, or is there some date range
> that we are working within?
>

Roughly speaking, we were thinking maybe over the weekend of MLK day
(Jan 18), but no specific plans have been made. Anything we should
keep in mind scheduling-wise?

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

[sage-devel] Re: n(list)

[Craig Citro]

>>> The question is, do we want this case to also raise an error, or the
>>> function n() to iterate over the argument when it's iterable?
>>
>> Why is there list comprehension in Python? I am "-1" concerning
>> iteration over the argument.
>
> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
> three values?  That way we could do:
>
> n(*my_list)
>

I'm -1 on this idea, for one reason: I find it wildly confusing to
have n(*my_list) do something very different based on the length of
the input. If we do this, we have to explain that "The n() function
can take any number of arguments, and if you give it more than 2, or
any iterable with more than 2 entries, it will iterate over them, but
with less than two, it will coerce into a real or complex number." I
think this will lead to an endless number of bugs -- you have a
perfectly valid and doctested program that happens to use this
behavior for n(), but then you happen to pass it a slightly shorter
list, and now you're getting the wrong datatype back. Of course, z[0]
and z[1] do return the two inputs -- but I still don't think this
makes it okay, because an element of CDF is *not* a list of length
two. (And x[0] fails for x a real number.)

In a perfect world, I'd say that we should make n(a,b) not return a
complex number -- and then I'm +0 on the idea. In principle I agree
with Simon -- this is what map and list comprehensions are for -- but
I also see that it's convenient. That said, map(n, ls) isn't really
that much longer than n(ls) -- and it's way, way clearer IMHO.

> Note that min, max, and other functions work something like this, in
> that they accept a variable number of arguments.
>

I don't think this is the same thing -- these are operations that go
from (List of comparable objects) -> (a single object). So in the case
of max, we're just adding a convenient calling convention, not
actually changing the function signature. For n, though, I think it's
a different story.

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

[sage-devel] Re: IRC logs for #sage-devel?

[Craig Citro]

>> I would go so far as to recommend
>> that we auto-email the logs each day to sage-devel.
>> Note that typically less than 20 people are logged into #sage-devel at
>> any time, and there is no posted log, so the people that benefit from
>> #sage-devel are about 2% of the subscribers to the sage-devel mailing
>> list, which isn't much.
>
> -1 to the idea of auto-emailing to sage-devel. If you want, we could
> make a sage-logs group like sage-trac, but sage-devel is high-volume
> enough as it is. Personally, this is one more email I'd delete every
> time it came in (I'd would like to be able to search them if I was
> looking for something).
>

I'm also -1 on emailing them to sage-devel.

I'm definitely a big +1 on making a sage-irc-logs list. In particular,
it would be *hugely* helpful to be able to search that via the google
groups search -- just think of how many times you've said "oh, I
remember talking about that with so-and-so on IRC ..." Now you could
just search the logs for the conversation, without us having to write
anything to make them searchable. (And using a google search which
shows context is way more handy than grepping through a directory of
files ...)

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

[sage-devel] Re: factoring zero

[Craig Citro]

>> My preference would be that factor works for all integers.  It's not
>> like it's hard to factor 0 or anything.  We just return the
>> factorization object [(0,1)].
>

I'm pretty indifferent on this, though mildly against -- so -0, I think.

> I think I would prfer the empty list of primes and a "unit" of 0:
>

If we're going to add it, I'm strongly on the other side of the fence:
I'd much prefer 0 show up in the list of primes, and not as the unit.
After all, 0 is a prime (in any domain, which is probably the case if
we're asking to factor), but it's only a unit in the zero ring -- and
we're unlikely to be factoring there. :) Seriously, though, if one of
the return values of a function is called "unit," I'd be really
annoyed if dividing by it raised a ZeroDivisionError.

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

[sage-devel] Re: round(), floor() and ceil() on interval objects

[Craig Citro]

> I speak from a programmatic point of view, though.  I'd like to not be
> surprised that the following doesn't work:
>
> a=sin(floor(RIF( (1.1,1.2) )))
> a.lower()
> a.upper()
>
>
> versus
>
> a=sin(floor(RIF((1.5,2.5
> a.lower()
> a.upper()
>

I'm a little confused -- *neither* of those would work. The proposal
is that the return type of floor be Integer, just like it is for every
other model of R. The only difference is that the second one would
raise an exception, since there's no unique floor for [1.5, 2.5].

> In other words, I don't think that the return type of floor() should
> depend on how big the interval is.
>

I agree. The return type is Integer (whenever the function returns).

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

[sage-devel] Re: round(), floor() and ceil() on interval objects

[Craig Citro]

> Okay, that seems like a valid point, though I still disagree. I think
> that we have two levels of consistency here: consistency with the
> function and consistency with the concept of interval arithmetic.  I
> think that in this case, the interval arithmetic requirement is more
> specific, so you should be consistent with having intervals.
>

Well, I guess this depends on your point of view. Robert B. and I
chatted about this thread when it started, and I think he convinced me
that the "right" point of view is that RIF is supposed to be a model
of \mathbb{R} that keeps track of errors for you -- that RIF is a
drop-in replacement for, say, RDF, and that it keeps track of
precision as you go. From this point of view, I think there's no
question of what the behavior of floor() should be.

On the other hand, if you're just thinking of intervals as
intrinsically interesting objects, maybe this isn't as natural? I
guess I can just put the ball back in your court: Jason, what do
intervals mean to you? ;)

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

[sage-devel] Re: round(), floor() and ceil() on interval objects

[Craig Citro]

> I really think that floor, ceil, and round should return intervals when
> they are fed intervals.  I thought that was the whole point of interval
> arithmetic.    Shouldn't sin(floor(interval)) be an interval?  It won't
> be if floor automatically converts things to integers.  Why should
> floor, ceil, and round get special treatment to yank things out of
> interval arithmetic?  Why not other functions too?  It seems that having
> some functions that yank you out of interval arithmetic sort of spoil
> everything.
>

Well, I'm a little confused -- I thought that the whole point of
floor() and ceil() was to return Integers. Indeed:

sage: x = 3.12312
sage: type(x)

sage: type(x.floor())

sage: x = RDF(x)
sage: type(x.floor())

sage: x = RealField(100)(x)
sage: type(x.floor())


So I think that this suggests returning an Integer is the right move
-- it's just a question of what to do if there *is* no single correct
integer.

> I really like the idea that we should have separate ifloor, iceil, and
> iround functions specifically on intervals that return integers, as
> described.
>

Definitely.

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

[sage-devel] Re: round(), floor() and ceil() on interval objects

[Craig Citro]

So there are two things people could want from an interval i:

1) { floor(x) for x in i }
2) min { floor(x) for x in i }

I think that David's unhappy with floor doing (2). The other proposal
is to have x.floor() return the unique element in (1) when it's a
singleton, and raise an exception otherwise. David -- would you be
happy with that?

Then there's also the issue that both Nick and William would like to
have functionality for (2) easily available -- we just need to agree
on a name. Ideas?

Also, one should note that this still doesn't completely solve Nick's
problem -- if you have code that uses a RealField element x, and it
calls x.floor(), you can't necessarily drop RIF in for RealField,
because (1) above might have multiple elements. But as David and
Robert pointed out, there's not really a way around that without
breaking the validity of results using RIF. I think Nick's previous
reply suggests he's okay with this, though ...

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

[sage-devel] Re: round(), floor() and ceil() on interval objects

[Craig Citro]

> Example:
>
> sage: floor(log(RIF(8)) / log(RIF(2)))
> 3.?
>
> Should this be 2? What if it returned an Integer if there was a
> unique floor (ceiling, etc.) and raised an exception otherwise?
>

I'm +1 on x.floor()/x.ceil() returning an Integer when possible, and
raising an Exception otherwise.

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

[sage-devel] Re: round(), floor() and ceil() on interval objects

[Craig Citro]

>> I propose, but I'm perhaps missunderstanding.
>>
>> a.lower().floor()
>> a.upper().ceil()
>> a.center().round()
>
> I know about those and always eventually end up using them.  But I
> don't consider them "easy".
>

Maybe include them and call them something like "ilower" and "iupper"?
I'm modeling this on isqrt: for a real number x, x.isqrt() is the
largest integer less than x.sqrt(); here x.ilower() would be the
largest integer less than x.lower().

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

[sage-devel] Re: typo in patch of ticket #6396: primes_of_degree_one is broken for relative extensions

[Craig Citro]

> However, -1 to doing this onlist to everybody.  What does that help?
>

I think a few on-list messages serve as a public reminder, and will
probably greatly lessen Nick's work -- everyone who reads the message
gets a reminder, not just the person who sent it. So I'm +1 on it
being on-list, and still strongly +1 for better quoting netiquette in
general -- I've honestly just stopped reading any reply that starts
with a screen full of quoting, unless I'm wildly interested in the
thread already.

-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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: typo in patch of ticket #6396: primes_of_degree_one is broken for relative extensions

[Craig Citro]

> I am going to start replying to messages that don't quote with good
> netiquette.
>

+1. More power to you.

-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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Suggestion to print extra information in the banner.

[Craig Citro]

> Perhaps a function "get_help()" (or "help()") could print a link to
> sage-support, could print the needed technical data, *and* could print
> a brief introduction on how to post a good request (i.e., odds are
> that we understand what the user means):
>

I much prefer something along these lines to any extra information in
the banner. Maybe even just call it something like "system_summary"
and suggest people include that info in any requests to sage-support.

Actually, it'd be a useful command anyway -- I often do most of those
commands at the top of sage scripts that generate a bunch of data;
it'd be easier to type one thing than three or four (especially since
I usually forget at least one).

-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
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Error in Graph.chromatic_number() and Graph.coloring()

[Craig Citro]

>> There is such a search right here:
>>
>>    http://groups..google.com/group/sage-devel
>> 
>
>
> Yes.  I meant "I love that Sage has a google search.  I wish the nauty
> list had a google search, but I can't seem to find any search for their
> archives at all!"
>

Can't you just do a google search and add
site:http://dcsmail.anu.edu.au/pipermail/nauty-list/? I just tried
this for graph6, and it seemed to turn up a bunch of stuff:

  
http://www.google.com/search?q=graph6+site%3Ahttp%3A%2F%2Fdcsmail.anu.edu.au%2Fpipermail%2Fnauty-list%2F

Mind you, I didn't actually *look* at the results ... but it seems to
be successfully searching that list. ;)

-cc

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

[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason

[Craig Citro]

> When you build packages in parallel, it is possible that a build
> failure is due to race conditions. That is a known problem with the
> current parallel build system of Sage. The relevant ticket is #6374
>
> http://trac.sagemath.org/sage_trac/ticket/6374
>

Actually, #6374 only fixes a race condition while building the sage
library itself -- it's not going to fix any problems showing up with
the polybori spkg, sadly. The original problem sounds pretty funky,
though -- I should hopefully have a little time to get some work done
again soon, and I'm hoping to look at a few of the Solaris issues
David's been hitting lately.

-cc

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

[sage-devel] Re: [sage-release] Re: Sage 4.1.1.alpha0 released

[Craig Citro]

>> On a fresh attempt to build from source, everything went fine.  For
>> the first attempt, the only difference I can discern is that I had set
>>
>> declare -x MAKE="make -j4"
>>
>> which in the past has smoothly allowed the build to use both
>> processors.  Is this the cause of my failure?
>
> No idea
>

This is a known race condition -- for a patch, see

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

The patch *should* fix the issue, but since it's an intermittent
problem, it's hard to know that it's *completely* fixed. This was
merged during 4.0.2, but somehow we mixed up merge trees and it wasn't
in the final release. I asked to get it into the last release, but it
still didn't make it ... maybe it'll make it in again soon? I marked
the ticket "needs review," but as I say on the ticket, it's actually
been reviewed once. It felt like cheating to make a new ticket and
list it as "with positive review." :)

-cc

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

[sage-devel] Re: sage-4.1.rc1

[Craig Citro]

> What about http://trac.sagemath.org/sage_trac/ticket/6374?  There is a
> patch up from 3 weeks ago, craigcitro (I guess) considers it a
> blocker.  Is it a blocker?
>

I think I labeled that a blocker simply so it got noticed and merged
in the next release cycle. It causes an annoying Heisenbug -- sage
will fail to build *sometimes* when building in parallel, based on
number of open processes, the alignment of the planets, etc. Also, it
was a patch that was merged at some point in the 4.0.2 release cycle
that didn't make it into the final release (Nick and I got out of sync
on pulling from the local/bin/ repo, I think). I made it a blocker
just so it would get noticed -- despite saying "needs review," it's
actually already been reviewed at #6234 -- it could just be merged.

-cc

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

[sage-devel] Re: Categories restart

[Craig Citro]

>        Hi Craig!
>
> So how is the baby?
>

Very overdue! But she'll hopefully be here soon. ;)

>> Honestly, I don't recall -- what was our plan for patching this in
>> the interim? Or did we not decide on anything because we got
>> sidetracked talking about #5986?
>
> We definitely got sidetracked talking about #5986 ...
>
> As far as I recall, the plan for #5985 was to just apply what's on
> trac (i.e. one patch to import the cPickle sources and tests in the
> sage tree and a 5 line patch on them), as a temporary measure until
> things get fixed in python.
>

So I chatted with Robert Bradshaw about this, and he reminded me what
we were talking about at SD15. Since this 5-line patch is one we
expect to be upstreamed, we should just patch our python spkg instead
of importing the cpickle file into the sage repo. I'll roll a new spkg
shortly.

> Are you ok finishing the review accordingly?
>

Yep, I'll try and work on it right now.

-cc

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

[sage-devel] Re: Categories restart

[Craig Citro]

> What's the status on this one? I though that the bottom line of the
> discussion at SD15 for this one (not to be mixed up with #5986) was that:
>
>  - Apart from importing the cPickle sources into the Sage tree, the
>   patch was essentially trivial (a 5 lines change to the cPickle
>   code) and therefore easy to review
>  - It had some reasonable chances to be merged into Python at some point.
>  - Craig was going to push this upstream
>  - There were no simple alternatives
>
> And that in view of all this it was good to go in Sage, and would get
> a positive review shortly. Which did not occur.
>
> Craig, Carl: could you please do this now or comment back why not?
>

My plan is still to push this upstream at some point soon, with the
intention that it make it into Python 2.7/3.2. However, the release
date for 2.7 isn't even set yet -- meaning it's still quite a ways
off. Honestly, I don't recall -- what was our plan for patching this
in the interim? Or did we not decide on anything because we got
sidetracked talking about #5986?

-cc

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

[sage-devel] Re: Should errors be returned or raised??

[Craig Citro]

>> I found a situation when calling GF(2) returned the tuple
>>  (TypeError, "error coercing to finite field")
>>
> Nice find.  Thanks for fixing this.  See my comments on the ticket.
>

Indeed, there are several more -- this will find them, but also
produce some noise:

sage: search_src("return", "Error")

-cc

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

[sage-devel] Re: Can I keep build data once a package is installed ok?

[Craig Citro]

> Perhaps this facility exists. If not, do others thinks it would be worth
> adding?
>

Yep, this is very handy -- and indeed already exists. Try sage -f -m
foo.spkg. (I have no idea what "m" stands for ... maybe William does?)
This will leave everything in $SAGE_ROOT/spkg/build after building the
spkg.

Or, alternatively, if you wanted it to work for *every* spkg, you
could change the default value of DELETE_TMP on line 76 of
$SAGE_ROOT/local/bin/sage-spkg.

-cc

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

[sage-devel] Re: /mpir-1.2.p4 has no entry for p4 is SPKG.txt

[Craig Citro]

> The SPKG.txt for mpir-1.2.p4 shows:
>
>
> == Changelog ==
>
> === mpir-1.2.p3 (Nick Alexander, June 9, 2009) ===
>  * Update to latest MPIR 1.2 final release.
>
> === mpir-1.2.p2 (William Stein, June 4, 2009) ===
>  * Update to latest MPIR 1.2 pre-release
>
>
> Shall this just be ignored?
> Do we want a trac ticket for it?
> Shall whoever created the patch add a quick note in the trac to say SPKG
> was not updated?
>

Ah, are you pointing out that I forgot to update the SPKG.txt when I
updated the MPIR spkg? The only change was to alter the spkg-install
so that it only ran the MPIR test suite when SAGE_CHECK was defined. I
don't think it's worth bothering to update the spkg now -- but it
wouldn't hurt for whoever updates it next to do so ...

-cc

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

[sage-devel] Re: 4.1.alpha2 released

[Craig Citro]

Hi David,

> I've got a build running on my laptop at the moment, and I was
> wondering: why does the install script not run the Flint test suite?
> I'm puzzled by this since it did run Flint tests when I installed
> 4.0.2, which was actually the same Flint spkg version
> (flint-1.3.0.p1.spkg)
>

We changed this between 4.0.2.rc3 and the final 4.0.2 release. The
tests for Flint and MPIR both get run if you set the environment
variable SAGE_CHECK to 'yes' before starting the build. My
understanding is that the plan is that all spkgs should do this, but
it just hasn't been pushed through yet.

-cc

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

[sage-devel] Re: Anybody tried search_* in 4.1.alpha1?

[Craig Citro]

> Should the strings extra1, etc., be searched for only in the source
> code, or should they be searched for both in the source code and the
> file name?
>

I've definitely used the "search path too" behavior on purpose at
various times. In particular, doing things like adding "matrix" to the
search essentially narrows the result to the sage/matrix/ directory,
which can be handy. Of course, this is clearly a bit of a hack, and
inconsistent (as John is pointing out). So how about instead, we
implement what I'm actually trying to do with this -- add a "path"
optional argument to the search_* functions. (If you're using os.walk,
this should be pretty trivial to add, I think.) It'd be especially fun
if you could give it the name of a module (so that I could tab
complete), too.

-cc

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

[sage-devel] Re: patch naming scheme on trac

[Craig Citro]

> Btw: would it be easy to extract from the current automated release
> tools a python function that given a ticket number would return the
> url's of the corresponding patches on trac?
>

See the first two functions in $SAGE_ROOT/local/bin/sage-apply-ticket.

-cc

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

[sage-devel] Re: patch naming scheme on trac

[Craig Citro]

>>> I think the following is a counterexample to "The trac_ prefix does
>>> not bring any useful information."
>>
>> I still think it's not really, and it is just making the name longer,
>> but I don't really care either.
>
> I don't see the use for it either, but it's not a huge issue for me.
>

I want to weigh in with a +1 on letting patches start with trac_. I
use it so that patches in a directory on my machine are grouped
together -- it's much easier to see them and move them around that
way, because then trac_* picks them up. I also use a system similar to
John Cremona, it seems -- patches named random_thing.patch are
half-finished things, and trac_-descr.patch are ready to get
uploaded. (So I can't just use *.patch -- it'll pick up both kinds of
patches.)

Of course, I'm also +10 on having the ticket number and a short
description, as everyone else commented, but that seems to be
unanimous on this thread.

-cc

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

[sage-devel] Re: patch naming scheme on trac

[Craig Citro]

> I used to include a commit message when I did not use MQs.  With MQs I
> make the patch using "sage -hg export qtip > blah.patch" and do not
> get prompted for a commit message.  Thelast one I did then ended up
> with "[mq]: intpts" where the commit message would be, so perhaps that
> is the commit message provided by MQ.
>
> I expect there is a way to change that default?
>

Hi John -- I think you just use the '-e' option to either qnew or
qrefresh -- I remember it as "e for editor." I learned about it here:

http://wiki.sagemath.org/MercurialQueues

-cc

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

[sage-devel] Re: "How to get into developing Sage" slides

[Craig Citro]

> It still seems rather dull to be honest. I'd appreciate any input.
>
>
You could always try walking them through the process by fixing a bug live
during the talk. I think William did this in his class last quarter, with
mixed results. It'd definitely be exciting, though. I don't know if you're
already planning this, but when you talk about the state of patches on trac,
etc., it'd be nice to load up trac live and show them what you mean.

One more random comment: for the bit about queues, I think this link should
be there, too:

  http://wiki.sagemath.org/MercurialQueues

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

Hi Georg,

> The root cause was the patch for trac #2513 which was incorporated in
> Sage-4.0.2.alpha4, concerning the setting (or not ...) of the variable
> LANG in the sage-env script.
>
> I'll prepare a nice patch with some explanations for the R.spkg's
> "spkg-install" script to use 'LANG="en_US.UTF-8"  && export LANG', and
> attach it to the yet-to-be-created trac ticket for this, but this
> might take more than a day.
>

Oops. I was hoping that since clisp was the culprit that got LANG
added in the first place, this problem might just disappear since
we've switched to ecl -- no such luck, I guess. Now, I'm curious about
the issues R has -- do you need LANG to be set whenever you *use* R,
or just when you run the spkg-install? Because if it's the former,
we're back to square one with #2513 ...

Another unfortunate possibility is that R isn't the only program that
has an issue with this -- once you add it to the spkg-install for R,
does the sage install finish without any trouble?

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

>> Interesting ... that means that the call to sys.exit(0) is generating
>> an exception that's getting caught in the except: clause. Can you file
>> a ticket for this? I'll happily review it. :)
>
> I created a ticket #6364, without a patch though since it's outside
> SAGE_ROOT/devel.
>

Actually, there's another hg repository in $SAGE_ROOT/local/bin -- but
the change is easy enough, so I went ahead and added a patch. Do you
want to give it a positive review?

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

> That did the trick -- ran fine and no "failure" line at the end.  (I
> moved that line to the end as suggested)
>

Interesting ... that means that the call to sys.exit(0) is generating
an exception that's getting caught in the except: clause. Can you file
a ticket for this? I'll happily review it. :)

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

>> Similar error with any other sage -merge command.  Am I doing
>> something wrong?
>
> I think I had this problem based on the current directory.  Could you
> try in a different directory?  (I think this is a sage-wide problem
> but I can't say with certainty.)
>

Yep, I remember Nick saying something about this and I forgot to look
into it. I'll add it to the "TODO" on wiki.sagemath.org/release right
now.

Just for the record -- which directory did you run it from when it failed?

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

> All seemed well with that test (all etsts passed, etc), but the final
> lines of output are
>
> All tests passed! Popping patches from queue ...
> cd "/home/jec/sage-4.0.2/devel/sage" && hg qpop -a
> cd "/home/jec/sage-4.0.2/devel/sage" && hg qdelete trac_5307.patch
> Building failed with SystemExit: 0
>
> -- what's with the "failed" in the last line?
>

Interesting ... I've never seen that before. What os/arch are you on?
Could I ask you to try one thing: go to $SAGE_ROOT/local/bin, and edit
sage-apply-ticket. On the 5th line from the bottom is "sys.exit(0)" --
could you try deleting that line and moving it to the very bottom (and
outdenting it)? I suspect that error will go away. Actually, you could
even try just deleting that line, and I suspect that will fix it, too.

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

> Yes, the parallel build code was reworked for 4.0.1.  Not sure why
> we're seeing this, but still.
>

Well, the parallel build code in 4.0.1 *should* be contained to the
sage build itself (it's in sage's setup.py, and it's a separate
builder that one has to instantiate). I won't say it's impossible,
because I know I'd have to eat my words, but I think it's at least
pretty unlikely.

That said, I think this is an issue with some race condition in our
build process. I don't have a 10.4.11 machine to look into this, and I
definitely don't want to before 4.0.2 (which is done) -- one can
simply unset MAKE and the problem goes away. ;)

Georg, you should definitely file a ticket for this on trac ...
hopefully someone will start looking into it during the next release
cycle.

-cc

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

[sage-devel] Re: sage 4.0.2.rc3 released

[Craig Citro]

> All tests passed on 64-bit Ubuntu 9.04 and 32-bit Fedora 10. All tests
> passed on bsd.math, except that #6242 is still a problem; the
> birds_other.rst doctests segfault between a quarter and a third of the
> time.
>

Yep, this is a known issue. This is the same as #6304, which David
Harvey had started to look at (as described on the ticket). I'm
closing #6242 as a duplicate of #6304 and making a note, since #6304
has more specific information.

-cc

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

[sage-devel] This year's Trophees du Libre -- congrats Tim Abbott!

[Craig Citro]

Hi all,

So everyone probably that we remembers that we won in the Science
category in the Trophees du Libre back in 2007. The 2009 awards have
been announced here:

http://www.trophees-du-libre.org/

Tim Abbott (who's the man behind sage being packaged for Debian) has
founded a startup called KSplice with three of his fellow students
from MIT. They won two awards at the Trophees du Libre this year --
they won in the Security category, as well as the "Open Source Spirit"
award. Congrats, Tim!

-cc

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

[sage-devel] Re: Poll: which debugger do you use?

[Craig Citro]

> My most important debugging tool is logical deduction using my brain.
>

Someone want to open a trac ticket for including that in Sage? ;)

-cc

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

[sage-devel] sage 4.0.2.rc3 released

[Craig Citro]

Hi all,

Here's rc3, which *should* be the last rc for this release cycle. I've
tested it on my laptop and the build farm, and I've had no troubles at
all, and it's currently going on a few other machines, so hopefully
that'll turn out fine, too. Please test it and let me know if you run
into anything at all.

Source and sage.math binary are here:

  http://sage.math.washington.edu/home/craigcitro/release/sage-4.0.2.rc3.tar
  
http://sage.math.washington.edu/home/craigcitro/release/sage-4.0.2.rc3-x86_64-Linux.tar.gz

I believe that the necessary upgrade bits are sitting here, but I
haven't tried it:

  http://sage.math.washington.edu/home/craigcitro/release/sage-4.0.2.rc3/

I think Minh will hopefully reply with a list of changes, but I want
to mention one that I'm excited about: I added the merge script that I
wrote with Nick Alexander. (It doesn't have an official review yet --
shh! :) ) I need to sit down and write more documentation, but here's
a quick summary: use sage -merge  to test the patches
on a trac ticket. There's a -t option for deciding which files to
test, -n to decide the number of threads to use, -r for which
repository to commit things to. By default, it pops all patches after
you're done. With -l, it leaves them in the queue, and with -f it
commits them to the repository on a successful test (f for finish, as
in qfinish). (These two can't be combined, of course, because that
doesn't make any sense.) There's -d to save the patches to another
directory (it currently uses a temp directory), and -o to overwrite
the patch files when it finds them (it won't by default). Finally, -c
by itself lists all patches with positive review on trac, and -a
instead of a ticket number does the above to all patches listed by -c.
I said more about this in my last message on the rc1 thread.

-cc

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

[sage-devel] Re: sage-4.0.2.rc1

[Craig Citro]

> Curiously enough, I think you will need very little hand-holding.
> (But I'm willing to answer whatever questions I can.)  Hopefully you
> won't have a whole lot of spkgs to update, and merging new code is
> very easy with Craig's apply_ticket.py program.  (Check ~ncalexan/bin
> for an hg repository.)
>

And in fact, I've even touched it up and added a few more options, and
I'm about to post it to #6170. Here's a fun option that I just added,
using some code that Nick wrote:

[craigci...@sharma ~/sage/release_scripts]  $ ./apply_ticket.py -c
Fetching http://trac.sagemath.org/sage_trac/report/11 ...

==
 >>> Tickets with positive review <<<
==

#3084:  Solve Sudoku faster!
#4290:  function to construct an Elliptic Curve from a plane curve of
genus one (using Magma)
#4712:  Make the doctest timeouts in Sage easily adjustable
#5307:  Bug in conductor() over number fields
#5594:  better error message for list_plot
#5637:  allow \[ and \] to delimit math in %html blocks
#5991:  Add a standard constructor for dynamic classes
#6027:  get_memory_usage() sucks performance wise on OSX
#6239:  fix ReST formatting for pydesign module ext_rep
#6261:  Add multiplicative order for matrices over finite fields
#6269:  Coloring odds and ends
#6273:  Improve random_element for number field orders and ideals
#6274:  fix formatting of files under sage/plot
#6289:  minor ref manual issue with calculus stuff
#6290:  Allow keywords such as latex_name=LaTeX while defining symbolic function
#6302:  make openopt an optional spkg
#6307:  Move javascript out of python-land
#6330:  optional doctest failure -- constructions number fields doctest failures
#6336:  optional doctest failure -- constructions calculus tests hang forever
#6349:  graphs -- bug in DiGraph constructor
#6351:  typo in Graph.plot docstring
#6354:  Advertise and improve sage -fixdoctest

Obviously one can just look on trac, but this is an easy way to see
what tickets you want to pass to the merge script. Now the next person
can write something that just iterates through those, and determines
which ones cause trouble ... in fact, that's only about 10 lines.
... [20 minutes pass] ...
And I just did it. It's not perfect, but I ran this one command:
 ./apply_ticket.py -a -n 12
in a sage shell (i.e. source sage-env or do sage -sh), and it tested
every ticket on the above list independently, using sage -tp 12. (Some
very minor work needs done to do this in series without committing the
changes -- see the comments involving the word 'qsave' in the source.)
It asked me to edit the patch order every time there were multiple
patches on a ticket (thank you Nick!), and ran some tests. Here was
the final result:

Tickets to merge:  ['6290', '6027', '4712', '5307', '6239', '6273',
'6330', '6336', '6354', '4290', '5594', '5637', '6261', '6269',
'6274', '6289', '6307', '6349', '6351', '3084']
Tickets I couldn't test:  ['6302']
Tickets needing work:  ['5991']

#5991 depends on another ticket, so that one makes sense. #6302 is
just an spkg -- it couldn't find any files to test.

Now, it only tested the files that were changed -- I could have used
the -t option to change this (thank you again Nick!). It has options
for "all changed files," "all files in any directory that was
touched," and "test everything." In particular, some of the tests
above were about #optional stuff -- this didn't notice anything with
those, since we haven't added a way of asking for #optional doctests.
(This would be fairly trivial to add.)

You can test these individually by putting a ticket number in place of
-a, and if you pass -f (for "finish," as in "qfinish") it will commit
the changes after a successful test.

Also, it rebuilds the reference manual each time -- if we set up
sphinx to turn warnings into errors (Mike Hansen said this is probably
-e), we could probably have reference manual issues show up as errors
here.

Looks like Tom has some patches already waiting! ;)

-cc

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

[sage-devel] Re: coercion in the developer's guide

[Craig Citro]

> That's exactly what my original question was about...
>

Sorry, apparently I can't read at all this morning. Wow ...

In that case, I vote for (1). And, then, (5) of course. :)

-cc

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

[sage-devel] Re: coercion in the developer's guide

[Craig Citro]

> Yes: #4196 talks about the developer's guide, while #5454 deals with
> the reference manual.
>

True, but the new section in the reference manual has a fair bit of
exposition at the top. What else would you want in the developer's
guide that isn't already in the reference manual? Or a note saying
"see the corresponding section in the reference manual"?

-cc

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

[sage-devel] Re: coercion in the developer's guide

[Craig Citro]

> Right now, the coercion section of Developer's guide starts off by
> saying
>
>  **September 2008:** Much of this material is out of date.  We are
>  working on a revised version.
>
> (The relevant ticket is  4196>.)
>

I think that this patch does a large part of this:

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

It was merged as part of 4.0.2. Any objection to closing #4196 with a
mention of #5454 being merged?

-cc

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

[sage-devel] Re: sage-4.0.2.rc1

[Craig Citro]

> No, it is not deliberate.  There is now an rc2 with this fixed an some other
> things fixed:
>
> http://sage.math.washington.edu/home/wstein/farm/src/sage-4.0.2.rc2.tar
>
> Craig just made the above, by the way.
>

Actually, this isn't going to be the final rc2 -- I had added a
handful of fixes, and wanted to give those a run. There are still 2-3
things that need to make it into rc2, though now that this has made it
out into the wild, maybe I'll call the next one rc3.

As Nick noted, I accidentally did sage -sdist sage-... instead of just
using the version number at the end; for anyone working on a release
in the future, just a tip -- that doesn't work too well. ;)

-cc

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

[sage-devel] Re: Sage 4.0.2.rc0 released

[Craig Citro]

> In alpha2, m4ri fails to build on OS X 10.5 PPC (the computer in Craig
> Citro's office).  I'm trying rc0 now:
>

Ah, I really need to get an account on that machine one day. (I'm not
kidding -- I don't actually have one.) Also, I should find out the
hostname so I can ssh in. William, do you have building on this
machine automated somewhere?

-cc

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

[sage-devel] Re: Sage 4.0.2.rc0 released

[Craig Citro]

> In alpha2, m4ri fails to build on OS X 10.5 PPC (the computer in Craig
> Citro's office).  I'm trying rc0 now:
>
> checking mm_malloc.h presence... no
> checking for mm_malloc.h... no
> checking for a sed that does not truncate output... /usr/bin/sed
> checking the number of available CPUs... 1
> checking the number of available CPUs... 1
> checking for x86 cpuid 0x0 output... unknown
> checking for the processor vendor... Unknown
> ./configure: line 21951: 0524288: value too great for base (error
> token is "0524288")
> Error configuring libm4ri
>

We hit this exact same error on another machine (which I'd forgotten
until William mentioned this error). I'm hoping that Martin Albrecht
will say "oh, it's just " -- Martin, is this something obvious? If
not, just let me know and I'll start digging. But after your instant
fix for the libsingular 64 bit OSX bug, I figure I should let you try
and fix it first ... ;)

-cc

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

[sage-devel] Re: arcsin or sin^{-1}

[Craig Citro]

 My vote is for arcsin.

>>>
>>> +1
>>
>> +1
>
> +1
>

+1

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

[sage-devel] Re: Sage 4.0.1.alpha0 linbox trying to build before blas was installed

[Craig Citro]

Hi David,

> atlas-3.8.3.p2 (needed hack suggested by ATLAS developer)
>
> Note blas is not in that list. But linbox is trying to build, which
> claims to need blas
>

Actually, isn't ATLAS providing our BLAS? So maybe somehow the linbox
script can't find it after whatever changes were made to the atlas
spkg? Or something else completely? :)

-cc

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

[sage-devel] Re: sage-4.0.1

[Craig Citro]

> Merged in Sage 4.0.1.rc3:
>
> #6179: John Palmieri: html -- doctest failure in sage-4.0.1.alpha0
> [Reviewed by Mike Hansen]
> #6217: Mike Hansen: fix issues with sorting in formal_sum [Reviewed by
> William Stein]
> #6230: Mike Hansen: Fix numerical noise and dictionary sorting issues
> in 4.0.1.rc2. [Reviewed by William Stein]
>

FWIW, there was actually one more ticket merged in that rc: #4652.
This didn't get closed at the time, but you can check that it shipped
with 4.0.1. And, if you set MAKE to 'make -j12' and SAGE_PARALLEL_DIST
to anything, distutils will dispatch the gcc calls in parallel.

We've merged #6234 in 4.0.2.alpha0, which means that you don't need
the SAGE_PARALLEL_DIST bit anymore -- if you asked to do things in
parallel, it'll all happen that way.

-cc

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

[sage-devel] Re: reworking the mac os x download page

[Craig Citro]

> Could we make the intel/powerpc split more obvious, or add
> instructions, or make just one directory with both?
>

I vote a big +1 on one directory with both -- I think that'd be way easier.

-cc

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

[sage-devel] Re: Sage 4.0.1.alpha0 released!

[Craig Citro]

> I've been
> thinking about writing something like this up for a while now, but
> there's never enough time to do everything one wants to in Sage :)
>

For the record, I'm in the process of writing a first system for doing
this right now. It's mostly done (I can automatically get a string of
patches from a ticket, merge, and test, then either delete them from
the history or commit them -- thank you queues!), but it's far from
perfect. I'm going to be using it tomorrow to merge the tickets with
positive review, and I'm sure I'm bound to hit a few more bugs while I
do that.

I'm definitely really excited to keep hearing what people want out of
such a system -- I'm just offering a heads-up, because I don't want
someone else to sit down and re-do the same work I've been doing. At
least until we decide that what I've done needs completely rewritten.
;)

In particular, I'm really curious what people think the right
interface for this is. I've done the following: I've written a bunch
of utility functions (to grab patches from a ticket, download a list
of patches to a temp dir, queue a bunch up, etc.) that I've put in the
sage library itself, since they seem like they'd be of independent
interest. However, the process of rebuilding and testing sage seems
unnatural to run from sage -- not impossible at all, just unnatural
(at least to me). So I've written a shell script that loads just the
utility file from the sage library, parses some command-line arguments
(with getopt), and then runs the process non-interactively. This will
work fine for a first go-round, but what do people want in general?

I feel like the process of "download patches from a ticket, apply in
some order, rebuild and test, and commit" makes sense as a menu-based
text interface, especially if you want to do several in a row. Or am I
the only one that likes that idea? I did spend too much time on MUDs
in high school; maybe it's the reason I seem to want to turn release
management into a text-based adventure game. "You are in a dark room,
facing a massive patch bomb. Run, fight, or merge?" ...

-cc

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

[sage-devel] Re: Using Cython / Numpy with Sage...

[Craig Citro]

> Trying an equivalent Cython NumPy test file yields the following error:
>
>
>
> tar...@tarbox-laptop:$ python setup.py build_ext --inplace
>

Just to confirm here: are you running from a sage shell (i.e. by
running sage -sh)? Otherwise my first thought would be to try sage
-python ...

-cc

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

[sage-devel] Re: change_ring returns self or a copy of self, depending on R

[Craig Citro]

>> How do you generally use the matrix after you call change_ring()?  It
>> seems like the normal thing to do would be to change the matrix in
>> some
>> way.  In that case, it is a huge bonus to have consistency between
>> returning the original object and returning a copy.
>
> I usually use change_ring on polynomials, after which I extract
> coefficients/find roots/factor/etc. It's also nice to change the ring
> to be over a fraction field (i.e. M.change_ring(M.base_ring
> ().fraction_field())) before taking the echelon form.
>

Yeah, I can see that it makes sense there (because you're calling to
something that will give you back a new matrix regardless). The use
case I had in mind when I voted +1 was that I have a matrix over a
number field or finite field, and I want to play with it in an
extension where some polynomial has a root. So change ring to the
extension, and manipulate the result -- here I think it's more
surprising when the behavior is different when the polynomial does or
doesn't have a root.

I don't think that one choice is clearly better than the other -- I
vote for adding a flag to change_ring, called copy. Now, of course,
what should the default be? I (obviously) vote for True; my reasoning
is this: if you wanted copy=False, and you get copy=True, then all you
get is a slowdown; if you wanted copy=True, and you get copy=False,
then you have possibly hard to find bugs. So the principle of least
surprise says we want copy=True, I think.

> In general I view X.change_ring(R) as shorthand for X.parent
> ().change_ring(R)(X), and given a parent R, R(x) generally returns x
> if x is already an element of R.
>

That's interesting -- I actually think of it as "tensor X.parent()
with R, and take the natural image of X in that tensor product"
(because I think of change_ring as a shorthand for base_change on the
parent). So I'd generally expect to get a (naturally isomorphic) copy
back.

-cc

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

[sage-devel] Re: change_ring returns self or a copy of self, depending on R

[Craig Citro]

>> Should this be changed so that m.change_ring(R) always returns a copy?
>
> Yes, I think so.
>

+1

-cc

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

[sage-devel] Re: reviewing tickets

[Craig Citro]

>> Maybe I'm just hung up on the word "assign", since it does most of
>> what I would want, it just seems pushy.
>
> I put the relevant usernames in the cc: box, presuming that they might
> take the hint.  Do they?  I haven't collected data :)
>

Indeed, I think what Nick's describing is a really good system. I've
often been cc'd on tickets, and I've definitely reviewed many of those
(which I presumably wouldn't have otherwise seen).

-cc

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

[sage-devel] Re: Element definition not loaded initially

[Craig Citro]

> Perhaps the class definition for Element should be loaded initially.
>

It's there, it's just not imported into the top-level namespace:

sage: sage.structure.element.Element?
Type: type
Base Class:   
String Form:   
Namespace:Interactive
File:
/sage/local/lib/python2.5/site-packages/sage/structure/element.so
Docstring:

Generic element of a structure. All other types of elements
(RingElement, ModuleElement, etc) derive from this type.

Subtypes must either call __init__() to set _parent, or may
set _parent themselves if that would be more efficient.

I'm a little surprised that SageObject and ModuleElement get imported;
SageObject is directly imported in sage.structure.all, so maybe
there's an obvious reason I'm missing. ModuleElement isn't listed
there -- I think it "accidentally" gets imported in the process of
loading sage, because I can't see why it's needed ...

-cc

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