[petsc-dev] discoverability

[Lisandro Dalcin]

On 22 February 2010 17:12, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   Over 10 years ago we had support for exactly this. Each section bracketed
> by PetscOptionsBegin/PetscOptionsEnd resulted in a page of options one could
> select for in a GUI. This is what the dead variable PetscOptionsPublish is
> related to. It used the Alice Memory Snooper to communicate between the
> PETSc processes and a Tcl GUI. It was pretty sweet, but DOE politics killed
> the Alice Memory Snooper.
>

Here is Barry's announcement on NA Digest

http://www.netlib.org/na-digest-html/99/v99n20.html

BTW, I'm curious about these policies, but I understand you may not be
able to comment on that..

>   The PetscOptionsGetXXXX() were the old, non-GUI routines and the
> PetscOptionsXXX without the Get  were layered on top and set up the data
> that was communicated to the GUI services by PetscOptionsEnd_Private().
>
>   I think the way to resurrect it is by using the Zope stuff that we added
> to PETSc a few years ago and display the GUI's in a browser (with javascript
> I guess).

Pyjamas could be handy way to generate the JS part...
http://pyjs.org/showcase/Showcase.html

> This would give portability and not require the user to install
> any GUI packages. Roughly the PetscOptionsEnd() routine would communicate
> via sockets to the Zope server which would display and get back the options
> via HTTP and the users browser. What the GUI system does is present the
> options and allow the user to set/change the options database graphically as
> the program runs; except for actually sending/getting back the values from
> the server the code is in PetscOptionsEnd_Private().
>

Indeed.

>  Zope is pretty cool but the damn fools have only support for very specific
> versions of Python which pisses me off,

Me too... This is IMHO a serious issue. Moreover, IMHO, Zope is too
much heavyweight for the needs of PETSc.

> why should it be specific for what
> they do I don't know.

Zope is complex, so complex that standard Python shows its limitation,
and Zope relies in deep implementation details on CPython and the
Python's stdlib, hacking and monkeypatching on all these details. That
way the cannot easily move to newer Python releases...

Still some folks on Python-Dev sometimes put Zope as an example of
"how to do nice things without requiring the language to change"... of
course, I cannot buy these comments..


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