Re: [sage-devel] Re: libpari segfault related to 64bit?
Hi As I've had one external confirmation, more than one sage version, and several laptops here, I'll continue to think about this. Looking for libpari-gmp.so, I found these: r...@capepoint:/usr/local/src/sage-4.5.3/local/lib#ls -l libpari* -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2 -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2.3.5 -rw-r--r-- 1 root root 5011724 Oct 11 17:06 libpari.a -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari.so r...@capepoint:/usr/local/src/sage-4.5.3/local/lib# How come they are not symlinks to one? Why three copies of the same thing? Would it help to somehow turn on debugging info from libpari-gmp.so? Not sure how yet... regards, Jan -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ -- 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: matrices and matrix group over a ring
On Sat, Oct 16, 2010 at 05:08:37PM -0400, David Roe wrote: > You can either inherit from sage.rings.commutative_ring.CommutativeRing, or > modify FreeModule to work better with the category framework. The first is > probably the easier option. Just a note: Testing if some parent belong to a category is fairly trivial (as it should): sage: CC in CommutativeRings() True sage: QQ in CommutativeRings() True sage: CC in CommutativeRings() True sage: as3 = SymmetricGroup(3).algebra(QQ) # The algebra QQ[S3] sage: as3 in CommutativeRings() False sage: as3 in Rings() True Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: matrices and matrix group over a ring
Right. I'm just not sure if there's any point within FreeModule that relies on having a method defined on sage.rings.commutative_ring.CommutativeRing, but possibly not in ParentMethods on the category. The only reason that changing the test in the __init__ method to checking "base_ring in CommutativeRings()" would be determining whether this was the case. David On Sun, Oct 17, 2010 at 04:42, Florent Hivert wrote: > On Sat, Oct 16, 2010 at 05:08:37PM -0400, David Roe wrote: > > You can either inherit from sage.rings.commutative_ring.CommutativeRing, > or > > modify FreeModule to work better with the category framework. The first > is > > probably the easier option. > > Just a note: Testing if some parent belong to a category is fairly trivial > (as > it should): > > sage: CC in CommutativeRings() > True > sage: QQ in CommutativeRings() > True > sage: CC in CommutativeRings() > True > sage: as3 = SymmetricGroup(3).algebra(QQ) # The algebra QQ[S3] > sage: as3 in CommutativeRings() > False > sage: as3 in Rings() > True > > Florent > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- 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: matrices and matrix group over a ring
Hi Florent, On 17 Okt., 10:42, Florent Hivert wrote: > On Sat, Oct 16, 2010 at 05:08:37PM -0400, David Roe wrote: > > You can either inherit from sage.rings.commutative_ring.CommutativeRing, or > > modify FreeModule to work better with the category framework. The first is > > probably the easier option. > > Just a note: Testing if some parent belong to a category is fairly trivial (as > it should): I disagree. Of course, testing that a parent was DEFINED in a certain category is trivial. But there is a long way to go until the test results will be what a mathematician might mean by "it BELONGS to a certain category". For example: sage: P. = GF(3)[] sage: P in Algebras(GF(3)) False Either (1) one should sytematically go through all parent classes in Sage and carefully choose the "right" category in the init method, or (2) one should introduce more elaborate tests for containment in categories, that would recognise "P in CommutativeAlgebras(GF(3))" even if P was just defined as being contained in Rings(). But what is the "right" category? Since there is Sage's coercion model: Wouldn't it be logical that "P in CommutativeAlgebras(ZZ)", because P is commutative and there is coercion from ZZ to GF(3)? Clearly those things can hardly be done when P is initialised. So, I believe that *if* we want to combine the category framework with Sage's coercion model than we have to opt for (2). I initiated a related discussion at http://groups.google.com/group/sage-algebra/browse_thread/thread/a937ffac63191edd, but perhaps it makes sense to discuss it on sage-devel? To summarise some of the arguments from the sage-algebra thread: * (1) would be the cleanest solution, but is likely to involve a lot of partially dull work. In the case of rings, it should always be tested if it is Rings() or CommutativeRings() or Algebras(R) or CommutativeAlgebras(R). Is this suitable for a student project? * (1) is fast, and we *want* that "X in Cat" is fast. * (1) is not so flexible - in the example above, one could hardly have "P in Algebras(ZZ)". * My suggestion for (2) is that, once "X in Cat" is establish, one would dynamically specialise the category of X by X._init_category_(Category.join([X.category(),Cat])). In that way, after the second call, (2) is as fast as (1). * Counterargument of Nicolas was that he knows cases in which (2) would be so slow that even doing it once is too much. So, if one opts for (2) (and I do) than one should introduce mechanisms to make things fast. For example, if the question is whether X is finite then I see four options/attitudes for the user. The user should be able to advice Sage: i) "I assert that X is finite. So, act on it, and don't try to verify that X is finite yourself", or ii) "I assert that X is not finite. So, act on it, and don't try to verify that X is infinite yourself", or iii) "I don't know whether X is finite, and I don't care. So, don't bother to test finiteness of X", or iv) "I don't know whether X is finite, but I am confident that you will find out by yourself". What should be the syntax in either case, and what should be the default? Besides, if one opts for (2) then it would also be reasonable to dynamically adapt parent and element classes. I think this could be done using ABCMeta from Python's abc module. I am not very experienced whith these things, but I hacked together an experimental version that somehow seems to work. More details are given in the thread on sage- algebra. Cheers, Simon -- 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: Strange behaviour of floating point numbers.
RDF just uses Python's str() method to format doubles, which apparently has a default of about 12 decimal digits. RealField is the mpfr arbitrary precision library. The default is 53bits as well, but it tries to print all decimal digits. Arguably the output should be the same, but then you'd either have to decrease the default RealField accuracy or break Python-compatibility when representing doubles. Volker -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] bug wranglers
> We might be able to overcome this with a "bug-wrangler" team, people > who volunteer to > > - look at newly submitted tickets, notify the related developers, ask >for examples and test cases if the report doesn't provide them, >etc. > > - every once in a while, go through the open tickets and see if >they were fixed in a recent release >(perhaps this won't be such a problem once the duplicates are >filtered properly) > > I know some people already spend time doing some of this, but it's > impossible to fight with more than 2000 open tickets without an > organized effort. ... > Comments? Hi, as far as I can tell all attempts at something like this failed in the past. One idea to avoid such a failure in the future would be to have an e-mail address, say "bug-wrangler" which rotates where it forwards to. So for example, one week I'd get these e-mails and it would be my responsibility to deal with them, the next week it is automatically sent to the next person etc. This is just a quick thought, so there might be many much better ideas to address past failures. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] bug wranglers
On 10/16/10 01:21 PM, Burcin Erocal wrote: Hi, Motivated by the call for the bug days, here is an idea to manage the rapidly increasing number of "new" tickets on trac. It is well known in industry that the cost to fix bugs increases rapidly as they time to fix them is delayed. See for example http://on-agile.blogspot.com/2006/12/hidden-cost-of-delaying-bug-fixes.html It depends very much on the industry, but set of quoted values are: $10 in Design phase $100 in working code $1,000 in released software Of course, in open-source software cost can not be considered too much in monetary terms (though clearly in this case a company are willing to pay to have bugs fixed). But if someone writes code with a bug, a second peson builds upon that buggy code with their own code, it should be obvious that there is a lot to be gained by fixing the bugs as soon as possible. But should not be allowed to linger on for a long time. I feel we should be putting higher priority on fixing the bugs sooner, and not adding more features. I recently wrote a very small shell script to automatically find bugs in Sage. It was slow, as each test invoked Sage once. I should be able to speed that up by a couple of orders of magnitude, by not starting a new instance of Sage before each test. (I'm in the process of re-writing it in C). I can't help but feel that some of these could be caught much earlier, with a bit more consideration given to testing. Simply by trying your code with invalid input will often show bugs. sage: seed(1,2) sage: seed(100,34) sage: seed(1,2,3,4,5,6,7) will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of invalid input to other commands will hang Sage, so the only answer is to kill the process. I think the main problem is ignorance. Good software engineering techniques do not form part of mathematics degrees, so most Sage developers are totally ignorant of the issues. Then those motivated to find more information soon hit the fact that books on this topic are not cheap. I have an 18-year old copy of this book, which despite the complaints the 7th edition is out of date, I think much of the material would be useful to Sage developers. http://www.amazon.com/Software-Engineering-Practitioners-Approach-International/dp/0071267824/ref=sr_1_1?ie=UTF8&s=books&qid=1287322048&sr=1-1 There's also plenty of books on software testing. http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=software+testing&x=0&y=0 Perhaps when William assembles the team in Seattle, he could find the money to buy each person a book on software testing. Buy each person a different book, then hopefully Sage developers will able to independently review the material. Perhaps they each write a Wiki page on what they though was the most important things they learned from the book. I believe any belief that having "bug hunt weeks" is a long term solution is rather flawed. The issues should be tackled at an earlier stage. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] bug wranglers
Hi > I believe any belief that having "bug hunt weeks" is a long term > solution is rather flawed. The issues should be tackled at an > earlier stage. Despite not being a sufficient solution, are they not nonetheless necessary? Or at least helpful? regards, Jan -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ -- 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] bug wranglers
On 2010-10-17 16:16, Jan Groenewald wrote: > Hi > >> I believe any belief that having "bug hunt weeks" is a long term >> solution is rather flawed. The issues should be tackled at an >> earlier stage. > > Despite not being a sufficient solution, are they not nonetheless > necessary? Or at least helpful? To me, the idea of these bug hunt days certainly sounds good. I've noticed during earlier Sage Days that putting developers physically together is a very good thing. It massively speeds up development. Jeroen. -- 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] bug wranglers
Hi Minh, On Sun, 17 Oct 2010 01:35:01 +1100 Minh Nguyen wrote: > On Sat, Oct 16, 2010 at 11:21 PM, Burcin Erocal > wrote: > > We might be able to overcome this with a "bug-wrangler" team, > > I would have thought "weed-wrangler" or "pest-wrangler". You know, > Sage and horticulture :-) We should definitely find a better name. I took the "bug-wrangler" name from the Gentoo project [1]. I'm sure other projects use different names, though I'm not familiar with anything else. [1] http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml Apparently Ubuntu has a BugSquad [2]. [2] https://wiki.ubuntu.com/BugSquad I prefer "squad" to "wrangler," so I suggest PestSquad or TracNinja. :) Does anybody else have suggestions for a name? > > people > > who volunteer to > > > > - look at newly submitted tickets, notify the related developers, > > ask for examples and test cases if the report doesn't provide them, > > etc. > > Also make sure the newly created ticket has sufficient information to > allow people to duplicate the bug. Things like linking to the original > bug report, if it exists, on any of the Sage mailing lists, providing > sample code to duplicate the bug (or weed or pest :-), make sure the > newly created ticket is not a duplicate of an existing ticket, cross > link tickets with that new ticket if possible. Good suggestions. We should put these on a wiki page. > > Another advantage is that the members of this team don't need to be > > developers, or even know how to code. It is enough to be able to > > listen to user requests and use trac. > > > > This could also be a good starting point for people who want to get > > into Sage development, since it provides an opportunity to look > > through the library and become familiar with the internal structure > > of Sage. > > I support your proposal as it is another way to encourage more people > to become familiar with the Sage library. Thanks. As I said before, there are a few people who try to do this already as time permits. I think it would just be easier on everyone if we got organized. So let's settle on a name and get started. Cheers, Burcin -- 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] bug wranglers
Hi Martin, On Sun, 17 Oct 2010 12:42:26 +0100 Martin Albrecht wrote: > > We might be able to overcome this with a "bug-wrangler" team, people > > who volunteer to > > > > - look at newly submitted tickets, notify the related developers, > > ask for examples and test cases if the report doesn't provide them, > >etc. > > > > - every once in a while, go through the open tickets and see if > >they were fixed in a recent release > >(perhaps this won't be such a problem once the duplicates are > >filtered properly) > > > > I know some people already spend time doing some of this, but it's > > impossible to fight with more than 2000 open tickets without an > > organized effort. > ... > > Comments? > > as far as I can tell all attempts at something like this failed in > the past. One idea to avoid such a failure in the future would be to > have an e-mail address, say "bug-wrangler" which rotates where it > forwards to. So for example, one week I'd get these e-mails and it > would be my responsibility to deal with them, the next week it is > automatically sent to the next person etc. This is just a quick > thought, so there might be many much better ideas to address past > failures. I was thinking of setting up trac to send a notice to a mailing list for each new issue. Then people interested in this effort can follow this list and help out. Is this possible? Can someone familiar with the trac set up comment? IMHO, distributing work day by day, or weekly is still putting too much load on one person. It should be enough if someone contributes to one issue per day. Perhaps we should come up with a locking mechanism, to prevent two different people from trying to sort the same issue at the same time, but it feels like too much organization at the beginning. Cheers, Burcin -- 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] bug wranglers
On 10/17/10 03:16 PM, Jan Groenewald wrote: Hi I believe any belief that having "bug hunt weeks" is a long term solution is rather flawed. The issues should be tackled at an earlier stage. Despite not being a sufficient solution, are they not nonetheless necessary? Or at least helpful? regards, Jan Yes, I think they would be useful. Periods of concentrated effort at fixing bugs is a standard practice in professional software engineering. In a similar way I feel "bug fix only releases" would be useful, where one concentrates on removing bugs, and not adding features. That idea has however been very much disliked by many people. Given the lack of enthusiasm by many (including William) for my suggestions of "bug-fix-only" releases, it will be interesting to see how many take William up on attending the "Bug Days". dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: Re: [sage-devel] bug wranglers
> I was thinking of setting up trac to send a notice to a mailing list > for each new issue. Then people interested in this effort can follow > this list and help out. Is this possible? Can someone familiar with the > trac set up comment? > IMHO, distributing work day by day, or weekly is still putting too much > load on one person. It should be enough if someone contributes to one > issue per day. > Perhaps we should come up with a locking mechanism, to prevent two > different people from trying to sort the same issue at the same time, > but it feels like too much organization at the beginning. My guess would be that we won't have the issue with locking very often (i.e. too many people doing too much work) but with no one feeling responsible. I guess for me your suggestion would turn out something like this: 1) I sign up to that mailing list since I feel a responsibility of contributing to Sage in such a way 2) For the first few days or weeks I go through newly opened tickets as you suggested. 3) Eventually, probably in some phase where I have less disposable time, I give up on dealing with this e-mail since "somebody else will take care of it". Of course, the answer could just be to not do step 3, but I would assume that it would happen to many of us. Being responsible for a week a time is something more local or short-time which would make it easier for me to commit. To given an example of the workload here's the list of tickets created on the 15th. It seems 3-5 new tickets a day is the normal load: * Ticket #10134 (Provide the enumeration of word morphisms from a range of integers) created by slabbe * Ticket #10133 (Make sure log(1) returns an Integer, not an int) created by kcrisman * Ticket #10132 (Differential Geometry via Sage) created by mikarm I am working in the field of differential geometry (research and teaching) … * Ticket #10131 (Add option to specifiy path for twistd's process ID (.pid) file) created by cschwan * Ticket #10130 (Revamp __hash__, __cmp__ and __richcmp__) created by roed There are a number of confusing and non-optimal features of the way Sage … Thus, as a rule of thumb we could say whoever is responsible for a day should deal with five tickets old and new. This seems like about 1-2h of work which seems doable to me. Of course, if many people feel differently then we should choose a different path. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: Re: [sage-devel] bug wranglers
> I prefer "squad" to "wrangler," so I suggest PestSquad or TracNinja. :) > Does anybody else have suggestions for a name? "Since 2005 a crack commando unit of developers is blamed for bugs they didn't commit. ... If you have a patch, if no-one else can help, and if you can e- mail them, maybe you can ask the B-Team." or so ;) Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] bug wranglers
On Sun, 17 Oct 2010 16:03:29 +0100 Martin Albrecht wrote: > > I prefer "squad" to "wrangler," so I suggest PestSquad or > > TracNinja. :) > > > Does anybody else have suggestions for a name? > > "Since 2005 a crack commando unit of developers is blamed for bugs > they didn't commit. ... If you have a patch, if no-one else can help, > and if you can e- mail them, maybe you can ask the B-Team." or so ;) Perfect! I vote +1 for B-Team. Shall we start calling you Hannibal? Are you setting up the mailing list? Cheers, Burcin P.S. I hope the name B-team doesn't mean that there will be only 4 members. P.P.S. mabshoff would have made a mean B.A. :) -- 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] bug wranglers
On 2010-10-16 14:21, Burcin Erocal wrote: > - look at newly submitted tickets, notify the related developers How are you going to figure out who the "related developers" are? -- 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] Retrying interrupts
I noticed that the notebook has a feature where interrupts are retried after 5 seconds. Does anybody have concrete examples of code which needs this? If code simply cannot be interrupted, that is a bug with that code. However, if a first interrupt doesn't work but a second one works, I believe this is a bug in the interrupt handling code. That's why I would like to see an example of this. Jeroen. -- 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: libpari segfault related to 64bit?
On two different 64-bit ubuntu machines: 1 works fine: j...@fermat%uname -a Linux fermat 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 2010 x86_64 GNU/Linux j...@fermat% sage -v | Sage Version 4.6.alpha3, Release Date: 2010-10-08 | * Warning: this is a prerelease version, and it may be unstable. * j...@fermat% sage -t devel/sage/sage/interfaces/sage0.py sage -t "devel/sage/sage/interfaces/sage0.py" [13.8 s] -- All tests passed! Total time for all tests: 13.8 seconds j...@fermat% dmesg|grep pari j...@fermat% 1 does not: j...@selmer%grep name /proc/cpuinfo | uniq model name : Quad-Core AMD Opteron(tm) Processor 8378 j...@selmer%uname -a Linux selmer 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux j...@selmer% sage -v | Sage Version 4.6.alpha3, Release Date: 2010-10-08 | * Warning: this is a prerelease version, and it may be unstable. * j...@selmer% sage -t devel/sage/sage/interfaces/sage0.py sage -t "devel/sage/sage/interfaces/sage0.py" [11.5 s] -- All tests passed! Total time for all tests: 11.5 seconds j...@selmer% dmesg|grep pari [8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7 sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000] [8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7 sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000] John On Fri, Oct 15, 2010 at 9:48 AM, Jan Groenewald wrote: > Hi > > Summary: On a mixture of sage 4.5.2, 4.5.3, and 4.6alpha3 > > Linux: > i7 64bit: sefgault > E8400 64bit: segfault > T4300 64bit: segfault > T3200 64bit: segfault > T2300 32bit: no segfault > > OS X 10.6 (Marshall: 32 or 64 bit?): no segfault > > Conjecture: It is a Linux specific 64bit problem. > > Can some people on 32bit and 64bit and different CPUs (amd as well) > send in the output of > > grep name /proc/cpuifo > uname -a > sage -v > sage -t devel/sage/sage/interfaces/sage0.py > dmesg|grep pari > > regards, > Jan > > -- > .~. > /V\ Jan Groenewald > /( )\ www.aims.ac.za > ^^-^^ > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: libpari segfault related to 64bit?
Very strange that these errors do not result in a failing doctest... John, Jan: On the failing machines, could you install the PARI spkg with checking enabled? i.e. please do env SAGE_CHECK=yes ./sage -f http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg Note that this might mess up your Sage installation, so do this only on a copy of Sage that you don't need anymore. Jeroen. -- 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: libpari segfault related to 64bit?
After doing that the doctest still passes, and I still get j...@selmer%dmesg|grep pari [8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7 sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000] [8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7 sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000] but I think these are the same messages as before, so things are now working? John On Sun, Oct 17, 2010 at 7:16 PM, Jeroen Demeyer wrote: > Very strange that these errors do not result in a failing doctest... > > > John, Jan: > > On the failing machines, could you install the PARI spkg with checking > enabled? i.e. please do > > env SAGE_CHECK=yes ./sage -f > http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg > > Note that this might mess up your Sage installation, so do this only on > a copy of Sage that you don't need anymore. > > > Jeroen. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: libpari segfault related to 64bit?
On 2010-10-17 20:09, John Cremona wrote: > After doing that the doctest still passes, and I still get > > j...@selmer%dmesg|grep pari > [8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7 > sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000] > [8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7 > sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000] > > but I think these are the same messages as before, so things are now working? If that's the code, I absolutely have no explanation for this. The newly installed spkg should be the same as the old, so...??? Jeroen -- 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] bug wranglers
On 10/17/2010 07:39:44 AM, Dr. David Kirkby wrote: In a similar way I feel "bug fix only releases" would be useful, where one concentrates on removing bugs, and not adding features. That idea has however been very much disliked by many people. I believe that there are many people, who are not heard from, since they are not on these lists, who might become sage users if a way could be found to address this problem. I personally have been burned enough times now by obvious bugs that have shown up when I try to demonstrate what I'm doing in sage, that I hesitate now to shares things readily. -Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Retrying interrupts
I suspect that this is aimed at C-computations that are not wrapped in a _sig_on _sig_off pair. Such code should be wrapped if it's going to take substantial time, but since it isn't always, two interrupts are sent. David On Sun, Oct 17, 2010 at 11:51, Jeroen Demeyer wrote: > I noticed that the notebook has a feature where interrupts are retried > after 5 seconds. Does anybody have concrete examples of code which > needs this? > > If code simply cannot be interrupted, that is a bug with that code. > However, if a first interrupt doesn't work but a second one works, I > believe this is a bug in the interrupt handling code. That's why I > would like to see an example of this. > > > Jeroen. > > -- > 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] Retrying interrupts
On 2010-10-17 20:49, David Roe wrote: > I suspect that this is aimed at C-computations that are not wrapped in a > _sig_on _sig_off pair. Such code should be wrapped if it's going to > take substantial time, but since it isn't always, two interrupts are sent. If the code isn't wrapped in sig_on()/sig_off() (note the syntax change at #10115), then sending two or more interrupts isn't going to help either... Jeroen. -- 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] Retrying interrupts
Right, but it may have finished within 5 seconds and proceeded on to something that is interruptable. David On Sun, Oct 17, 2010 at 14:53, Jeroen Demeyer wrote: > On 2010-10-17 20:49, David Roe wrote: > > I suspect that this is aimed at C-computations that are not wrapped in a > > _sig_on _sig_off pair. Such code should be wrapped if it's going to > > take substantial time, but since it isn't always, two interrupts are > sent. > > If the code isn't wrapped in sig_on()/sig_off() (note the syntax change > at #10115), then sending two or more interrupts isn't going to help > either... > > Jeroen. > > -- > 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
[sage-devel] Re: libpari segfault related to 64bit?
Two data points: Sage 4.5.2.alpha0, Sage 4.6.alpha0 32-bit, no segfault on either everything else is the same for both: model name : Intel(R) Pentium(R) M processor 2.00GHz Linux atoll 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux sage -t "devel/sage/sage/interfaces/sage0.py" [39.9 s] -- All tests passed! Total time for all tests: 40.0 seconds -- 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: libpari segfault related to 64bit?
Hi On Sun, Oct 17, 2010 at 08:26:08PM +0200, Jeroen Demeyer wrote: > On 2010-10-17 20:09, John Cremona wrote: > > After doing that the doctest still passes, and I still get > > > > j...@selmer%dmesg|grep pari > > [8562085.592129] gp[1128] trap invalid opcode ip:7f7f003b5be7 > > sp:7fff08dcd840 error:0 in libpari-gmp-2.4.so.3[7f7f000d3000+421000] > > [8562093.886034] gp[26164] trap invalid opcode ip:7fafab0bdbe7 > > sp:7fffb3ad7540 error:0 in libpari-gmp-2.4.so.3[7fafaaddb000+421000] > > > > but I think these are the same messages as before, so things are now > > working? > > If that's the code, I absolutely have no explanation for this. The > newly installed spkg should be the same as the old, so...??? > I still get the segfault with the new spkg. John's result is perhaps valuable. I don't know how. Jan -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ -- 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: libpari segfault related to 64bit?
On Oct 15, 3:48 am, Jan Groenewald wrote: > Can some people on 32bit and 64bit and different CPUs (amd as well) > send in the output of 64bit Debian here, no problem goodr...@y560:/media/disk30/sage-4.6.alpha3$ grep name /proc/cpuinfo model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz goodr...@y560:/media/disk30/sage-4.6.alpha3$ uname -a Linux Y560 2.6.35-7.slh.1-aptosid-amd64 #1 SMP PREEMPT Wed Sep 29 02:30:35 UTC 2010 x86_64 GNU/Linux goodr...@y560:/media/disk30/sage-4.6.alpha3$ ./sage -v | Sage Version 4.6.alpha3, Release Date: 2010-10-08 | * Warning: this is a prerelease version, and it may be unstable. * goodr...@y560:/media/disk30/sage-4.6.alpha3$ ./sage -t devel/sage/sage/ interfaces/sage0.py sage -t "devel/sage/sage/interfaces/ sage0.py" [26.3 s] -- All tests passed! Total time for all tests: 26.5 seconds goodr...@y560:/media/disk30/sage-4.6.alpha3$ dmesg | grep pari [167793.880983] ACPI: Preparing to enter system sleep state S3 [201102.253580] ACPI: Preparing to enter system sleep state S3 [253592.296030] ACPI: Preparing to enter system sleep state S3 [254532.778486] ACPI: Preparing to enter system sleep state S3 goodr...@y560:/media/disk30/sage-4.6.alpha3$ Ben -- 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] Blockers for Sage 4.6
We still have 4 blocker tickets for Sage 4.6 that need work or review: Another doctest failure in sage/graphs/graphs.py http://trac.sagemath.org/sage_trac/ticket/10081 Doctest error in sage/schemes/generic/toric_divisor.py on OS X http://trac.sagemath.org/sage_trac/ticket/9926 Doctest failure in sage/rings/polynomial/polynomial_element.pyx http://trac.sagemath.org/sage_trac/ticket/10042 Upgrading from 4.5.3 to 4.6.alpha* can fail (not limited to MacOS X) http://trac.sagemath.org/sage_trac/ticket/9896 If you can, please help with reviews, comments, and or needed work. I'd really like to merge these and the already positively reviewed blockers soon into 4.6.rc0. Thanks! -- 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-release] Blockers for Sage 4.6
Hello Leonardo kindly reviewed #9422 several days ago, which was one of the many ways to solve #10081 :-) Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
