#2127: Python implementation of g.message
-------------------------+--------------------------------------------------
Reporter: huhabla | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Python | Version: svn-trunk
Keywords: | Platform: Unspecified
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by huhabla):
Replying to [comment:1 glynn]:
> Replying to [ticket:2127 huhabla]:
>
> > In case these messages are called many times (> 100), the overhead of
calling g.message rises and can slow the actual processing massively down.
>
> Why would you call them so many times?
I would like to add debug messages, verbose messages and the percentage
output to many processing steps in the temporal framework, so that the
user can follow the processing of time stamped maps. I usually handle
hundreds to many thousands of maps. In the current message approach
g.message is called every single step to evaluate the debug, verbosity
level and so on.
>
> I can just about understand it for debug(), in which case it might be
better to use native Python equivalents (e.g. the `logging` module). If
you're calling anything else >100 times (even verbose()), the script is
probably too chatty.
>
> > I would suggest to implement the behavior of g.message directly in
Python to reduce the overhead, replacing the functions that make use of
g.message:
>
> Then we would need to keep the two in sync.
>
> G_message() etc aren't exactly trivial; they support multiple output
formats, word-wrapping, configution of verbosity and output format via
environment variables and command-line switches, and reporting of messages
via stderr, log file and/or email.
>
> If performance is a genuine issue, I would rather see g.message enhanced
so that it can be used as a server, with the script spawning a single
persistent g.message process which can accept multiple messages (of
varying priorities) read from stdin.
That is a great idea indeed. I would suggest to implement this message
server using Python that calls the G_message() functions using ctypes.
This can be part of PyGRASS that implements the server process and the
client access functions that sends text messages to the sever process that
writes to stderr.
Example interface:
{{{
import grass.pygrass.messages as messages
# Create the messenger object that starts the server process.
# As Glynn said, the server accepts multiple messages with different
priorities.
msgr = messages.Messenger()
# In addition to the stdout/stderr output, the server can write the
messages into a logfile
msgr.set_logfile("logfile.txt")
# Send an info message to the server, the server will call the G_info()
function using ctypes
msgr.info("This is an info message")
# Send a verbose message, the server will call the G_verbose() function
using ctypes
msgr.verbose("This is a verbose message")
# Send a warning message, the server will call the G_warning() function
using ctypes
msgr.warning("This is the last warning")
# Send an error message, the server will call the G_error() function using
ctypes
msgr.error("This is an error message")
# Send a percentage message, the server will call the G_percent() function
using ctypes
msgr.percent(1, 1, 1) # 100%
}}}
The PyGRASS implementation could be able to respawn the server process in
case a G_fatal_error() occurred while using the ctypes interface. The
server process will be shut down if the Python object gets deleted. The
communication between server and client functions should be as fast as
possible, hence the client simply sends out a message and does not wait
for a server response.
As Vaclav pointed out: such an interface would be very useful for Python
libraries, modules and the GUI.
This kind of client server approach where the server calls ctype GRASS
functions can also be useful in other application: for example the GUI can
send vector editing messages (ctypes objects?) to a GRASS vector edit
server process, that can be respawned in case of a fatal error. Hence the
GUI will not crash when an error occurs.
Sounds like a kind of remote procedure call interface to the functions of
the GRASS C-libraries.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2127#comment:3>
GRASS GIS <http://grass.osgeo.org>
