[GRASS5] OOP and 3rd party libs

[David D Gray]

Andreas, thanks for your comments

Andreas Lange wrote:
> 
> 
> David D Gray wrote:
> 
> > 2. As an extension to the above there is the whole question of
> > linking to Fortran code. We already have some Fortran routines.
> > Do we have any Fortran developers? If I am right, this was
> > settled in the GRASS camp about 10 years ago - long before my time -
> > when it was decided as policy that future development would
> > concentrate on C and Fortran routines would be deprecated.
> > This is fine as far as it goed but I don't think we should
> > reject external Fortran routines if they do a specific job
> > more efficiently,  and in any case will be maintained by others
> > who have skills more appropriate to the task, eg. mathematicians.
> > I am thinking of things where heavy repetitive number-crunching is
> > involved - co-ordiantes transformations, as in projection support,
> > possibly, finite element analysis, stats or (as above) linear algebra
> > routines.
> 
> If some module/function/library is only available in Fortran and the
> code can be compiled with g77, i have no objections to including Fortran
> code. But maybe it would be simpler to convert the whole module with f2c
> to avoid possible compiling problems.

Yes, I notice now looking that BLAS and LAPACK are available as C code. 
CLAPACK has been converted with f2c, then altered to be more C-friendly.
If you are interested (or anyone else is interested) there is
information
about these and other high performance maths libraries on
http://www.netlib.org and its mirrors.

> 
> > 4. Then - how much do we want ot rely on third party libraries?
> > They will generally be maintained by others, though they will
> > be GPL/BSD licensed, so we should be able to modify/improve them
> > as we see fit, and return the results to the broader community.
> 
> If the library has real benefits for GRASS, is needed for a
> module/function in GRASS, gives better maintainability and performance
> and has a compatible License (GPL/LGPL/BSD/PD) we should include it.
> But i think that this cannot be decided in general, we should discuss
> this as needed.

To come back to linear algebra:

There was recently a debate about GRASS and parallel computing
systems on this list. This and other considerations show that
there is an interest in deploying GRASS on high performance systems -
not just linux PC's (or other PC's . . .). The advantage with things
like BLAS and LAPACK is that they are standards and it should be
possible to slot in versions optimised for high grade systems and
special tasks in place of the portable, general-purpose ones that
can be freely distributed from netlib. Of course I am not really
experienced here and I'm only repeating what I've read. There's
no reason why free GPL'd code like the GNU Scientific Library (gsl)
should not contain such special implementations, but the legacy
code is well ahead here, and if needed I see no problem with using
it as long as the license is compatible. 

[A general question - does it violate the GPL if someone links to
a non-free dynamic library on their own system, where the link replaces
a link to a free distributable implementation - but without the
need to distribute the special implementation? ]

> 
> > 5. Finally, what about OOP. DO we want to start developing OOP
> > rouitnes within GRASS itself. 
> ...

> I would like to program in a script language (i know tcl/tk and Perl,
> but both are not suited for GIS tasks) instead of writing C-Programs. I
> had a glance at Python and think it is worth learning.

I seem to recall some months ago I read somewhere, maybe on this list,
that there is a movement to get python scripting in ArcView? A possible
development would be code libraries and core stuff in C and provide 
python hooks for rapid deployment of _modules_. ie write the modules in
python, or whatever scripting language we use. This wouldn't need to be
done all at once. The code could be written at first on an experimental
basis and as the need arises.

Quite a few of the issues raised here do depend on resolving one
problem, that has also been discussed before, and that is
dynamic linking.

Best wishes

David



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'