Re: [GRASS-dev] temporal framework currently not working on windows
Hi Glynn, thanks a lot for this excellent explanation. Best regards Soeren 2014-11-27 18:59 GMT+01:00 Glynn Clements gl...@gclements.plus.com: Sören Gebbert wrote: I would like to better understand, this point... Why the decorator must_be_open it seems to work so far? which is the difference between @must_be_open[0] and @mdebug[1]? Any Ideas? Unfortunately i have no idea. I did not found good information about when and how exactly these decorators are processed. So my guess was that (because of the backtrace) the decorator function is somehow analyzed at import time and the messenger process gets started. A function used as a decorator is invoked when the decorated function is defined, which is usually at import time. The code: @decorator def foo(): pass is equivalent to def foo(): pass foo = decorator(foo) Whether this poses a problem depends upon exactly *what* the decorator does. Typical decorators simply return a closure, i.e. a local function which, when called, calls the function being decorated. This situation is usually harmless, as nothing significant happens until the decorated function is actually invoked. As a general rule, modules shouldn't do anything substantial on import. If you're using decorators, this typically means that the decorators shouldn't do anything substantial, as they'll be called on import. Any work should be deferred until the decorated function is called (i.e. it goes inside the local function, not in the body of the decorator). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] temporal framework currently not working on windows
Hi,
it looks like the problem is the function decorator @mdebug. I am
not a Python expert, but IMHO this problem occurs because:
1.) Windows sucks ;)
2.) The function decorator code is analysed at import time, which is a
bad idea, since the messaging server process get started at import
time. This should be avoided on any OS.
3.) See the first point
My solution would be to remove the function decorator code using the
most simple approach to add debug messages to the module interface:
Instead of a function decorator we place this code snippet in the
function that should emit a debug message.
{{{
from grass.pygrass.messages import get_msgr
get_msgr().debug(1, self.get_bash())
}}}
What do you think?
Pietro do you have any objections ... or does my approach does not
solve the problem?
Best regards
Soeren
2014-11-26 21:15 GMT+01:00 Anna Petrášová kratocha...@gmail.com:
I just realized temporal framework doesn't work with recent GRASS 70 version
on Windows:
t.list or t.create give me:
Traceback (most recent call last):
File string, line 1, in module
File C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py, line 380,
in main
prepare(preparation_data)
File C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py, line 495,
in prepare
'__parents_main__', file, path_name, etc
File C:\GRASS70\GRASS GIS 7.0.0svn\scripts\t.create.py,
line 60, in module
import grass.temporal as tgis
File C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\temporal\__init__.py, line 29, in
module
from temporal_vector_algebra import *
File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\tempo
ral\temporal_vector_algebra.py, line 422, in module
import grass.pygrass.modules as pygrass
File C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\modules\__init__.py, line
2, in module
from grass.pygrass.modules.interface import Module,
ParallelModuleQueue
File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\__init__.py, line 9, in module
from grass.pygrass.modules.interface import module
File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py, line 188, in module
class Module(object):
File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py, line 591, in Module
@mdebug(1, extra=_get_bash)
File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py, line 36, in mdebug
msgr = get_msgr()
File C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py,
line 352, in get_msgr
_instance[0] = Messenger(*args, **kwargs)
File C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py,
line 175, in __init__
self.start_server()
File C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py,
line 185, in start_server
self.server.start()
File C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\process.py, line 130,
in start
self._popen = Popen(self)
File C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py, line 258,
in __init__
cmd = get_command_line() + [rhandle]
File C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py, line 358,
in get_command_line
is not going to be frozen to produce a Windows
executable.''')
RuntimeError:
Attempt to start a new process before the
current process
has finished its bootstrapping phase.
This probably means that you are on Windows and
you have
forgotten to use the proper idiom in the main
module:
if __name__ == '__main__':
freeze_support()
...
The freeze_support() line can be omitted if
the program
is not going to be frozen to produce a Windows
executable.
I tested with the most recent build and a user reports the same problem with
r62706.
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] temporal framework currently not working on windows
2014-11-26 21:15 GMT+01:00 Anna Petrášová kratocha...@gmail.com: I just realized temporal framework doesn't work with recent GRASS 70 version on Windows: t.list or t.create give me: [...] File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\forking.py, line 258, in __init__ cmd = get_command_line() + [rhandle] File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\forking.py, line 358, in get_command_line is not going to be frozen to produce a Windows executable.''') RuntimeError: Attempt to start a new process before the current process has finished its bootstrapping phase. This probably means that you are on Windows and you have forgotten to use the proper idiom in the main module: if __name__ == '__main__': freeze_support() ... The freeze_support() line can be omitted if the program is not going to be frozen to produce a Windows executable. see also [1]. Martin [1] http://trac.osgeo.org/grass/ticket/580#comment:60 -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] temporal framework currently not working on windows
Hi Sören,
On Thu, Nov 27, 2014 at 11:38 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
My solution would be to remove the function decorator code using the
most simple approach to add debug messages to the module interface:
Instead of a function decorator we place this code snippet in the
function that should emit a debug message.
{{{
from grass.pygrass.messages import get_msgr
get_msgr().debug(1, self.get_bash())
}}}
What do you think?
Pietro do you have any objections ... or does my approach does not
solve the problem?
No objections from my side.
I'm going to remove the decorator.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] temporal framework currently not working on windows
On Thu, Nov 27, 2014 at 11:38 AM, Sören Gebbert soerengebb...@googlemail.com wrote: The function decorator code is analysed at import time, which is a bad idea, since the messaging server process get started at import time. This should be avoided on any OS. I would like to better understand, this point... Why the decorator must_be_open it seems to work so far? which is the difference between @must_be_open[0] and @mdebug[1]? Any Ideas? Pietro [0] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/errors.py [1] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/module.py#L26 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] temporal framework currently not working on windows
Unfortunately i have no idea. I did not found good information about when and how exactly these decorators are processed. So my guess was that (because of the backtrace) the decorator function is somehow analyzed at import time and the messenger process gets started. So maybe the difference is that the must_be_open method is analyzed later or that the messenger function is in an if statement? Best regards Soeren 2014-11-27 16:03 GMT+01:00 Pietro peter.z...@gmail.com: On Thu, Nov 27, 2014 at 11:38 AM, Sören Gebbert soerengebb...@googlemail.com wrote: The function decorator code is analysed at import time, which is a bad idea, since the messaging server process get started at import time. This should be avoided on any OS. I would like to better understand, this point... Why the decorator must_be_open it seems to work so far? which is the difference between @must_be_open[0] and @mdebug[1]? Any Ideas? Pietro [0] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/errors.py [1] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/module.py#L26 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] temporal framework currently not working on windows
Sören Gebbert wrote: I would like to better understand, this point... Why the decorator must_be_open it seems to work so far? which is the difference between @must_be_open[0] and @mdebug[1]? Any Ideas? Unfortunately i have no idea. I did not found good information about when and how exactly these decorators are processed. So my guess was that (because of the backtrace) the decorator function is somehow analyzed at import time and the messenger process gets started. A function used as a decorator is invoked when the decorated function is defined, which is usually at import time. The code: @decorator def foo(): pass is equivalent to def foo(): pass foo = decorator(foo) Whether this poses a problem depends upon exactly *what* the decorator does. Typical decorators simply return a closure, i.e. a local function which, when called, calls the function being decorated. This situation is usually harmless, as nothing significant happens until the decorated function is actually invoked. As a general rule, modules shouldn't do anything substantial on import. If you're using decorators, this typically means that the decorators shouldn't do anything substantial, as they'll be called on import. Any work should be deferred until the decorated function is called (i.e. it goes inside the local function, not in the body of the decorator). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] temporal framework currently not working on windows
I just realized temporal framework doesn't work with recent GRASS 70 version on Windows: t.list or t.create give me: Traceback (most recent call last): File string, line 1, in module File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\forking.py, line 380, in main prepare(preparation_data) File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\forking.py, line 495, in prepare '__parents_main__', file, path_name, etc File C:\GRASS70\GRASS GIS 7.0.0svn\scripts\t.create.py, line 60, in module import grass.temporal as tgis File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\temporal\__init__.py, line 29, in module from temporal_vector_algebra import * File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\tempo ral\temporal_vector_algebra.py, line 422, in module import grass.pygrass.modules as pygrass File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygrass\modules\__init__.py, line 2, in module from grass.pygrass.modules.interface import Module, ParallelModuleQueue File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra ss\modules\interface\__init__.py, line 9, in module from grass.pygrass.modules.interface import module File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra ss\modules\interface\module.py, line 188, in module class Module(object): File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra ss\modules\interface\module.py, line 591, in Module @mdebug(1, extra=_get_bash) File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra ss\modules\interface\module.py, line 36, in mdebug msgr = get_msgr() File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygrass\messages\__init__.py, line 352, in get_msgr _instance[0] = Messenger(*args, **kwargs) File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygrass\messages\__init__.py, line 175, in __init__ self.start_server() File C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygrass\messages\__init__.py, line 185, in start_server self.server.start() File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\process.py, line 130, in start self._popen = Popen(self) File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\forking.py, line 258, in __init__ cmd = get_command_line() + [rhandle] File C:\GRASS70\GRASS GIS 7.0.0svn\Python27\lib\multiprocessing\forking.py, line 358, in get_command_line is not going to be frozen to produce a Windows executable.''') RuntimeError: Attempt to start a new process before the current process has finished its bootstrapping phase. This probably means that you are on Windows and you have forgotten to use the proper idiom in the main module: if __name__ == '__main__': freeze_support() ... The freeze_support() line can be omitted if the program is not going to be frozen to produce a Windows executable. I tested with the most recent build and a user reports the same problem with r62706. Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
