On 2018-12-06 14:07, Simon King wrote:
And if I understand correctly what you said in another post, it is
*dynamically* determined which reference is weak and which reference
is strong. When is it determined? During cyclic gc?
Yes, during GC: that's the only time where it matters. More precisel
On 2018-12-06, Simon King wrote:
> Hopefully it is explained in #26790; I'll have a look...
Sorry, must be another ticket. #26811, I guess.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
Hi Jeroen,
On 2018-12-06, Jeroen Demeyer wrote:
> * The domain and codomain store MultiWeakref references to the map,
> where one of those references is weak and one is strong.
And if I understand correctly what you said in another post, it is
*dynamically* determined which reference is weak an
On 2018-12-06 08:35, Simon King wrote:
Then what will be your reference graph? Or phrased differently:
Where/how will you store coercion maps?
The basic idea is the following (I have not worked out all the details yet):
* The coercion model only stores weak references to anything (domains,
co
Hi Jeroen,
On 2018-12-05, Jeroen Demeyer wrote:
> On 2018-12-05 14:54, Simon King wrote:
>> o Mild problem: If there is an external strong reference to, say,
>> f, then it is possible that Q becomes garbage collected anyway,
>> and we would end up with an invalid map.
>
> Th
On 2018-12-06 01:36, Nils Bruin wrote:
Because the coercion map from A to
B is also stored on A, a strong reference to B exists.
No. The map will be referenced both from A and from B with one of those
references weak and one of those references strong, without specifying a
priori which one is
On Wednesday, December 5, 2018 at 1:53:07 PM UTC-8, Jeroen Demeyer wrote:
>
>
> With my idea, the domain and codomain would be treated exactly the same:
> my plan is to reference the map from both the domain and codomain in a
> symmetric way. In that way, the lifetime of A wouldn't depend on C th
On 2018-12-05 18:33, Nils Bruin wrote:
I think you were thinking of limiting the life span of c via referencing
it via a "MultiWeakRef" from both A and C. However, with the scenario
above, A has its life span already bounded below by C anyway, so the
"MultiWeakRef" never gets to work its magic.
On Wednesday, December 5, 2018 at 8:43:06 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2018-12-05 14:54, Simon King wrote:
> > o Mild problem: If there is an external strong reference to, say,
> > f, then it is possible that Q becomes garbage collected anyway,
> > and we would en
On 2018-12-05 14:54, Simon King wrote:
o Mild problem: If there is an external strong reference to, say,
f, then it is possible that Q becomes garbage collected anyway,
and we would end up with an invalid map.
That is one of the things that I would like to fix: maps and ac
On 2018-12-05 16:50, Volker Braun wrote:
Right, automatic clearing of circular references is only in Python 3...
I would phrase that as: properly dealing with __del__ is only in Python 3.
Luckily, __del__ is used only very rarely in Sage.
--
You received this message because you are subscribe
Right, automatic clearing of circular references is only in Python 3...
On Wednesday, December 5, 2018 at 9:06:39 AM UTC-5, E. Madison Bray wrote:
>
> On Wed, Dec 5, 2018 at 2:57 PM Simon King > wrote:
> >
> >
> >
> > Am Mittwoch, 5. Dezember 2018 13:38:03 UTC+1 schrieb Volker Braun:
> >>
Thanks for explaining it in detail. I used to have to chase large amounts of
memory leaks and your discussion reminded me of that complex chase every two to
three months which had to fit in our software release cycles.
Sent from my iPhone
> On Dec 5, 2018, at 3:50 AM, Simon King wrote:
>
> H
Hi Erik,
On 2018-12-05, E. Madison Bray wrote:
>> Has that changed? I recall that in my early days in Sage (when I created the
>> first version of my group cohomology package) I had to remove some __del__
>> method (or change it into a __dealloc__ method), since otherwise some
>> reference cyc
On Wed, Dec 5, 2018 at 2:57 PM Simon King wrote:
>
>
>
> Am Mittwoch, 5. Dezember 2018 13:38:03 UTC+1 schrieb Volker Braun:
>>
>> On Wednesday, December 5, 2018 at 6:52:55 AM UTC-5, Simon King wrote:
>>>
>>> - If there is a reference cycle involving one instance with a __del__
>>> method, then P
Am Mittwoch, 5. Dezember 2018 13:38:03 UTC+1 schrieb Volker Braun:
>
> On Wednesday, December 5, 2018 at 6:52:55 AM UTC-5, Simon King wrote:
>>
>> - If there is a reference cycle involving one instance with a __del__
>> method, then Python would not apply garbage collection to that cycle.
>>
Hi Jeroen,
Am Montag, 3. Dezember 2018 11:46:50 UTC+1 schrieb Jeroen Demeyer:
>
> I am studying the coercion model in detail, looking for optimization
> opportunities. One source of slow-down is the use of weak references.
>
> Over time, more and more places in Sage use weak references. But I'd
On Wednesday, December 5, 2018 at 6:52:55 AM UTC-5, Simon King wrote:
>
> - If there is a reference cycle involving one instance with a __del__
> method, then Python would not apply garbage collection to that cycle.
>
Python will garbage collect the cycle by not calling __del__ on some of the
Hi Steven,
On 2018-12-05, Steven Craighead wrote:
> How difficult is it to create a stack that can control the order of objects
> being created and destroyed so you prevent leaks? Can you add a new method
> on your base class that is inherited to all children to track this?
One basic principle
How difficult is it to create a stack that can control the order of objects
being created and destroyed so you prevent leaks? Can you add a new method on
your base class that is inherited to all children to track this?
Sent from my iPad
> On Dec 4, 2018, at 6:54 PM, David Roe wrote:
>
>
>
On Tue, Dec 4, 2018 at 9:06 PM wrote:
> Would it be advisable to change the base programming language to one that
> does automatic garbage collection instead of having to check to see if a
> class has been properly disposed like it appears from all of these related
> bugs?
>
I can't tell if you'
Would it be advisable to change the base programming language to one that does
automatic garbage collection instead of having to check to see if a class has
been properly disposed like it appears from all of these related bugs?
Sent from my iPhone
> On Dec 4, 2018, at 12:44 PM, Jeroen Demeyer
On 2018-12-04 18:06, Nils Bruin wrote:
Tripledict does that to some extent (with its keys): if one of the key
parts gets deallocated, the weakref callback removes the strong
reference to the value.
Yes, but then we potentially end up again in the situation where things
are *only* weakly refere
On Tuesday, December 4, 2018 at 1:50:19 AM UTC-8, Jeroen Demeyer wrote:
>
> On 2018-12-03 17:21, Nils Bruin wrote:
> > In order to
> > make that possible, the coercion map (referenced strongly on the
> > codomain -- it needs to be strongly referenced somewhere to keep it
> > alive) must not hol
On 2018-12-03 17:21, Nils Bruin wrote:
In order to
make that possible, the coercion map (referenced strongly on the
codomain -- it needs to be strongly referenced somewhere to keep it
alive) must not hold a strong ref to the domain.
I wonder if there is a way to somehow reference an object from
On Monday, December 3, 2018 at 2:46:50 AM UTC-8, Jeroen Demeyer wrote:
>
> It's not clear to me why this double weak reference is needed, but maybe
> I'm missing something. It seems more logical to use strong references in
> the coercion map but then store a weak reference to the map.
>
> The we
You should surely be able to extract some info in this ticket where we
fought hard memory leaks:
https://trac.sagemath.org/ticket/715
Maybe comment 75 though I did not really go through the whole ticket:
https://trac.sagemath.org/ticket/715#comment:75
--
You received this message because you are
27 matches
Mail list logo
