I'm getting close to having a set-up for using socket communications for
display drivers. I've got it working here, but I haven't uploaded all
the necessary changes yet (d.mon has a few...). Also, I want to be sure
the G_sock library functions don't cause any breakage before continuing.
Anyway, one thing I'm worried about is the path name length restriction
for local sockets. I understand it maxes out at 104 or 108, depending
on platform. While that's pretty long, I can see it happening. If that
barrier is hit, then the socket driver breaks. I'd like to stay away
from using /tmp (which is what things like X, ssh, GNOME, and others use
for unix socket files).
Proposed Solution: Create a $HOME/.grass5 directory, with some shallow
subdirectories like "com" for communications, maybe move tempfiles here?
Such a directory should be chmod 700 to keep out snoopers and for a
small modicum of security. Anyway, anyone have any thoughts? (We could
move $HOME/.grass5rc to $HOME/.grass5/grass5rc too???).
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Okay, I think I have everything in place for people to try the sockets
based XDRIVER. Run ./configure --with-socks to set it up.
Please post any problems.
Huidae, I'd especially like your feedback since you've done so much work
with the IPC set-up (thanks for making README.ipc so generic...). I
want to be sure I haven't missed anything important.
Files to look at include:
src/libes/raster/socket.new/io.c
src/display/devices/XDRIVER/XDRIVER24/socket.new/SWITCHER.c
src/display/d.mon/pgms/start.c
src/libes/gis/unix_socks.c
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
After installing beta11, I'm a little confused about the new
directory structure. Maybe I did something wrong, or maybe
one of the "make clean" variations fixes this.
It looks like I get identical copies of the /bin /bwidget /documents
/driver /etc ...and so on directories in both:
I just put the *.tar.gz in /usr/local/grass5 and unzipped/untarred
then went into grass5.0beta11_src and ran:
./configure
make
make install
??
Bill B.
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Sat, Feb 10, 2001 at 03:36:18PM -0700, bakerwl wrote:
Hello,
After installing beta11, I'm a little confused about the new
directory structure. Maybe I did something wrong, or maybe
one of the "make clean" variations fixes this.
It looks like I get identical copies of the /bin /bwidget /documents
/driver /etc ...and so on directories in both:
I just put the *.tar.gz in /usr/local/grass5 and unzipped/untarred
then went into grass5.0beta11_src and ran:
./configure
make
make install
??
Yes, this is "correct". Essentially the set-up builds everything into
$(SRC)/dist.$(ARCH). "make install" basically copies this to the final
destination. Given the way gmake5 and the sources are set-up, this was
a work around to allow a full build to be done (as any old user) and
then the install to be done as a priveledged user.
It probably would be better if each Gmakefile built its final modules in
OBJ.$(ARCH) and then there was an "install" target, but I don't think
the gmake5 setup will work this way (not sure). That's probably how
grass5.1 will work.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Sat, Feb 10, 2001 at 12:11:17PM -0800, Eric G . Miller wrote:
Okay, I think I have everything in place for people to try the sockets
based XDRIVER. Run ./configure --with-socks to set it up.
Please post any problems.
Huidae, I'd especially like your feedback since you've done so much work
with the IPC set-up (thanks for making README.ipc so generic...). I
want to be sure I haven't missed anything important.
Files to look at include:
src/libes/raster/socket.new/io.c
src/display/devices/XDRIVER/XDRIVER24/socket.new/SWITCHER.c
src/display/d.mon/pgms/start.c
src/libes/gis/unix_socks.c
Added:
src/display/devices/lib/socket.new/SWITCHER.c
and modified README.ipc, so now CELL and HTMLMAP *should* work with the
sockets set-up (have only tested CELL driver).
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Sat, Feb 10, 2001 at 03:36:18PM -0700, bakerwl wrote:
> Hello,
>
> After installing beta11, I'm a little confused about the new
> directory structure. Maybe I did something wrong, or maybe
> one of the "make clean" variations fixes this.
>
> It looks like I get identical copies of the /bin /bwidget /documents
> /driver /etc ...and so on directories in both:
>
> /usr/local/grass5
> /usr/local/grass5/grass5.0beta11_src/dist.i686-pc-linux-gnu/
>
> I just put the *.tar.gz in /usr/local/grass5 and unzipped/untarred
> then went into grass5.0beta11_src and ran:
> ./configure
> make
> make install
>
> ??
Yes, this is "correct". Essentially the set-up builds everything into
$(SRC)/dist.$(ARCH). "make install" basically copies this to the
final destination. Given the way gmake5 and the sources are set-up,
this was a work around to allow a full build to be done (as any old
user) and then the install to be done as a priveledged user.
It probably would be better if each Gmakefile built its final modules
in OBJ.$(ARCH) and then there was an "install" target, but I don't
think the gmake5 setup will work this way (not sure). That's probably
how grass5.1 will work.
Just to add to Eric's comments.
This new directory structure follows methods (described in Eric's first
paragraph) used in several Open Source software and is recommended by
the GNU software coding standards (see the section titled "Standard
Targets for Users" at http://www.gnu.org/prep/standards.html#SEC53 for
more details).
If you want to delete the $(SRC)/dist.$(ARCH) and $(SRC)/bin.$(ARCH)
directories then issue a "make clean" command.
Hope this helps.
--
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'
Proposed Solution: Create a $HOME/.grass5 directory, with some
shallow subdirectories like "com" for communications, maybe move
tempfiles here? Such a directory should be chmod 700 to keep out
snoopers and for a small modicum of security. Anyway, anyone have any
thoughts? (We could move $HOME/.grass5rc to $HOME/.grass5/grass5rc
too???).
I don't see any problems with this solution and we can move the
.tcltkgrassrc file in there as well. The best part about this is that
everything (sockets, tmp files, rc files) is under a single directory
instead of being scattered (especially the tmp files) all over the
place.
--
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'
On Mon, Feb 12, 2001 at 10:05:53AM +0700, Justin Hickey wrote:
Hi Eric
"Eric G . Miller" wrote:
> Proposed Solution: Create a $HOME/.grass5 directory, with some
> shallow subdirectories like "com" for communications, maybe move
> tempfiles here? Such a directory should be chmod 700 to keep out
> snoopers and for a small modicum of security. Anyway, anyone have any
> thoughts? (We could move $HOME/.grass5rc to $HOME/.grass5/grass5rc
> too???).
I don't see any problems with this solution and we can move the
.tcltkgrassrc file in there as well. The best part about this is that
everything (sockets, tmp files, rc files) is under a single directory
instead of being scattered (especially the tmp files) all over the
place.
Shall I look into what library code needs to be modified/added? Seems
it will be a pretty small amount of changes. Do you want to look into
the Init code (will need migration code)? Is there anything we should
be particularly aware of?
So we have, maybe:
$HOME/.grass5:
grass5rc
tcltkgrassrc
com/
tmp/
?
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Shall I look into what library code needs to be modified/added? Seems
it will be a pretty small amount of changes. Do you want to look into
the Init code (will need migration code)? Is there anything we should
be particularly aware of?
So we have, maybe:
$HOME/.grass5:
grass5rc
tcltkgrassrc
com/
tmp/
?
I can take care of the Init code, including the clean function that is
called at the end of grass to remove the tmp files. One thing though is
that I would like to drop the version number. Since Grass 4.x didn't
have a $HOME/.grass directory there will be no conflict with it. Having
the version in the top source directory is fine, but keeping it in
executables and resource files is a pain when the version changes. Does
anyone have objections?
The migration code should be fairly simple. In fact we can make a new
script strictly for the migration so it would be easy to remove later.
The only things I can see to include in the script would be:
o move the $HOME/.grassrc5 file to $HOME/.grass/grassrc
o move the $HOME/.tcltkgrassrc file to $HOME/.grass/tcltkgrassrc
o remove any tmp directories in known mapsets (they shouldn't be there
in the first place but just in case)
We can do this for 5.0 and then remove the script for 5.1. Hopefully,
everyone will have upgraded to 5.0 by then. If not, the worst case is
that grass will start as if it was running for the first time, and if
the user complains, we can get them to check for the old files. What do
you think?
Does anyone see anything we might have missed?
BTW, has Markus commented on this yet?
--
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'
On Mon, Feb 12, 2001 at 01:42:30PM +0700, Justin Hickey wrote:
I can take care of the Init code, including the clean function that is
called at the end of grass to remove the tmp files. One thing though is
that I would like to drop the version number. Since Grass 4.x didn't
have a $HOME/.grass directory there will be no conflict with it. Having
the version in the top source directory is fine, but keeping it in
executables and resource files is a pain when the version changes. Does
anyone have objections?
No argument here.
The migration code should be fairly simple. In fact we can make a new
script strictly for the migration so it would be easy to remove later.
The only things I can see to include in the script would be:
o move the $HOME/.grassrc5 file to $HOME/.grass/grassrc
o move the $HOME/.tcltkgrassrc file to $HOME/.grass/tcltkgrassrc
Maybe the Init code could handle this without the need for a separate
script? Should grassrc contain a version string for later updates (with
a well defined structure like Major.Minor.Revision)?
o remove any tmp directories in known mapsets (they shouldn't be there
in the first place but just in case)
No opinion...
We can do this for 5.0 and then remove the script for 5.1. Hopefully,
everyone will have upgraded to 5.0 by then. If not, the worst case is
that grass will start as if it was running for the first time, and if
the user complains, we can get them to check for the old files. What do
you think?
Does anyone see anything we might have missed?
BTW, has Markus commented on this yet?
Not that I'm aware of...
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 01:42:30PM +0700, Justin Hickey wrote:
> The migration code should be fairly simple. In fact we can make a
> new script strictly for the migration so it would be easy to remove
> later. The only things I can see to include in the script would be:
>
> o move the $HOME/.grassrc5 file to $HOME/.grass/grassrc
> o move the $HOME/.tcltkgrassrc file to $HOME/.grass/tcltkgrassrc
Maybe the Init code could handle this without the need for a separate
script?
OK.
Should grassrc contain a version string for later updates (with
a well defined structure like Major.Minor.Revision)?
I don't see a real need for a version string. The contents of the file
are only environment variables and Grass doesn't assume the existance of
the file, so it doesn't matter if the variables exist or not. Therefore,
a version string is not necessary.
If we ever do decide to put something into grassrc other than
environment variables, then we would need a version string.
--
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'
On Sat, Feb 10, 2001 at 03:37:08PM -0800, Eric G . Miller wrote:
On Sat, Feb 10, 2001 at 03:36:18PM -0700, bakerwl wrote:
> Hello,
>
> After installing beta11, I'm a little confused about the new
> directory structure. Maybe I did something wrong, or maybe
> one of the "make clean" variations fixes this.
>
> It looks like I get identical copies of the /bin /bwidget /documents
> /driver /etc ...and so on directories in both:
>
> /usr/local/grass5
> /usr/local/grass5/grass5.0beta11_src/dist.i686-pc-linux-gnu/
>
> I just put the *.tar.gz in /usr/local/grass5 and unzipped/untarred
> then went into grass5.0beta11_src and ran:
> ./configure
> make
> make install
>
> ??
Yes, this is "correct". Essentially the set-up builds everything into
$(SRC)/dist.$(ARCH). "make install" basically copies this to the final
destination. Given the way gmake5 and the sources are set-up, this was
a work around to allow a full build to be done (as any old user) and
then the install to be done as a priveledged user.
It probably would be better if each Gmakefile built its final modules in
OBJ.$(ARCH) and then there was an "install" target, but I don't think
the gmake5 setup will work this way (not sure). That's probably how
grass5.1 will work.
To overcome this problem in 5.0, Huidae Cho has been implementing
gmake5 -i
If the module was already installed etc, you can use the flag to
get an updated modules into the final place without running the
entire make install process again. It directly copies the updated
module from dist.$ARCH to /usr/local/grass/... or wherever your
grass5 lives. Nice feature, just try it.
Regards
Markus Neteler
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 01:42:30PM +0700, Justin Hickey wrote:
Hi Eric
"Eric G . Miller" wrote:
> Shall I look into what library code needs to be modified/added? Seems
> it will be a pretty small amount of changes. Do you want to look into
> the Init code (will need migration code)? Is there anything we should
> be particularly aware of?
>
> So we have, maybe:
>
> $HOME/.grass5:
> grass5rc
> tcltkgrassrc
> com/
> tmp/
> ?
I can take care of the Init code, including the clean function that is
called at the end of grass to remove the tmp files. One thing though is
that I would like to drop the version number. Since Grass 4.x didn't
have a $HOME/.grass directory there will be no conflict with it. Having
the version in the top source directory is fine, but keeping it in
executables and resource files is a pain when the version changes. Does
anyone have objections?
The migration code should be fairly simple. In fact we can make a new
script strictly for the migration so it would be easy to remove later.
The only things I can see to include in the script would be:
o move the $HOME/.grassrc5 file to $HOME/.grass/grassrc
o move the $HOME/.tcltkgrassrc file to $HOME/.grass/tcltkgrassrc
o remove any tmp directories in known mapsets (they shouldn't be there
in the first place but just in case)
We can do this for 5.0 and then remove the script for 5.1. Hopefully,
everyone will have upgraded to 5.0 by then. If not, the worst case is
that grass will start as if it was running for the first time, and if
the user complains, we can get them to check for the old files. What do
you think?
Does anyone see anything we might have missed?
BTW, has Markus commented on this yet?
Hi Eric, hi Justin,
I simply like this idea. Having it all-in-one directory is always
the best. I can "provide" my student to test later, they usually
find every bug we would never even dream of.
The only problem is: How long shall we continue on GRASS 5.0, when
to switch over to 5.1?
Regards
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
o it works o.k.! And, hey, you can simply click-off the monitor...
This is definitly a useful improvement.
o the monitor comes up much faster
o the refresh problem with hidden monitor is still there (KDE2,
you will know it).
Small idea to improve:
If you click-off a monitor and run d.rast (or whatever) later, you get:
d.rast tk25
Socket is already in use or not accepting connections.
This message might be extended: "Run d.mon to start new monitor.".
A problem is, that the message doesn't time-out. Means, you need to Ctrl-C
it away (funny: you have to hit return, before Ctrl-C is accepted).
Could you use G_fatal_error() for this message?
Eric, congratulations to you quick implementation of sockets. It offers
long awaited features.
regards
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 11:48:41AM +0000, Markus Neteler wrote:
Hi Eric,
here my report on XDRIVER/sockets:
o it works o.k.! And, hey, you can simply click-off the monitor...
This is definitly a useful improvement.
o the monitor comes up much faster
o the refresh problem with hidden monitor is still there (KDE2,
you will know it).
I'm still trying to figure out how to get the XDRIVER to handle 'Expose'
events properly. Unfortunately, I know little about X programming, and
am unsure what the XDRIVER would use to repaint the screen (if the
server won't do it with backing-store). Note: I'm running KDE2.1beta
and this problem doesn't exist here (with the changes to XF86Config to
always do backing store).
Small idea to improve:
If you click-off a monitor and run d.rast (or whatever) later, you get:
d.rast tk25
Socket is already in use or not accepting connections.
This message might be extended: "Run d.mon to start new monitor.".
A problem is, that the message doesn't time-out. Means, you need to Ctrl-C
it away (funny: you have to hit return, before Ctrl-C is accepted).
Could you use G_fatal_error() for this message?
Yea, I'll try to clean up some of the reporting/d.mon stuff. My first
goal was just to get it working
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 11:48:41AM +0000, Markus Neteler wrote:
Small idea to improve:
If you click-off a monitor and run d.rast (or whatever) later, you get:
d.rast tk25
Socket is already in use or not accepting connections.
Okay, I looked into this. The problem is, most programs don't seem to
check the return value of R_open_driver(). It returns a non-zero value
if it fails. Putting an exit() or similar into libraster would break
d.mon's ability to report the status of all the drivers. So, all d.*
programs need to check that they actually were able to open the display
driver (rather than just assuming).
This message might be extended: "Run d.mon to start new monitor.".
A problem is, that the message doesn't time-out. Means, you need to Ctrl-C
it away (funny: you have to hit return, before Ctrl-C is accepted).
Could you use G_fatal_error() for this message?
d.rast get's hung because it tries to do drawing when there's nothing to
draw to. This is a module problem, not a library problem.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 11:48:41AM +0000, Markus Neteler wrote:
Hi Eric,
here my report on XDRIVER/sockets:
o it works o.k.! And, hey, you can simply click-off the monitor...
This is definitly a useful improvement.
o the monitor comes up much faster
o the refresh problem with hidden monitor is still there (KDE2,
you will know it).
Try recompiling the XDRIVER with the little change I just made. I
turned of backingstore in X and it seems to repaint the screen correctly
now. Before, it was checking if the server responded to
DoesBackingStore() with 'Always'. However, it could also respond with a
'WhenMapped' which also means it does backingstore, but only if the
window is mapped. I changed it to check against 'NotUseful', which
means backingstore is off in the server by default. Hope it works...
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 01:03:47PM -0800, Eric G . Miller wrote:
On Mon, Feb 12, 2001 at 11:48:41AM +0000, Markus Neteler wrote:
> Small idea to improve:
> If you click-off a monitor and run d.rast (or whatever) later, you get:
> d.rast tk25
> Socket is already in use or not accepting connections.
Okay, I looked into this. The problem is, most programs don't seem to
check the return value of R_open_driver(). It returns a non-zero value
if it fails. Putting an exit() or similar into libraster would break
d.mon's ability to report the status of all the drivers. So, all d.*
programs need to check that they actually were able to open the display
driver (rather than just assuming).
Hi Eric,
this sounds like a bunch of work. Is there a chance to use an "intelligent"
script to exchange the R_open_driver() command by an improved call
to R_open_driver() with checking the exit status (hi script gurus!)?
> This message might be extended: "Run d.mon to start new monitor.".
> A problem is, that the message doesn't time-out. Means, you need to Ctrl-C
> it away (funny: you have to hit return, before Ctrl-C is accepted).
> Could you use G_fatal_error() for this message?
d.rast get's hung because it tries to do drawing when there's nothing to
draw to. This is a module problem, not a library problem.
I see. Thanks for clarification.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
just found a problem: You can start x0 (and other monitors)
several times. If this is known, excuse me. Of course I can
click them off.
Maybe the tcltkgrass problem with XDRIVER/sockets is somehow related
to above problem?
Eric, I don't want to bother you, but simply try to catch all
problems.
Regards
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Feb 13, 2001 at 04:22:55PM +0000, Markus Neteler wrote:
Hi again (sorry),
just found a problem: You can start x0 (and other monitors)
several times. If this is known, excuse me. Of course I can
click them off.
Nope, never thought to try that. It's a, umm, feature ;).
Maybe the tcltkgrass problem with XDRIVER/sockets is somehow related
to above problem?
Possibly/Probably. Will require some research to find a nice solution.
Seems bind() in the local namespace does not work like binding to a port
in the internet namespace. I've got an idea or two how to deal with
this, but I want to hunt around a bit for a good solution...
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
