* Bug: In Hurricane::DbU, replace long by DbU::Unit (aka int64_t) in all
remaining occurrences.
* Change: In Hurricane::DbU::getValueString(), rewrite using ostringstream.
* Change: In Hurricane, in PyHurricane.h, PyAny_AsLong<> template to
convert any kind of Python integer into DbU, making sure we always
use 64 bits integers (long long for 32 bits and long for 64 bits).
PyDbU_FromLong<> template to peform the reverse, DbU to Python
integer in 64 bits (either using PyLong_FromLong() or
PyLong_FromLongLong()).
* Bug: In Isobar, in PyArg_ParseTuple(), never use the "l" direct
converter when reading a DbU. Instead read a PyObject then convert
using PyAny_AsLong<>. This ensure to never do a truncature.
* Change: In Hurricane Commons.h, even when cdebug print nothing, it slow
down the program (three times for Kite!). Create a macro cdebug_log
which calls cdebug *only* if the debug level is active.
* Change: In Hurricane, in Flags add operator overload for "int" type
and not only "unsigned int". Otherwise the compiler complaints about
ambiguous overload when using enum values which are considered as
"int".
Simpler code for the BaseFlags::contains() method.
Added implicit conversion from BaseFlags toward bool type.
* Change: In Hurricane, in Commons, complete replacement of the previous
two trace systems (trace & ltrace) by a stream-based one.
As it is a true object it is much less fragile than the one based
on defines (but maybe a little slower).
Define a reservation table for the trace levels for all the
Coriolis & Chams components.
* Change: All tools, use the new trace system.
* Change: In Isobar, the Python interface was not exactly mirroring the
C++ one, now it is the case. The Python code should look likes almost
exactly like the C++ one, the only differences remaining being due
to the languages respective syntaxes. Note that in the case of
constructor functions, it leads to a slightly longer notation in
Python that it could have been (mimic the ".create()" static
member). Main modifications:
1. Mirror the static constructor syntax with create():
Cell( ... ) ==> Cell.create( ... )
2. Correct hierarchy for constants in Instance, Net, Pin
& Transformation. For example:
Hurricane.PlacementStatusFIXED
==> Hurricane.Instance.PlacementStatus.FIXED
Hurricane.OrientationID
==> Hurricane.Transformation.Orientation.ID
Hurricane.TypeLOGICAL ==> Hurricane.Net.Type.LOGICAL
Hurricane.DirectionIN ==> Hurricane.Net.Direction.IN
* Change: In CRL Core, correction to match the improved Python API
in the configutation helpers.
* Change: In Cumulus, correction to match the improved Python API.
* Change: In Stratus, correction to match the improved Python API.
* Change: In Documenation, update for the new Python interface
(both user's guide & examples).
* Note: We must port those changes into Chams for it to continue
to run.
* Change: In Documenation, update the Python script support part.
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.
Jean-Paul Chaput
Damien Dupuis