The wxpython interface is still seriously unusable in grass RC5 on unstable. I
found the same result using current 6.4.0 branch r39426.
Trying to edit any vector files this is the result:
Traceback (most recent call last):
File
"/usr/lib/grass64/etc/wxpython/gui_modules/vdigit.py", line
233, in __init__
mapwindow)
File
"/usr/lib/grass64/etc/wxpython/vdigit/grass6_wxvdigit.py",
line 334, in __init__
this = _grass6_wxvdigit.new_Digit(*args)
TypeError: in method 'new_Digit', argument 2 of type
'wxWindow *'
Currently there are at least a couple of differences among sid and e.g.
Ubuntu karamic (where it seems working):
swig 1.3.39 instead of 1.3.36
wxpython 2.8.7 instead of 2.8.10
I suspect the main problem is swig, due to past experiences. What are
the reference versions suggested currently? I would suggest to
distribute swig generated stuff by default and allowing re-building
on demand. That solved various swig-related problems in the past.
I'm doing some other trials to discover if my guess is true.
2009/10/7 Francesco P. Lovergine <frankie@debian.org>:
[...]
swig 1.3.39 instead of 1.3.36
wxpython 2.8.7 instead of 2.8.10
I suspect the main problem is swig, due to past experiences. What are
the reference versions suggested currently? I would suggest to
distribute swig generated stuff by default and allowing re-building
on demand. That solved various swig-related problems in the past.
yes, downgrade to swig 1.3.36 helps. I hope to have more time to dig
into the problem.
On Wed, Oct 07, 2009 at 03:46:40PM +0200, Martin Landa wrote:
Hi,
2009/10/7 Francesco P. Lovergine <frankie@debian.org>:
[...]
> swig 1.3.39 instead of 1.3.36
> wxpython 2.8.7 instead of 2.8.10
>
> I suspect the main problem is swig, due to past experiences. What are
> the reference versions suggested currently? I would suggest to
> distribute swig generated stuff by default and allowing re-building
> on demand. That solved various swig-related problems in the past.
yes, downgrade to swig 1.3.36 helps. I hope to have more time to dig
into the problem.
Martin
Yep, indeed it works with current testing swig. And it also fixes the problem
issued for 3d view by other users. As said, it would be a good idea adding
known working swig stuff to the source tarball, as gdal does. It is almost
impossible having the same swig version installed on all systems and swig
is a know source of problems...
> > swig 1.3.39 instead of 1.3.36
> > wxpython 2.8.7 instead of 2.8.10
> >
> > I suspect the main problem is swig, due to past experiences. What are
> > the reference versions suggested currently? I would suggest to
> > distribute swig generated stuff by default and allowing re-building
> > on demand. That solved various swig-related problems in the past.
>
> yes, downgrade to swig 1.3.36 helps. I hope to have more time to dig
> into the problem.
Yep, indeed it works with current testing swig. And it also fixes the problem
issued for 3d view by other users. As said, it would be a good idea adding
known working swig stuff to the source tarball, as gdal does. It is almost
impossible having the same swig version installed on all systems and swig
is a know source of problems...
The other option is to abandon SWIG in favour of Python's ctypes
module. This is more work, but it's also more flexible, and will
produce a better result in the end.
It may even be possible to automate the wrapper generation. While this
won't be perfect, neither is SWIG; any automatic approach has the
problem that a C prototype doesn't contain enough information.
On Thu, Oct 08, 2009 at 02:13:46AM +0100, Glynn Clements wrote:
> Yep, indeed it works with current testing swig. And it also fixes the problem
> issued for 3d view by other users. As said, it would be a good idea adding
> known working swig stuff to the source tarball, as gdal does. It is almost
> impossible having the same swig version installed on all systems and swig
> is a know source of problems...
The other option is to abandon SWIG in favour of Python's ctypes
module. This is more work, but it's also more flexible, and will
produce a better result in the end.
It may even be possible to automate the wrapper generation. While this
won't be perfect, neither is SWIG; any automatic approach has the
problem that a C prototype doesn't contain enough information.
I opened a ticket #782 about that, just to leave trace of the problem.
BTW, the wrapper generation _is_ automated by means of swig currently:
that's exactly the problem here
> The other option is to abandon SWIG in favour of Python's ctypes
> module. This is more work, but it's also more flexible, and will
> produce a better result in the end.
>
> It may even be possible to automate the wrapper generation. While this
> won't be perfect, neither is SWIG; any automatic approach has the
> problem that a C prototype doesn't contain enough information.
I opened a ticket #782 about that, just to leave trace of the problem.
BTW, the wrapper generation _is_ automated by means of swig currently:
that's exactly the problem here
SWIG generates C or C++ code for a binary extension module. This is
sensitive to the version of Python installed.
If anything, providing SWIG-generated wrappers to the user will be
worse for compatibility. While it isn't guaranteed that the user's
SWIG is compatible with the user's Python, it's even less likely that
the developer's SWIG will be compatible with the user's Python.
ctypes wrappers are pure Python code, which means that they can adapt
to the version of Python used at run-time if necessary.
If the wrappers were auto-generated, this would be a one-time
operation. The wrappers would be source code, not intermediate files
which are generated as part of the build process, and would be updated
manually if the library changed.
The other option is to abandon SWIG in favour of Python's ctypes
module. This is more work, but it's also more flexible, and will
produce a better result in the end.
honestly I don't know how to do it...
It may even be possible to automate the wrapper generation. While this
won't be perfect, neither is SWIG; any automatic approach has the
problem that a C prototype doesn't contain enough information.
My attempt is to improve current situation and to make wxGUI
extensions working on MS Windows. I will appreciate any help from you.
The other option is to abandon SWIG in favour of Python's ctypes
module. This is more work, but it's also more flexible, and will
produce a better result in the end.
.. as long as you weren't intending to use swig + perl or java bindings ..
