[GRASS-dev] temporal framework currently not working on windows

[Sören Gebbert]

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á <kratochanna at 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