[GRASS5] Re: GRASS - Prototypes and encapsulation
B Drapeau
drapeaub at yahoo.com
Thu Oct 19 22:36:40 EDT 2000
--- Markus Neteler <neteler at 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 at yahoo.com
>
> Regards
>
> 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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev
mailing list