Re: [sage-devel] Re: PariInstance never deallocated ?

Needs review ! http://trac.sagemath.org/ticket/18385 Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

> > If all tests pass then any further change is either trivial (pretty much > by definition), or there is something so seriously foobared that the entire > ticket needs to be rethought (e.g. no testing). > That's complete garbage and you know it. There are all sorts of things that a reviewe

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

On Friday, May 8, 2015 at 11:26:08 AM UTC+2, Clemens Heuberger wrote: > > Proposed Solution 2: Somehow introduce a flag that a positive_review > ticket must > no longer be changed because it is under consideration by the RM (many > variants > proposed, e.g. simply set it to "closed" or set some

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

On Thursday, May 7, 2015 at 10:18:24 AM UTC+2, Nathann Cohen wrote: > > In my experience, people don't set a ticket to needs_work because of > something trivial at that time. If all tests pass then any further change is either trivial (pretty much by definition), or there is something so seriou

[sage-devel] Re: ipython

I've never seen that. Just to point out the obvious, you don't have a coredump "core" file lying around in cwd or the ipython tree? That might mess up the "from core import".. On Friday, May 8, 2015 at 11:48:36 PM UTC+2, William wrote: > > Hi, > > Why is this happening? > > 1. I build sage.

[sage-devel] ipython

Hi, Why is this happening? 1. I build sage. 2. I make a binary. 3. I extract the binary on an identical machine and start it and get "ImportError: No module named core.getipython". 4. Doing ./sage -f ipython fixes the problem. I've seen this issue in all kinds of places lately. What is ipyth

[sage-devel] password reset at http://trac.sagemath.org/

Is it working? I tried to reset my password. sage-trac sent me an email with a new one but it does seem to work. Anybody try this lately? -- Forwarded message -- From: sage-trac Date: 8 May 2015 at 17:30 Subject: [Sage] Trac password reset for user: bpage To: bill.p...@newsynthe

[sage-devel] Re: Problem while compiling

leif wrote: > leif wrote: >> leif wrote: >>> Do you intentionally build Sage's GCC? >>> >>> Building Sage should work with your distro's, but you may have to >>> install some prerequisites first (such as probably gfortran, which >>> incidentally is no longer explicitly listed in [1]). >> >> P.S.:

[sage-devel] Re: PariInstance never deallocated ?

Nathann Cohen wrote: >> This works for me (quick'n'dirty): >> >> Haven't tested with valgrind though. > > Well, Valgrind seems happy! ;-) > > Do you think that there is a sensible reason to not apply this change > (with some more documentation)? I do not mind doing it, unless you > prefer to do i

Re: [sage-devel] Re: PariInstance never deallocated ?

> This works for me (quick'n'dirty): > > Haven't tested with valgrind though. Well, Valgrind seems happy! ;-) Do you think that there is a sensible reason to not apply this change (with some more documentation)? I do not mind doing it, unless you prefer to do it yourself. Nathann -- You receiv

[sage-devel] random_matrix with algorithm='subspaces' almost always fails

Hi, I don't have time right now to dig into this and see what's wrong, but if you do random_matrix(QQ, 7,4, algorithm='subspaces') almost always it fails, saying that the rank cannot exceed the number of rows or columns. The documentation says the rank is generated randomly, so it seems like the

[sage-devel] Re: PariInstance never deallocated ?

leif wrote: > Nathann Cohen wrote: >> It is not deallocated when you quit Sage either. This is how I noticed it. > > So we'd in principle have to revert the changes made by #13741. > > Using 'del pari' in quit_sage() doesn't work, and one cannot call > pari.__dealloc__() explicitly, hence another

[sage-devel] Re: PariInstance never deallocated ?

Nathann Cohen wrote: >> Isn't this object representing the fact that `pari.so` has been loaded as a >> dynamic library? Does that library ever get unloaded? I think it's just >> representing reality by never being deallocated. > > It is not deallocated when you quit Sage either. This is how I noti

Re: [sage-devel] Re: PariInstance never deallocated ?

> What do you mean by "safely"? I meant "without a noticeable performance penalty" > It's not clear to me why at all you want the PARI instance to get > deallocated (upon exit) though. Nothing specific. I was using Valgrind for other things, and this problem is ranked first among Sage's memory l

[sage-devel] Re: PariInstance never deallocated ?

Nathann Cohen wrote: > Oh. Well that explains it: "module global variables are not cleaned > automatically" [1]. > > Copy/paste this code into some Sage module, and you will never see > "Really ?" printed: > > --- > cdef class A: > def __init__(self): > print "HeyA" > def __deallo

Re: [sage-devel] Re: PariInstance never deallocated ?

> Isn't this object representing the fact that `pari.so` has been loaded as a > dynamic library? Does that library ever get unloaded? I think it's just > representing reality by never being deallocated. It is not deallocated when you quit Sage either. This is how I noticed it. > A similar thing h

[sage-devel] Re: PariInstance never deallocated ?

On Friday, May 8, 2015 at 2:26:55 AM UTC-7, Nathann Cohen wrote: > > Hello everybody, > > It seems that the PariInstance object, created when Sage starts, is > never deallocated. In particular, none of the 'print "He" ' I > added in sage.libs.pari.pari_instance.PariInstance.__dealloc__ were

[sage-devel] Re: PariInstance never deallocated ?

Nathann Cohen wrote: > I think this is http://trac.sagemath.org/ticket/17686 > (needs review). > > > Not sure that it is the same problem: when I apply that branch, the > __dealloc__ function still is not called. You're right, the PariInstance is

Re: [sage-devel] Re: PariInstance never deallocated ?

Oh. Well that explains it: "module global variables are not cleaned automatically" [1]. Copy/paste this code into some Sage module, and you will never see "Really ?" printed: --- cdef class A: def __init__(self): print "HeyA" def __dealloc__(self): print "Really?" cdef A

Re: [sage-devel] Re: PariInstance never deallocated ?

> isn't it about Python's GC? See e.g. gc.get_referrers(*objs) It tells you who points to the object indeed. It does not give you the list of "those who will never be automatically deallocated". And unfortunately there are many things in there :-/ Nathann -- You received this message because y

Re: [sage-devel] Re: PariInstance never deallocated ?

On Friday, 8 May 2015 14:41:06 UTC+1, Nathann Cohen wrote: > > > IMHO #1786 is about pexpect, whereas your problem is about a library > > interface to Pari. > > I am trying to figure out whether all objects with a reference to a > PariInstance are all deallocated, but I am no very sure I know

Re: [sage-devel] Re: PariInstance never deallocated ?

> IMHO #1786 is about pexpect, whereas your problem is about a library > interface to Pari. I am trying to figure out whether all objects with a reference to a PariInstance are all deallocated, but I am no very sure I know how to check that O_o Nathann -- You received this message because you a

[sage-devel] Re: PariInstance never deallocated ?

On Friday, 8 May 2015 14:18:22 UTC+1, Nathann Cohen wrote: > > I think this is http://trac.sagemath.org/ticket/17686 (needs review). > > > Not sure that it is the same problem: when I apply that branch, the > __dealloc__ function still is not called. > > IMHO #1786 is about pexpect, whereas you

[sage-devel] Slightly OT but still relevant

What I find interesting about this article is the almost complete lack of discussing the computer as something to help *discover* theorems then verified "by hand", ala "The Computer as Crucible". Appearances by JH Conway, Voevodsky, Frenkel, et al. http://nautil.us/issue/24/error/in-mathematic

[sage-devel] Re: PariInstance never deallocated ?

> > I think this is http://trac.sagemath.org/ticket/17686 (needs review). Not sure that it is the same problem: when I apply that branch, the __dealloc__ function still is not called. Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

> > In my experience, people don't set a ticket to needs_work because of > > something trivial at that time. Less read the code anyway, once it is > > already in positive_review ;-) > > Or else they add a commit immediately. > > Or at least are pretty specific about what the issue is. (Somet

[sage-devel] Re: Problem while compiling

leif wrote: > leif wrote: >> Do you intentionally build Sage's GCC? >> >> Building Sage should work with your distro's, but you may have to >> install some prerequisites first (such as probably gfortran, which >> incidentally is no longer explicitly listed in [1]). > > P.S.: In Ubuntu 14.04 (and

[sage-devel] Re: Problem while compiling

leif wrote: > Dima Pasechnik wrote: >> On 8 May 2015 at 10:51, Christophe Clavier >> wrote: >>> I do not see any reason why my 64-bit installation of the distribution would >>> be not clean. > > Do you intentionally build Sage's GCC? > > Building Sage should work with your distro's, but you may

[sage-devel] Re: Problem while compiling

Dima Pasechnik wrote: > On 8 May 2015 at 10:51, Christophe Clavier > wrote: >> I do not see any reason why my 64-bit installation of the distribution would >> be not clean. Do you intentionally build Sage's GCC? Building Sage should work with your distro's, but you may have to install some prer

[sage-devel] Re: Problem while compiling

On 8 May 2015 at 10:51, Christophe Clavier wrote: > I do not see any reason why my 64-bit installation of the distribution would > be not clean. I'd also try to rule out: * cross-platform tools (or other strange things) that you might have installed in /usr/local or somewhere else in your PATH;

[sage-devel] Re: PariInstance never deallocated ?

Nathann Cohen wrote: > It seems that the PariInstance object, created when Sage starts, is > never deallocated. In particular, none of the 'print "He" ' I > added in sage.libs.pari.pari_instance.PariInstance.__dealloc__ were > ever printed. > > Would anybody know why that happens ? I think th

[sage-devel] Re: upgrade of sage from 6.4.1 to 6.6 eclib linkage error

-sam- wrote: > I tried to upgrade sage from 6.4.1 to 6.6 under linuxmint 17.1 (32 bits, > MATE) and I got this linkage error for the package eclib-20150323. This error is unrelated to eclib; somehow FLINT got built with/linked against GMP (not MPIR). Try './sage -f flint' to rebuild it, and run '

[sage-devel] Re: Problem while compiling

this probably indicates that you have something funny going on with 32-bit vs 64-bit support. Do you have a strange gcc installed on the system? What does gcc -v say? On Wednesday, 6 May 2015 22:28:11 UTC+1, larut...@gmail.com wrote: > > > Hello, > > I have tried to compile sage from sources but

[sage-devel] PariInstance never deallocated ?

Hello everybody, It seems that the PariInstance object, created when Sage starts, is never deallocated. In particular, none of the 'print "He" ' I added in sage.libs.pari.pari_instance.PariInstance.__dealloc__ were ever printed. Would anybody know why that happens ? Nathann -- You received

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

Am 2015-05-07 um 10:39 schrieb Jeroen Demeyer: > On 2015-05-06 21:24, Volker Braun wrote: >> There is no reason that "closed" should be final, until the new branch >> is published we *can* always back. That doesn't mean that you *should* >> dump a pile of extra bookkeeping on me. > > Let me make i

Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow

Am 2015-05-07 um 10:27 schrieb Jeroen Demeyer: > On 2015-05-07 06:15, Clemens Heuberger wrote: >> Am 2015-05-07 um 03:42 schrieb leif: >>> I might be wrong, but isn't it trivial to check whether the branch of a >>> ticket changed (after you merged it into some preliminary release)? >> >> It is easy

Re: [sage-devel] removing the dev scripts

On 08/05/15 07:56, Jeroen Demeyer wrote: > On 2015-05-07 22:36, Volker Braun wrote: >> We could add "git trac" as a standard package now, I haven't made any >> changes outside of the release management stuff in a while > > It's not just about installing them, it's also about making it work > w