[GRASS5] Migration to Trento almost done

GRASS GRASS developer
1

Hi all,

the GRASS migration to Trento seems to be always done:

- Hannover is a mirror of http://grass.itc.it now
  (the other mirror may continue to read from Hannover, otherwise
  rsync grass.itc.it::grass grass
  )

- mailing lists migrated to Trento

- automated update jobs (cronjobs) at Trento web server:

    - the GRASS 5 html pages updating from CVS [daily]
    - the winGRASS install docs from CVS [daily]
    - the GRASS 5 html pages package built [weekly]
    - CVS snapshot [weekly]

- Todo:
   - set up FTP space in Trento
   - create search engine at Trento
   - fix remaining URLs (tell me please, check at Trento site)
   - add formmail.pl to send html forms (bugreports etc)
   - what else?

So, hunting now for a glass of wine,

Markus

2

Markus Neteler wrote:

- Todo:
   - set up FTP space in Trento
   - create search engine at Trento
   - fix remaining URLs (tell me please, check at Trento site)
   - add formmail.pl to send html forms (bugreports etc)
   - what else?

So, hunting now for a glass of wine,

Markus,

so now when you have migrated everything so brilliantly
and had your glass of wine, would it be possible to release
GRASS5.0 so that we have one stable version? I have had
problems with people getting all kinds of versions of GRASS
and CVS updates so it has been hard to tell what works and what
does not.

you can have another glass of wine then,

thanks for everything,

helena

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

3

On Wed, Aug 08, 2001 at 09:13:55PM -0500, Helena wrote:

Markus Neteler wrote:

> - Todo:
> - set up FTP space in Trento
> - create search engine at Trento
> - fix remaining URLs (tell me please, check at Trento site)
> - add formmail.pl to send html forms (bugreports etc)
> - what else?
>
> So, hunting now for a glass of wine,

Markus,

so now when you have migrated everything so brilliantly
and had your glass of wine, would it be possible to release
GRASS5.0 so that we have one stable version? I have had
problems with people getting all kinds of versions of GRASS
and CVS updates so it has been hard to tell what works and what
does not.

you can have another glass of wine then,

The bottle is already bought!

So, what's remaining to do for 5.0.0?
Starting a list:

- GDAL changes need to go into release_branch
- NVIZ crashes on Redhat 7.1 (even I cannot use it any more :-(( )
- what else?

Markus

4

So, what's remaining to do for 5.0.0?
Starting a list:

- GDAL changes need to go into release_branch
- NVIZ crashes on Redhat 7.1 (even I cannot use it any more :-(( )
- what else?

one more:
- the src/libes/gmath/ contains routines to replace the
  "Numerical Receipes in C" functions. The "NR" use for GRASS is
  granted, but it is not GPL compliant.
  I have already been moving this numerical code from the individual modules
  to src/libes/gmath/ to assemple same functionality in one place. Glynn has
  been extending it. However, at time added new code to replace the NR
  functions is not used yet, but still the "old" NR functions are in use.
  This is the last GPL limitation in GRASS, eventually todo for 5.0.0?!

Markus

5

On Thu, Aug 09, 2001 at 10:42:43AM +0200, Markus Neteler wrote:

> So, what's remaining to do for 5.0.0?
> Starting a list:
>
> - GDAL changes need to go into release_branch
> - NVIZ crashes on Redhat 7.1 (even I cannot use it any more :-(( )
> - what else?

one more:
- the src/libes/gmath/ contains routines to replace the
  "Numerical Receipes in C" functions. The "NR" use for GRASS is
  granted, but it is not GPL compliant.

And even worse: It is not Free Software!!!

  I have already been moving this numerical code from the individual modules
  to src/libes/gmath/ to assemple same functionality in one place. Glynn has
  been extending it. However, at time added new code to replace the NR
  functions is not used yet, but still the "old" NR functions are in use.
  This is the last GPL limitation in GRASS, eventually todo for 5.0.0?!

We _must_ fix this for GRASS 5.0.0,
because it would render GRASS 5.0.0 non-free otherwise
and we could not distribute it.

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

6

Bernhard Reiter wrote:

> > So, what's remaining to do for 5.0.0?
> > Starting a list:
> >
> > - GDAL changes need to go into release_branch
> > - NVIZ crashes on Redhat 7.1 (even I cannot use it any more :-(( )
> > - what else?
>
> one more:
> - the src/libes/gmath/ contains routines to replace the
> "Numerical Receipes in C" functions. The "NR" use for GRASS is
> granted, but it is not GPL compliant.

And even worse: It is not Free Software!!!

> I have already been moving this numerical code from the individual modules
> to src/libes/gmath/ to assemple same functionality in one place. Glynn has
> been extending it. However, at time added new code to replace the NR
> functions is not used yet, but still the "old" NR functions are in use.
> This is the last GPL limitation in GRASS, eventually todo for 5.0.0?!

We _must_ fix this for GRASS 5.0.0,
because it would render GRASS 5.0.0 non-free otherwise
and we could not distribute it.

AFAIK, the list of affected functions is:

+ del2g - Used by i.zc, i.shape.

Not itself encumbered, but depends upon fft.

+ egvorder/egvorder2 - Used by i.cca, i.pca.

I've added new versions of these which use mat_struct. However, it
would probably be quicker to modify the new versions to use the old
prototype than to modify applications to use the mat_struct interface.

+ fft - Used by i.fft, r.surf.fractal.

Could be replaced with the FFTW library, but that solution:

a) adds another library dependency,

b) requires either that existing applications are re-written to use
the FFTW interface, or that we add code to convert between the
existing and FFTW interfaces (which might introduce inefficiency; I
don't know the semantics of the existing interface, so I can't tell).

+ gauss - Used by r.surf.fractal, r.surf.gauss.

Does anyone know of a GPL-compatible (GPL or public domain)
implementation of this function? If not, we would have to do without
it.

+ jacobi - Used by i.cca

I have a description of Jacobi iteration in one of my mathematics
textbooks, but I haven't been able to figure out how that correlates
with the existing code. Can anyone provide a precise description of
the intended semantics?

+ rand1 - Used by r.surf.fractal, r.surf.gauss, r.surf.random.

Free PRNGs are readily available; the most obvious candidates are:

1. The ANSI C rand() and srand() functions.
2. The BSD random() and srandom() functions.

1 is available on all platforms, but some implementations have poor
entropy.

2 may not be available on all platforms; it is available in BSD4.3
onwards, and in GNU libc. If it isn't available, 1 could be used
instead. Alternatively, the code could be taken from GNU libc.

Conclusions:

If non-GPL code must be removed for the 5.0.0 release, and time is
pressing, I suggest simply removing the offending code, and either
removing dependent programs, or disabling them in src/CMD/lists/GRASS.

I suspect that failure to work altogether is more likely to result in
a program being fixed than failure to comply with the GPL.

I'll work on egvorder/egvorder2 and rand1 initially.

I'm willing to work on fft/del2g and jacobi if someone can provide me
with test cases (test data and usage instructions) which exercise the
functions in question.

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

7

On Thu, Aug 09, 2001 at 12:56:43PM +0100, Glynn Clements wrote:

Conclusions:

If non-GPL code must be removed for the 5.0.0 release, and time is
pressing, I suggest simply removing the offending code, and either
removing dependent programs, or disabling them in src/CMD/lists/GRASS.

I suspect that failure to work altogether is more likely to result in
a program being fixed than failure to comply with the GPL.

A completly agree that we have to remove the code then.
Disabling will collide with the GPL.

I'll work on egvorder/egvorder2 and rand1 initially.

I'm willing to work on fft/del2g and jacobi if someone can provide me
with test cases (test data and usage instructions) which exercise the
functions in question.

Thanks for helping.
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

8

On Thu, Aug 09, 2001 at 02:34:05PM +0200, Bernhard Reiter wrote:

On Thu, Aug 09, 2001 at 12:56:43PM +0100, Glynn Clements wrote:

> Conclusions:
>
> If non-GPL code must be removed for the 5.0.0 release, and time is
> pressing, I suggest simply removing the offending code, and either
> removing dependent programs, or disabling them in src/CMD/lists/GRASS.
>
> I suspect that failure to work altogether is more likely to result in
> a program being fixed than failure to comply with the GPL.

A completly agree that we have to remove the code then.
Disabling will collide with the GPL.

Well, disabling important tools like i.pca would be very bad.
This would upset many users. We should try to migrate at
least the i.pca and i.[i]fft, maybe look at the others with
low priority.

> I'll work on egvorder/egvorder2 and rand1 initially.
>
> I'm willing to work on fft/del2g and jacobi if someone can provide me
> with test cases (test data and usage instructions) which exercise the
> functions in question.

Thanks for helping.

I volunteer for testing and suggest to use synthetic data (as proposed
here in another thread).

Markus

9

Markus Neteler wrote:

On Wed, Aug 08, 2001 at 09:13:55PM -0500, Helena wrote:
> Markus Neteler wrote:
>
> > - Todo:
> > - set up FTP space in Trento
> > - create search engine at Trento
> > - fix remaining URLs (tell me please, check at Trento site)
> > - add formmail.pl to send html forms (bugreports etc)
> > - what else?
> >
> > So, hunting now for a glass of wine,
>
> Markus,
>
> so now when you have migrated everything so brilliantly
> and had your glass of wine, would it be possible to release
> GRASS5.0 so that we have one stable version? I have had
> problems with people getting all kinds of versions of GRASS
> and CVS updates so it has been hard to tell what works and what
> does not.
>
> you can have another glass of wine then,

The bottle is already bought!

So, what's remaining to do for 5.0.0?
Starting a list:

- GDAL changes need to go into release_branch
- NVIZ crashes on Redhat 7.1 (even I cannot use it any more :-(( )

Markus, can you get it there installed on a single processor machine?
I will try to do it here next week - I cannot get to it sooner. I would
not
delay release because of this because it seems that it is only two of us

who are having this problem and it may not be GRASS problem.
BTW I am using Nviz here almost every day, I just make sure that I am
not
running anything when I open or close it.

Helena

- what else?

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

10

Markus Neteler wrote:

> > Conclusions:
> >
> > If non-GPL code must be removed for the 5.0.0 release, and time is
> > pressing, I suggest simply removing the offending code, and either
> > removing dependent programs, or disabling them in src/CMD/lists/GRASS.
> >
> > I suspect that failure to work altogether is more likely to result in
> > a program being fixed than failure to comply with the GPL.
>
> A completly agree that we have to remove the code then.
> Disabling will collide with the GPL.

Well, disabling important tools like i.pca would be very bad.
This would upset many users. We should try to migrate at
least the i.pca and i.[i]fft, maybe look at the others with
low priority.

> > I'll work on egvorder/egvorder2 and rand1 initially.
> >
> > I'm willing to work on fft/del2g and jacobi if someone can provide me
> > with test cases (test data and usage instructions) which exercise the
> > functions in question.
>
> Thanks for helping.

I volunteer for testing and suggest to use synthetic data (as proposed
here in another thread).

Here's an update.

I have re-implemented egvorder2, rand1 and fft. This allows i.fft,
i.pca, i.zc, r.surf.random and i.shape to be built without any
copyright issues.

The outstanding functions are jacobi, gauss and egvorder (the last one
is trivial, but there's no point until jacobi is done). This means
that i.cca, r.surf.fractal and r.surf.gauss still require non-GPL
code.

I wouldn't have a clue as to how to implement gauss, so unless someone
can find an existing GPL-compliant implementation, r.surf.fractal and
r.surf.gauss aren't going to make it into any 100% GPL distribution.

As for jacobi, I suspect that most of the effort is going to be
determining the semantics of the existing function. Jacobi iteration
itself doesn't seem that complex.

I've added configure tests for the FFTW library, which is required by
fft. However, the existing build process doesn't directly support
condional compilation according to the results of configure tests, so
I'll probably need to make fft() a stub function (which generates an
error at run-time) if FFTW isn't available.

I've also done some other stuff, mainly relating to PNG: added
configure tests for the PNG and GD libraries, modified r.{in,out}.png
so that they don't need the netpbm/pbmplus headers, and modified
PNGdriver so that it will output a (non-LZW) GIF file if the GD
library doesn't support PNG.

I'm waiting until CVS is fixed before committing anything.

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

11

Glynn Clements wrote:

I wouldn't have a clue as to how to implement gauss, so unless someone
can find an existing GPL-compliant implementation, r.surf.fractal and
r.surf.gauss aren't going to make it into any 100% GPL distribution.

Everything I've managed to find on the WWW about generating Gaussian
distributed variables uses exactly the same algorithm as gauss() (this
is known as the Box-Muller transform). Furthermore, I notice that
libg++ uses this algorithm for the "Normal" class (which implements a
Gaussian PRNG).

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

12

On Thu, Aug 09, 2001 at 12:56:43PM +0100, Glynn Clements wrote:

+ jacobi - Used by i.cca

I have a description of Jacobi iteration in one of my mathematics
textbooks, but I haven't been able to figure out how that correlates
with the existing code. Can anyone provide a precise description of
the intended semantics?

Glynn,

I don't know much about the intended semantics, but the jacobi() is
described here:
http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookcpdf/c11-1.pdf

Maybe this helps,

Markus

13

One more comment,

On Thu, Aug 09, 2001 at 12:56:43PM +0100, Glynn Clements wrote:
[...]

+ rand1 - Used by r.surf.fractal, r.surf.gauss, r.surf.random.

Free PRNGs are readily available; the most obvious candidates are:

1. The ANSI C rand() and srand() functions.
2. The BSD random() and srandom() functions.

1 is available on all platforms, but some implementations have poor
entropy.

2 may not be available on all platforms; it is available in BSD4.3
onwards, and in GNU libc. If it isn't available, 1 could be used
instead. Alternatively, the code could be taken from GNU libc.

My colleague recommends drand48() - maybe not surprising for you.
I don't know too much about this stuff.

Please keep in mind that drand48() is lacking on Cygwin and MacOSX,
compare for a workaround:
src/raster/r.mapcalc/mapcalc/xrand.c

Markus

14

Markus Neteler wrote:

> + rand1 - Used by r.surf.fractal, r.surf.gauss, r.surf.random.
>
> Free PRNGs are readily available; the most obvious candidates are:
>
> 1. The ANSI C rand() and srand() functions.
> 2. The BSD random() and srandom() functions.
>
> 1 is available on all platforms, but some implementations have poor
> entropy.
>
> 2 may not be available on all platforms; it is available in BSD4.3
> onwards, and in GNU libc. If it isn't available, 1 could be used
> instead. Alternatively, the code could be taken from GNU libc.

My colleague recommends drand48() - maybe not surprising for you.
I don't know too much about this stuff.

Please keep in mind that drand48() is lacking on Cygwin and MacOSX,
compare for a workaround:
src/raster/r.mapcalc/mapcalc/xrand.c

OK; I'll use drand48() if it's available. And fix xrand.c.

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

15

Markus Neteler wrote:

> + jacobi - Used by i.cca
>
> I have a description of Jacobi iteration in one of my mathematics
> textbooks, but I haven't been able to figure out how that correlates
> with the existing code. Can anyone provide a precise description of
> the intended semantics?

I don't know much about the intended semantics, but the jacobi() is
described here:
http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookcpdf/c11-1.pdf

That indicates that jacobi() is finding eigenvalues and eigenvectors.
In which case, doesn't eigen() do that?

Changing jacobi() to call eigen() instead is trivial:

  int
  jacobi (double a[MX][MX], long n, double d[MX], double v[MX][MX])
  {
    double *aa[MX], *vv[MX], *dd;
    int i;
    for (i = 0; i < n; i++) {
      aa[i] = &a[i+1][1];
      vv[i] = &v[i+1][1];
    }
    dd = &d[1];
    eigen(aa, vv, dd, n);
  }

However, I don't enough about i.cca (or the imagery programs
generally) to be able to test it.

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

16

Hi everybody,

I spent some time during my vacations in the Alps (as some
rest activity after wandering :wink: looking at m.in.e00
and solved two bugs :
- when you use an absolute path name, the grass file keeps
  a leading / in his name, which is an illegal character...
- when the number of points was odd in single precision,
  xmin or xmax and ymin or ymax were false.

I just updated the CVS tree (vector.c, main.c)

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

17

Dear developers,

since Glynn could eliminate the remaining "Numerical Receipes in C"
functions from the code, we seem to be pretty close to release!

So, anything really important missing? (yes, I have tons of Ideas, RT is
also there etc.).

But: Let's go for release.

Markus

18

Markus

did you get a chance to try the very latest changes that Bob made to NVIZ -

I did not have time to do it. It would be good to make sure that everything
runs OK.
I checked the bug tracking system and I don't see anything terribly
important
there - maybe others should check too (was the NFS problem solved, how
about r.cost
segmentation fault? v.in.shape dumps core occasionally, but that is
probably more data
than the program - it should just crash in a nicer way, but these aren't
crucial).
I think that you should release it so that we can have one stable version
and move on
to 5.1 as everybody seems to have lots of plans for new improvements
(including myself).

Helena

Neteler wrote:

Dear developers,

since Glynn could eliminate the remaining "Numerical Receipes in C"
functions from the code, we seem to be pretty close to release!

So, anything really important missing? (yes, I have tons of Ideas, RT is
also there etc.).

But: Let's go for release.

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

19

Helena,

On Wed, Sep 05, 2001 at 12:15:32PM -0400, Helena Mitasova wrote:

Markus

did you get a chance to try the very latest changes that Bob made to NVIZ -

I did not have time to do it. It would be good to make sure that everything
runs OK.

yes, sure! Bob did an excellent job, I think. The latest changes have been
cosmetics only (except the horrible (fixed) lat/long problem).

I checked the bug tracking system and I don't see anything terribly
important
there - maybe others should check too (was the NFS problem solved,

I don't know if the NFS problem is solved. We are using NFS here, so far
no problems. However, maybe our installation differs from the Trieste's one.

how about r.cost segmentation fault?

Even no idea, no problems here.

v.in.shape dumps core occasionally, but that is
probably more data than the program - it should just crash in a nicer way, but these aren't
crucial).

Yes, v.in.shape is still a bit weak (due to those ugly data). However, David
is offline for some more time. Volunteers?

I think that you should release it so that we can have one stable version
and move on to 5.1 as everybody seems to have lots of plans for new improvements
(including myself).

Helena

Yes, it's almost getting too much new ideas :slight_smile:

Other comments?

Markus

Neteler wrote:

> Dear developers,
>
> since Glynn could eliminate the remaining "Numerical Receipes in C"
> functions from the code, we seem to be pretty close to release!
>
> So, anything really important missing? (yes, I have tons of Ideas, RT is
> also there etc.).
>
> But: Let's go for release.
>
> Markus
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

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

20

Hi all, Hi Markus,

Markus Neteler wrote:

> I checked the bug tracking system and I don't see anything terribly
> important
> there - maybe others should check too (was the NFS problem solved,

I don't know if the NFS problem is solved. We are using NFS here, so far
no problems. However, maybe our installation differs from the Trieste's one.

What was the NFS Problem? It works here with Linux and IRIX as NFS
Server and client. Its hard to say something if i do not know the OS and
the exact problem.

> I think that you should release it so that we can have one stable version
> and move on to 5.1 as everybody seems to have lots of plans for new improvements
> (including myself).
>
> Helena

I vote for releasing next week so that there is some time to do a final
check. I still can not compile the PNGdriver on Linux and cygwin.

cu,

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net