Hi,
I have commited few changes to grass51:
1) Make
I have merged and modified
grass50/configure + grass51/notyetuploaded/new_makefile_system
Make system is not my hobby but it was impossible to compile grass51
in the new dir structure with old gmake system. Anybody can modify
and improve or completely rewrite that.
2) Debug
New function G_debug (int level, char * msg) prints message if enviroment
variable GRASS_DEBUG_LEVEL is set to level equal or higher.
My proposal for levels is:
* Levels: (recommended levels)
* 1 - messages printed once or few times per module
* 3 - each row (raster) or line (vector)
* 5 - each cell (raster) or point (vector)
and I use optional compilation (speed):
#ifdef GDEBUG
G_debug (1, "Vect_open_old(): name = %s mapset= %s", name, mapset);
#endif
3) Multiformat vector
I have built into vector library frame for multiformat support. At present we
have:
* native - read/write on level1
* shape - reads geometry of all types (point, line, polygon), for polygons
I want add some pseudo topological access i.e. areas can be
read, but correct topology is no available
* postGIS - written is only small test (read/write line geometry).
On PostGIS interface will work group of students
on "University of Sannio" lead by Professor Giuliano
Antoniol. They should start next week.
Non-native sources are defined in frmt file in vector dir, example:
FORMAT: shape
SHAPE: /home/radim/gdata/g4t/cmd/shpout/river
CAT_COLUMN: id
or:
FORMAT: postgis
DATABASE: pgis
GEOM_TABLE: t1
GEOM_GEOM: the_geom
First benchmark (native x postGIS)
50 lines (each 100 points)
Action native postGis
import 1 26
display 1 1
export 1 3
But !!! everything is done through text strings, it will be better in final
version.
4) Plans
During next days I want to modify native vector format according to
discussion in Trento (type as byte, shorter header) and then look at topo
file and try to update topology support for g51 and clean bit lib/diglib/
dir.
I think that we should open new mailing list for grass51 development
and possibly close some mailing lists with low traffic:
- Grass GUI (last message Mon, 5 Nov 2001 about gdal installation !!!)
- SQL Grass (19 messages October-December)
- NVIZ (no message abou nviz in archive)
Radim
Radim Blazek wrote:
2) Debug
New function G_debug (int level, char * msg) prints message if enviroment
variable GRASS_DEBUG_LEVEL is set to level equal or higher.
My proposal for levels is:
* Levels: (recommended levels)
* 1 - messages printed once or few times per module
* 3 - each row (raster) or line (vector)
* 5 - each cell (raster) or point (vector)
and I use optional compilation (speed):
#ifdef GDEBUG
G_debug (1, "Vect_open_old(): name = %s mapset= %s", name, mapset);
#endif
Too much of this can make the code messy. Parameter tracing is usually
better performed with gdb command sequences, e.g.
break Vect_open_old
commands
silent
printf "Vect_open_old(): name = %s mapset= %s", name, mapset
continue
end
Unfortunately, it isn't straightforward to set a breakpoint in the
middle of a function without using line numbers (which need to be
updated whenever the source changes).
I do think that we should have something similar to G_warning() for
user messages, rather than just printing to stdout/stderr.
--
Glynn Clements <glynn.clements@virgin.net>
Hi Radim,
On Sun, Jan 06, 2002 at 09:13:10PM +0100, Radim Blazek wrote:
Hi,
I have commited few changes to grass51:
1) Make
I have merged and modified
grass50/configure + grass51/notyetuploaded/new_makefile_system
Make system is not my hobby but it was impossible to compile grass51
in the new dir structure with old gmake system. Anybody can modify
and improve or completely rewrite that.
the new Makefile system runs well. Some updates have been necessary
(I posted to you personally), now the compilation is complete
including XDRIVER etc. The "make mix" does a well job to link the
5.0 into the new structure along with the new Makefiles. Thanks
a lot! This may survive for some time to avoid that we have to
maintain too many branches/trees.
So, I have compiled GRASS 5.1 according to the INSTALL file:
./configure --with-grass50=/full/path/to/grass50(MAIN)/source
make mix
make
and can start:
bin.i686-pc-linux-gnu/grass51
Welcome to GRASS 5.1 (January 2001)
Geographic Resources Analysis Support System (GRASS) is Copyright,
1999-2002 by the GRASS Development Team, and licensed under terms of the
GNU General Public License (GPL).
[...]
A question is now: Do we want a separate mailing list for 5.1 or now?
Votes are welcome.
Congratulations, Radim!
Markus
On Mon, Jan 07, 2002 at 03:24:06PM +0100, Markus Neteler wrote:
On Sun, Jan 06, 2002 at 09:13:10PM +0100, Radim Blazek wrote:
A question is now: Do we want a separate mailing list for 5.1 or now?
Votes are welcome.
No.
Congratulations, Radim!
Yes, good work.
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
On Monday 07 January 2002 13:20, Glynn Clements wrote:
Radim Blazek wrote:
> 2) Debug
> New function G_debug (int level, char * msg) prints message if
> enviroment variable GRASS_DEBUG_LEVEL is set to level equal or higher.
> My proposal for levels is:
> * Levels: (recommended levels)
> * 1 - messages printed once or few times per module
> * 3 - each row (raster) or line (vector)
> * 5 - each cell (raster) or point (vector)
> and I use optional compilation (speed):
> #ifdef GDEBUG
> G_debug (1, "Vect_open_old(): name = %s mapset= %s", name, mapset);
> #endif
Too much of this can make the code messy. Parameter tracing is usually
better performed with gdb command sequences, e.g.
break Vect_open_old
commands
silent
printf "Vect_open_old(): name = %s mapset= %s", name, mapset
continue
end
Unfortunately, it isn't straightforward to set a breakpoint in the
middle of a function without using line numbers (which need to be
updated whenever the source changes).
I do think that we should have something similar to G_warning() for
user messages, rather than just printing to stdout/stderr.
Yes, but I was thinking about user debugging.
It is often problem to reproduce the same bug on other machine with
other data. Then you have to comunicate a lot with user and possibly
exchange data.
Debugging with gdb may be complicated for common users. I thing that
reasonable output printed by G_debug may help in many cases.
Radim
On Monday 07 January 2002 14:34, you wrote:
Hi Radim,
Still this error is remaining:
make[4]: Entering directory
/amd/cage0/ssi/BIO/software/GRASS5.0.0/grass51/lib/db/sqlp/test'
make[4]: *** No rule to make target 'sqlp', needed by
/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/etc/bin/cmd/sqltest'.
Stop.
-> no Makefile in CVS, please upload (I guess you have it)
Commited.
Then I have fixed
tools/link.conf
for the current XDRIVER in stable branch. However, a library
link seems to be missing in Makefile. I can't compile that
yet.
It is impossible to have g51 compilable with both stable and devel branch,
and because devel tree contains new features we must link
g51 to g50devel !!!!
display/driver/lib is needed only because of driverlib.h and doesn't need to
be compiled.
Another suggestion:
Let us put the display drivers into lib/ as they are no modules.
I never liked them in 5.0 to live in driver/ directory.
OK, I don't insist on that location.
There is test location on:
http://www.raz-dva.cz/krakonos/g51test-1.tar.gz
Start grass51, select test1 mapset, go to location dir and try scripts:
./io
./display
(see README).
Radim
So far for now,
Markus
Markus Neteler wrote:
A question is now: Do we want a separate mailing list for 5.1 or now?
Votes are welcome.
I vote no. Anyone working on GRASS needs to know what's happening with
both versions.
--
Glynn Clements <glynn.clements@virgin.net>
On Mon, Jan 07, 2002 at 09:26:33PM +0100, Radim Blazek wrote:
On Monday 07 January 2002 14:34, you wrote:
> Hi Radim,
>
> Still this error is remaining:
> make[4]: Entering directory
> /amd/cage0/ssi/BIO/software/GRASS5.0.0/grass51/lib/db/sqlp/test'
> make[4]: *** No rule to make target 'sqlp', needed by
> /ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/etc/bin/cmd/sqltest'.
> Stop.
>
> -> no Makefile in CVS, please upload (I guess you have it)
Commited.
> Then I have fixed
> tools/link.conf
> for the current XDRIVER in stable branch. However, a library
> link seems to be missing in Makefile. I can't compile that
> yet.
It is impossible to have g51 compilable with both stable and devel branch,
and because devel tree contains new features we must link
g51 to g50devel !!!!
Radim,
sorry - that was not clear to me (please add a comment in INSTALL).
My suggestion is to immediately merge back the XDRIVER and monitor
to devel tree, then g51 and g50 are sync'ed again (and we don't
miss the important improvements in XDRIVER).
The merge back of the other modules may follow then after getting
this experience.
Glynn, what do you think?
display/driver/lib is needed only because of driverlib.h and doesn't need to
be compiled.
> Another suggestion:
> Let us put the display drivers into lib/ as they are no modules.
> I never liked them in 5.0 to live in driver/ directory.
OK, I don't insist on that location.
There is test location on:
http://www.raz-dva.cz/krakonos/g51test-1.tar.gz
Start grass51, select test1 mapset, go to location dir and try scripts:
./io
./display
(see README).
I will try that directly when the current problem is solved.
If we want to wait more time with the merge back, I will have
to revert my recent changes in grass51 to get it functional
against the current devel tree again.
Excuse me for this confusion,
Markus
Markus Neteler wrote:
> > Then I have fixed
> > tools/link.conf
> > for the current XDRIVER in stable branch. However, a library
> > link seems to be missing in Makefile. I can't compile that
> > yet.
>
> It is impossible to have g51 compilable with both stable and devel branch,
> and because devel tree contains new features we must link
> g51 to g50devel !!!!
sorry - that was not clear to me (please add a comment in INSTALL).
My suggestion is to immediately merge back the XDRIVER and monitor
to devel tree, then g51 and g50 are sync'ed again (and we don't
miss the important improvements in XDRIVER).
The merge back of the other modules may follow then after getting
this experience.
Glynn, what do you think?
I think that the complete merge should be done ASAP. The longer it is
left, the more work is involved, and the greater the risk that
conflicts will arise.
--
Glynn Clements <glynn.clements@virgin.net>