[GRASS5] AIX 4.3.3 again

GRASS GRASS developer
1

Hello to everybody,

once again I' d be very glad to get some help.
Is anyone familiar with the following output?

Thanks in advance!

Ulrich

Hint: With changing the time declaration from type "long" to "time_t" in
file "menu.c" I can suppress the warning.

        gcc -O
-I/a/zisp0401/export/zi/aix/fs2/dist/graphic/grass-4.3/src/src/include
-c menu.c
menu.c: In function `F_menu':
menu.c:214: warning: assignment makes integer from pointer without a
cast
menu.c: In function `P_termexit':
menu.c:251: warning: passing arg 2 of `signal' from incompatible pointer
type
menu.c:252: warning: passing arg 2 of `signal' from incompatible pointer
type
menu.c:253: warning: passing arg 2 of `signal' from incompatible pointer
type
menu.c: In function `F_universe':
menu.c:388: conflicting types for `time'
/usr/include/time.h:114: previous declaration of `time'
menu.c:388: warning: extern declaration of `time' doesn't match global
one
menu.c:396: warning: comparison between pointer and integer
menu.c:397: warning: assignment makes integer from pointer without a
cast
menu.c: In function `P_getusrinpt':
menu.c:577: warning: assignment makes integer from pointer without a
cast
menu.c:591: warning: assignment makes integer from pointer without a
cast
menu.c:604: warning: assignment makes integer from pointer without a
cast
menu.c: In function `P_writowin':
menu.c:765: warning: comparison between pointer and integer
menu.c:776: warning: comparison between pointer and integer
menu.c:792: warning: comparison between pointer and integer
menu.c: In function `P_writo_Menu_win':
menu.c:843: warning: comparison between pointer and integer
menu.c:870: warning: comparison between pointer and integer
menu.c:883: warning: comparison between pointer and integer
menu.c:900: warning: assignment makes integer from pointer without a
cast
menu.c:916: warning: comparison between pointer and integer
menu.c: In function `P_menuerror':
menu.c:982: warning: comparison between pointer and integer
menu.c:985: warning: comparison between pointer and integer
menu.c:989: warning: assignment makes integer from pointer without a
cast
make: 1254-004 The error code from the last command is 1.

Stop.
GISGEN failure at STEP: src/general/g.help

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Hi Justin (hi all),

we have been talking about the GRASS environmental variables,
if and how to include a GRASS_TEMP variable etc. From
sitting here with Roger Bivand at Chatham campus, we got the
idea that a GRASS daemon might be great to solve a couple
of problems.

Roger needs the GRASS metadata (location parameters) to be know
for his R-statistics interface. Currently this is done by reading
the environmental variables, but this is not very elegant and
efficient. To have a daemon serving these data would be quite
good even for other applications coupled to GRASS.
And the (hopefully forthcoming) new XDRIVER with sockets may
make use of it, too.
Maybe (you will know that better than me) it is a way to make
possible location changes on-the-fly.

What we would have to do is to reserve a port number (I hope there
is one free), have the daemon of course and modify the
G_environment. Probably it could be useful too in order to set
up parallel GRASS sessions without locking. And maybe they could
talk to each other and share the workload on different CPU's? A
simple "parallel GRASS"?

I would be glad to receive comments on this and if you consider
this is feasible.

Greetings from U.K.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Hi Markus

Markus Neteler wrote:

we have been talking about the GRASS environmental variables,
if and how to include a GRASS_TEMP variable etc. From
sitting here with Roger Bivand at Chatham campus, we got the
idea that a GRASS daemon might be great to solve a couple
of problems.

Interesting idea but I don't know much about daemons except that they
are processes that sit there and provide a service to other processes.
Could you please elaborate on what you expect the daemon to do with
respect to the kinds of services it will provide?

By the way, there is no problem with reserving a port there are many
free ones.

--
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!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Justin:

On Fri, 25 Aug 2000, Justin Hickey wrote:

Markus Neteler wrote:
> we have been talking about the GRASS environmental variables,
> if and how to include a GRASS_TEMP variable etc. From
> sitting here with Roger Bivand at Chatham campus, we got the
> idea that a GRASS daemon might be great to solve a couple
> of problems.

Interesting idea but I don't know much about daemons except that they
are processes that sit there and provide a service to other processes.
Could you please elaborate on what you expect the daemon to do with
respect to the kinds of services it will provide?

The reason for the question is that when GRASS data are used by GRASS
programs in the GRASS environment, they are associated with
"their" metadata (location, region etc.) through environmental
variables. When the data are interfaced to R or indeed PostgreSQL, it
isn't too clear how to maintain consistency between the data and their
initial metadata, which ought to matter in general, and does matter when
they move back into the environment used by GRASS programs. In the first
R/GRASS interface version, all the data moved were tagged with their
metadata, but this led to lots of duplication. The fact that the same
question appears to affect PostgreSQL made us feel that it is a general
one, calling for consideration of how to keep the metadata and the data
consistent.

How this makes our concern clearer!

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

Hello Roger

Roger Bivand wrote:

The reason for the question is that when GRASS data are used by GRASS
programs in the GRASS environment, they are associated with
"their" metadata (location, region etc.) through environmental
variables. When the data are interfaced to R or indeed PostgreSQL, it
isn't too clear how to maintain consistency between the data and their
initial metadata, which ought to matter in general, and does matter
when they move back into the environment used by GRASS programs. In
the first R/GRASS interface version, all the data moved were tagged
with their metadata, but this led to lots of duplication. The fact
that the same question appears to affect PostgreSQL made us feel that
it is a general one, calling for consideration of how to keep the
metadata and the data consistent.

OK, I think I understand the problem. So, for example, in PostgreSQL, we
would want to store attribute data corresponding to geographic data in
GRASS. And to link the two pieces of data we need to also keep track of
the metadata (location, mapset). Now the question being raised is "How
to link the two data items using the metadata?" Is this a correct
analogy of the problem?

If so, then I still don't understand how a daemon could be used to solve
this problem. The metadata would still need to be obtained from
somewhere and sent to the appropriate process that is requesting the
data. I do not see how the duplication is avoided.

Could you please indicate how you expect the daemon to operate and how
the duplication is avoided, in terms of data management? I'm not clear
on this part.

--
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!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hello Justin,

On Tue, 29 Aug 2000, Justin Hickey wrote:

OK, I think I understand the problem. So, for example, in PostgreSQL, we
would want to store attribute data corresponding to geographic data in
GRASS. And to link the two pieces of data we need to also keep track of
the metadata (location, mapset). Now the question being raised is "How
to link the two data items using the metadata?" Is this a correct
analogy of the problem?

Yes, as a subset. I'm not clear myself (as you can see!), but potentially
external programs like R or PostgreSQL can generate new or modified GRASS
data objects themselves, that ought to be related to the location
metadata. So it's potentially not just to link two data items, but maybe
to build an audit trail for data moving in and out of the GRASS database.

If so, then I still don't understand how a daemon could be used to solve
this problem. The metadata would still need to be obtained from
somewhere and sent to the appropriate process that is requesting the
data. I do not see how the duplication is avoided.

Could you please indicate how you expect the daemon to operate and how
the duplication is avoided, in terms of data management? I'm not clear
on this part.

One possibility would be to ask processes making transactions against the
GRASS database to check them in and out (like CVS?), say in a
database. The daemon idea would be a "middleware" to link the transactions
(what, how, which metadata?) to the database back-ends on the one hand and
application front-ends on the other. A daemon is one way (maybe?), but
it's rather like an object-broker interface too. A daemon would look like
"postmaster", for registering transactions or for retrieving data about
transactions (given that the transaction key is "glued" to the data
object). I know that this isn't too clear, but I'm not sure that it's
entirely fruitless either.

Yours,

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Hi all,
I am thinking about this daemon idea for a couple of minutes now
and as Justin I still fail to see the need for it.
This only shows that the problem and the proposed solution
is not explained enough and in a way that I can grasp it easily.

Let me give you my thoughts on the original idea:

On Fri, Aug 25, 2000 at 11:08:45AM +0100, Markus Neteler wrote:

we got the idea that a GRASS daemon might be great to solve a couple
of problems.

Roger needs the GRASS metadata (location parameters) to be know
for his R-statistics interface. Currently this is done by reading
the environmental variables, but this is not very elegant and
efficient.

It is basic, but is works nicely. But it is also simple.
This being non elegant or efficient does not create a reason
to change it in my eyes, because it is good enough for the task.

To have a daemon serving these data would be quite
good even for other applications coupled to GRASS.

Why? The daemon how I understood so far would just be a database
for environment variables, just like a global dictionary.
But this is exactly what environment variables are.

I can see two possible advantages of the daemon:
  - It might check dependecies and notify _running_ programms
  that they have to take action. So another part of grass
  would register and get's called back.
  But this is much more than being a daemon, this would
  be a major redesign of grass, to have a core.

  - It might serve more than one location.
  (Though again this is like running more than one grass
  session.)

And the (hopefully forthcoming) new XDRIVER with sockets may
make use of it, too.

How? The communication between the grass-database part and the
x11 display part is very special and has nothing do to with
the grass database, I presume.

Maybe (you will know that better than me) it is a way to make
possible location changes on-the-fly.

No. Why should it.
Just changing the environment variables or the variables held by
the daemon is not more or less difficult.

Probably it could be useful too in order to set
up parallel GRASS sessions without locking. And maybe they could
talk to each other and share the workload on different CPU's? A
simple "parallel GRASS"?

If you work on a database file, you have to lock it.
If you have one graphical display (e.g. monitor) you have to lock this.

We could thing about introducing read only locks and write locks,
this is entirely on the locking mechanism intelligence part.
Then we might start two grass processes on the same environmental
variables and this would be the most basic paralleling in GRASS.

And the next step for paralleling in GRASS I see is to make selected
single grass commands work parallel inside.

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

8

Hi all,

concerning the daemon discussion (to daemon or not to daemon):
We are currently facing a set of problems which should be fixed
in near future. If a daemon is required - I don't know.
THe problems are totally different, some of those listed
below might belong to another discussion.

What's required (partly already implemented):

- external applications like "R" needs to get the
  metadata (location, mapset, resolution, projection)
- external applications should be able to set new
  location parameters easily (like R, web applications,...)

- if storing entire datasets into PostgreSQL (or another DBMS)
  the metadata needs to stay somewhere. Suppose we
  analyse GIS data in R, taking vectors directly from
  GRASS using the GRASS/R interface and taking raster data
  delivered by PostgreSQL (using the RPgSQL or RODBC proxy),
  how to keep the location settings in sync? The basic
  problem will arise from data storage in PostgreSQL
  if one wants to analyse a subset of data only.

- database locking will be required (already implemented)
- but: concurrent GRASS sessions should be possible, at
  least with different locations (so a daemon could check
  for conflicts, environment variables might not be sufficient)

- changing location on-the-fly should be possible (daemon
  might not be required)

- the monitor should be closeable by click without the
  "d.mon stop" command (for user's convenience). This will
  require the fifos exchange to a sockets concept
- monitor locking is required (already implemented)

Most of these topics are concerning user's convenience. For
wider GRASS acceptance I feel we should take care of this.

Just some discussion comments,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Markus Neteler wrote:

Hi all,

concerning the daemon discussion (to daemon or not to daemon):
We are currently facing a set of problems which should be fixed
in near future. If a daemon is required - I don't know.
THe problems are totally different, some of those listed
below might belong to another discussion.

What's required (partly already implemented):

- external applications like "R" needs to get the
  metadata (location, mapset, resolution, projection)
- external applications should be able to set new
  location parameters easily (like R, web applications,...)

- if storing entire datasets into PostgreSQL (or another DBMS)
  the metadata needs to stay somewhere. Suppose we
  analyse GIS data in R, taking vectors directly from
  GRASS using the GRASS/R interface and taking raster data
  delivered by PostgreSQL (using the RPgSQL or RODBC proxy),
  how to keep the location settings in sync? The basic
  problem will arise from data storage in PostgreSQL
  if one wants to analyse a subset of data only.

- database locking will be required (already implemented)
- but: concurrent GRASS sessions should be possible, at
  least with different locations (so a daemon could check
  for conflicts, environment variables might not be sufficient)

- changing location on-the-fly should be possible (daemon
  might not be required)

- the monitor should be closeable by click without the
  "d.mon stop" command (for user's convenience). This will
  require the fifos exchange to a sockets concept
- monitor locking is required (already implemented)

Most of these topics are concerning user's convenience. For
wider GRASS acceptance I feel we should take care of this.

In our project, we want to interface GRASS, agricultural models
(like EPIC, CERES, CARE) to a common database. We area facing
the same problem. On a theoritical point of view, all data
(including the metadata) should be in the database. Database
management softwares (DBMS) offer tools for looking records and
other data management functions. DBMS looks like daemon for
the application. The DBMS is able to perform the functions that
you are wishing for the daemon. For the old GRASS data structure
(using flat files), a daemon is require and one possibility to
investigate is to create a daemon that mimic the DBMS interface
such as OBDC. With this approch, any GRASS application could
interface to any DBMS or conventional GRASS data transparently.
For the DBMS, the metadata structure needs to be define which
needs some work. Our analysis (which is begining) could be a
base of discussion. This approch is in the OPENGIS direction.

This only one opinion that I hope will fuel other reflexions.

Just some discussion comments,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'