- Change: New problem identified with the Python modules: each module seems
to be built as a complete binary, so all the static C++ initializers are
allocated in each module. In particular the C++ tree inheritance is built
for *each* module so we cannot longer uses the typeid() comparisons
across modules... It was used by boost::program_options to perform is
casts with boost::any and was starting throwing exceptions because of
bad casts. program_option was first initialized in "configuration"
first included by PyViewer then in PyCRL (see Utilities.cpp).
A first solution is to re-order the import of Python modules in
stratus1/st_model so that CRL is imported first.
The second is to not not link "configuration" with boost::program_option
as only the binary vlsisapd-conf-editor needs it.
That is a serious problem of which we must be aware and can cause further
strange behaviors.
Debug code used to diagnostic has been kept commented in the sources a
it may be needed again :-(
This behavior do not affect our singletons because they are part of
dynamic libraries that seems to be correctly shared between the various
Python modules.
- Bug: target_link_libraries() must be put back for OSX Snow Leopard
(doesn't seems to affect Leopard). As I do not have an OSX under
my hand it's untested and is likely to fail at that point.
* ./hurricane:
- Bug: In Instance, correct support for Instance::PlacementStatus::Code.
- New: NetExternalComponents python object wrapper, moves
getExternalComponents() from Hurricane module into that new object.
- New: Breakpoint python object wrapper, to allow stratus1 to stop each
times it calls the viewer.
- Change: In PyHurricane, UpdateSession is now a true object with static
methods.
- Change: In BreakpointWidget uses a local event loop mechanism that no
longer consumes 100% of a CPU while doing nothing... (copied from
Qt's sources of QDialog).
- export MousePositionWidget.h so pharos can use it (displays the (x,y) mouse position in status bar)
ADDS
- add a getOnPhysicalGrid() in DbU
- add getPhysical and getOnPhysicalGrid functions in PyDbU and also defines useful CONSTANTS
I rewrited everything like it was in Coriolis-1 (PyType_create) and reuse the precedent hierarchical system (PyTypeInheritedObjectDefinition)
With all these changes Pharos is able to run the same script several times without any error (and not only 7 times before crash)
Maybe there are still some bugs but it seems ok for the moment :D.
does not throw Error anymore but cerr and return
this way it is possible to execute python script more than one time
Adding trace information for DirectDeleteMethod
deprecated conversion from string constant to char*
still one occurrence of this warning, but I don't know how to treat
it between C++ and Python C API.
* ./hurricane/src
- Simplification of the Inspector internal mechanism. Simple, but with
more templates, means a slower compilation.
- The DbU::Unit problem : DbU::Unit are only typedef over long type,
so we cannot create a specific overload for them. Uses "getValueRecord()"
instead of "getRecord()"
- For HInspectorWidget add a "getClone()" method. Also add a global
object counter (for Record too) to track down memory leaks.
- Big rewrite of the HInspectorWidget : now do not leak memory like hell,
and only kept allocated the current Record and not the full stack
of them (instead, we stack Slots which are ligthweigh objects).
- Rename of "real" unit to "grid" unit.
- New conversion function "getPhysicalsPerGrid()" and associated
mechanism.
* ./coriolis/src/crlcore :
- Synchronise with the Hurricane modifications.
Jean-Paul Chaput
Damien Dupuis