[sage-devel] Help us test Cython?

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

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

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

[sage-devel] Re: final projects for undergrad sage course

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

[sage-devel] Re: icc

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

[sage-devel] Re: OS X 10.6 port

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

[sage-devel] Re: OS X 10.6 port

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

Re: [sage-devel] Re: Wiki question

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

Re: [sage-devel] Re: Wiki question

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

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

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

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

>    [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@goog

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

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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ex

[sage-devel] OSX 10.6 bug = dead

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 lin

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

> 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

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

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

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

> 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

Re: [sage-devel] Reorganisation of graph methods

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

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

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

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

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

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

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

Re: [sage-devel] problem using %timeit

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

Re: [sage-devel] problem using %timeit

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

Re: [sage-devel] problem using %timeit

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

Re: [sage-devel] SageTex

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

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

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.

[sage-devel] Re: sage releases

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

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

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

[sage-devel] Re: sage releases

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

[sage-devel] Re: upcoming sage days

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 ove

[sage-devel] Re: n(list)

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

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

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

[sage-devel] Re: factoring zero

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

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

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

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

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

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

> 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

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

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 otherw

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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-devel] Re: Categories restart

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

[sage-devel] Re: Categories restart

> 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

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

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

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

> 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

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

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

[sage-devel] Re: 4.1.alpha2 released

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

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

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

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

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

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

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

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

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

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

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

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

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_

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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 KSp

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

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

[sage-devel] sage 4.0.2.rc3 released

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 anyt

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

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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

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 t

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

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

[sage-devel] Re: sage-4.0.1

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

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

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

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

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

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

> 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

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

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

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

>> 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...@go

[sage-devel] Re: reviewing tickets

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

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

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

  1   2   3   >