[GRASS5] GRASS releases - some remarks

Markus_Neteler1 · March 17, 2004, 12:54pm

Hello developers,

another time I have received new developed source code
based on GRASS 5.0 - in this case the internationalization
of tcltkgrass and NVIZ.
I feel that we either need a release of 5.3 or that
we should somehow modify the web pages to make clear
that new developments should be at least based
on 5.3 (for vectors: 5.7).
Also, as posted earlier, I received other comments that
without an official release (of 5.3) they would stick
with 5.0.

Sounds a bit unfortunate to me, so let me put again
into discussion the suggestion to publish a 5.3.0 version.

[hey: 5.3 indicates *development*]

Look at the statistics (only HTTP, rsync/FTP not included):
http://grass.itc.it/webalizer/usage_200402.html#TOPURLS

-> Top 10 of 59396 Total URLs By KBytes (Feb 2004)
# hits
1 430 /grass5/binary/linux/grass5.0.3_i686-pc-linux-gnu_bin.tar.gz
2 353 /grass5/binary/windows_cygnus/wingrass_generic/grass5.0.2_i686-pc-cygwin_bin.tar.gz
3 283 /grass5/binary/windows_cygnus/wingrass_xserver/grass5.0.3_i686-pc-cygwin_bin.tar.gz
4 388 /grass5/source/grass-5.0.3_src.tar.gz
5 173 /grass5/binary/mac_os_x/grass5.0.2_powerpc-apple-darwin6.5_bin.tar.bz2
7 104 /grass5/source/grass-5.0.0_src.tar.gz
9 62 /grass5/source/grass-5.0.2_src.tar.gz

I can only see 5.0.x downloads in the TOP10 list.

While the nice features are in 5.7, most developers work in 5.3
and the users download 5.0

We should improve the situation and make available at least 5.3
to a wider audience.

Markus

Richard_Greenwood1 · March 17, 2004, 2:32pm

Markus Neteler wrote:

Hello developers,

another time I have received new developed source code
based on GRASS 5.0 - in this case the internationalization
of tcltkgrass and NVIZ.

<snip>

Yesterday I built new Cygwin distributions for 5.0.3 and 5.3. I am working on a 5.7 build. These are available at greenwoodmap.com/grass, or I would be happy to ftp them to you if you prefer.

The 5.0.3 bindist fixes three problems:
1. It includes Glynn's working nviz (I can not build a working nviz on my Cygwin installation, and I am not smart enough to figure out why).
2. It includes fftw
3. It includes gd, thus a working PNG driver.

The 5.3 bindist also includes Glynn's working nviz, fftw, PNG, and was built from March 13, 2004 snapshot.

There is a 5.7 bindist at greenwoodmap.com/grass build from an early January snapshot. You have a link to it from the binary distributions page at grass.itc.it.

Regarding the binary distribution directory at grass.itc.it, the 5.7 directory is named "5.1".

Best regards,
Rich

--
Richard Greenwood
www.greenwoodmap.com

Glynn_Clements · March 17, 2004, 2:52pm

Richard Greenwood wrote:

> another time I have received new developed source code
> based on GRASS 5.0 - in this case the internationalization
> of tcltkgrass and NVIZ.

Yesterday I built new Cygwin distributions for 5.0.3 and 5.3. I am
working on a 5.7 build. These are available at greenwoodmap.com/grass,
or I would be happy to ftp them to you if you prefer.

The 5.0.3 bindist fixes three problems:
1. It includes Glynn's working nviz (I can not build a working nviz on
my Cygwin installation, and I am not smart enough to figure out why).
2. It includes fftw
3. It includes gd, thus a working PNG driver.

FWIW, the 5.3 PNG driver should work fine with 5.0.3; i.e. you should
be able to drop the 5.3 driver/PNG.exe into a 5.0.3 installation
without any complications.

Is the 5.0.3 PNG driver built with GD 2.x? If not, it might be worth
making the 5.3 version available separately for any 5.0.3 users who
want to create 24-bit PNGs (GD 1.x only supports 8-bit PNGs).

--
Glynn Clements <glynn.clements@virgin.net>

Jean-Denis_Giguere1 · March 17, 2004, 4:19pm

Hi,

I'm working on a linux distro called EduLinux. It is developed at Sherbrooke University mostly for students of all ages and all domains. I have to package GIS related software for this distro. I wish to improve the use of free software in our departement of geomatic and I think that integration of GRASS and other GIS related software in an open source desktop system is a good way.

I would like to know wich version of GRASS should I include. Improve in 5.7 are great and we use a lot vectors in our labs (mostly ArcGis), but is it enough stable to use it daily ?

I have two weeks for packaging GRASS and related software (postGIS, mapserver, ...). Advices will be very appreciated.

Thank you,

Jean-Denis Giguère
President of the Sherbrooke University Undergraduate Geomatic Students Association
Developer for Edulinux

Markus Neteler wrote:

Hello developers,

another time I have received new developed source code
based on GRASS 5.0 - in this case the internationalization
of tcltkgrass and NVIZ.
I feel that we either need a release of 5.3 or that
we should somehow modify the web pages to make clear
that new developments should be at least based
on 5.3 (for vectors: 5.7).
Also, as posted earlier, I received other comments that
without an official release (of 5.3) they would stick
with 5.0.

Sounds a bit unfortunate to me, so let me put again
into discussion the suggestion to publish a 5.3.0 version.

[hey: 5.3 indicates *development*]

Look at the statistics (only HTTP, rsync/FTP not included):
http://grass.itc.it/webalizer/usage_200402.html#TOPURLS

-> Top 10 of 59396 Total URLs By KBytes (Feb 2004)
# hits
1 430 /grass5/binary/linux/grass5.0.3_i686-pc-linux-gnu_bin.tar.gz
2 353 /grass5/binary/windows_cygnus/wingrass_generic/grass5.0.2_i686-pc-cygwin_bin.tar.gz
3 283 /grass5/binary/windows_cygnus/wingrass_xserver/grass5.0.3_i686-pc-cygwin_bin.tar.gz
4 388 /grass5/source/grass-5.0.3_src.tar.gz
5 173 /grass5/binary/mac_os_x/grass5.0.2_powerpc-apple-darwin6.5_bin.tar.bz2
7 104 /grass5/source/grass-5.0.0_src.tar.gz
9 62 /grass5/source/grass-5.0.2_src.tar.gz

I can only see 5.0.x downloads in the TOP10 list.

While the nice features are in 5.7, most developers work in 5.3
and the users download 5.0

We should improve the situation and make available at least 5.3
to a wider audience.

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Richard_Greenwood1 · March 17, 2004, 10:51pm

Glynn Clements wrote:

FWIW, the 5.3 PNG driver should work fine with 5.0.3; i.e. you should
be able to drop the 5.3 driver/PNG.exe into a 5.0.3 installation
without any complications.

Is the 5.0.3 PNG driver built with GD 2.x? If not, it might be worth
making the 5.3 version available separately for any 5.0.3 users who
want to create 24-bit PNGs (GD 1.x only supports 8-bit PNGs).

Yes, my 5.0.3 is compiled with GD 2.x. However I have a new PNG related problem - when building 5.7 it fails in display/drivers/PNG. The full output is pasted below. There are various references to xdr_ types and functions. I have a current sun rpc installed.

Suggestion?

Thanks,
Rich

=== pasted compiler output ====

gcc -s -L/usr/local/lib -L/usr/X11R6/lib -L/lib -L/cygdrive/e/projects/grass/gr
ass57_exp_2004_03_13/dist.i686-pc-cygwin/lib -L/lib -o /cygdrive/e/projects/gra
ss/grass57_exp_2004_03_13/dist.i686-pc-cygwin/driver/PNG -L/cygdrive/e/projects
/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib OBJ.i686-pc-cygwin/Can_do.
o OBJ.i686-pc-cygwin/Clr_table.o OBJ.i686-pc-cygwin/Color.o OBJ.i686-pc-cygwin/D
raw_line.o OBJ.i686-pc-cygwin/Get_w_box.o OBJ.i686-pc-cygwin/Get_w_line.o OBJ.i6
86-pc-cygwin/Get_w_pnt.o OBJ.i686-pc-cygwin/Graph_Clse.o OBJ.i686-pc-cygwin/Grap
h_Set.o OBJ.i686-pc-cygwin/Panel.o OBJ.i686-pc-cygwin/Polygn_abs.o -lgrass_drive
r -lgrass_display -lgrass_raster -lgrass_gis -lgrass_datetime -lpng -lz -L/
usr/X11R6/lib -lSM -lICE -lX11
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(opencell.o)(.text+0x780):opencell.c: undefined reference to `xdrmem_cre
ate'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(range.o)(.text+0x231):range.c: undefined reference to `xdrmem_create'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(range.o)(.text+0x241):range.c: undefined reference to `xdr_double'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(range.o)(.text+0x258):range.c: undefined reference to `xdr_double'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(range.o)(.text+0x8bb):range.c: undefined reference to `xdrmem_create'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(range.o)(.text+0x8c8):range.c: undefined reference to `xdr_double'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(range.o)(.text+0x8df):range.c: undefined reference to `xdr_double'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(init_map.o)(.text+0xe2):init_map.c: undefined reference to `xdr_double'

/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(init_map.o)(.text+0x21a):init_map.c: undefined reference to `xdr_float'

/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(put_row.o)(.text+0xed5):put_row.c: undefined reference to `xdrmem_creat
e'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(put_row.o)(.text+0xf39):put_row.c: undefined reference to `xdr_float'
/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(put_row.o)(.text+0xf9c):put_row.c: undefined reference to `xdr_double'
collect2: ld returned 1 exit status
make: *** [/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin
/driver/PNG] Error 1

--
Richard Greenwood
www.greenwoodmap.com

Glynn_Clements · March 18, 2004, 5:14am

Richard Greenwood wrote:

> FWIW, the 5.3 PNG driver should work fine with 5.0.3; i.e. you should
> be able to drop the 5.3 driver/PNG.exe into a 5.0.3 installation
> without any complications.
>
> Is the 5.0.3 PNG driver built with GD 2.x? If not, it might be worth
> making the 5.3 version available separately for any 5.0.3 users who
> want to create 24-bit PNGs (GD 1.x only supports 8-bit PNGs).

Yes, my 5.0.3 is compiled with GD 2.x. However I have a new PNG related
problem - when building 5.7 it fails in display/drivers/PNG. The full
output is pasted below. There are various references to xdr_ types and
functions. I have a current sun rpc installed.

Suggestion?

/cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
ss_gis.a(opencell.o)(.text+0x780):opencell.c: undefined reference to
`xdrmem_create'

Short version:

Add $(XDRLIB) anywhere after $(LIBES) in the actual link command (the
last non-empty line in display/drivers/PNG/Makefile).

Long version:

This is due to an error in the 5.7 Makefile; libgis uses XDR functions
for storing FP values, so anything which uses libgis also requires the
library which provides the XDR functions (the $(XDRLIB) variable
exists for this purpose).

On Linux, the XDR functions are in GNU libc, which is linked
automatically, so forgetting to add $(XDRLIB) to the link command
won't actually cause any problems.

On Cygwin, the XDR functions are in a separate library (librpclib.a)
so, if the Makefile omits $(XDRLIB), the link will fail.

So, add $(XDRLIB) anywhere after $(LIBES) in the actual link command
(the last non-empty line in display/drivers/PNG/Makefile).

Ultimately, include/Make/Grass.make.in should be re-written so that
the definition of GISLIB includes $(XDRLIB); it already includes some
of its dependencies, but not XDRLIB.

OTOH, this approach can result in the executables having unnecessary
dependencies when the GRASS libraries are built as static libraries.
E.g. GISLIB has $(SOCKLIB) as a dependency, although that is only
actually required for the functions in lib/gis/unix_socks.c.
Consequently, all programs which use libgis will have a dependency
upon $(SOCKLIB), although most of them don't actually need it.

It's arguable that $(SOCKLIB) should be moved to the libraries which
actually use the G_sock_* functions (i.e. libraster and libdriver).

--
Glynn Clements <glynn.clements@virgin.net>

Markus_Neteler1 · March 18, 2004, 9:42am

On Thu, Mar 18, 2004 at 05:14:13AM +0000, Glynn Clements wrote:

Richard Greenwood wrote:

> > FWIW, the 5.3 PNG driver should work fine with 5.0.3; i.e. you should
> > be able to drop the 5.3 driver/PNG.exe into a 5.0.3 installation
> > without any complications.
> >
> > Is the 5.0.3 PNG driver built with GD 2.x? If not, it might be worth
> > making the 5.3 version available separately for any 5.0.3 users who
> > want to create 24-bit PNGs (GD 1.x only supports 8-bit PNGs).
>
> Yes, my 5.0.3 is compiled with GD 2.x. However I have a new PNG related
> problem - when building 5.7 it fails in display/drivers/PNG. The full
> output is pasted below. There are various references to xdr_ types and
> functions. I have a current sun rpc installed.
>
> Suggestion?

> /cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
> ss_gis.a(opencell.o)(.text+0x780):opencell.c: undefined reference to
> `xdrmem_create'

Short version:

Add $(XDRLIB) anywhere after $(LIBES) in the actual link command (the
last non-empty line in display/drivers/PNG/Makefile).

Fixed in CVS.

Long version:

This is due to an error in the 5.7 Makefile; libgis uses XDR functions
for storing FP values, so anything which uses libgis also requires the
library which provides the XDR functions (the $(XDRLIB) variable
exists for this purpose).

On Linux, the XDR functions are in GNU libc, which is linked
automatically, so forgetting to add $(XDRLIB) to the link command
won't actually cause any problems.

On Cygwin, the XDR functions are in a separate library (librpclib.a)
so, if the Makefile omits $(XDRLIB), the link will fail.

So, add $(XDRLIB) anywhere after $(LIBES) in the actual link command
(the last non-empty line in display/drivers/PNG/Makefile).

Ultimately, include/Make/Grass.make.in should be re-written so that
the definition of GISLIB includes $(XDRLIB); it already includes some
of its dependencies, but not XDRLIB.

OTOH, this approach can result in the executables having unnecessary
dependencies when the GRASS libraries are built as static libraries.
E.g. GISLIB has $(SOCKLIB) as a dependency, although that is only
actually required for the functions in lib/gis/unix_socks.c.
Consequently, all programs which use libgis will have a dependency
upon $(SOCKLIB), although most of them don't actually need it.

It's arguable that $(SOCKLIB) should be moved to the libraries which
actually use the G_sock_* functions (i.e. libraster and libdriver).

Glynn,

may I ask you to implement the suggestions? I don't know enough about
good Makefile programming to do it. Before making it worse, I would
like to ask you to fix the problem.

Markus

Glynn_Clements · March 18, 2004, 5:44pm

Markus Neteler wrote:

> Ultimately, include/Make/Grass.make.in should be re-written so that
> the definition of GISLIB includes $(XDRLIB); it already includes some
> of its dependencies, but not XDRLIB.
>
> OTOH, this approach can result in the executables having unnecessary
> dependencies when the GRASS libraries are built as static libraries.
> E.g. GISLIB has $(SOCKLIB) as a dependency, although that is only
> actually required for the functions in lib/gis/unix_socks.c.
> Consequently, all programs which use libgis will have a dependency
> upon $(SOCKLIB), although most of them don't actually need it.
>
> It's arguable that $(SOCKLIB) should be moved to the libraries which
> actually use the G_sock_* functions (i.e. libraster and libdriver).

may I ask you to implement the suggestions? I don't know enough about
good Makefile programming to do it. Before making it worse, I would
like to ask you to fix the problem.

I'm not sure that I know enough about 5.7's build system not to make
it worse.

The XDRLIB issue should be simple enough; anything which reads or
writes rasters uses parts of libgis which require the XDR functions
(opencell.c, get_row.c, put_row.c).

One issue is that it's hard to tell if it's correct with Linux, as GNU
libc includes everything which lives in $(SOCKLIB), $(INTLLIB) or
$(XDRLIB) on other platforms (except that $(XDRLIB) also incorporates
zlib, which should probably be a separate variable).

--
Glynn Clements <glynn.clements@virgin.net>

Markus_Neteler1 · March 18, 2004, 7:46pm

On Thu, Mar 18, 2004 at 05:44:51PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> > Ultimately, include/Make/Grass.make.in should be re-written so that
> > the definition of GISLIB includes $(XDRLIB); it already includes some
> > of its dependencies, but not XDRLIB.
> >
> > OTOH, this approach can result in the executables having unnecessary
> > dependencies when the GRASS libraries are built as static libraries.
> > E.g. GISLIB has $(SOCKLIB) as a dependency, although that is only
> > actually required for the functions in lib/gis/unix_socks.c.
> > Consequently, all programs which use libgis will have a dependency
> > upon $(SOCKLIB), although most of them don't actually need it.
> >
> > It's arguable that $(SOCKLIB) should be moved to the libraries which
> > actually use the G_sock_* functions (i.e. libraster and libdriver).
>
> may I ask you to implement the suggestions? I don't know enough about
> good Makefile programming to do it. Before making it worse, I would
> like to ask you to fix the problem.

I'm not sure that I know enough about 5.7's build system not to make
it worse.

Ok, I give up to ask for help (for now).

Whenever a user isn't able to compile *and* he/she reports,
we may catch it, otherwise not.

Markus

Richard_Greenwood1 · March 19, 2004, 12:25am

5.7 v.digit fails under Cygwin, error pasted log below. I built 5.3 and 5.7 from March 13, 2004 snapshot. Any suggestions?

Regards,
Rich

=== error log ================

child killed: segmentation violation
     while executing
"exec v.digit -n map=fart >@stdout 2>@stdout"
     ("eval" body line 1)
     invoked from within
"eval "exec $cmd >@stdout 2>@stdout""
     (procedure "Dm::execute" line 12)
     invoked from within
"Dm::execute $cmd"
     (procedure "DmVector::WorkOnVector" line 21)
     invoked from within
"DmVector::WorkOnVector $sel"
     ("vector" arm line 2)
     invoked from within
"switch $type {
         raster {
             return
         }
         labels {
             return
         }
         vector {
      DmVector::WorkOnVecto..."
     (procedure "Dm::edit" line 10)
     invoked from within
"Dm::edit"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .mainframe.topf.tb0.bbox2.b5"
     (command bound to event)

--
Richard Greenwood
www.greenwoodmap.com

Markus_Neteler1 · March 22, 2004, 9:38am

Rich,

looking at that message again: did you launch it from the
display manager? I think yes:

GRASS 5.7.-cvs:~/grass57/display/d.m > grep v.digit *
vector.tcl: set cmd "v.digit -n map=$opt($id,map)"

Can you please try to launch it from cmd line:

d.mon x0
v.digit -n map=fart

Does this work at least?

Markus

On Thu, Mar 18, 2004 at 05:25:37PM -0700, Richard Greenwood wrote:

5.7 v.digit fails under Cygwin, error pasted log below. I built 5.3 and
5.7 from March 13, 2004 snapshot. Any suggestions?

Regards,
Rich

=== error log ================

child killed: segmentation violation
child killed: segmentation violation
    while executing
"exec v.digit -n map=fart >@stdout 2>@stdout"
    ("eval" body line 1)
    invoked from within
"eval "exec $cmd >@stdout 2>@stdout""
    (procedure "Dm::execute" line 12)
    invoked from within
"Dm::execute $cmd"
    (procedure "DmVector::WorkOnVector" line 21)
    invoked from within
"DmVector::WorkOnVector $sel"
    ("vector" arm line 2)
    invoked from within
"switch $type {
        raster {
            return
        }
        labels {
            return
        }
        vector {
      DmVector::WorkOnVecto..."
    (procedure "Dm::edit" line 10)
    invoked from within
"Dm::edit"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.topf.tb0.bbox2.b5"
    (command bound to event)

--
Richard Greenwood
www.greenwoodmap.com

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

Markus_Neteler1 · March 22, 2004, 9:47am

Once again,

maybe we have a stdout redirection problem:

GRASS 5.7.-cvs:~/grass57/display/d.m > grep stdout *
d.m.tcl: puts stdout $cmd
[...]
d.m.tcl: eval "exec $cmd >@stdout 2>@stdout"

?

Glynn sent some remarks in
http://grass.itc.it/pipermail/grass5/2003-April/007725.html
http://grass.itc.it/pipermail/grass5/2003-April/007735.html
http://grass.itc.it/pipermail/grass5/2003-April/007754.html

but I don't know what to do (and have no Cygwin at time).

Rich, maybe you can try to modify display/d.m/d.m.tcl
accordingly and test it?

Markus

On Thu, Mar 18, 2004 at 05:25:37PM -0700, Richard Greenwood wrote:

5.7 v.digit fails under Cygwin, error pasted log below. I built 5.3 and
5.7 from March 13, 2004 snapshot. Any suggestions?

Regards,
Rich

=== error log ================

child killed: segmentation violation
child killed: segmentation violation
    while executing
"exec v.digit -n map=fart >@stdout 2>@stdout"
    ("eval" body line 1)
    invoked from within
"eval "exec $cmd >@stdout 2>@stdout""
    (procedure "Dm::execute" line 12)
    invoked from within
"Dm::execute $cmd"
    (procedure "DmVector::WorkOnVector" line 21)
    invoked from within
"DmVector::WorkOnVector $sel"
    ("vector" arm line 2)
    invoked from within
"switch $type {
        raster {
            return
        }
        labels {
            return
        }
        vector {
      DmVector::WorkOnVecto..."
    (procedure "Dm::edit" line 10)
    invoked from within
"Dm::edit"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.topf.tb0.bbox2.b5"
    (command bound to event)

--
Richard Greenwood
www.greenwoodmap.com

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Bernhard_Reiter · March 23, 2004, 5:57pm

On Wed, Mar 17, 2004 at 11:19:06AM -0500, Jean-Denis Giguere wrote:

I'm working on a linux distro called EduLinux.

Will it be based on a GNU/Linux system with completely Free Software?

It is developed at
Sherbrooke University mostly for students of all ages and all domains. I
have to package GIS related software for this distro. I wish to improve
the use of free software in our departement of geomatic and I think
that integration of GRASS and other GIS related software in an open
source desktop system is a good way.

I would like to know wich version of GRASS should I include. Improve in
5.7 are great and we use a lot vectors in our labs (mostly ArcGis), but
is it enough stable to use it daily ?

It highly depends on the intended audience and use.
Asking the user list might give better insights.

I have two weeks for packaging GRASS and related software (postGIS,
mapserver, ...). Advices will be very appreciated.

If you seek advice for other packages ask on the FreeGIS list.

Bernhard_Reiter · March 23, 2004, 6:02pm

On Wed, Mar 17, 2004 at 01:54:38PM +0100, Markus Neteler wrote:

another time I have received new developed source code
based on GRASS 5.0 - in this case the internationalization
of tcltkgrass and NVIZ.

I feel that we either need a release of 5.3 or that
we should somehow modify the web pages to make clear
that new developments should be at least based
on 5.3 (for vectors: 5.7).

The best would be to do both.
Changing the webpages probalby can be done quicker.

Also, as posted earlier, I received other comments that
without an official release (of 5.3) they would stick
with 5.0.

Not a bad attitude in itself, we have to accept that some users
are conservative. However they must be aware that we consider 5.3.0
quite okay and that 5.0.x might be more stable, but that also
includes stability of the "weaknesses" and "bugs".
Then they can decide for themselfs.

Sounds a bit unfortunate to me, so let me put again
into discussion the suggestion to publish a 5.3.0 version.

[hey: 5.3 indicates *development*]

Someone just need to do it.
As you might have seen, I would not contribute much to GRASS
development in the last weeks.
So I am not in the position to demand that anythink should be done.
However I see no tactical problems in publishing 5.3.0 tarballs
and target 5.4.0 as soon as we can after a reasonable testing period.

While the nice features are in 5.7, most developers work in 5.3
and the users download 5.0

We should improve the situation and make available at least 5.3
to a wider audience.

Richard_Greenwood1 · March 23, 2004, 8:09pm

Markus Neteler wrote:

Rich,

looking at that message again: did you launch it from the
display manager? I think yes:

GRASS 5.7.-cvs:~/grass57/display/d.m > grep v.digit *
vector.tcl: set cmd "v.digit -n map=$opt($id,map)"

Can you please try to launch it from cmd line:

d.mon x0
v.digit -n map=fart

Does this work at least?

Markus

Sorry not to follow up sooner. I have had little time.

Starting from the command prompt with a map= option, it will create the
new vector map if necessary, but then immediately causes a Segmentation
fault.

Starting it from the cm line without any parameters, or starting it
with d.m opens the initial dialog (in which the name of the input vector
is specified). Upon entering a vector map name and clicking Run, a stack
dump file is written out (no error message is displayed).

In your subsequent email you wrote:

maybe we have a stdout redirection problem:

GRASS 5.7.-cvs:~/grass57/display/d.m > grep stdout *
d.m.tcl: puts stdout $cmd
[...]
d.m.tcl: eval "exec $cmd >@stdout 2>@stdout"

Indeed there does appear to be a problem, I get:

   GRASS 5.7.-cvs:~ > grep stdout *
   out.txt:v.digit.log:"exec v.digit -n map=fart >@stdout 2>@stdout"
   out.txt:v.digit.log:"eval "exec $cmd >@stdout 2>@stdout""
   grep: test: Permission denied
   grep: test.txt: Permission denied
   v.digit.log:"exec v.digit -n map=fart >@stdout 2>@stdout"
   v.digit.log:"eval "exec $cmd >@stdout 2>@stdout""

I am sure this is rudimentary to most of the readers of this list, but I am lost here. Anyone want to give me a more verbose explanation as to where, and why, stdout is being redirected?

In the mean time, I will look thru the emails that you referenced:

    http://grass.itc.it/pipermail/grass5/2003-April/007725.html
    http://grass.itc.it/pipermail/grass5/2003-April/007735.html
    http://grass.itc.it/pipermail/grass5/2003-April/007754.html

Regards,
--
Richard Greenwood
www.greenwoodmap.com