[GRASS5] Some news: KerGIS
Thierry Laronde
tlaronde at polynum.com
Sat Jan 24 09:08:14 EST 2004
Hello,
Some may wonder, after the discussions held in the late november, if I
have made some vaporware announces and if actually something is done.
Short answer: YES.
Long answer follows...
0. Introduction
In the end of November 2003 I have decided that it was more easy to
start from scratch from the last CERL public release of the public
domain GRASS than to start to reorganize and fix the code in the current
GNU GRASS.
The reasons are the following:
- CERL GRASS was developped by a very small core team, focusing on
general programs and functions, and having explicit goals. That is:
this code was consistent. So it is far more easy to evolve a
consistent, "small" code, than to try to fix code gathered from
distinct sources, not having the same goals nor skills, and
developping for customed applications with no overview in mind.
- to make the code evolve, one needs an overview. The same premises
lead to the same conclusion: more easy to gain this overview with
the smallest set of consistent code.
1. State after 2 months (calendar) -- 1 month (real coding time)
My premises were correct. Indeed the code is consistent. "Old" i.e. pre
C standardization, yes ---and this is a pain by itself. But the project
conducted by Michael Shapiro and Dave Gerdes _was_ conducted, and they
have anticipated a great deal about things that were not obvious to
many by the time.
The fact that GRASS (and indeed, until very recently _this_ GRASS) is
still here is due to this far-sighted leading. It's normal that after
more than ten years, the same code is no more far-sighted... but this
can be in no way attributed to its creators, but to _us_ who have made
nothing of this stuff.
There are places ---mainly with the vector code--- where some
disorganization is found. But this is because all was under construction
or under reorganization. There are a lot of TODO, and some duplication
of code that have conducted Dave Gerdes to plan to strenghten the code
(creation of the digitizer library, reorganization of the digitizing
stuff with incorporation of LTPlus and so on).
=> I have fixed these while fixing the code and put the libraries
where they belong and created, for example, the digitizer library.
So after this time, and after fixing the things explained in details
after (in short, standard C and POSIX, fix the code ---so there
is no more warnings from the compiler--- first reorganization), _all_
the libraries of the not X code, all the programs from general, display,
fonts, vector are UP and RUNNING, fixed and compile with:
COMPILE_FLAGS = -O -fno-builtin -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror
except one (newly created file) defining the new function G_read_line
which replaces the limited and unsafe G_gets, with dynamic allocation of
memory to absorb a not limited line and handling signals, since I use a
non local goto and gcc issues a non pertinent warning [gcc is a great
tool, it's just unfortunate that one can not specify to not stop on
"may" errors].
Here is the list:
src/libes/btree
src/libes/ibtree
src/libes/linkm
src/libes/gis
src/libes/display
src/libes/dig_atts
src/libes/digit
src/libes/vector
src/libes/vask
src/libes/transform
src/libes/segment
src/libes/rowio
src/libes/raster
src/libes/lock
src/libes/imagery
src/libes/icon
src/libes/proj
src/libes/coorcnv
src/libes/bitmap
src/libes/D
src/libes/digitizer
src/libes/build
src/display/devices/lib
src/display/devices/XDRIVER
src/display/devices/monitorcap
src/fonts/for_grass
src/display/d.3d
src/display/d.ask
src/display/d.colormode
src/display/d.colors
src/display/d.colortable
src/display/d.display
src/display/d.erase
src/display/d.font
src/display/d.frame
src/display/d.geodesic
src/display/d.graph
src/display/d.grid
src/display/d.his
src/display/d.histogram
src/display/d.icons
src/display/d.label
src/display/d.labels
src/display/d.legend
src/display/d.mapgraph
src/display/d.measure
src/display/d.menu
src/display/d.mon
src/display/d.p.labels
src/display/d.points
src/display/d.profile
src/display/d.rast
src/display/d.rast.arrow
src/display/d.rast.edit
src/display/d.rast.num
src/display/d.rast.zoom
src/display/d.rgb
src/display/d.rhumbline
src/display/d.save
src/display/d.scale
src/display/d.sites
src/display/d.text
src/display/d.title
src/display/d.vect
src/display/d.what.rast
src/display/d.what.vect
src/display/d.where
src/display/d.zoom
src/general/g.access
src/general/g.ask
src/general/g.filename
src/general/g.findfile
src/general/g.gisenv
src/general/g.help
src/general/g.manual
src/general/g.mapsets
src/general/g.region
src/general/g.menu.region
src/general/g.tempfile
src/general/g.setproj
src/general/g.version
src/general/gis
src/general/manage
src/vector/v.alabel
src/vector/v.apply.census
src/vector/v.area
src/vector/v.build
src/vector/v.cadlabel
src/vector/v.clean
src/vector/v.cutter
src/vector/v.digit
src/vector/v.extract
src/vector/v.in.arc
src/vector/v.in.ascii
src/vector/v.in.dlg
src/vector/v.in.dxf
src/vector/v.in.tig
src/vector/v.in.transects
src/vector/v.mkgrid
src/vector/v.out.arc
src/vector/v.out.dxf
src/vector/v.out.moss
src/vector/v.patch
src/vector/v.proj
src/vector/v.prune
src/vector/v.spag
src/vector/v.stats
src/vector/v.support
src/vector/v.to.rast
src/vector/v.to.sites
src/vector/v.transform
2. Fixing: Goals and Method
I want the code to compile smoothly on any standard C and POSIX
platform. This is a portability goal, but a consistency one too: the
standard C prototypes are the correct way to ensure that the functions
are used the way they are designed to be [and I have actually found
programs where this was not the case!]
The implication are simple: support of TERMIOS and that's all, no
support for the deprecated and not portable setruid(3) and setrgid(3).
The method was the following.
First, since the amount of work is huge, I have started by discarding
all the code that was obsolete or useless. By principe, I have kept all
the CERL code, and review first the contrib sources. The result is that
I have discarded everything in the contrib sources ---limited use,
licence problems, poor coding--- but general programs found in
the SCS.
I have only kept devices that I plan to use: i.e. PostScript for
hardcopy, X for display.
This was the first simplification.
While fixing the code I have made further ones, deleting junks
(including a SPARC core dump file!), backup, saved,
duplicates, unused (and useless) files and kept only 1 version, the
latest one (if there are problems in the latest ones, this needs to be
fixed but it is useless to keep all the others).
If I found a program whose utility was doubtful AND poorly coded I have
saved it in my unlimited storage device: /dev/null.
Further more, I have kept only the "cmd" version, since the huge
majority of the programs already used the parser. So the files of the
program live now directly under its subdirectory and not in the
<program>/cmd. If the "interactive" version was totally different from
the "cli" one, i have created a new program: example (sole one at the
moment) g.region, where the "interactive" version is a menu driven one
=> creation of g.menu.region.
THERE IS NO MORE MAKELINKS DANCE.
If I found _inside a file_, unused portions of code I have deleted them
if they were useless, or resurrected portions that were usefull ones.
Example: v.digit
-> There were functions handy to identify (debug) one particular
element (and I was planning to modify the code to support this)
=> resurrected
-> There was one SCS extension usefull to everybody (Snap to line)
=> resurrected
Note: the original version do the Zoom is more handy and powerful
than the present ones (can widen the window i.e. see the whole map
with the portion presently displayed and can define a new zone)
=> this "original" version of v.digit is more handy than the
present one.
In mode details
2.A Algorithms
At the present no changes are attempted in this area so no bugs are
introduced while trying to suppress the old ones.
2.C Consistency
To ease the maintainance, there must be some style and some naming
conventions: I have modified the names so that a library is identified
clearly by a conventional prefix (gis had G_, I have created DZ_ for the
digitizer libray, B_ for the build one and so on).
General functions put in userland programs have been extracted from the
programs and put back in their libraries.
A first attempt has been made to avoid circular dependices between
libraries, and for example certain functions in GISLIB using VASKLIB
have been extracted and renammed and put back in VASKLIB, the goal
being, too, to avoid the ABAB dance when linking libraries with
reciprocal dependencies.
Headers have been created and standardized too with a common naming
scheme and so on.
Libraries and headers have been gathered in the correct places i.e. in
one place.
A common style is defined (beginning) for the name of files, headers,
the use of general functions (DEBUGF) and so on.
2.O Optimizations
"Early optimizations are the root of all evil".
Since I wanted to start by fixing the old code, I have, initially,
refrained from doing optimizations.
But I have finally decided to do the obvious ones (so obvious that these
should not imply new bugs).
The main optimizations are macros replacing functions simply calling
another function (without sharing static variables not accessible from
extern), and the suppression of GIS functions simply mimicking (with
limitations...) standard C ones (G_*alloc, string manipulations
functions). [not to mention in the case of the memory allocation that
some day one will want to "improve" them by doing a custom management,
and that programs were happily mixing G_*alloc with *alloc and free...]
AFTER THE FIRST TESTS, THESE SIMPLE OPTIMIZATIONS HAVE ALREADY
LED TO SPEED IMPROVMENTS
2.S Security
G_gets has been replaced with the secure (newly created) G_read_line
But the code remains unsafe, since there are a lot of sprintf spread all
around that don't limit nor check the amount of data they put in the
buffer
=> TODO
3. Future directions
I will continue to fix the code in this order:
paint (PostScript)
raster
sites
imagery
misc
and finally xgrass.
In the mean time (since the work is mainly boring, I need to have some
more exciting coding stuff) I will start developping new applications
in the DB field (where I keep strictly nothing).
Things to be fixed:
XDRIVER: only handle 8 bits depth -> improved, with GLX support
The combination is standard C, POSIX, X, GLX and Motif for the X
interface.
The goals are always:
0. Consistency, primitives not policies
1. Portability
2. Accuracy
3. Efficiency
4. Scalability
4. The name of the game
KerGIS
5. Licence
At the moment, BSD style one. The first public release will be done when
the code is fixed and the source tree reorganized.
To be continued...
--
Thierry Laronde (Alceste) <tlaronde at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
More information about the grass-dev
mailing list