[GRASS-dev] 6.4.0 blocker bugs

GRASS GRASS developer
21

Markus Neteler wrote:

Hi again,

Markus Neteler:

Hi,

proposal for action plan:

As before I suggest:

- release 6.4.0 now as-is
- increment SVN release branch to 6.4.1
- start immediately to backport relevant patches into 6.4.1
- winGRASS binaries will become available through josef
- Linux snapshots as well
- Get out first 6.4.1RC1 by August
- Have final 6.4.1 ready in September for FOSS4G 2010

It's a bit late, but no blocker bugs are left apart from writing the
release announcement. That means it's possible, as long as nobody is
slowing it down.

+1

Markus M

22

Markus Metz wrote:

It's a bit late, but no blocker bugs are left apart from
writing the release announcement.

well it's written, as is the blurb. look in grass-web/
announces/ for drafts. please proof read, comment, etc.
(see earlier post about that from last weeks, ticket)

That means it's possible, as long as nobody is slowing it
down.

two changes I will try to make tonight: backport Paul's
g.proj linebreak fix to 6.4 and edit the menu label for
v.in.mapgen (it's Matlab compatible ascii, not Matlab
format per se). I do not plan on backporting r.in.wms
and r.tileset patches as there have been reports of
m.proj/cs2cs problems from them.

and one last read through of forgotten bug reports.. :slight_smile:

regards,
Hamish
(traveling with limited internet access)

23

On Mon, Aug 9, 2010 at 4:43 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus Metz wrote:

It's a bit late, but no blocker bugs are left apart from
writing the release announcement.

well it's written, as is the blurb. look in grass-web/
announces/ for drafts. please proof read, comment, etc.
(see earlier post about that from last weeks, ticket)

The current state is here:
http://svn.osgeo.org/grass/grass-web/trunk/announces/announce_grass640.html

That means it's possible, as long as nobody is slowing it

down.

two changes I will try to make tonight: backport Paul's
g.proj linebreak fix to 6.4 and edit the menu label for
v.in.mapgen (it's Matlab compatible ascii, not Matlab
format per se). I do not plan on backporting r.in.wms
and r.tileset patches as there have been reports of
m.proj/cs2cs problems from them.

and one last read through of forgotten bug reports.. :slight_smile:

great, we are finally close :slight_smile:

We need to notify the binary packagers unless they don't read
here to get binaries out at the same time (ideally we put out the
source code ball without announcement, package and publish
as much as possible at the same moment).

Markus

24

A request for quickfix:
I'm requesting permission (as we are so close to release) to backport
r43023 to 6.4. It fixes r.mask failure to remove MASK if GISDBASE
contains spaces in path. [1]

As I'm leaving town right now, in case of OK, somebody, please, do backporting.

Thanks.
Maris.

1. http://trac.osgeo.org/grass/changeset/43023

2010/8/9, Markus Neteler <neteler@osgeo.org>:

On Mon, Aug 9, 2010 at 4:43 AM, Hamish <hamish_b@yahoo.com> wrote:

Markus Metz wrote:

It's a bit late, but no blocker bugs are left apart from
writing the release announcement.

well it's written, as is the blurb. look in grass-web/
announces/ for drafts. please proof read, comment, etc.
(see earlier post about that from last weeks, ticket)

The current state is here:
http://svn.osgeo.org/grass/grass-web/trunk/announces/announce_grass640.html

That means it's possible, as long as nobody is slowing it

down.

two changes I will try to make tonight: backport Paul's
g.proj linebreak fix to 6.4 and edit the menu label for
v.in.mapgen (it's Matlab compatible ascii, not Matlab
format per se). I do not plan on backporting r.in.wms
and r.tileset patches as there have been reports of
m.proj/cs2cs problems from them.

and one last read through of forgotten bug reports.. :slight_smile:

great, we are finally close :slight_smile:

We need to notify the binary packagers unless they don't read
here to get binaries out at the same time (ideally we put out the
source code ball without announcement, package and publish
as much as possible at the same moment).

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

25

Hi,

2010/8/9 Maris Nartiss <maris.gis@gmail.com>:

A request for quickfix:
I'm requesting permission (as we are so close to release) to backport
r43023 to 6.4. It fixes r.mask failure to remove MASK if GISDBASE
contains spaces in path. [1]

As I'm leaving town right now, in case of OK, somebody, please, do backporting.

done in r43025.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

26

Markus Neteler wrote:

> two changes I will try to make tonight: backport Paul's
> g.proj linebreak fix to 6.4 and edit the menu label for
> v.in.mapgen (it's Matlab compatible ascii, not Matlab
> format per se). I do not plan on backporting r.in.wms
> and r.tileset patches as there have been reports of
> m.proj/cs2cs problems from them.
>
> and one last read through of forgotten bug reports.. :slight_smile:

great, we are finally close :slight_smile:

I'd like to just make one final request to remove the swig directory
before release. Otherwise, people will try and use it.

--
Glynn Clements <glynn@gclements.plus.com>

27

Hi,

2010/8/10 Glynn Clements <glynn@gclements.plus.com>:

I'd like to just make one final request to remove the swig directory
before release. Otherwise, people will try and use it.

I would vote for it. The wxGUI vdigit and nviz has been disabled,
there is nothing which uses swig. We could include ctypes in >= 6.4.1
or in 6.5 and reenable wxGUI nviz and rewritten vdigit afterwards.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

28

Martin Landa wrote:

> I'd like to just make one final request to remove the swig directory
> before release. Otherwise, people will try and use it.

I would vote for it. The wxGUI vdigit and nviz has been disabled,
there is nothing which uses swig.

Even if they were enabled, vdigit and (the SWIG-based version of) nviz
don't use anything from the swig directory.

--
Glynn Clements <glynn@gclements.plus.com>

29

On Tue, Aug 10, 2010 at 6:31 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Martin Landa wrote:

> I'd like to just make one final request to remove the swig directory
> before release. Otherwise, people will try and use it.

Good point.

I would vote for it. The wxGUI vdigit and nviz has been disabled,
there is nothing which uses swig.

Even if they were enabled, vdigit and (the SWIG-based version of) nviz
don't use anything from the swig directory.

I see that the ctypes backport consists of two commits:
http://trac.osgeo.org/grass/changeset/42916
http://trac.osgeo.org/grass/changeset/43015

No patch problems with
patch -p4 < changeset_r42916.diff

Nor compilation issues after:
cd lib/python/ctypes/
chmod a+x ctypesgen.py

Question: side-effects to be expected?

Markus

PS: perhaps we should move
swig/python/examples
elsewhere.

30

Hi,

2010/8/11 Markus Neteler <neteler@osgeo.org>:

Nor compilation issues after:
cd lib/python/ctypes/
chmod a+x ctypesgen.py

Question: side-effects to be expected?

there is still problem to ctypes on MS Windows [1].

Martin

[1] http://trac.osgeo.org/grass/ticket/1125

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

31

On Wed, Aug 11, 2010 at 10:56 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2010/8/11 Markus Neteler <neteler@osgeo.org>:

Nor compilation issues after:
cd lib/python/ctypes/
chmod a+x ctypesgen.py

Question: side-effects to be expected?

there is still problem to ctypes on MS Windows [1].

An option might be to skip ctypes compilation on Windows for
now in 6.4.0 (Makefile condition).

Markus

Martin

[1] http://trac.osgeo.org/grass/ticket/1125

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

32

Glynn wrote:
I'd like to just make one final request to remove the swig
directory before release. Otherwise, people will try
and use it.

(& they already are trying)

I have no problem with this, but am not really able to test
anything well right now as traveling either. If doing it I think
we'd need to tag one last RC; perhaps no need to formally announce
that beyond the grass-* mailing lists. I don't think to just
rename it as the stable release if the tests are all good, as
gdal does, but tagging rev+1 after modifying the VERSION file.
(hope that makes sense, I mean re-tag, not renaming the tarball
file)

if removing the full swig/ dir, are there ctype options for
perl/java/.net/etc users? if not, were they doomed to fail with
swig anyway?

MarkusN:

PS: perhaps we should move
swig/python/examples
elsewhere.

yes, I thought the same thing. I'd like to see the examples/
all ported to ctypes. (I still need to learn..)

cheers,
Hamish

33

Hamish wrote:

if removing the full swig/ dir, are there ctype options for
perl/java/.net/etc users?

The ctypes wrappers haven't been back-ported to 6.4 yet.

However, it should be much easier to add ctypes wrappers to an
installed version than to do likewise for SWIG wrappers.

if not, were they doomed to fail with swig anyway?

Pretty much. Even the relatively few attempts to use the SWIG wrappers
were continually running into issues with functions needing or
returning internal SWIG objects which we couldn't figure out how to
create or use.

--
Glynn Clements <glynn@gclements.plus.com>

34

Markus Neteler wrote:

>> > I'd like to just make one final request to remove the swig directory
>> > before release. Otherwise, people will try and use it.

Good point.

>> I would vote for it. The wxGUI vdigit and nviz has been disabled,
>> there is nothing which uses swig.
>
> Even if they were enabled, vdigit and (the SWIG-based version of) nviz
> don't use anything from the swig directory.

I see that the ctypes backport consists of two commits:
http://trac.osgeo.org/grass/changeset/42916
http://trac.osgeo.org/grass/changeset/43015

Please bear in mind that removing the SWIG wrappers and adding the
ctypes wrappers are entirely orthogonal. As nothing (except for the
new nviz module, which isn't in 6.4) depends upon either, removing the
swig directory doesn't imply backporting the ctypes wrappers.

1. The swig directory uses SWIG to generate Python binding for the
GRASS libraries. Nothing in GRASS uses these; the intent was to allow
add-ons to be written in Python.

2. The lib/python/ctypes directory also generates Python bindings for
the GRASS libraries. Whereas SWIG-based bindings consist of a binary
module plus a Python module, ctypes-based bindings consist only of
Python modules which use the ctypes module in the Python standard
library (in Python 2.5 and later; ctypes was available as an add-on
module for 2.4). Nothing in 6.4 uses this, and the intent is to allow
add-ons to be written in Python.

3. The wx GUI's vdigit and nviz modules consist of a mix of C++ and
Python, and use SWIG to generate the Python bindings for their C++
component. They do not use the bindings for the GRASS libraries from
the swig directory. They do require the swig program to be installed,
and GRASS to be configured --with-python.

4. The new nviz module in 6.5 and 7.0 (but not 6.4) no longer has a
C++ component. Instead, it's written entirely in Python, using the
ctypes-based bindings for the nviz and ogsf libraries. Nothing else in
GRASS (and nothing at all in 6.4) uses the ctypes bindings.

IOW: the swig directory can be removed without affecting any other
part of GRASS, including the vdigit/nviz modules. The configure checks
relating to SWIG (i.e. --with-python) and the requirement for the swig
program relate to the vdigit and (6.4) nviz modules. lib/python/ctypes
is only required for the ctypes-based nviz module in 6.4/7.0, or if we
want to offer the ctypes-based bindings for use by add-ons.

So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1,
or even make a separate package which works with 6.4.0 (so long as we
don't change the API, we would just need to ensure that grass.py
contains the correct definition for GIS_H_VERSION so that G_gisinit()
works).

But if we release 6.4.0 with the swig directory in place, we'll still
be getting questions about it (that we probably won't be able to
answer) in ten years time.

--
Glynn Clements <glynn@gclements.plus.com>

35

On Wed, Aug 11, 2010 at 9:10 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

[... thanks for the long summary which explains it perfectly...]

IOW: the swig directory can be removed without affecting any other
part of GRASS, including the vdigit/nviz modules. The configure checks
relating to SWIG (i.e. --with-python) and the requirement for the swig
program relate to the vdigit and (6.4) nviz modules. lib/python/ctypes
is only required for the ctypes-based nviz module in 6.4/7.0, or if we
want to offer the ctypes-based bindings for use by add-ons.

So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1,
or even make a separate package which works with 6.4.0 (so long as we
don't change the API, we would just need to ensure that grass.py
contains the correct definition for GIS_H_VERSION so that G_gisinit()
works).

But if we release 6.4.0 with the swig directory in place, we'll still
be getting questions about it (that we probably won't be able to
answer) in ten years time.

Given Glynn's suggestion I redraw my suggestion to add ctypes now.
We'll do that for 6.4.1.

Can anyone remove swig/ in the 6.4-release branch? I am also on the
road these days with sporadic internet access. Then we can release
6.4.0 next week.

thanks
Markus

36

Hi,

2010/8/12 Markus Neteler <neteler@osgeo.org>:

So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1,
or even make a separate package which works with 6.4.0 (so long as we
don't change the API, we would just need to ensure that grass.py
contains the correct definition for GIS_H_VERSION so that G_gisinit()
works).

on the other hand what can cost to add ctypes now. One RC? That's
acceptable. I would suggest to add ctypes now, publish RC7 and in
one/two weeks final (before FOSS4G 2010). Stable will be released with
ctypes and without swig.

But if we release 6.4.0 with the swig directory in place, we'll still
be getting questions about it (that we probably won't be able to
answer) in ten years time.

Given Glynn's suggestion I redraw my suggestion to add ctypes now.
We'll do that for 6.4.1.

Can anyone remove swig/ in the 6.4-release branch? I am also on the
road these days with sporadic internet access. Then we can release
6.4.0 next week.

Done in r43095.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

37

I am updating the course material and just in case GRASS64 becomes available next week
I would like to verify what GUI will the users see when they install GRASS64 from the binary
and open it for the first time and get past the start-up page:

- on MSWindows wxGUI opens
- on Mac and linux TclTk opens

If that is true I need to add an extra step on how to change the default GUI
(which is simple to do through TclTk GUI, it just adds to the complexity right at the
beginning when one tries to make everything look as simple as possible).

thank you,

Helena

38

On Mon, Aug 16, 2010 at 2:49 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:

I am updating the course material and just in case GRASS64 becomes available next week
I would like to verify what GUI will the users see when they install GRASS64 from the binary
and open it for the first time and get past the start-up page:

- on MSWindows wxGUI opens
- on Mac and linux TclTk opens

If that is true I need to add an extra step on how to change the default GUI
(which is simple to do through TclTk GUI, it just adds to the complexity right at the
beginning when one tries to make everything look as simple as possible).

I fully agree that it is unfortunate to still open the TclTK GUI on Mac
and Linux. The only solution is to make 6.4.1 asap after the 6.4.0
release and not wait
another year.

Markus

39

Hi,

2010/8/16 Markus Neteler <neteler@osgeo.org>:

On Mon, Aug 16, 2010 at 2:49 AM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:

I am updating the course material and just in case GRASS64 becomes available next week
I would like to verify what GUI will the users see when they install GRASS64 from the binary
and open it for the first time and get past the start-up page:

- on MSWindows wxGUI opens
- on Mac and linux TclTk opens

If that is true I need to add an extra step on how to change the default GUI
(which is simple to do through TclTk GUI, it just adds to the complexity right at the
beginning when one tries to make everything look as simple as possible).

I fully agree that it is unfortunate to still open the TclTK GUI on Mac
and Linux. The only solution is to make 6.4.1 asap after the 6.4.0
release and not wait
another year.

or as I suggested to publish RC7 (ctypes added, swig removed, default
wxGUI). Wait one/two weeks and release 6.4.0.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

40

Hi,

On Fri, Aug 13, 2010 at 6:03 PM, Martin Landa <landa.martin@gmail.com> wrote:

2010/8/12 Markus Neteler <neteler@osgeo.org>:
>> So, there's no need to delay 6.4.0 for ctypes. We can add it in 6.4.1,
>> or even make a separate package which works with 6.4.0 (so long as we
>> don't change the API, we would just need to ensure that grass.py
>> contains the correct definition for GIS_H_VERSION so that G_gisinit()
>> works).

on the other hand what can cost to add ctypes now. One RC? That's
acceptable. I would suggest to add ctypes now, publish RC7 and in
one/two weeks final (before FOSS4G 2010). Stable will be released with
ctypes and without swig.

@developers: please give your opinion on Martin's suggestion.

thanks
Markus