Hi,
a lot of tests are failing:
http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
it seems that
http://trac.osgeo.org/grass/changeset/62349
causes a lot failures. Problems are in some temporal modules, pygrass and gunittests tests.
Anna
Hi,
2014-10-23 21:10 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
it seems that
http://trac.osgeo.org/grass/changeset/62349
causes a lot failures. Problems are in some temporal modules, pygrass and
gunittests tests.
hm, Soeren/Pietro any idea why it fails? Thanks, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Thu, Oct 23, 2014 at 9:25 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-23 21:10 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
it seems that
http://trac.osgeo.org/grass/changeset/62349
causes a lot failures. Problems are in some temporal modules, pygrass and
gunittests tests.hm, Soeren/Pietro any idea why it fails? Thanks, Martin
yes I think it fails because has broken the "pickability" of the
Module instance.
It should be fix in r62374.
However, I would like to revert your change... 
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class is indirectly using ctypes.
Therefore all the work done to distinguish and isolate pygrass'
submodules that are using the ctypes is not valid any more.
Finally, I wrote a method decorator to add a debug message, this
function it is general enough to be used outside pygrass, but again it
is using ctypes that could be a problem if in a gui etc.
Otherwise we can modify the Messenger class to avoid to use the ctypes.
I don't know which option of the above is the right choice...
Pietro
Hi,
2014-10-24 12:04 GMT+02:00 Pietro <peter.zamb@gmail.com>:
On Thu, Oct 23, 2014 at 9:25 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-23 21:10 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
it seems that
http://trac.osgeo.org/grass/changeset/62349
causes a lot failures. Problems are in some temporal modules, pygrass and
gunittests tests.hm, Soeren/Pietro any idea why it fails? Thanks, Martin
yes I think it fails because has broken the "pickability" of the
Module instance.
It should be fix in r62374.
Thats an interesting approach, very sophisticated. However, the direct use of
the "get_msgr()" function would solve the problem as well.
For explanation: the messenger module creates pipes, locks and
subprocesses and somehow you cant use them when the object that
contains them should be serialized.
The error is that Python lock objects should only be shared between
processes through inheritance.
The problem is IMHO not related to ctypes, since ctypes is used in the
subprocess that communicates via pipes with the messenger (main
process).
However, I would like to revert your change...
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class is indirectly using ctypes.
Therefore all the work done to distinguish and isolate pygrass'
submodules that are using the ctypes is not valid any more.Finally, I wrote a method decorator to add a debug message, this
function it is general enough to be used outside pygrass, but again it
is using ctypes that could be a problem if in a gui etc.Otherwise we can modify the Messenger class to avoid to use the ctypes.
Ctypes is IMHO not the problem here, since it is used in the messenger
subprocess.
No GRASS library function is called in the main Python process.
This is a principal design of an RPC approach.
I don't know which option of the above is the right choice...
The decorator looks nice, but using get_msgr() that uses a singleton
approach directly should work as well.
It is important that messenger objects are NOT part of objects that
should be serialized.
Hence do not:
self._msgr = get_msgr()
self._msgr.debug(0, "Hello")
Use instead:
get_msgr().debug(0, "Hello")
Or like this:
from grass.pygrass.messages import get_msgr as msgr
msgr().message("Hallo")
Best regards
Soeren
Pietro
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2014-10-24 12:04 GMT+02:00 Pietro <peter.zamb@gmail.com>:
However, I would like to revert your change...
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class is indirectly using ctypes.
Therefore all the work done to distinguish and isolate pygrass'
submodules that are using the ctypes is not valid any more.
well, it's _very_ useful info to know which commands are called on
background. So if you revert it please provide this info somehow in
other way.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
On Fri, Oct 24, 2014 at 12:56 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
However, I would like to revert your change...
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class is indirectly using ctypes.
Therefore all the work done to distinguish and isolate pygrass'
submodules that are using the ctypes is not valid any more.Finally, I wrote a method decorator to add a debug message, this
function it is general enough to be used outside pygrass, but again it
is using ctypes that could be a problem if in a gui etc.Otherwise we can modify the Messenger class to avoid to use the ctypes.
Ctypes is IMHO not the problem here, since it is used in the messenger
subprocess.
No GRASS library function is called in the main Python process.
This was not true, libgis.G_gisinit('') was called at import level, I
removed the line in r62376.
So now what you said is true.
So, I think that now the decorator is re-usable for general debug
purpose, so I think should move somewhere, I can move it to
pygrass.functions, other ideas?
On Fri, Oct 24, 2014 at 1:05 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-24 12:04 GMT+02:00 Pietro <peter.zamb@gmail.com>:
However, I would like to revert your change...
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class is indirectly using ctypes.
Therefore all the work done to distinguish and isolate pygrass'
submodules that are using the ctypes is not valid any more.well, it's _very_ useful info to know which commands are called on
background. So if you revert it please provide this info somehow in
other way.
I agree that is useful and this is why I didn't revert it.
So now it provide as a decorator.