Add lock to Cell #1963
Comments
|
A general write lock is possible I think, but whether that is possible on cell level I have some doubts. For shapes I think so, but for instances, the situation is more complicated. Instances not only change the cell per se, but also the relationship between cells and KLayout does not differentiate between cell and the cell graph. So locking the cell graph may be possible, but locking one cell against adding or removing instances which another cell isn't locked, probably is not possible. Regarding the layout state changes there is this bug: #1955. It may be related to your problem. Technically the problem arises from a leak that keeps locks on the layout forever. The root cause is pretty basic, so it does not only apply to the specific situation described in the bug. If you like, you can try the corresponding branch. Maybe it fixes your problem. Matthias |
|
Yeah, I would be totally happy if the shapes.insert (or more generally the shapes), transform and insert are locked (first one highest desired others nice to have). I fully understand it's not practical to lock everything. The main thing I want to avoid is accidental modification of cells which are already in a "finished construction" state. I am fully aware an absolute locking is not possible, especially if the cell_index of an instance is changed or similar. I am not trying to build fort knox, just trying to minimize feet loss due to accidental foot-shooting ;) I also think this could be one of the ways to avoid the library cell being modified in the UI problem (but please give me a way to enable it anyway, because I am using library cells for photonic PDK like packages, and they cannot be a pure static gds ;)) And thanks for the indicator. I would be very happy to try that fix, but I need to wait until I can find a reproducible error (it somehow seemed to error out on regions, but I couldn't pin it exactly). But looking at it, it could indeed be the problem. |
A cell can be locked using cell.locked = true and unlocked again using cell.locked = false Also, cell.is_locked? can be used to test the locked state. In locked state writing shapes and instances is forbidden and doing so would raise an exception. Also, cells cannot be deleted when locked. However, Layout#clear and Layout#_destroy are always available. Cells can still be renamed, even if locked.
Hi Matthias,
Would it be possible to add a "lock" to the Cell class?
This might sound like a weird request, so let me explain the background a bit first. In gdsfactory/kfactory when we create cells, we usually do that with cached functions. Now, sometimes we want to modify cells in a certain way, e.g. add some cladding or exclude layers. This often happens with helper functions. When the caching has been done, it is (almost always) a bad idea to further alter the cell. Therefore, kfactory implemented a "locked" state on its implementation of the Cell, KCell. This lock prevents some stuff that is accessible to the user such as creation of ports (essentially pins with a width and angle) or transform (there is a slight modification to the function in order to transform to transform the ports as well). What of course doesn't (easily) work is to lock the addition of shapes, as those are completely managed by klayout. Ideally, we can enhance this lock to cover most bases (as always, there will be ways to get to the gun and shoot your foot, just want to avoid the non-obvious cases).
I understand if this would go too far into the core of
dband would require lots of engineering or hog too much resources. But I thought it's still worth asking ;)P.S. I am not sure what it is related to, but recently I have seen some weird behavior of the layout changes state. I couldn't determine yet where exactly it's coming from, but I am getting some of the "layout state is not writable - forcing update" (sorry forgot exact error message) on write. I think it either comes from the TilingProcessor or from dangling references to shape/instance iterators is my guess (I usually only see this message with slightly faulty code or in failing tests). Will the latter cause the layout to be in the state equivalent to
Layout.start_changes()? If not , did any of the TilingProcessor code change recently? I haven't seen anything in the patch notes. (Sorry, was not sure where to add this, so I added it here, but I can make a new issue of course if desired, or forum post).The text was updated successfully, but these errors were encountered: