Forum Replies Created
-
Posts
-
Version 4.3.19 is released and it it fixes a few minor bugs plus a couple of more serious ones to do with the geometry processing engine.
In particular the connectivity extraction algorithm has had improvements made that eliminate a few corner case bugs that could cause incorrect connectivity.
LVS with a hierarchical netlist still needs more testing as I just have 2 testcases currently.
Lastly more regression tests are being added to ensure bugs don't reappear!
You can only use a foreign debugger that allows setting breakpoints in your Glade python scripts while they are executed by Glade.
So for example I have successfully used Komodo which is a commercial IDE/debugger. I believe Wing IDE also should work. They both listen on a port for their python code loaded into Glade to be called and communicate with them. The Pythonwin IDE does not have this kind of debugging capability.
A foreign interpreter alone is not going to help, you can't just load up your python scripts into it as even though they may try to import the ui module, that is just a python wrapper with hooks into C++ code generated by SWIG that call Glade ui and db functions.
I'd suggest reading up the python docs about the builtin pdb debugger which although rather crude, does work and costs nothing.
I have seen this when either the PYTHONPATH is wrong, or it is pointing to an older version of the code, or a corrupted ui.pyc.
However, on looking more closely I'll guess you're trying to load the ui.py code into a foreign Python interpreter. Which does not know about the _ui module because that is generated by SWIG which created a ui_wrap.cxx file that gets linked to the Glade executable.
Hard to say though without knowing exactly what you're trying to do.
Due to a build problem, 4.3.16 initially had some problems. In particular, the Linux versions had incorrect bindings for the arrow (pan) keys.
This has been fixed and the builds have been re-built and are currently being uploaded to the website. Please download these builds, which should show a compile date of 17th Oct.
Hi FriendFX,
Well spotted. In fact the ruler code, which I have not touched for a long time, merely sets the ruler color to the cursor colour (there could be a specific ruler layer system colour if it's useful?). It does not set the line width, so it inherits the line with of what was drawn immediately previously.
Obviously this ought to change and it should use the more recent method of setting layer display colours / fills / line widths. I'll get that done in the next release.
regards
Keith
I'm impressed!
BTW, you could put the call to cv.update() outside the two for loops to speed things up a bit, as it only needs to be called on completion of operations on the cellView.
The code is similar, so the fix will be the same. If it's OK I will leave this until 4.3.15 to fix as it's more an annoyance than a serious problem?
OK I can reproduce that. I've fixed it on Win32/64 and Mac and uploaded to the website. Version 4.3.14 still but with a compile timestamp of this afternoon.
Other platforms to follow…
Ah… Is the thing you are querying part of a pcell? Are you using pcells which modify their parameters?
Do the coordinates in the query window change? What happens if you hit apply instead of OK?
I am running on Mountain Lion 10.8.2 with the default Python here (2.7)
Assuming I am understanding you correctly and you have used:
# Create a pcell instance
k = cv.dbCreatePCellInst("default", "pcellname", "layout", origin)
# Set the pcell properties
k.dbAddProp(…)
# Update the pcell to reflect its new properties
cv.dbUpdatePCell(k)then k is a pointer to the instance of the pcell, and you can use:
k.Flatten(cv, dbTransform trans)
to flatten it, where trans is its transform e.g.
dbTransform trans(k.orient(), k.origin(), k.mag())
Just curious, what naming issue is causing the problem with other software?
thanks
Keith
It should be sufficient after making any changes to a cellView in a script to call cv.update() after all changes have been made.
This does the following:
1) recomputes and updates the cellview bounding box.
2) Forces an tree optimisation to take into account new shape bounding boxes in the tree.
3) Marks the cellview as edited (so you get warned to save it if you try and close it).
4) Updates the cellview modification date.I'll have a look at your example script to see if there is any reason why this might fail to update correctly. Objects that 'disappear' when zooming in are normally s sure sighn that the tree for the layer the object is contained in has net bee updated with its new bounding box.
cheers,
Keith
