[Keith]

I can't reproduce this on a Macbook Pro running Mavericks 10.9.5. I get:

Code:

>>> cv=getEditCellView()

>>> lib = cv.lib()

>>> lib.dbuPerUU()

1000

>>> lib.dbu()

1e-09

>>> lib.dbuPerUU(2000)

>>> lib.dbuPerUU()

2000

>>>

(not you can set dbuPerUU() by specifying an argument i.e. dbuPerUU(2000). Same goes for dbu() )

Now things may be different on Yosemite – the numbers you are showing appear to be the maximum for an unsigned 16 bit int (which is odd, as internally it's stored as a 32 bit int) and something near the minimum of a 64 bit float. Why I have no idea. I'll have a google to see if there are any known problems with Yosemite. I do have to point out that Glade is not currently built on Yosemite, and I'm not sure whether Qt will compile on it.

[Keith]

Hi Ewald,
Thanks for this info. It would appear that Ubuntu 14.04 is shipping with Qt 4.8.6 libraries installed, whereas Glade was compiled and linked to Qt 4.8.5 libraries.

From my understanding from the Qt docs (http://qt-project.org/doc/qt-4.8/deployment-plugins.html), the application should look in the $GLADE_HOME/bin directory first for the localtion of the plugin directory used (imageformats). And this should work, because the plugin used is in there.

If not found there, then look in $QTDIR/plugins. And of course that could be a different Qt version.

However I was only expecting glade to look for the imageformats/libqjpeg.so plugin. Looks like it tries to load a load of other plugins too (by setting export QT_DEBUG_PLUGINS=1 before running Glade).

So 2 possible solutions:
1) build Ubuntu 14.04 with Qt 4.8.6
2) ship all the required plugins the app tries to load, even though they are not all used.
3) Do both of 1&2.

This may take a little time, but in the meantime your workaround looks a good alternative.

– Keith

[Keith]

This version will have several important fixes to the geom… relational code to fix some long standing bugs.

The next priority is to speed up the geomConnect() extraction code. It's currently not that efficient and with some changes based on the above could be speeded up quite a bit.

[Keith]

OK the versions just uploaded (no version increment) should have rpath working…

[Keith]

I'll give it a try.

[Keith]

Odd. It looked OK in the makefile that qmake created… let me check if there was some mistake with the build…

[Keith]

The RPATH thing should work in 4.4.26 and later

[Keith]

Glade has been developed on Windows and ported to Linux on 64 and 32 bit versions (plus Mac and Solaris).

Now all the regression tests passed on Windows and Linux 64 bit, so I was not aware they might fail on Linux 32 bit… 2 tests did, and they were subtle ones. Windows 32/64, Linux64 and Mac use the SSE registers. But Linux32 with gcc default options doesn't – it uses the 387 FPU registers.

End result is some (small) differences when rounding coordinates in certain operations. The difference is minor (like 1 dbu) but its good to have found and fixed the problem. The downside is that Linux32 builds will not run on pre-SSE processors from 10+ years ago, but hey ho, that's life.

[Keith]

OK I'll try this in the next version and see how it goes. Anything to reduce the env var dependencies is a good thing.

regards

Keith

[Keith]

Thanks veganglade,

I am not familiar with RPATH I'll look it up. Does setting LD_LIBRARY_PATH not do the same thing? Or do you just want to avoid setting it?

[Keith]

There are several possible ways of providing the functionality you need:

1) a new function polygon::at(int index) that gets the point at the vertex given by index. It would be up to the user to check that index is valid i.e. less than the number of vertices.

2) A python addition to the polygon class getPoints() that returns a python array of the polygon points.

3) A polygon::points() function that returns a pointList object that can be iterated over.

Which do you think you prefer? It would be possible to implement one or more of the above.

(1) has been implemented in 4.4.22.

[Keith]

Hi Francesc,

I managed to look at this in a bit more detail. What you can do already is something like this:

Code:

# Imagine I've got a path in the variable path
poly = path.shapeToPoly(cv)

# Then poly is a polygon. Get the (Point *) array of points and the size
pts = poly.ptlist()
size = poly.nPoints()

# Construct a pointList from this (there should be a way of getting the polygon's own pointList directly, but this kludge will work until the next release)

ptlist = pointList(pts, size)

# Now access the pointList (an iterator will be provided in the next
# release to iterate points and edges of the polygon's pointList)
p0 = ptlist.at(0)
p1 = ptlist.at(1)

# etc…

regards

Keith

[Keith]

Hi Francesc,

I'll need to spend a little time looking at this. As you know, the poly.ptlist() function returns (in C++) a Point *, which is not so easy to use in Python. What I would need to give you is a function that returns a 'pointList' object which would be easier to iterate over in Python.

I'm on vacation at the moment so I can't promise anything before I return on 3rd August.

regards

Keith

[Keith]

There is an option on the export GDS form to output all cells (the checkbox 'All?').

This is the default option. However, if you uncheck it and specify the cell name(s) in the 'Cell Names' field, then only those cell(s) will be output. If 'Child Cells?' is checked, then subcells of the specified cell(s) are also output – else there will be just the cell data and no hierarchy.

Hope this helps

Keith

[Keith]

Just as a followup: there was a bug in the flattener. It expected a hierarchical netlist to have the leaf cells defined first, and lastly the top cell. This is the way many netlisters e.g. Cadence seem to work.

In this case, there were some problems:
1) the higher level cells were present first
2) There was no top level .subckt – just an instance XX1 of one of the subcells
3) there was no *.GLOBAL nets section so the power/ground nets were treated as local to the subckt they were in.

The netlister has been fixed in 4.4.21 to handle hierarchical netlists in any order.

There are one or two other fixes planned for the flattener:
– take the global nets from the LVS dialog and merge them in with the schematic netlist
– handle hierarchical netlists with devices other than mosfets and instances of subckts. Currently the flattener ignores R,C,D,Q etc devices!
This will be done when I'm back from vacation… along with Linux builds etc.

[Author]

Posts