[GRASS5] Re: GRASS - Prototypes and encapsulation

[B Drapeau]

--- 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'