> o now MatNullSpace instances cannot be freed with > PetscObjectDestroy()... This change broke bad petsc4py Python+PETSc > refcounting management. BTW, PetscObjectDestroy() does not take a > pointer... And IMHO PetscHeaderDestroy should also take a pointer...
Thank you for the explanation. petsc4py relies on PetscObjectDestroy() which won't work when some destroys take & and some don't. I didn't know you needed PetscObjectDestroy() to always work. The correction solution is to switch to using the & in all destroys. It sounds like this has to happen sooner rather than later. Barry On Mar 24, 2011, at 11:28 AM, Lisandro Dalcin wrote: > On 23 March 2011 20:09, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >> On Mar 23, 2011, at 5:58 PM, Lisandro Dalcin wrote: >> >>> Are you going to rename MatNullSpaceDestroy -> MatNullSpaceDestroy_ >>> and add the backward compatibility #define? Changeset 1a6f5fc1c27b >>> broke petsc4py... >> >> No, it was changed to the &object paradigm. >> >> Basically what is happening now is that commonly used destroys are changed >> with the _ paradigm >> >> Uncommonly used destroy are fixed to use the &object paradigm. >> >> Don't like the fact that there are two paradigms well I could change >> everything to & immediately :-( >> > > Barry, whatever you want to do, please be consistent :-)... The lines > below are from MatNullSpaceCrete > > /* cannot use MatNullSpaceDestroy() as generic destroy function > because it takes pointer to the object */ > ierr = > PetscHeaderCreate(sp,_p_MatNullSpace,int,MAT_NULLSPACE_CLASSID,0,"MatNullSpace",comm,0,0);CHKERRQ(ierr); > > So now MatNullSpace instances cannot be freed with > PetscObjectDestroy()... This change broke bad petsc4py Python+PETSc > refcounting management. BTW, PetscObjectDestroy() does not take a > pointer... And IMHO PetscHeaderDestroy should also take a pointer... > > Barry, please, just reconsider this and make MatNullSpaceDestroy > follow the same pattern as Object, IS, Vec, Mat, etc. > > PS: I still think all this is going to be a mess... now one commented > about my previous proposal about a compatibility header. what's wrong > with that? > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169
