Removing children

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing children

Reza Razavi
Hi all,

It seems that PRRemoveCommand >> doExecute does not remove the
children of the current structure. Am I missing something, or should
the following be added just before *self structure remove*:

self structure enumerator contents do: [:aChild | aChild remove ]

Thank you in advance for our response,
Regards,
Reza




_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Removing children

Lukas Renggli
Why do you think this is a problem?

Lukas

On 31 August 2010 14:23, Reza Razavi <[hidden email]> wrote:

> Hi all,
>
> It seems that PRRemoveCommand >> doExecute does not remove the children of
> the current structure. Am I missing something, or should the following be
> added just before *self structure remove*:
>
> self structure enumerator contents do: [:aChild | aChild remove ]
>
> Thank you in advance for our response,
> Regards,
> Reza
>
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Removing children

Reza Razavi
At 14:53 31/08/2010, Lukas Renggli wrote:
>Why do you think this is a problem?

Hi Lukas,

It seems that the children keep pointing to their parent, which is
the removed structure. I'd expect the children to be removed too,
actually starting from the leaf nodes. So something like (not tested):

PRRemoveCommand >> removeWithChildren: aStructure

         aStructure hasChildren ifTrue:
                 [ aStructure enumerator contents do: [:aChild | self
removeWithChildren: aChild ]].
         aStructure remove

PRRemoveCommand >> doExeccute
         [...]
         self removeWithChildren: self structure
         [...]

Does this makes sense?

Regards,
Reza



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Removing children

Lukas Renggli
>> Why do you think this is a problem?
>
> Hi Lukas,
>
> It seems that the children keep pointing to their parent, which is the
> removed structure. I'd expect the children to be removed too, actually
> starting from the leaf nodes. So something like (not tested):

Keeping the relationship is intentional to be able to remove and
reinstall the tree somewhere else. I think the parent link is also
required to be able to restore a deleted page.

So why do you think the parent should be nilled?

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Removing children

Reza Razavi
At 18:13 31/08/2010, Lukas Renggli wrote:
>Keeping the relationship is intentional to be able to remove and
>reinstall the tree somewhere else. I think the parent link is also
>required to be able to restore a deleted page.

Well noted; thanks for the precisions!

>So why do you think the parent should be nilled?

It seems that the memory space is never released, because even when
later the *max history* is reached in PRHistoryPersistency, #do: just
removes from its history collection the context that points to the
"removed" (hidden?) structure. So, if I understand well, the
structure will not be garbage collected due to the circular
relationship between the parent and its children?

Regards,
Reza

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Removing children

Lukas Renggli
On 31 August 2010 18:57, Reza Razavi <[hidden email]> wrote:

> At 18:13 31/08/2010, Lukas Renggli wrote:
>>
>> Keeping the relationship is intentional to be able to remove and
>> reinstall the tree somewhere else. I think the parent link is also
>> required to be able to restore a deleted page.
>
> Well noted; thanks for the precisions!
>
>> So why do you think the parent should be nilled?
>
> It seems that the memory space is never released, because even when later
> the *max history* is reached in PRHistoryPersistency, #do: just removes from
> its history collection the context that points to the "removed" (hidden?)
> structure. So, if I understand well, the structure will not be garbage
> collected due to the circular relationship between the parent and its
> children?

If you flush the PRHistoryPersistency the references should go. Unless
they are still referenced somewhere else (e.g. sessions).

I don't think that there are any Smalltalk VMs left that do not
collect circular references.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Removing children

Reza Razavi
At 19:05 31/08/2010, Lukas Renggli wrote:
>If you flush the PRHistoryPersistency the references should go. Unless
>they are still referenced somewhere else (e.g. sessions).

Well noted, many thanks Lukas!
I'll do more systematic tests regarding this, and also the circular
references later.

Regards,
Reza

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki