[GRASS-dev] making py.monitor listen to external commands

Hallo,

I'm trying to script something, which could be in the future called
py.mon(itor) using wxpython together with xrc.

The basic is here - I can display ppm file

Now, I would like to make it "listen" to command line commands and I
have been thinking of approach like this:

The idea is, you would tip just normal py.* commands in the command line,
but there would be process running in background, which would pick up
the last line from history file (e.g. .monitor_x0_history) and add it to stack of
commands for the monitor.

We would have to create set of py.* commands, which would replace the
d.* commands and general structure of this py.* commands would look like
this:

---------------------------
# py.rast

# get the selected monitor
monitor = os.getenv("GRASS_MONITOR")

# get the file name
command_file = os.path.join(GISBASE,LOCATION,MAPSET,".monitor_"+monitor+"_history)

# write d.rast to commands
file = open(command_file,"a")
file.write("d.rast "+sys.arg[1:])
file.close()
---------------------------

Then there should be loop in py.monitor:

    1) watcher(), which would take care on the .monitor_x0_history file just like tail -f does
       if there would be some change, it would add command to the
        monitor commands stack and redraw the monitor with new set of
        commands

    2) pymonitor.MainLoop(), which displays the gui and sets the
        variables

So, I have monitor (see screenshot [1]), I can tip commands in some
"terminal" under the window. I have "watcher" which takes care on the
command file and if there is some change, it should set the "monitor
terminal" to the value of the command(s) to new command.

But it does not because the processes do not "see" each other. I'm also
not able to kill the processes while closing the monitor, because of I'm
not able to get their PIDs.

So my question: how to perform task like this? I know, this is task for
"reall" programmers, maybe I choosed completly wrong approach.

I took the code from
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012 and
modified it like this:

-------------------------------
class Monitor(wx.App):
    """
    py.monitor gui
    """

    def OnInit(self):
        """
        Init the gui
        """

        try:
            pid = os.fork()
            if pid > 0:
                # exit first parent
                sys.exit(0)
        except OSError, e:
            print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno,
    e.strerror)
            sys.exit(1)

        # decouple from parent environment
        os.setsid()
        os.umask(0)

        # initialize the GUI
        self.initFrame()
        self.rast = map.raster.Raster()
        self.initToolBar()
        self.initCommands()
        self.initDrawArea()
        self.frame.Show()

        # do second fork
        try:
            pid = os.fork()
            if pid > 0:
                # exit from second parent, print eventual PID before
                #print "Daemon PID %d" % pid
                
                # OnInit should return boolean value
                return True

                #sys.exit(0)
        except OSError, e:
            print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno,
    e.strerror)
            sys.exit(1)

        # start the daemon watcher
        self.watcher()

[....]

# startin the gui
def main():
    pymonitor = Monitor(0)
    pymonitor.MainLoop()

-------------------------------

Thanks for hints I hope, one can understand, what I wanted to say.

Jachym

[1] http://les-ejk.cz/tmp/py.monitor.png
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

One thing that might be helpful is to have a file which lists the
currently displayed ppm images (in the monitor) in the order that they
are displayed. Then a command line program could replace the list with
new data (d.erase) or append to the list (d.rast -o). The monitor
would need to check if the list had been changed and then update
itself (maybe after receiving an update yourself signal via a socket)

Ideally, the monitor list would contain enough information to update
the gis.m widgets as well.

In other words, d.erase would erase the monitor and (optionally) also
remove all the drawing "widgets" from gis.m. Issuing a d.rast command
would, in addition to updating the monitor, replace or append to the
gis.m widgets as appropriate.

--
David Finlayson

On Mon, Jun 12, 2006 at 12:36:32PM -0700, David Finlayson wrote:

One thing that might be helpful is to have a file which lists the
currently displayed ppm images (in the monitor) in the order that they
are displayed. Then a command line program could replace the list with
new data (d.erase) or append to the list (d.rast -o). The monitor
would need to check if the list had been changed and then update
itself (maybe after receiving an update yourself signal via a socket)

Ideally, the monitor list would contain enough information to update
the gis.m widgets as well.

In other words, d.erase would erase the monitor and (optionally) also
remove all the drawing "widgets" from gis.m. Issuing a d.rast command
would, in addition to updating the monitor, replace or append to the
gis.m widgets as appropriate.

yes, yes, that is no question about what it should do

def watcher(self):
    commands_file = "py.commands"
    commands = open(commands_file,"r")
    st_results = os.stat(commands_file)
    st_size = st_results[6]
    commands.seek(st_size)

    while 1:
        where = commands.tell()
        line = commands.readline()
        if not line:
            time.sleep(1)
            commands.seek(where)
        else:
            line = line.strip()

            if line == "d.erase":
                self.commandsCtrl.SetValue('')
            else:
                self.commandsCtrl.SetValue(
                    self.commandsCtrl.GetValue()+"\n"+line+"\n")

But how?

I have rewritten the code a bit, but it does not seem, that both
processes would have same space in memory :frowning:

class Monitor(wx.App):
    def OnInit(self):
        ...
        
        try:
            pid = os.fork()
            if pid == 0:
                self.watcher()
            else:
                print self.semafor
                print "otec"
        except OSError, e:
            # no fork
            sys.exit(1)
        return True

It would be maybe better, do it in MainLoop, but I did not found the
approach, how to smuggle watcher() in the MainLoop :frowning:

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

It's worthwhile to see how we've done this same kind of thing in the GIS
Manager console using TclTk.

If the commands are done through the GUI or a python command console, it
really isn't necessary to constantly listen for commands because the user is
the one who issues commands. These commands can be captured at the time they
are issued by the user and echoed back to the command history console. The
stdout and stderr from each command can also be captured and echoed back.
Since all this is simply text (commands and their output), it can go into a
scrolling text widget producing a history of commands and output.

In other words, this can be be event driven in a simple, straightforward
manner. Pressing "run" button (if default, pressing return) runs a command
and echoes the command to history. When a command is issued, its output is
automatically captured and sent to history.

This done in a more sophisticated way in the gronsole that Cedric Shock did.
It separates commands from their output and allows the output to be folded
out of sight. Buttons that are put into the text widget alongside each
command will automatically copy the command from history back to the command
console where it can be edited and run again.

Hope this helps

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Jachym Cepicky <jachym.cepicky@centrum.cz>
Date: Mon, 12 Jun 2006 21:47:22 +0200
To: David Finlayson <david.p.finlayson@gmail.com>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] making py.monitor listen to external commands

On Mon, Jun 12, 2006 at 12:36:32PM -0700, David Finlayson wrote:

One thing that might be helpful is to have a file which lists the
currently displayed ppm images (in the monitor) in the order that they
are displayed. Then a command line program could replace the list with
new data (d.erase) or append to the list (d.rast -o). The monitor
would need to check if the list had been changed and then update
itself (maybe after receiving an update yourself signal via a socket)

Ideally, the monitor list would contain enough information to update
the gis.m widgets as well.

In other words, d.erase would erase the monitor and (optionally) also
remove all the drawing "widgets" from gis.m. Issuing a d.rast command
would, in addition to updating the monitor, replace or append to the
gis.m widgets as appropriate.

yes, yes, that is no question about what it should do

def watcher(self):
    commands_file = "py.commands"
    commands = open(commands_file,"r")
    st_results = os.stat(commands_file)
    st_size = st_results[6]
    commands.seek(st_size)

    while 1:
        where = commands.tell()
        line = commands.readline()
        if not line:
            time.sleep(1)
            commands.seek(where)
        else:
            line = line.strip()

            if line == "d.erase":
                self.commandsCtrl.SetValue('')
            else:
                self.commandsCtrl.SetValue(
                    self.commandsCtrl.GetValue()+"\n"+line+"\n")

But how?

I have rewritten the code a bit, but it does not seem, that both
processes would have same space in memory :frowning:

class Monitor(wx.App):
    def OnInit(self):
        ...
        
        try:
            pid = os.fork()
            if pid == 0:
                self.watcher()
            else:
                print self.semafor
                print "otec"
        except OSError, e:
            # no fork
            sys.exit(1)
        return True

It would be maybe better, do it in MainLoop, but I did not found the
approach, how to smuggle watcher() in the MainLoop :frowning:

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

David Finlayson wrote:

One thing that might be helpful is to have a file which lists the
currently displayed ppm images (in the monitor) in the order that they
are displayed.

does d.save help?

Hamish

D.save only works with commands sent to the XDRIVER. It would be much more
useful if it kept track of all GRASS commands and didn't depend on x11.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 13 Jun 2006 17:54:15 +1200
To: David Finlayson <david.p.finlayson@gmail.com>
Cc: <jachym.cepicky@centrum.cz>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] making py.monitor listen to external commands

David Finlayson wrote:

One thing that might be helpful is to have a file which lists the
currently displayed ppm images (in the monitor) in the order that they
are displayed.

does d.save help?

Hamish

Hallo,

after long discussion with Michael and a bit coding, I would like to
present new new concept of GRASS monitors.

I prepared set of py.* commands, which IMHO *should* became parts of d.*
commands. This is just a workaround this.

General concept is, each monitor has it's own LOCATION/MAPSET/.pyX file,
in which the d.* files are stored. This file is checked from the GUI and
if there is some change, it's content serves for creating the map.

Advantage of this approach is, that this file can be modified from any
GUI/CLI. Target is, to have py.mons *independent* on any UI, however
managable from *any* of them.

Screenshot can be found on [1], set of new tools can be found on [2].

Example session (in xterm) can look like follows:

py.mon start=x0
py.mon start=py0
py.rast soils
py.vect roads
py.ctrl -l
py.ctrl remove=vect
py.rast fields -o
py.vect fields fcol=yellow
py.ctrl -l

(see screenshot [1] for details and possible outputs).

py.rast and py.vect commands can be used just like the old d.* commands

for installation just untar [2] and cd new py.monitor directory

[1] http://les-ejk.cz/tmp/py.mon.png
[2] http://les-ejk.cz/programs/grass/py.monitor.tgz

Please test and discusse.

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Hallo,

bugfix version of py.monitor scripts. Some people tested the scripts and
they found it nice. What about you, developers?

Current version avaliable on
http://les-ejk.cz/programs/grass/py.monitor-06-06-14-4.tgz

tar xzf py.monitor-06-06-14-4.tgz
cd py.monitor
py.mon start=py0
py.rast soils -o
py.vect roads
py.erase
...

Everything, what should work (all toolbar buttons, etc.) works. Zoom/Unzoom
avaliable via mouse wheel. Mapcontent manageable via py.* commands (this
should move to d.* commands in the future) from commandline and via any
other interface via LOCATION/MAPSET/.pyX file.

Starting with the morning, I will not have much time and I will not be
so close to internet for a week, so I will not spam your mailboxes
for a while.

It would be good just to send me some note, e.g., that you tryed, but it did
not work. It is not so easy to develop GUI without any feedback.

Looking forward

Jachym

On Wed, Jun 14, 2006 at 11:34:09AM +0200, Jachym Cepicky wrote:

Hallo,

after long discussion with Michael and a bit coding, I would like to
present new new concept of GRASS monitors.

I prepared set of py.* commands, which IMHO *should* became parts of d.*
commands. This is just a workaround this.

General concept is, each monitor has it's own LOCATION/MAPSET/.pyX file,
in which the d.* files are stored. This file is checked from the GUI and
if there is some change, it's content serves for creating the map.

Advantage of this approach is, that this file can be modified from any
GUI/CLI. Target is, to have py.mons *independent* on any UI, however
managable from *any* of them.

Screenshot can be found on [1], set of new tools can be found on [2].

Example session (in xterm) can look like follows:

py.mon start=x0
py.mon start=py0
py.rast soils
py.vect roads
py.ctrl -l
py.ctrl remove=vect
py.rast fields -o
py.vect fields fcol=yellow
py.ctrl -l

(see screenshot [1] for details and possible outputs).

py.rast and py.vect commands can be used just like the old d.* commands

for installation just untar [2] and cd new py.monitor directory

[1] http://les-ejk.cz/tmp/py.mon.png
[2] http://les-ejk.cz/programs/grass/py.monitor.tgz

Please test and discusse.

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

OK, I don't know much about Python, but this is what I get
when I do: ./py.mon start=py0

   File "mon.py", line 15, in ?
     import wx
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/__init__.py", line 42, in ?
     from wx._core import *
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 4, in ?
     import _core_
ImportError: /usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core_.so: symbol _ZTV17wxMemoryFSHandler, version WX_2.6 not defined in file libwx_gtk2_core-2.6.so.0 with link time reference

... so one more dependency to worry about in the future?

Or is this something that can easily be taken care of with a
modified configure script?

Best,

Benjamin

Jachym Cepicky wrote:

Hallo,

bugfix version of py.monitor scripts. Some people tested the scripts and
they found it nice. What about you, developers?

Current version avaliable on
http://les-ejk.cz/programs/grass/py.monitor-06-06-14-4.tgz

tar xzf py.monitor-06-06-14-4.tgz
cd py.monitor
py.mon start=py0
py.rast soils -o
py.vect roads
py.erase
...

Everything, what should work (all toolbar buttons, etc.) works. Zoom/Unzoom
avaliable via mouse wheel. Mapcontent manageable via py.* commands (this
should move to d.* commands in the future) from commandline and via any
other interface via LOCATION/MAPSET/.pyX file.

Starting with the morning, I will not have much time and I will not be
so close to internet for a week, so I will not spam your mailboxes
for a while.

It would be good just to send me some note, e.g., that you tryed, but it did
not work. It is not so easy to develop GUI without any feedback.

Looking forward

Jachym

On Wed, Jun 14, 2006 at 11:34:09AM +0200, Jachym Cepicky wrote:

Hallo,

after long discussion with Michael and a bit coding, I would like to
present new new concept of GRASS monitors.

I prepared set of py.* commands, which IMHO *should* became parts of d.*
commands. This is just a workaround this.

General concept is, each monitor has it's own LOCATION/MAPSET/.pyX file,
in which the d.* files are stored. This file is checked from the GUI and
if there is some change, it's content serves for creating the map.

Advantage of this approach is, that this file can be modified from any
GUI/CLI. Target is, to have py.mons *independent* on any UI, however
managable from *any* of them.

Screenshot can be found on [1], set of new tools can be found on [2].

Example session (in xterm) can look like follows:

py.mon start=x0
py.mon start=py0
py.rast soils
py.vect roads
py.ctrl -l
py.ctrl remove=vect
py.rast fields -o
py.vect fields fcol=yellow py.ctrl -l

(see screenshot [1] for details and possible outputs).

py.rast and py.vect commands can be used just like the old d.* commands

for installation just untar [2] and cd new py.monitor directory

[1] http://les-ejk.cz/tmp/py.mon.png
[2] http://les-ejk.cz/programs/grass/py.monitor.tgz

Please test and discusse.

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
----------------------------------------- OFFICE: GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

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

------------------------------------------------------------------------

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

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

OK, I installed wxpython on my Gentoo Linux box.
This is what I get now:

/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py:13155: UserWarning: wxPython/wxWidgets release number mismatch
   warnings.warn("wxPython/wxWidgets release number mismatch")
Traceback (most recent call last):
   File "mon.py", line 314, in ?
     main()
   File "mon.py", line 293, in main
     pymonitor = Monitor(0)
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 7473, in __init__
     self._BootstrapApp()
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 7125, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File "mon.py", line 54, in OnInit
     self.initDrawArea()
   File "mon.py", line 101, in initDrawArea
     self.back.getRegion()
   File "/home/benni/grass-cvs/py.monitor-06-06-14-4/map/raster.py", line 138, in getRegion
     key,value = line.split(":")
ValueError: too many values to unpack

Obviously due to a minor difference in library versions.
But I don't understand the message well enough to know what exactly
the problem is.

Benjamin

  Jáchym Èepický wrote:

Hallo,

yes, most of the developers desided, that wxwindows and python are the best tools which are working on *every* supported platform. I personaly would choose pygtk. But as long as you have wxwidgest and python in your system, this should work. This should also work, if you try it on ms windows - you should not need xdriver at least for the basic operation.

anyway, if you want to get rid of xdriver, you need somethign else - some other dependency.

look after thy wxpython package, it should help

jachym
______________________________________________________________

Od: benjamin.ducke@ufg.uni-kiel.de
Komu: grass-dev@grass.itc.it
Datum: 15.06.2006 10:17
Pøedmìt: Re: [GRASS-dev] making py.monitor listen to external commands

OK, I don't know much about Python, but this is what I get
when I do: ./py.mon start=py0

File "mon.py", line 15, in ?
   import wx
File

"/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/__init__.py", line
42, in ?

   from wx._core import *
File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py",

line 4, in ?

   import _core_
ImportError:

/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core_.so: symbol
_ZTV17wxMemoryFSHandler, version WX_2.6 not defined in file
libwx_gtk2_core-2.6.so.0 with link time reference

... so one more dependency to worry about in the future?

Or is this something that can easily be taken care of with a
modified configure script?

Best,

Benjamin

Jachym Cepicky wrote:

Hallo,

bugfix version of py.monitor scripts. Some people tested the scripts

and

they found it nice. What about you, developers?

Current version avaliable on

http://les-ejk.cz/programs/grass/py.monitor-06-06-14-4.tgz

tar xzf py.monitor-06-06-14-4.tgz

cd py.monitor
py.mon start=py0
py.rast soils -o
py.vect roads
py.erase
...

Everything, what should work (all toolbar buttons, etc.) works.

Zoom/Unzoom

avaliable via mouse wheel. Mapcontent manageable via py.* commands

(this

should move to d.* commands in the future) from commandline and via any
other interface via LOCATION/MAPSET/.pyX file.

Starting with the morning, I will not have much time and I will not

be

so close to internet for a week, so I will not spam your mailboxes
for a while. > > It would be good just to send me some note, e.g., that

you tryed, but it did

not work. It is not so easy to develop GUI without any feedback.

Looking forward > > Jachym
On Wed, Jun 14, 2006 at 11:34:09AM +0200, Jachym Cepicky wrote:

Hallo,

after long discussion with Michael and a bit coding, I would like to
present new new concept of GRASS monitors.

I prepared set of py.* commands, which IMHO *should* became parts of

d.*

commands. This is just a workaround this.

General concept is, each monitor has it's own LOCATION/MAPSET/.pyX

file,

in which the d.* files are stored. This file is checked from the GUI

and

if there is some change, it's content serves for creating the map.

Advantage of this approach is, that this file can be modified from any
GUI/CLI. Target is, to have py.mons *independent* on any UI, however
managable from *any* of them.

Screenshot can be found on [1], set of new tools can be found on [2].

Example session (in xterm) can look like follows:

py.mon start=x0
py.mon start=py0
py.rast soils
py.vect roads
py.ctrl -l
py.ctrl remove=vect
py.rast fields -o
py.vect fields fcol=yellow >>py.ctrl -l

(see screenshot [1] for details and possible outputs).

py.rast and py.vect commands can be used just like the old d.* commands

for installation just untar [2] and cd new py.monitor directory

[1] http://les-ejk.cz/tmp/py.mon.png
[2] http://les-ejk.cz/programs/grass/py.monitor.tgz

Please test and discusse.

Jachym
-- >>Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG:

http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc

----------------------------------------- >>OFFICE:

                  >>GDF-Hannover

Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

_______________________________________________

grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

------------------------------------------------------------------------

_______________________________________________

grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

-- Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

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

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Benjamin Ducke wrote:

OK, I installed wxpython on my Gentoo Linux box.
This is what I get now:

/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py:13155: UserWarning: wxPython/wxWidgets release number mismatch

What are the release numbers of the two, i.e. of wxPython and of wxWidgets (called libwxgtk in Debian) ?

Moritz

It seems that wxwidgets is 2.6.2 while
wxpython is 2.6.1. Could that be enough to cause
trouble?

Benjamin

Moritz Lennert wrote:

Benjamin Ducke wrote:

OK, I installed wxpython on my Gentoo Linux box.
This is what I get now:

/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py:13155: UserWarning: wxPython/wxWidgets release number mismatch

What are the release numbers of the two, i.e. of wxPython and of wxWidgets (called libwxgtk in Debian) ?

Moritz

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Benjamin Ducke wrote:

It seems that wxwidgets is 2.6.2 while
wxpython is 2.6.1. Could that be enough to cause
trouble?

Can you put them to equal versions and see ?

Moritz

Benjamin

Moritz Lennert wrote:

Benjamin Ducke wrote:

OK, I installed wxpython on my Gentoo Linux box.
This is what I get now:

/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py:13155: UserWarning: wxPython/wxWidgets release number mismatch

What are the release numbers of the two, i.e. of wxPython and of wxWidgets (called libwxgtk in Debian) ?

Moritz

Hallo,

I just tryed the py.mon stuff on win xp box and it nearly worked :slight_smile: the window appears, but I did not manage to display any map.
this just means, that used approach (python + wxwidget) seem really to work on windows and that it can use at least some commands from grass via os.system()

screenshot on les-ejk.cz/tmp/pymon-win.png [0.5 MB]

Have a nice weekend

Jachym

P.S. I used Wingrass (qgis+grass) precompiled package from Radim, started qgis, started GRASS-Shell and run. Maybe in commandline.exe it would work better?
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
LDF MZLU v Brnì
Zemìdìlská 3
613 00 Brno
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

______________________________________________________________

Od: jachym.cepicky@centrum.cz
Komu: grass-dev@grass.itc.it
Datum: 12.06.2006 20:32
Pøedmìt: [GRASS-dev] making py.monitor listen to external commands

Hallo,

I'm trying to script something, which could be in the future called
py.mon(itor) using wxpython together with xrc.

The basic is here - I can display ppm file

Now, I would like to make it "listen" to command line commands and I
have been thinking of approach like this:

The idea is, you would tip just normal py.* commands in the command line,
but there would be process running in background, which would pick up
the last line from history file (e.g. .monitor_x0_history) and add it to

stack of

commands for the monitor.

We would have to create set of py.* commands, which would replace the
d.* commands and general structure of this py.* commands would look like
this:

---------------------------
# py.rast

# get the selected monitor
monitor = os.getenv("GRASS_MONITOR")

# get the file name
command_file =

os.path.join(GISBASE,LOCATION,MAPSET,".monitor_"+monitor+"_history)

# write d.rast to commands
file = open(command_file,"a")
file.write("d.rast "+sys.arg[1:])
file.close()
---------------------------

Then there should be loop in py.monitor:

   1) watcher(), which would take care on the .monitor_x0_history file

just like tail -f does

      if there would be some change, it would add command to the
       monitor commands stack and redraw the monitor with new set of
       commands

   2) pymonitor.MainLoop(), which displays the gui and sets the
       variables

So, I have monitor (see screenshot [1]), I can tip commands in some
"terminal" under the window. I have "watcher" which takes care on the
command file and if there is some change, it should set the "monitor
terminal" to the value of the command(s) to new command.

But it does not because the processes do not "see" each other. I'm also
not able to kill the processes while closing the monitor, because of I'm
not able to get their PIDs.

So my question: how to perform task like this? I know, this is task for
"reall" programmers, maybe I choosed completly wrong approach.

I took the code from
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012 and
modified it like this:

-------------------------------
class Monitor(wx.App):
   """
   py.monitor gui
   """

   def OnInit(self):
       """
       Init the gui
       """

       try:
           pid = os.fork()
           if pid > 0:
               # exit first parent
               sys.exit(0)
       except OSError, e:
           print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno,
   e.strerror)
           sys.exit(1)

       # decouple from parent environment
       os.setsid()
       os.umask(0)

       # initialize the GUI
       self.initFrame()
       self.rast = map.raster.Raster()
       self.initToolBar()
       self.initCommands()
       self.initDrawArea()
       self.frame.Show()

       # do second fork
       try:
           pid = os.fork()
           if pid > 0:
               # exit from second parent, print eventual PID before
               #print "Daemon PID %d" % pid
               
               # OnInit should return boolean value
               return True

               #sys.exit(0)
       except OSError, e:
           print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno,
   e.strerror)
           sys.exit(1)

       # start the daemon watcher
       self.watcher()

[....]

# startin the gui
def main():
   pymonitor = Monitor(0)
   pymonitor.MainLoop()

-------------------------------

Thanks for hints I hope, one can understand, what I wanted to say.

Jachym

[1] http://les-ejk.cz/tmp/py.monitor.png
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

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

I just updated wxpython to the newest version, compiled from
source and this is the result:

   File "mon.py", line 15, in ?
     import wx
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/__init__.py", line 42, in ?
     from wx._core import *
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 4, in ?
     import _core_
ImportError: /usr/lib/libwx_base_odbc-2.6.so.0: symbol _ZN9wxVariantaSEPK14tagDATE_STRUCT, version WX_2.6 no t defined in file libwx_base-2.6.so.0 with link time reference

Forgive me, but I am starting to like Tcl/Tk more and more.
That has worked for me without a flaw since 1996 ...

Benjamin

  Jáchym Èepický wrote:

Hallo,

I just tryed the py.mon stuff on win xp box and it nearly worked :slight_smile: the window appears, but I did not manage to display any map.
this just means, that used approach (python + wxwidget) seem really to work on windows and that it can use at least some commands from grass via os.system()

screenshot on les-ejk.cz/tmp/pymon-win.png [0.5 MB]

Have a nice weekend

Jachym

P.S. I used Wingrass (qgis+grass) precompiled package from Radim, started qgis, started GRASS-Shell and run. Maybe in commandline.exe it would work better?
--
Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg\_public\_key/ ----------------------------------------- OFFICE: Department of Geoinformation Technologies LDF MZLU v Brnì Zemìdìlská 3 613 00 Brno e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

______________________________________________________________

Od: jachym.cepicky@centrum.cz
Komu: grass-dev@grass.itc.it
Datum: 12.06.2006 20:32
Pøedmìt: [GRASS-dev] making py.monitor listen to external commands

Hallo,

I'm trying to script something, which could be in the future called
py.mon(itor) using wxpython together with xrc.

The basic is here - I can display ppm file

Now, I would like to make it "listen" to command line commands and I
have been thinking of approach like this:

The idea is, you would tip just normal py.* commands in the command line,
but there would be process running in background, which would pick up
the last line from history file (e.g. .monitor_x0_history) and add it to

stack of

commands for the monitor.

We would have to create set of py.* commands, which would replace the
d.* commands and general structure of this py.* commands would look like
this:

---------------------------
# py.rast

# get the selected monitor
monitor = os.getenv("GRASS_MONITOR")

# get the file name
command_file =

os.path.join(GISBASE,LOCATION,MAPSET,".monitor_"+monitor+"_history)

# write d.rast to commands
file = open(command_file,"a")
file.write("d.rast "+sys.arg[1:])
file.close()
---------------------------

Then there should be loop in py.monitor:

  1) watcher(), which would take care on the .monitor_x0_history file

just like tail -f does

     if there would be some change, it would add command to the
      monitor commands stack and redraw the monitor with new set of
      commands

  2) pymonitor.MainLoop(), which displays the gui and sets the
      variables

So, I have monitor (see screenshot [1]), I can tip commands in some
"terminal" under the window. I have "watcher" which takes care on the
command file and if there is some change, it should set the "monitor
terminal" to the value of the command(s) to new command.

But it does not because the processes do not "see" each other. I'm also
not able to kill the processes while closing the monitor, because of I'm
not able to get their PIDs.

So my question: how to perform task like this? I know, this is task for
"reall" programmers, maybe I choosed completly wrong approach.

I took the code from
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012 and
modified it like this:

-------------------------------
class Monitor(wx.App):
  """
  py.monitor gui
  """

  def OnInit(self):
      """
      Init the gui
      """

      try: pid = os.fork() if pid > 0:
              # exit first parent
              sys.exit(0) except OSError, e: print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno,
  e.strerror) sys.exit(1)

      # decouple from parent environment
      os.setsid() os.umask(0)

      # initialize the GUI
      self.initFrame()
      self.rast = map.raster.Raster()
      self.initToolBar()
      self.initCommands()
      self.initDrawArea()
      self.frame.Show()

      # do second fork
      try: pid = os.fork() if pid > 0:
              # exit from second parent, print eventual PID before
              #print "Daemon PID %d" % pid
                            # OnInit should return boolean value
              return True

              #sys.exit(0) except OSError, e: print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno,
  e.strerror) sys.exit(1)

      # start the daemon watcher
      self.watcher()

[....]

# startin the gui
def main():
  pymonitor = Monitor(0)
  pymonitor.MainLoop()

-------------------------------

Thanks for hints I hope, one can understand, what I wanted to say.

Jachym

[1] http://les-ejk.cz/tmp/py.monitor.png
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
----------------------------------------- OFFICE: GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

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

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

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Right, I fixed linker symbol problem by compiling wxpython
with exactly the same options as wxwidgets (both newest
versions).
Now I am back to the old error:

Traceback (most recent call last):
   File "mon.py", line 314, in ?
     main()
   File "mon.py", line 293, in main
     pymonitor = Monitor(0)
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 7473, in __init__
     self._BootstrapApp()
   File "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py", line 7125, in _BootstrapApp
     return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File "mon.py", line 54, in OnInit
     self.initDrawArea()
   File "mon.py", line 101, in initDrawArea
     self.back.getRegion()
   File "/home/benni/grass-cvs/py.monitor-06-06-14-4/map/raster.py", line 138, in getRegion
     key,value = line.split(":")
ValueError: too many values to unpack

No idea what to do about this.
Btw.: if py.mon crashes before it even gets a chance to open a
monitor, it still leaves a lockfile .py0 in the current mapset
preventing it to start next time.

Best,

Benjamin

  Jáchym Èepický wrote:

Hallo,

I just tryed the py.mon stuff on win xp box and it nearly worked :slight_smile: the window appears, but I did not manage to display any map.
this just means, that used approach (python + wxwidget) seem really to work on windows and that it can use at least some commands from grass via os.system()

screenshot on les-ejk.cz/tmp/pymon-win.png [0.5 MB]

Have a nice weekend

Jachym

P.S. I used Wingrass (qgis+grass) precompiled package from Radim, started qgis, started GRASS-Shell and run. Maybe in commandline.exe it would work better?
--
Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://les-ejk.cz/gnupg\_public\_key/ ----------------------------------------- OFFICE: Department of Geoinformation Technologies LDF MZLU v Brnì Zemìdìlská 3 613 00 Brno e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

______________________________________________________________

Od: jachym.cepicky@centrum.cz
Komu: grass-dev@grass.itc.it
Datum: 12.06.2006 20:32
Pøedmìt: [GRASS-dev] making py.monitor listen to external commands

Hallo,

I'm trying to script something, which could be in the future called
py.mon(itor) using wxpython together with xrc.

The basic is here - I can display ppm file

Now, I would like to make it "listen" to command line commands and I
have been thinking of approach like this:

The idea is, you would tip just normal py.* commands in the command line,
but there would be process running in background, which would pick up
the last line from history file (e.g. .monitor_x0_history) and add it to

stack of

commands for the monitor.

We would have to create set of py.* commands, which would replace the
d.* commands and general structure of this py.* commands would look like
this:

---------------------------
# py.rast

# get the selected monitor
monitor = os.getenv("GRASS_MONITOR")

# get the file name
command_file =

os.path.join(GISBASE,LOCATION,MAPSET,".monitor_"+monitor+"_history)

# write d.rast to commands
file = open(command_file,"a")
file.write("d.rast "+sys.arg[1:])
file.close()
---------------------------

Then there should be loop in py.monitor:

  1) watcher(), which would take care on the .monitor_x0_history file

just like tail -f does

     if there would be some change, it would add command to the
      monitor commands stack and redraw the monitor with new set of
      commands

  2) pymonitor.MainLoop(), which displays the gui and sets the
      variables

So, I have monitor (see screenshot [1]), I can tip commands in some
"terminal" under the window. I have "watcher" which takes care on the
command file and if there is some change, it should set the "monitor
terminal" to the value of the command(s) to new command.

But it does not because the processes do not "see" each other. I'm also
not able to kill the processes while closing the monitor, because of I'm
not able to get their PIDs.

So my question: how to perform task like this? I know, this is task for
"reall" programmers, maybe I choosed completly wrong approach.

I took the code from
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012 and
modified it like this:

-------------------------------
class Monitor(wx.App):
  """
  py.monitor gui
  """

  def OnInit(self):
      """
      Init the gui
      """

      try: pid = os.fork() if pid > 0:
              # exit first parent
              sys.exit(0) except OSError, e: print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno,
  e.strerror) sys.exit(1)

      # decouple from parent environment
      os.setsid() os.umask(0)

      # initialize the GUI
      self.initFrame()
      self.rast = map.raster.Raster()
      self.initToolBar()
      self.initCommands()
      self.initDrawArea()
      self.frame.Show()

      # do second fork
      try: pid = os.fork() if pid > 0:
              # exit from second parent, print eventual PID before
              #print "Daemon PID %d" % pid
                            # OnInit should return boolean value
              return True

              #sys.exit(0) except OSError, e: print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno,
  e.strerror) sys.exit(1)

      # start the daemon watcher
      self.watcher()

[....]

# startin the gui
def main():
  pymonitor = Monitor(0)
  pymonitor.MainLoop()

-------------------------------

Thanks for hints I hope, one can understand, what I wanted to say.

Jachym

[1] http://les-ejk.cz/tmp/py.monitor.png
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
----------------------------------------- OFFICE: GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

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

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

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg