I saw this idea mentioned in the previous year's idea list, but no one
picked
it up. So I was wondering if people still want to get this done.
I am interested in the project as I have some experience with Qt and part of
my previous GSoC project was modifiying a PyQt based application.
I looked a
On Saturday, January 31, 2015 at 5:06:54 PM UTC-8, Volker Braun wrote:
>
> On Saturday, January 31, 2015 at 3:59:05 PM UTC-5, Jeroen Demeyer wrote:
>>
>> In any case: after removing __del__ from Expect and Interface, all
>> doctests pass, so it's not that bad.
>>
>
> Also __del__ is never going t
On Saturday, January 31, 2015 at 3:59:05 PM UTC-5, Jeroen Demeyer wrote:
>
> In any case: after removing __del__ from Expect and Interface, all
> doctests pass, so it's not that bad.
>
Also __del__ is never going to be reliably called in the face of cyclic
references, so I'm all for taking it o
On Saturday, January 31, 2015 at 3:45:33 PM UTC-5, Jeroen Demeyer wrote:
>
> I have been thinking many times about rewriting pexpect from scratch and
> this would be yet another reason.
Some of the pty kernel bugs that I've seen tell me that this will be a
frustrating exercise...
--
You rec
On 22 December 2014 at 00:43, Robert Jacobson wrote:
> Hi. I have yet to contribute code to sage, but I think I've found something
> easy enough for me to start with. I'd like to talk about how to proceed.
>
> I found ticket #13892 and the apparent duplicate ticket #15318 which
> indicate that the
I guess the easiest solution is probably to make a custom class deriving
from the pexpect "spawn" class to implement kill-on-del.
In any case: after removing __del__ from Expect and Interface, all
doctests pass, so it's not that bad.
--
You received this message because you are subscribed to
On 2015-01-31 21:26, Nils Bruin wrote:
I imagine that the __del__ kills the process that is being interfaced
That's true unfortunately. I would have expected the pexpect library to
do that, but it doesn't!! It's only Sage's quit() method which kills the
process.
I have been thinking many time
On Saturday, January 31, 2015 at 11:57:14 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2015-01-31 19:22, Nils Bruin wrote:
> > Another is to put all the "__del__" code into a separate object that the
> > "parent" object holds a reference to, but that itself does not refer to
> > the parent. Then the _
On 2015-01-31 19:22, Nils Bruin wrote:
Another is to put all the "__del__" code into a separate object that the
"parent" object holds a reference to, but that itself does not refer to
the parent. Then the __del__-equipped object is not involved in a cycle.
Obvious question: do we need a custom _
On Saturday, January 31, 2015 at 9:15:33 AM UTC-8, vdelecroix wrote:
>
> I found out where it is. The Interface objects inherits from
> ParentWithBasis and the base is itself...
>
> sage: p = Gp()
> sage: p._base is p
> True
>
Hm, that's a problem. Parent objects are virtually always involved
I found out where it is. The Interface objects inherits from
ParentWithBasis and the base is itself...
sage: p = Gp()
sage: p._base is p
True
Now, setting _base to None, it gets deleted
sage: p._base = None
sage: del p
Vincent
--
You received this message because you are subscribed to the Goo
2015-01-31 18:05 UTC+01:00, Vincent Delecroix <20100.delecr...@gmail.com>:
> I am not sure where is
> this cycle with expect/Gp though.
And I am pretty sure there is one inside Gp itself since
sage: p = Gp()
sage: import gc
sage: any(id(x) == id(p) for x in gc.get_referrers(p))
True
--
You re
One possible issue is that an object that holds a reference to itself
and implement a __del__ method is not collected. Pick the minimal
example
sage: class A(object):
def __del__(self):
print "delete %d"%id(self)
sage: a = A()
sage: a.a = a
sage: del a
sage: gc.collect()
2
sage: gc.ga
On Saturday, January 31, 2015 at 7:08:28 AM UTC-8, Volker Braun wrote:
>
> I don't know, but have you tried gc.get_referrers? This is usually easy to
> figure out.
>
You'd first have to get a hold of the object, though. You could in
principle do that by holding a weakref before deleting it, but
I don't know, but have you tried gc.get_referrers? This is usually easy to
figure out.
On Saturday, January 31, 2015 at 4:40:43 AM UTC-5, Jeroen Demeyer wrote:
>
> I am debugging a pexpect interface issue at
> http://trac.sagemath.org/ticket/17686
> When creating an Expect object, say "g = Gp
Hello
What are prospective ideas for projects by Sage for GSoC 2015 ?
--
Pratik
ᐧ
--
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...@googleg
I am debugging a pexpect interface issue at
http://trac.sagemath.org/ticket/17686
When creating an Expect object, say "g = Gp()", doing "del g" afterwards
doesn't actually destroy the object, even if followed by "gc.collect()".
I want to understand why, in particular who keeps these Expect obje
On 2015-01-30 16:31, Julien Puydt wrote:
Hi,
I'm now trying to understand how sage and GP interface, and much like
with ECL+Maxima, I'll definitely need some help.
Just to comment about the bigger picture: you probably don't need the GP
interface, use the PARI library interface instead.
--
Yo
18 matches
Mail list logo
