--- Markus Neteler <neteler@geog.uni-hannover.de>
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
Some comments:
Good Evening,
I've got intermittent connexion to the Internet.
I use Sneaker Net once a week
to download files.
I will not have access to CVS.
I will not upload directly to CVS.
For the moment, I only surf at the university
until the computer services close the labs.
Then I will need another "big drive", to
dump GRASS and bring everything home.
I slowly modify GRASS' source from the 5.beta8
snapshot. I will release some scripts
to scan and modify GRASS.
The scrips will only produce coherent
source modifications, an improved Lint
to tweak a protoized code.
The first conversion step is to insert
as many prototypes as possible and
integrate abstract data types:
color-types, pointers, cell-types,
generic vector-types, coordinates-types,
temporal-types.
Later, the source might be decyphered
and converted in dynamic libraries.
Swig is a great product to plug user interface
to a back-end core. It simplifies the
user interface design and enhances
the data abstraction barriers.
www.swig.org
I will not subscribe to the mailing list
for the next 2 months since my internet
access is intermittent.
I will get back to the mailing in December.
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.comRegards
Markus Neteler
__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
http://im.yahoo.com/
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'