[Keith]

I actually reported a problem to the python.org developers, as it seems if you try and install Python for both 32 and 64 bit mode on a (in my case windows 7 64bit) PC, then only one of the DLL's gets installed. But they were adamant that the installer works correctly… the fact that the ActiveState installer always got things right suggests to me that the python.org installer has a bug.

[Keith]

Yes, the gui command 'ui::hierFlatten()' does a bit more than just call 'inst::Flatten()' In fact, inst:Flatten() creates a new instance in the cellView you specify. This is in a bit of 10 year old code to I'm not sure what my original intentions were… I'll review it and see if it makes sense to change the inst::Flatten() function to do what effectively you need.

Firstly it (ui::hierFlatten()) sets up the transform correctly.

Code:

orient = inst.orient()
origin = inst.origin()
mag = inst.mag()
trans = dbTransform(orient, origin, mag)

Next, it flattens the instance:

master = inst.master()
# iterate over all shapes in the inst.
lpps = cv.getLpps()
for lpp in lpps :
obj = lpp.first()
while obj :
obj.Flatten(cv, trans)
obj = lpp.next()

The other thing the gui call does is, after flattening, it deleted the instance. So you would need to do a

Code:

cv.dbDeleteObj(inst)

to delete the original instance…

[Keith]

Hi,

Thanks, this is the first feedback I've had that the move to Python 2.7 may cause some problems.

Can you check that you have (for 64 bit windows) a C:Windowssystem32Python27.dll file. It should be the same as the one in the distribution i.e. if you right click on it to show its properties, it should be size 2.84Mb create 19 Dec 2012 11:16:57

The corresponding 32 bit windows DLL somewhat confusingly goes in C:WindowsSysWOW64Python27.dll. If you right click on that one it should show you size 2.17Mb, created 19 Dec 2012 11:17:49

What could be a problem is that you might have the wrong version of the dll already in your windows folder. And if you invoke Glade from anywhere other than the installation directory, it may be picking up the one from the windows folder first. You may be able to run Dependency Walker (http://www.dependencywalker.com/) to find the conflict.

Any info put in the log file?

BTW the version of Python used to compile Glade (and the python27.dll distributed with it) came from http://www.python.org/download/releases/2.7/.

thanks

Keith

[Keith]

One other thing to watch out for on the Mac. If you have Qt libraries installed on your machine, and they are defined in the DYLD_LIBRARY_PATH environment variable, and they are of a different version to the ones shipped with the glade.app bundle, then you will most likely get a crash if you try and run Glade from the command line rather than click on it in the Finder.

The reason is that when clicked on with the Finder, OSX environment variables are ignored by the app, which looks for and finds the Qt libs in the .app bundle.

When run from the command line, the executable knows nothing about the .app bundle libs, and looks at DYLD_LIBRARY_PATH instead. And if e.g. you have Qt 4.8.2 on your system, but Glade was compiled with 4.8.6, it will print an error message to the terminal and die…

[Keith]

This version marks a departure from linking to ActiveState Python, and instead using python from http://www.python.org. The primary reason is that if you want to develop python scripts and pcells, you will need a python installation on your machiine, and it had better be compatible with the one Glade is linked to.

However, ActiveState no longer provide older versions of python for download for free for a while now. So for example if Glade is linked to python2.6 (as it has been for a while) or even 2.4 on Solaris, then the user has a problem in that a compatible python download is just not available.

Making the change was not as simple as I'd expected. On Windows, python.org provides Windows installers for the wn23 and win64 versions of Python 2.7.3. However, just as with ActiveState, the python build does not put the python27.dll in the DLLs directory of the installation, as you'd hope, but puts it directly in %windows%/system32 or %windows%/SysWOW64. Or so you'd hope, but it gets it wrong, at least for me. A bit of careful work with Dependency Walker was required to find out what dll was what.

Hopefuly the windows builds are fine now thanks to feedback from fvila who did the testing (I appreciate your help here). Ubuntu 10 and Centos 5 builds are also done; Centos 4 will be done in the near future. For OSX I have always used the native python 2.7. Solaris 2.8?… well lets see if python 2.7 will compile on it, if so it will happen, but Solaris is pretty much EOL these days.

Anyway, make sure you back up your old copy before downloading the new ones just in case… and if you have problems, please report or post them.

Lastly, Merry Christmas and a happy New Year for those that are taking holidays this December. I'm sure we've all deserved a break!

[Keith]

This version, like several before it, is focussed on fixing some tiresome crashes that have either been reported or found with the more extensive regression testing recently put in place.

As always though, if you get a crash, please send the crash dump file that Glade (usually) is able to generate. The crash dump file includes both the stack trace at the time of the crash, and the logfile, which gives a much better insight into why the crash might occur.

If you're getting a crash and need to send data but it is confidential, I am generally OK with signing a NDA (non-disclosure agreement) if it is reasonable. All user data is kept encrypted and will never be disclosed without the originator's express permission. My PGP public key is available on request for encrypting data before sending.

[Keith]

If you see a warning message if you start Glade from the command line on Mac OS X of the form:

2012-12-08 14:13:43.040 glade[37831:707] *** WARNING: Method
userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It
should not be used in new applications. Use convertRectToBacking:
instead.

Don't worry, this should not cause any problems. I have submitted this bug to the Qt folks and already got a patch for it which is applied to the version of Qt used to build 4.3.25, and will be in subsequent Qt 4.8.x/5.0.

[Keith]

Ah ok. They may have been copied from Linux to a Windows box at some stage which will helpfully put in a cr/lf sequence rather than just a lf.

It should be reasonably easy to clean out the offending character…

[Keith]

Hmm, I guess the lines are not blank but contain e.g. a cr/lf character…

[Keith]

4.3.24 has this fix now, plus several other bugfixes. It's currently available on win32/win64 and mac64; linux builds will follow in due course.

[Keith]

It's a trivial fix to ignore blank lines; it will be in the next release. Thanks for reporting it!

– Keith S

[Keith]

Hmm, thanks. That seems perfectly legal techDisplays() syntax and should parse OK – and if the packet name was not read in the display.drf, will give an error message.

What I've seen is that the display.drf gets parsed, but identifies no colors/stipples/linestyles etc – it normally prints the number if finds – and then of course when the techfile is parsed it will fail as none of the layer/purpose pair info from the display.drf was ever read.

Just removing the packet field as you mention will cause problems later when the techfile is read…

– Keith S.

[Keith]

I've heard from a couple of people about problems reading Cadence display.drf files leading to crashes, due to the fact the parser fails to identify layers/stipples/packets in the file.

Unfortunately all the examples I have work fine, so if you hit a crash importing a Cadence display file / techfile, let me know, and if you can send an example display.drf which fails to read the layer info, that would help (they do not contain any design or process data btw).

[Keith]

There is currently a known problem with the 'Create Layer' command in 4.3.21; it causes a crash.

To workaround, with a cellView open, run a Python script like this:

Code:

from ui import *
cv = getEditCellView()
lib = cv.lib()
tech = lib.tech()
lyr = tech.createLayer("myLayer", "drawing")
tech.setLayerGdsLayer(lyr, 999)
tech.setLayerDataType(lyr, 0)

The above will create a layer called "myLayer" with purpose
"drawing", and map this to GDS layer 999 datatype 0.

The bug will be fixed in the next release.

[Keith]

Yes, this is a real pain them not providing older releases. I keep dowloads of each release as it comes out, just in case.

We had some problems with AS Python 2.7 on Linux, so I rolled back to using 2.6 on everything except Mac, where 2.7 works fine.

[Author]

Posts