Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selected shape object disappears (undesired garbage collection?) #278

Closed
olcc opened this issue Jun 16, 2019 · 5 comments
Closed

Selected shape object disappears (undesired garbage collection?) #278

olcc opened this issue Jun 16, 2019 · 5 comments

Comments

@olcc
Copy link

@olcc olcc commented Jun 16, 2019

Hello,

In the following script, shape s disappears even though it is still bound to an identifier. Is it normal? Can it be improved?

import pya
import time

layout_view = pya.LayoutView.current() 
     
def get_selection():
  return layout_view.object_selection
  
# We suppose that the selection contains shapes
shapes = [opath.shape for opath in get_selection()]

s = shapes[0]
print("Shape: {}".format(s))  # Shape: box (x;y)
time.sleep(1)
print("Shape: {}".format(s))  # Shape: null

Note: A workaround is to keep a reference to layout_view.object_selection. But, as said, it is a workaround. The shape object should normally survive without this workaround, no?

@klayoutmatthias
Copy link
Collaborator

@klayoutmatthias klayoutmatthias commented Jun 17, 2019

Thanks for reporting this. It's kind of weird. Apparently I don't understand precisely what the list comprehension does with the reference count of Python objects. A simple print("anything") is sufficient to spoil the reference to the Shape objects.

The expanded form works well:

shapes = []
for opath in get_selection():
  shapes.append(opath.shape)

I wonder what's the difference between this form and [ opath.shape for opath in get_selection() ]. That's going to be some awful debugging ...

Matthias

Loading

@thomaslima
Copy link
Collaborator

@thomaslima thomaslima commented Jun 17, 2019

Loading

@klayoutmatthias
Copy link
Collaborator

@klayoutmatthias klayoutmatthias commented Jun 17, 2019

OK, wasn't that difficult :)

Loading

@klayoutmatthias
Copy link
Collaborator

@klayoutmatthias klayoutmatthias commented Jun 17, 2019

@thomaslima It wasn't the reference count in fact (if you use Python from debug build it will track the counts). The issue was actually that the Shape object from ObjectInstPath#shape wasn't passed as copy but as pointer (the Python function generator by default treats const db::Shape & with copy semantics and db::Shape & as reference-to-member which bears the risk of lost references). In this case, this wasn't intended and is easy to fix by picking the right overload.

Loading

@thomaslima
Copy link
Collaborator

@thomaslima thomaslima commented Jun 18, 2019

Loading

klayoutmatthias added a commit that referenced this issue Jun 18, 2019
Fixed #278 (lost reference to Shape object from ObjectInstPath)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants