[GRASS-dev] 6.4.0 blocker bugs

[Hamish]

everyone wrote:
> > >>> time to get out 6.4.0final :-)

MN:
> > I learned that we should await the ctypes port to get
> > rid of SWIG?

Glynn:
> SWIG is only used within GRASS for the wxGUI vdigit and
> nviz modules. It's also used to generate wrappers for
> programmers who wish to access the libraries directly, but
> these aren't used by any part of GRASS.
> 
> I suggest disabling all of this in the final release. The
> vdigit and nviz modules don't work on Windows, and aren't
> particularly robust on other platforms (and being loaded
> in-process means that any problems affect the GUI as a whole,
> not just the vdigit/nviz modules).
> 
> The SWIG wrappers for the libraries are barely usable and
> are planned to be replaced, so we shouldn't be encouraging
> their use.
> 
> IOW:
> 
> 1. The "swig" directory should be removed from DIRS in the
> top-level Makefile, so it isn't built (unless the user builds
> it manually).

fyi I've just commented out the SUBDIRS+=python in the
grass 6.5 swig/Makefile, assuming ctypes will take its place
there. no objection to it happening in the root Makefile.

I agree that we shouldn't release 6.4.0 with swig enabled, as
it will only encourage folks to invest in a dead-end.

> 2. Official binaries shouldn't use --with-python; this will
> prevent the vdigit and nviz modules from being built.
>
> 3. Optionally back-port the ctypes wrappers (lib/python/
> ctypes). Even if this doesn't work (fails to build or
> generates broken wrappers), it shouldn't break anything which
> would otherwise work.
> 
> 4. Optionally back-port the ctypes-based nviz module
> (wxnviz.py). This has most of the same issues as nviz/vdigit
> (i.e. the GRASS libraries are being accessed directly from the
> GUI process, so a segfault or G_fatal_error() will kill the
> GUI), but not all of them.
>
> 4b. Alternatively, back-port the changes but not wxnviz.py
> itself. The result is equivalent to just building
> --without-python (i.e. the GUI will try to import the wxnviz
> module, fail, and warn that it's disabled), except that the
> user can drop in wxnviz.py from SVN if they want to try it out.

I've no big opinion on if wxVdigit and wxNviz using swig should
remain enabled in 6.4.0 for now, or not. Works for me.

I suggest to continue to stabilize ctypes in 6.5svn and see where
it ends up. If it works cleanly there, backport to the 6.4 branch
for 6.4.1. (or if it's a quick job, for 6.4.0, but then as Martin
suggests we'd need one last RC. If it means a better end product
I don't mind that much)

Some folks on the list (eg Kim) report working Python interfaces,
I'm not sure if that has anything to with SWIG or just lib/python/
and init.* magic. Anyway, we should announce intentions once we
have some so they can adapt as needed. :)

Python programming hooks are a big selling point these days (our
univ even offers a new course in geospatial programming using
python) so it would be a pity to remove that from the 6.4.0
release announcement, but not the end of the world if it will be
released mature in 6.4.1. Personally I'd say that the stuff
offered by lib/python/ and our solid collection of low-level C
modules let us claim support for python programmers with a
straight face, even if it isn't every single libgis C lib fn.

--

RC bugs according to the trac'er:
  https://trac.osgeo.org/grass/report/13

of those, weak-blockers IMO are-

seems solvable with slight effort AFAICT:
 #1006   r.terraflow fails to stat() stream file on Windows
 #994    v.buffer creating wrong buffer around polygon edges

I'm still meaning to spend a little time on this:
 #1051   wxgui: SEARCH_PATH corruption

and verify that g.proj's memory bug is /really/ fixed:
 https://trac.osgeo.org/grass/ticket/1032
 https://trac.osgeo.org/grass/ticket/827
 https://trac.osgeo.org/grass/ticket/820
 https://trac.osgeo.org/grass/ticket/555

v.in.gpsbabel on WinGrass + a GPX file as in #555 is a quick test:
> why does g.proj consistently fail in one particular script
> with exit code 5, "ERROR_ACCESS_DENIED", and yet works fine
> from the MSys command line and in other scripts?

could someone with MS-Windows please (re)test that?

--

Helena, fyi the FOSS4G 2010 Live osgeo demo DVD/usb stick will
ship with 6.4.0rc6; but MacOSX and MS Windows installers can be
updated at the last minute if newer versions become available.
The live version ships with the version UbuntuGIS has at build
time (which in turn is often derived from what Debian's Testing
has). We've got to prep, build, test, and send the master to
press a long time before the actual conference.


when it's ready,
Hamish