Wrong parent in RBProgramNode after a #copy

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

Wrong parent in RBProgramNode after a #copy

Jan Vrany
Hi,

while writing some code transformation code, I found out
that in many implementations of RBProgramNode & co. the #copy
message makes a sort of deep copy, copying also it's child nodes.

However, it does NOT sets it's parent to the copy, so for copied
nodes, following does not hold:

  someNode children anyOne parent == someNode

This seems to br wrong to me. In other implementations I can
simply use #deepCopy and works fine, but I cannot do this in
Pharo because #deepCopy fails. The reason is that in Pharo
RBProgramNodes are infested with OpalCompiler stuff which
apparently keeps BlockClosures which cannot be deep-copied.
The tree I'm trying to copy is obtained using
BlockClosure>>sourceNode.

Question: Is there a way how to copy the parse tree with parents
set properly?

If not, I'm inclined to fix #copy so it sets parent node properly
If that's not desirable for one reason or another, no problem, I'll
do it differently (but not-so-nicely :-)

Best, Jan




Reply | Threaded
Open this post in threaded view
|

Re: Wrong parent in RBProgramNode after a #copy

stepharo
Hi jan

to me it looks like a bug.

Stef


Le 18/6/15 08:04, Jan Vrany a écrit :

> Hi,
>
> while writing some code transformation code, I found out
> that in many implementations of RBProgramNode & co. the #copy
> message makes a sort of deep copy, copying also it's child nodes.
>
> However, it does NOT sets it's parent to the copy, so for copied
> nodes, following does not hold:
>
>    someNode children anyOne parent == someNode
>
> This seems to br wrong to me. In other implementations I can
> simply use #deepCopy and works fine, but I cannot do this in
> Pharo because #deepCopy fails. The reason is that in Pharo
> RBProgramNodes are infested with OpalCompiler stuff which
> apparently keeps BlockClosures which cannot be deep-copied.
> The tree I'm trying to copy is obtained using
> BlockClosure>>sourceNode.
>
> Question: Is there a way how to copy the parse tree with parents
> set properly?
>
> If not, I'm inclined to fix #copy so it sets parent node properly
> If that's not desirable for one reason or another, no problem, I'll
> do it differently (but not-so-nicely :-)
>
> Best, Jan
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Wrong parent in RBProgramNode after a #copy

Jan Vrany
Ah, I'm sorry. Pharo is actually file, i.e., sets parent properly on
copy. I checked source of some methods but it's actually done
in others.

Sorry for the noise!

Best, Jan


On Thu, 2015-06-18 at 08:08 +0200, stepharo wrote:

> Hi jan
>
> to me it looks like a bug.
>
> Stef
>
>
> Le 18/6/15 08:04, Jan Vrany a écrit :
> > Hi,
> >
> > while writing some code transformation code, I found out
> > that in many implementations of RBProgramNode & co. the #copy
> > message makes a sort of deep copy, copying also it's child nodes.
> >
> > However, it does NOT sets it's parent to the copy, so for copied
> > nodes, following does not hold:
> >
> >    someNode children anyOne parent == someNode
> >
> > This seems to br wrong to me. In other implementations I can
> > simply use #deepCopy and works fine, but I cannot do this in
> > Pharo because #deepCopy fails. The reason is that in Pharo
> > RBProgramNodes are infested with OpalCompiler stuff which
> > apparently keeps BlockClosures which cannot be deep-copied.
> > The tree I'm trying to copy is obtained using
> > BlockClosure>>sourceNode.
> >
> > Question: Is there a way how to copy the parse tree with parents
> > set properly?
> >
> > If not, I'm inclined to fix #copy so it sets parent node properly
> > If that's not desirable for one reason or another, no problem, I'll
> > do it differently (but not-so-nicely :-)
> >
> > Best, Jan
> >
> >
> >
> >
> >
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Wrong parent in RBProgramNode after a #copy

Marcus Denker-4

> On 18 Jun 2015, at 21:19, Jan Vrany <[hidden email]> wrote:
>
> Ah, I'm sorry. Pharo is actually file, i.e., sets parent properly on
> copy. I checked source of some methods but it's actually done
> in others.
>
> Sorry for the noise!
>

The note with the blocks is correct, though… it is on my list to get rid
of OCKeyedSet. (I reduced it already to just one use)

        Marcus