Lisandro,
In the current model of initializations there are two submodels
1) no dynamic libraries (example Mat, others should be the same)
MatCreate() ALWAYS calls MatInitializePackage(). Inside
MatInitializePackage()
is a static variable indicating if initialization has take place.
The user is not allowed to call any other Mat... methods BEFORE
MatCreate(),
if they do bad things could happen. For example, you cannot call
MatNorm() if you
have not yet created a Mat.
2) dynamic libraries
when the libpetscmat.so dynamic library is opened by PETSc,
MatInitializePackage()
is automatically called. PetscInitialize() automatically opens all
the standard
dynamic libraries like libpetscmat.so
If the user calls any Mat routine before PetscInitialize() it
won't work. If the
user calls MatNorm() before a MatCreate() it will not work, but not
for the same
reason as 1), only because they are not passing a matrix in.
With python you care about the dynamic case: so long as your python
initialization
occurs after PetscInitialize() which it must and will ALL packages
have been registered
(unless we have a bug). So I think your code should be fine. You say
that you can use the PETSC_COOKIE of zero
to find such a bug, a pretty weak argument.
I don't like the idea of you using the MAT_COOKIE directly at all
for your cool
python dictionary building. Reason: it is not extensible. Some one
adds a new
ZAP_COOKIE and you don't know about it and when you find out you have
to go
change your code. Correct?
Here is an alternative model that I think is much better. Every
call to PetscCookieRegister()
actually registers the cookie (currently it is not recorded in any
way, it is only registered in the logging)
with the name; could be into something as ugly as a global array or
linked list. Your python "caster"
(each times it needs to cast) then could look in this global array or
linked list and do the
translation. This way your caster will always work; if later in the
run someone registers
new cookies your caster now has access to it. Now your python code
doesn't ever
need to see, touch or taste a XXX_COOKIE variable directly; I view the
global XXX_COOKIE variables
as private to that class implementation and really don't want any
other code outside that class
touching them directly.
Sound workable?
Barry
I am assuming that your Python caster only needs to know the string
name of the class (like "Mat") to manage the
caste. If it actually needs specific code written for each class then
I would like that specific code to be inside
that class and not managed in some central location (that is, it would
go somewhere in the src/mat/.... directory tree.
On Oct 10, 2008, at 1:31 PM, Lisandro Dalcin wrote:
> In petsc4py, I've just implemented support for compose()/query() in my
> base Object class. However, I wanted to implement query() in such a
> way that 'dynamic_cast' (in the C++ sense, i.e, downcast) the composed
> PETSc object and return to Python code an instance of the appropriate
> Python type. Then, if you compose() a Mat, then query() will return a
> Mat.
>
> I manages all this inside a private python dictionary mapping
> PetscCookie -> Python type. Of course, this required to make sure that
> ALL PetscXXXInitializePackage() have been called before adding stuff
> to my dict. All is working fine; moreover, this machinery is also
> being used in slepc4py and tao4py (yes, I have those...), then after
> importing slepc4py or tao4py, the dictionary is populated as
> appropriate.
>
> Then, the question are: Do this approach sound good enough? Is it too
> much hackery? Can I relly in the long future that this approach will
> always work?
>
> BTW, now I have a clear use case for initalizing all the XXX_COOKIE's
> to 0 in core PETSc. This will really help me to spot package
> initialization problems. In fact, I had to manage some of those
> problems in petsc-2.3.2, petsc-2.3.3 and tao-1.9 .
>
> PS: The renaming DA_COOKIE -> DM_COOKIE does not play well with all
> this, but I do not care about it right now.
>
>
> --
> Lisandro Dalc?n
> ---------------
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>
