I'm going to work on PETSc's dynamic libraries support

[Lisandro Dalcin]

On Fri, Oct 17, 2008 at 8:25 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> On Oct 17, 2008, at 5:51 PM, Lisandro Dalcin wrote:
>
>> On Fri, Oct 17, 2008 at 4:47 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>>
>>> I guess it is ok to add them, but I hate to add stuff, you know.
>>>
>>
>> Just to make it clear, I'm not actually adding stuff.
>
>   I understand this.  I still don't like adding PETSc functions unless they
> are really adding some value. If the use of dlopen() currently in PETSc
> is just replaced by PetscDLOpen() I don't see it as worthwhile,

Well, you surely agree that making the code base cleaner and amenable
for future extension is always worthwhile, right?

> it is only
> worthwhile if you plan to use PetscDLOpen() in other places as well
> (and those other places also have to have a valid reason to exist distinct
> from the current use).
>

Indeed, and that's my intention. I want PETSc to be able to dlopen()
and dlsym() dynamic libraries completely unrelated to PETSc. As you
may guess, I want so dlopen() the Python library for bootstrapping the
loading of petsc4py.

Other use case in core PETSc: The PF implementation of type 'string'
is currently broken in petsc-dev. Unfortunatelly, I do not see any
testcases for PF of type 'string', so the problems never showed up. If
you want to know the details, just ask. A you said below, libraries
(and specially dynamic ones) are complex!!! At this point, fixing
PFSTRING is a low priority for me.

>   I know I am being a bit anal, but I believe 99% of people who do numerical
> computing are overwhelmed by complexity of libraries (and this is why
> some nice C++ math libraries are not used by many people) and I think
> PETSc is successful because we try very hard not to add stuff unless it is
> crucial.

Indeed.

> Numerical computing people are also stupid, in that complexity
> of a part of the library they will never use  (like sys) does not make the
> software
> harder to use for them but they irrationally cannot see this and think the
> package is too complex.

I really agree with you here. But we cannot stop the process of
improving and cleaning up the code base just because of the opinions
of those users, right?.

Perhaps we can (in the near future) move many uninsteresting stuff in
petsc.h and petscsys.h to some new xxximpl.h headers inside
include/private? Whould that help a bit?


-- 
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