[GRASS5] Re: GRASS - Prototypes and encapsulation

GRASS GRASS developer
1

Dear Bernard,

thanks for your mail! I hope you don't mind that I CC to
the GRASS 5 developers list as your mail is of interest
for a wider audience. Please subscribe to this list to
follow the discussion:
http://www.geog.uni-hannover.de/grass/grassdevel.html

Some comments:

On Sat, Oct 14, 2000 at 07:40:26PM -0700, B Drapeau wrote:

Good Evening Markus,

Ten months ago, I contacted you for
directions on how to contribute to GRASS.

I've been working away at other
projects and mastered perl in the meanwhile.
I came back to my first plan and
started to modify GRASS' source code.

I use perl to automatically insert tokens
in the C source files after a "brute force"
"ANSI"fication. I intend to reach ISO C compliance
and drop K&R syntax and anachonisms.

I'm half of the way through the construction of
a 5-pass "converter". The conversion process
will require hand editing. My project might
ease the standardisation, and modularisation
of GRASS. (The tool can be reused as many times
as you require.)

I would like to get your input on
future GRASS development.

-- Will there be a unified programming style
   in all modules?

Yes, this is our intention.

-- Will there be a standard documentation
   within the source code? (litterate programming)

In my opinion very useful as authors may change in
an open source project

-- Will GRASS be modularised and designed
   with reentrant and thread-safe programming
   interfaces (libraries)?

Again yes. Currently I cannot describe the status, probably
the others can say more?

-- Will GRASS support different natural languages?

Highly wanted! This will require a different concept of course.
Currently we are preparing GRASS 5.0stable which will be released
soon. This week, maybe the next we just concentrate on bugfixes.
Then a new CVS tree will be started with a reorganized
GRASS source code structure and other stuff. Details can be found
in CVS (documents/code_freeze.txt).

I would like to see GRASS with a complete
ISO C interface with multilingual support
(multibytes character sets and various locales).

Like me:-) As many projects already support multiple
languages, we can learn from them (at least me).

The first step is to define the programming
interfaces and the valid ranges for each
data types. The C compiler doesn`t work
with ranges. The prototype match in an ANSI
compliant source helps to detect errors but
doesn`t garantee there won't be wild pointers.

I convert the source with a perl script.
Then gcc and protoize to add ANSI prototypes.
Then ident to rewrite neatly the source.
Then lclint to find errors.
  (This is important to run perl scripts.)
Then a new perl script to analyse the errors from
lclint and protoize.
Then a perl script to rewrite the source.

My project is to define an automated
procedure to insert the advanced LCLint
tokens for enhanced validation.

Then using an external data type definition,
we could write some black-box tests.

I will investigate the use of GNU nana,
SWIG and doxygen.

I would like to see GRASS with
better abstract datatypes. It would be easier
to port to 32 and 64 bit machines and
support non-English characters.
By defining smartly the headers, the source
could easily be integrated with C++ and SWIG.

This week, I will write the error analyser script
to insert new statements in the C source.

The rough conversion compiles almost completely
but I don't know enough on GRASS to test my
modifications on a working dataset.

Just to know: Are you in sync with GRASS/CVS?
Generally platform independence is one of our aims.

I would like your impressions on my project.

Bernard Drapeau
bdrapeau@yahoo.com

Regards

Markus Neteler

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

2

Hi Markus, hi Bernard,

the CVS server is very slow now, so that i have time to comment on the
mail. Please consider my comments as my very personal opinion.

I think that in general the concepts Bernard considered are very nice.
But there are some problematic aspects.

At first i think that we have to define the programming style before we
start to modify the source (automated or by hand). We now have no style
suggestions/standards so that it is not possible for the authors to
confine to a standard (other than ANSI-C, with which not much is won). I
would ask to give the authors active right now the opportunity to revise
their own code before changing anything automated. ( I am scared that i
can not read my own code after that ...).

I personally feel that introducing standard documentation in the source
code will scare off authors and duplicate the effort with the GRASS
programming handbook. The whole handbook must be re-integrated in the
source in this case, which would be an herculean effort. Perhaps we can
find a solution at least for new library code. For modules i can not see
the advantage of this.

Concerning modularization: Again my very personal opinion: I believe
that the most important thing will be to allow shared libraries/dynamic
linking. This will reduce the size of the binaries and will reduce the
whole size of the grass binary tree dramatically. It will simplify
development, as changes in the library do not require the re-compiling
of all modules depending on that library. In my opinion we should first
implement this step and then discuss again if the trouble in splitting
the whole distribution is worth the effort. Space and download
considerations IMHO do not justify the effort (there are other packets
with less functionality and bigger size).

Language support: This includes two different topics: The language of
the interfaces (for the modules, tcltkgrass and the documentation) and
the output of multibyte characters/non ANSI characters on the CELL
driver (monitors). I think the second is more important. The first would
require some sort of "pluggable" language files, as i fear that a
complete implementation of internationalisation is too much work. This
is done very smart in TNTmips (sorry that i compare here with commercial
software), where users can provide text files with their own
translation. But with grass the approach has to consider the modularized
structure.

Reentrant and thread-safe programming: This requires some conceptual
changes to the libraries as far as i can see. But i do not know enough
on this to dig further here. We must define our goals here too, so that
authors can write new code without introducing new problems.

As a final clause i would ask not to start too many things at a time, so
that the single contributer is not overwhelmed with new things to learn.
This concerns only general changes that affect the whole source, not the
changes to libraries or modules.

Please do not consider this all as criticism, i would be glad to see
your improvements. But please use this list to discuss your improvements
first.

cu,

Andreas

Markus Neteler wrote:

Dear Bernard,

thanks for your mail! I hope you don't mind that I CC to
the GRASS 5 developers list as your mail is of interest
for a wider audience. Please subscribe to this list to
follow the discussion:
http://www.geog.uni-hannover.de/grass/grassdevel.html

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

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

3

On Sun, Oct 15, 2000 at 11:37:21AM +0100, Markus Neteler wrote:
<snip>

On Sat, Oct 14, 2000 at 07:40:26PM -0700, B Drapeau wrote:
>
> Good Evening Markus,

<snip>

> -- Will GRASS be modularised and designed
> with reentrant and thread-safe programming
> interfaces (libraries)?
Again yes. Currently I cannot describe the status, probably
the others can say more?

Making GRASS thread-safe might be a large undertaking. There is quite
alot of static variables both within libraries and modules to maintain
state information. These would have to be replaced with other
mechanisms (such as encapsulating state in an "object" structure).
IMHO, first is to get shared libraries going (libtool anyone?).

--
/bin/sh ~/.signature:
Command not found

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

4

Hi all.

I believe
that the most important thing will be to allow shared libraries/dynamic
linking.

I have lately been experimenting with building Grass DLL's under Windows. I
promised to comment to Markus, and in the end I have little to say in broad
terms other than to pose the question:

Do you want a monolithic library with every library function in it (eg
libgrass.dll), or a small one for each set of functions (eg libvector.dll,
libraster.dll, libdatetime.dll etc)?

If monolithic, then the source code can stay as it is. If not then a major
reorganisation, particularly in the vector subdirectory, is needed.

Under Windows all symbols need to be resolved at link time for a DLL, even
if only as calls to load other DLL's via interface libraries. Unfortunately
certain parts of Grass, particularly the Vector subdirectories are
interdependent and have different "prefix" functions mixed into the same
object files.

Another issue is whether it would be possible to separate non-Unix specific
code from Unix specific code, so that either MS Visual C++ or
gcc -mno-cygwin (or maybe even compilers for hand-held/palm computers, for
mobile data entry and GPS work) could be used to compile segments of the
library needed to write a completely new GUI, which would not be dependent
on the fifo system used by d.mon and friends.

Cheers

Mike Thomas.

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

5

Hello all

I basically agree with what Andreas has said but I want to add a couple
of points that I may be able to contribute.

Andreas Lange wrote:

At first i think that we have to define the programming style before
we start to modify the source (automated or by hand). We now have no
style suggestions/standards so that it is not possible for the authors
to confine to a standard (other than ANSI-C, with which not much is
won). I would ask to give the authors active right now the opportunity
to revise their own code before changing anything automated. ( I am
scared that i can not read my own code after that ...).

After the code freeze, I am willing to draw up an initial draft for a
programming style if people are interested.

Language support: This includes two different topics: The language of
the interfaces (for the modules, tcltkgrass and the documentation) and
the output of multibyte characters/non ANSI characters on the CELL
driver (monitors). I think the second is more important. The first
would require some sort of "pluggable" language files, as i fear that
a complete implementation of internationalisation is too much work.
This is done very smart in TNTmips (sorry that i compare here with
commercial software), where users can provide text files with their
own translation. But with grass the approach has to consider the
modularized structure.

Before Jacques Bouchard submitted his revised version of tcltkgrass, I
had started working on a new version that had the system you describe. I
know how to do it but it will be a tedious job to change tcltkgrass or
plain grass for that matter.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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