[GRASS5] new Linux Binaries

GRASS GRASS developer
1

Markus,

Can I recreate the Linux binaries with the May 20 snapshot, or should I use a
new snapshot with the latest changes ?

Moritz

From neteler Wed May 30 15:29:06 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id PAA25616; Wed, 30 May 2001 15:29:06 +0100
Date: Wed, 30 May 2001 15:29:05 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] s.label
Message-ID: <20010530152905.C24189@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <01053014421700.11764@blazek>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <01053014421700.11764@blazek>; from Radim.Blazek@dhv.cz on Wed, May 30, 2001 at 02:42:17PM +0200
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 4525
Lines: 80

--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, May 30, 2001 at 02:42:17PM +0200, Radim Blazek wrote:

Hi,

where is s.label?

Hi Radim,

find attached (from 4.3). It needs to be updated to 5.0.

Cheers

Markus

--2fHTh5uZTiUOsy+g
Content-Type: application/x-tar-gz
Content-Disposition: attachment; filename="s.label.tar.gz"
Content-Transfer-Encoding: base64

H4sIAJz9FDsAA+0aa3PbNjJfzV+x0aWJ5FIK5WcqTzuxbFn2jK14LF/vfL2OBqIgiTVJsCBo
W+nkv98C4EsU5Thpk8xNuWkNAfvAYnex2oUdtlwypu7rZ18QLGvH2t/dxdGy9vd21Nje0WMM
z6z9bWu3vb+3t7X1zGq39/e3n8Hul1QqgSgUhAM886mgLuWP0FEefg2Fvi6Esf/jsXXVOzy+
6P21e1hty9qL/V3i//ZOGz/vI257e39nC+MEV/b2noH116pRDn9z/59w5sGMkzBsuk4owia7
9yl/6zHmt2xqU94i3Fu0PMeFE+7AkAawtQ3WDx1rF46Or6H9ww87xjAa/0Zt0YGhI2j4yn+l
Yik0rmjgLprXrKN3iNQWZbKNFRryUNy+/ji+YRwTQTtSS1OqKDWVykF7r2Ntd3Z34Htry7Kg
ftG7huPhdcMwTllAp5HrLkDMnRDuHdcF6k+AwNgRwKYw5TI6hMN8RIo5hPJ4QJBEH7ADZxBE
wiAQXx8IOEM1PUAOpe5rx7eZ5/gz3III8MitFAABcXyhhTSnjktxJ3QDURsYyg9ql7vWXQuM
U3KHBFGsgyOeG8bl3HGdAH6mfE5m1DeaTcMwYA0MQYADNszViIoBXMEh/rssYbqiMzwuIS4c
cntOmctmTmjP1cy5oxyPEsIlZ7/RW2EYZMJpiGZI4NIlvkCN4CJyJpSjCey5gPbOyjZtq/0G
rn+GQy8UlE+It0JxfdqDQQ9/Xp0fDo6HRjBnPs12gvp2uwFbFuxu7cLum+1dY0oeOnkBBYId
gzY94rgZjceEoG8fwh3iui3fNYxvfRe/BST5vy9DU4biF9jjI/kfr+V2If9v7+63q/z/NeDy
6l0ffoQX9e7ZYHT0bnB9ddYdHV0cN5KKwDBe1CVRo5MkuRZD8v7Z8Pys2zA2uAfNKZAWiwS8
eGtsvKgfHTWQ4Pz45PywP2yUc3l3Gcu3NsHfGor1n/0F9nj8/uOXsrVbvP87u1Z1/78GvN78
bHhtvN5cV3N8DBLmpG76LObD88vTw7TkmjIO/avD4RB2Wu2PM/8ptc+x1AwFYD0UYrXUietN
Qb0x5brq/FI7jxcdKFR/T2ceCgfrMVmNXh0eXn7izutquycxr9R7n7JzoRT8NLULVd6nMX8W
FGN7qehv6rVi0Q+y6M8zR6FuGihMaGhzJ1BdCAlB0AdxoBAyI4FNfAgDajvTRcaMRwWmOEJ1
LSR1tm8L3ikc0Z1PLCgzGKq7pFWs5or6f63B/kQaMv6BXZYbTSjUsFlpzWuGgZW+D3XCZ7YJ
+POuYciGS84PDHuOCX9zUy4fGMYfhkI5B8aERWM8FiWhMMFnXMwPjKnLsG3rmTCI+SaR5y1+
eWP9aipPyE+JROkoEzanzBfxEuV85IWzX/ArLqW6IEFIE4Lzs0FPizBOzs57sKn7yoN4pvpN
xIWCR7aI3Qab55JIuuCgiFH99xLmxCUz2LyiMlWt0v+bTadKm8L6zZr1KzqlnPr2qqQTderC
4uVwVLp+hG0lL1H+/arcfzkT6YfC6qldKuH0vpS6W07dZRzz2Mryu4D8HqEiRn+E0eT4jpBx
dPeL9WsDF1MLY9HcH02wZfLpSN+1OuJTdPOnW7pAmpryYW0Jk7/RSDEgHpWvDbk7t0wvFoHc
7vrmsjcaYoE+6C+hOf09cjidIMlNb4g6pvFRrmOKTnVUUVdbwqzVsZgGltnKVM2hV1SNAzOv
6BQjVqoZoxIlX/FXubWCehcyZ+nXGZWtspcVVM+Io7zcGjEytcWDntdymMJm77Q0bQJMMw/N
CZ7Jlug8V94UZ4PrXr93lcMSP7zHrIvipIY3j2l4U9BwkWp480QNF0sa3jyq4U25hunNL9cx
Rada8mSltoQtaJqJDRj6TyuYIy+Lpxw609GmPhYWy8zJV2CKNl06FSZ3ZnNhRkEgF9i94jJk
nio/msSkp5LJvZasFc5ykseVKa4xmc7YefgTwicpU07hBGfaC+64tjljYj4bCz1yPToCR07p
rR0PoQkzzultoOeh6QjiOradjMkC2oB5xLfjIdTjRA+BHlCWPp1t6lEmMSPO6OWWipGpsYJw
FNsrxRRMdslCMVQLICmhLqsVLEf0U2cQtjwSNA5g0Oq2pDYUi92JEwYuWejX2jGV4Z3YSsl4
nt+uzAspMmftU+reUSyOiZl+anaZO8lN341dB78XCgTJ6rXj0bB5JQ0Xf1bs+uOZMnpuPV44
YhF3MAjjUbPkJ4n04cIbM9c8vMMKvI8HpYhlt8V5Qp1bPqaeU5wnZJIF1dU0+UmsXbJ0rq7L
0iymyEwxIJyz+5WFog3j1VVT5sgT5IDeH+GljfhiaM/d8W1s3JXlWJeVdbV16WrMcUlcgr0Q
iwWn0yI6x/IfEkyP5nhjKF80L+jEiTyNqanK4P3aouB9vh54T2vJWuE6qG9KkBRQx7jG4G9G
WH+EjZShNGVrVJZX2paVMuSCvN1EhMQYqv4q11WhUmVV4VRLVwvqXmMBDAWSshsXozIFxy6x
bzOenI5YehFTofEnRsEYw8LHHIgOwoZzofKa/EgXpuNPnBkzPdkCC2IC48SfUTOIeOBSE4sM
885hLhXmPSZKai6oi8lenl6VlOWnV6j09KqarKWrRWchKygSWRjJZgDqzMeWSuawQGYuYJEI
ItHIRJS6L8bl/JcxFN0n9dfFb/kBNC49wTzxTrJeOMMp3mZX3mjtRt0sPn6SRFKZoxNcdhSf
+TTHlDuOxJhfw926KVhjrvslh88Tjyfrj7p8XjDeIza7f8T9CTIzmpVjyVnMSgKg+0gAdJcD
YIymnXEW+bLI6JYHQTelSS9z9xEnd9c5ufsNnax7uTUmUbjMJGpay9aL5tCiUlPEVKWmiHGr
pogR38IUun8tN4XGpaZgalrL1ot9hBYlGNxh95CGOKculTUFOFMYF4IHnBBCxNuCTho5yWXm
S3CZ+RaqVU7Wc9ZDhOkzeTzcs94fBYTLR6vcCw808B99cDB3NdvQiCnThjHe4/mPMPjn+XkD
/jDkg5V66yp/l8vev+QL04Z+tlFWRZtORoqwXlO8r/WrTc2EXKurNzSxe0JdNqQuiYhMhY2N
MOAoAJHxUxHSXxbV+S4En8kCGY38/L9+2TZyiw3UjGA1MkJR0lWxRFC4D3gEraU+AguoP8LC
5klH0IpLObrFziSo+cin91DPPUgkfP2RpzjrDemODQcZ2ygEA1babjqjIoS6fAIz4Y1lxn9T
0cj7CA2EnYA9x3JIT22CzUG7o5wXhjbxpzBhVBuI2DbFRkJFWvyWJ5Ox42MWhufxE6UKYEpQ
5NTh8qEvpDaTf/OB/7f3MLG7MscTrl47HNk00iQEUBm9Y6xzDR3z3RRNpt4ETXjZU6bekA+I
eNS61qHRU4vO99+rccwpuT1ITrLVeYLYgRarXiRzcgePyG3vrRMcZoLlF33jMSH72s5kKuRv
NfZj45hwz+XdUBdEmk0GtY3BKWSiaCe2wjsaCRUgUFdhYuZfVpd2j+Mitz8mLhK5opNT7oMh
/9vYMDY4xYLeh7olowoDG4OGyvu87o7K3Ufqj2rw7CVh+sk3dJimhtWruSL/SVez/F6p+1mi
cHYfV660uoofvdLScOhYe07tW5nEVe8dzlmEG2JLXezKlUelfdLWuZhN+6NQcDtYQP2l5DAL
hFJV5aUiXYFIKqWDK05/aCx1V1UY6V+J2MyTbxVNdU/1bz4cOkl/3aF0jTNMf4QpZjkEX+oY
fBkH4Uv5hdeAn8AC7e1p4m1tPHS2ZOjghVTelRPltFU6JTElVLM1lPELI9KGirbwJriGa1Hg
unkSF6fTlGPl3WwNj/RMyqT8tIZQfeGnlEtd3hoO2dqmDPm2dQ29KoJThqVGaQ3HfFmp5Y5k
Hc/yNssF+RqerO5J+bpP2UtXnxnPUgW5hkeXaZpHcS0XTmu4ZILN8ahI1/kmn0Bx+qH6C5wK
KqigggoqqKCCCiqooIIKKqigggoqqKCCCiqooIIKKqigggoqqKCC/1/4HyRy4loAUAAA

--2fHTh5uZTiUOsy+g--

From neteler Wed May 30 15:40:05 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id PAA25699; Wed, 30 May 2001 15:40:05 +0100
Date: Wed, 30 May 2001 15:40:05 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] new Linux Binaries
Message-ID: <20010530154005.A25677@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <E1555sm-00023z-00@paf-linux.ulb.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E1555sm-00023z-00@paf-linux.ulb.ac.be>; from mlennert@ulb.ac.be on Wed, May 30, 2001 at 03:19:28PM +0200
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 369
Lines: 11

On Wed, May 30, 2001 at 03:19:28PM +0200, mlennert@ulb.ac.be wrote:

Markus,

Can I recreate the Linux binaries with the May 20 snapshot, or should I use a
new snapshot with the latest changes ?

Personally I would prefer the latest code (due to new Xdriver improvements).
However, this would be 5.0.0pre1b. Or shall I re-tag and we produce
5.0.0pre2 ?

Markus

2

Hi Markus

Markus Neteler wrote:

On Wed, May 30, 2001 at 03:19:28PM +0200, mlennert@ulb.ac.be wrote:
> Markus,
>
> Can I recreate the Linux binaries with the May 20 snapshot, or
> should I use a new snapshot with the latest changes ?

Personally I would prefer the latest code (due to new Xdriver
improvements). However, this would be 5.0.0pre1b. Or shall I re-tag
and we produce 5.0.0pre2 ?

If we are going to produce another release then it should be named
5.0.0pre2. I see no reason for using multiple versions of pre1.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

3

Markus Neteler wrote:

> > On Wed, May 30, 2001 at 03:19:28PM +0200, mlennert@ulb.ac.be wrote:
> > > Markus,
> > >
> > > Can I recreate the Linux binaries with the May 20 snapshot, or
> > > should I use a new snapshot with the latest changes ?
> >
> > Personally I would prefer the latest code (due to new Xdriver
> > improvements). However, this would be 5.0.0pre1b. Or shall I re-tag
> > and we produce 5.0.0pre2 ?
>
> If we are going to produce another release then it should be named
> 5.0.0pre2. I see no reason for using multiple versions of pre1.

O.k. (good luck that pre1 is not anounced yet :slight_smile:

Perhaps we should wait until the V_stuff is fixed? Glynn, Huidae, do
you have a timeline for this?

I've commited the initial changes (remove ASIAN_CHARS macro; the 7-bit
wrapping has gone altogether).

I'll do the more substantial changes to vasklib today or tonight.

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

4

Glynn Clements wrote:

> Perhaps we should wait until the V_stuff is fixed? Glynn, Huidae, do
> you have a timeline for this?

I've commited the initial changes (remove ASIAN_CHARS macro; the 7-bit
wrapping has gone altogether).

I'll do the more substantial changes to vasklib today or tonight.

I've now commited these.

The main change is that V_call() now has curses process the escape
sequences for extended keys, rather than using hardcoded definitions.

Extended keys (cursor keys, Home, End) should now work on any terminal
which has a correct termcap/terminfo entry.

One possible disadvantage is that if the termcap/terminfo entry is
broken, you will get undesirable results. This seems most likely to
happen with xterm, which has many configuration options which impact
upon the necessary terminal description.

The main one of relevance here is the sunKeyboard resource,
corresponding to the [+/-]sp command line flag and the "Sun Keyboard"
(or "VT220 Keyboard" in recent XFree86) menu option (Ctrl + left mouse
button). This affects whether the escape sequences generated by
Home/End are the Sun versions or the VT220 versions.

BTW: I tagged the previous version of V_call.c with "pre-curses-fix",
in case anyone needs the original breakage (to match a broken
terminfo).

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

From neteler Fri Jun 1 10:26:32 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id KAA10845; Fri, 1 Jun 2001 10:26:32 +0100
Date: Fri, 1 Jun 2001 10:26:32 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] Re: [GRASS_DE] r.mapcalc round()
Message-ID: <20010601102632.A10781@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <20010515213706.E29011@hgeo02.geog.uni-hannover.de> <15105.62896.407558.51019@cerise.nosuchdomain.co.uk> <20010516102627.E4694@hgeo02.geog.uni-hannover.de> <15106.35904.891581.763174@cerise.nosuchdomain.co.uk> <20010516182732.C8586@hgeo02.geog.uni-hannover.de> <15106.62821.108818.801581@cerise.nosuchdomain.co.uk> <20010517151944.B18204@hgeo02.geog.uni-hannover.de> <15108.14978.788581.317987@cerise.nosuchdomain.co.uk> <20010518092400.F5273@hgeo02.geog.uni-hannover.de> <15109.1786.23059.639776@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15109.1786.23059.639776@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Fri, May 18, 2001 at 12:26:50PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 3268
Lines: 84

Hi all,

On Fri, May 18, 2001 at 12:26:50PM +0100, Glynn Clements wrote:

[CC'd to grass5, as I really think that this merits some discussion.]

Markus Neteler wrote:

> as you really know much more than me about the precision issue and the
> related %f (and whatever), may I leave eventual changes to you? I am
> afraid to introduce more problems that currently there. My intention is
> to have relyable numbers, not optically polished numbers, no question!
>
> The candidates seem to be
> r.stats
> r.to.sites
> r.describe
> r.report
>
> which print numbers to stdout.

I started looking into r.stats, and noticed a couple of issues:

1. r.stats uses DCELL for all floating-point data. Theoretically this
needs 17 significant digits in order to preserve accuracy, but would
the data ever be this accurate?

For geographical data, I suspect not; but how accurate might it be? If
we pick some "reasonable" value, that then becomes the limit of its
accuracy. If we don't, 17 digits is likely to be too many in 99% of
cases (9 digits too many for all FCELL data).

I noticed some code which appeared to be intended to support
specifying the precision ("dp" variable in main.c, "fmt" argument to
cell_stats, print_cell_stats). However, this isn't actually used (in
that "dp" can't actually be changed).

2. Shouldn't the format of "r.stats -1" be consistent for all data?

This initially started as a question of whether to strip trailing
zeroes, but then there's the issue that, with "%g", some values could
be printed in exponential form and others not.

One solution would be to select either "%e" or "%f" (and an
appropriate precision) once, based upon the overall range of the data,
rather than letting "%g" choose for each individual value.

3. Might the output from "r.stats -1" be fed to programs which don't
recognise exponential form? The ANSI functions (atof, strtod, *scanf)
all support it, but not everything uses those.

I haven't looked at the other programs; I suspect that similar issues
may apply to those.

If the output from the above programs (apart from r.to.sites) is
intended for a user (instead of or as well as for programs), then
appearance is a valid consideration. Further, programs may impose
limitations on their input (e.g. a program which reads floating-point
values may first store the string in a buffer which isn't wide enough
for the full precision of a double).

It might be worth the effort of designing and implementing (the latter
is the easy part) a system-wide function for converting floating-point
numbers to decimal.

At it's simplest, this could be little more than:

  sprintf(buf, getenv("GRASS_FLOAT_FMT"), val);

(don't take this too literally).

A better approach would allow individual programs to specify
particular requirements, with the default format filling in the
blanks.

An additional possibility is a new option type (in the sense of
G_define_option) to allow consistent input of format specifications as
command-line parameters.

unfortunately there is still no discussion on these problems...

Just want to get this problem back into minds :slight_smile:

Markus