[GRASS-dev] GRASS GIS 7 tech-preview release preparations

GRASS GIS GRASS GIS developer
1

It’s really a bite that I cannot a working Mac version of GRASS 7 without some post-compilation hacking. While I can create a useable Mac binary with some effort, it could be a problem for others who wish to do so.

Glynn suggests that this is a ctypes issue and Anna thinks it may be something that has consequences for numerous modules (I’m inclined to agree). But so far, we’re stuck.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 13, 2013, at 10:46 AM, grass-dev-request@lists.osgeo.org wrote:

From: Moritz Lennert <mlennert@club.worldonline.be>

Subject: Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

Date: July 13, 2013 3:16:12 AM MST

To: Markus Metz <markus.metz.giswork@gmail.com>

Cc: grass-dev <grass-dev@lists.osgeo.org>

On Fri, July 12, 2013 22:04, Markus Metz wrote:

On Fri, Jul 12, 2013 at 3:21 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Main issues I see for grass7 currently to get it preview-release ready:

[…]

  • LFS handling in Windows

https://trac.osgeo.org/grass/ticket/1131 (not sure I understand where we
are
at with this)

Global LFS is enabled by default and working on all officially
supported platforms, plus *BSD and some UNIX systems.

That means we can close this ticket ?

Moritz

2

On Sun, Jul 14, 2013 at 1:32 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

It's really a bite that I cannot a working Mac version of GRASS 7 without
some post-compilation hacking. While I can create a useable Mac binary with
some effort, it could be a problem for others who wish to do so.

Glynn suggests that this is a ctypes issue and Anna thinks it may be
something that has consequences for numerous modules (I'm inclined to
agree). But so far, we're stuck.

Michael,

please send the ticket number for this... (don't find it)

Markus

3

On Jul 13, 2013, at 7:32 PM, Michael Barton wrote:

It's really a bite that I cannot a working Mac version of GRASS 7 without some post-compilation hacking. While I can create a useable Mac binary with some effort, it could be a problem for others who wish to do so.

I was just trying to compile grass7 on a new airbook that I am taking to Prague, and I can confirm
hat there is a problem.

Also, related to the tech preview, the current wingrass6.4.3svn and wingrass7 binaries from Martin crash on networked windows8 in our lab and for my colleague (the startup does not open) but run fine on the windows side of my student's Mac.
I did not have time to look into any of this as we are leaving for Europe on Monday (I guess that is today).
Hopefully we will be able to resolve at least some of these issues in Prague,

Helena

Glynn suggests that this is a ctypes issue and Anna thinks it may be something that has consequences for numerous modules (I'm inclined to agree). But so far, we're stuck.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 13, 2013, at 10:46 AM, grass-dev-request@lists.osgeo.org wrote:

From: Moritz Lennert <mlennert@club.worldonline.be>
Subject: Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations
Date: July 13, 2013 3:16:12 AM MST
To: Markus Metz <markus.metz.giswork@gmail.com>
Cc: grass-dev <grass-dev@lists.osgeo.org>

On Fri, July 12, 2013 22:04, Markus Metz wrote:

On Fri, Jul 12, 2013 at 3:21 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Main issues I see for grass7 currently to get it preview-release ready:

[...]

- LFS handling in Windows

https://trac.osgeo.org/grass/ticket/1131 (not sure I understand where we
are
at with this)

Global LFS is enabled by default and working on all officially
supported platforms, plus *BSD and some UNIX systems.

That means we can close this ticket ?

Moritz

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

4

I will make one as soon as I get a chance. Crazy day so far.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 14, 2013, at 2:05 AM, Markus Neteler <neteler@osgeo.org>
wrote:

On Sun, Jul 14, 2013 at 1:32 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

It's really a bite that I cannot a working Mac version of GRASS 7 without
some post-compilation hacking. While I can create a useable Mac binary with
some effort, it could be a problem for others who wish to do so.

Glynn suggests that this is a ctypes issue and Anna thinks it may be
something that has consequences for numerous modules (I'm inclined to
agree). But so far, we're stuck.

Michael,

please send the ticket number for this... (don't find it)

Markus

5

I just created a ticket for this: #2034 (GUI crashes on launch for newly compiled binary for Mac OS X) – GRASS GIS

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Jul 14, 2013, at 2:05 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Sun, Jul 14, 2013 at 1:32 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

It's really a bite that I cannot a working Mac version of GRASS 7 without
some post-compilation hacking. While I can create a useable Mac binary with
some effort, it could be a problem for others who wish to do so.

Glynn suggests that this is a ctypes issue and Anna thinks it may be
something that has consequences for numerous modules (I'm inclined to
agree). But so far, we're stuck.

Michael,

please send the ticket number for this... (don't find it)

Markus

6

Hi devs,
we should consider to get the preview (!) release out for the FOSS4G
conference in Nottingham in September.

The wxGUI refactoring done by Anna and Vaclav (sponsored by Fondazione
Edmund Mach) is also in SVN. We should identify the preview blockers
now.

Markus

7

On 26/08/13 08:56, Markus Neteler wrote:

Hi devs,
we should consider to get the preview (!) release out for the FOSS4G
conference in Nottingham in September.

+1

I would love to use it for teaching also, but need a +/- official version to get it accepted from our computer room managers.

The wxGUI refactoring done by Anna and Vaclav (sponsored by Fondazione
Edmund Mach) is also in SVN. We should identify the preview blockers
now.

https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&priority=critical&priority=blocker&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=component&milestone=7.0.0

Main blocker IMHO is still the Python and script launching issues (#580 and #1871, which are related). We did advance a bit, mainly looking at the possible solution of using the Python Launcher [1], but then I left on vacation and I don't think things have advanced since then. I believe that solution is worth some more detailed study and testing.

For other two blockers:

- One has a patch applied that needs testing (#1941, Japanese locale)
- The other (#2017, compilation of osgf library) cannot be reproduced by those that have tried. Can others try to reproduce ?

Concerning the critical ones:

- Two concern Windows code page issues (#995, #1288) for which I don't really know what a possible solution would be (is it possible to create a launcher for GRASS in Python, without using .bat at all ?)

- #1778 concerning modules not launcing GUIs is linked to there being not one single required option in these modules. The question raised was whether there is a possibility to make at a choice of at least one out of a group of options required.

- #1662 has not been confirmed by anyone. Maybe Sören could provide the test data.

- #1742 (menus hidden in non-english languages): It seems that the only solution besides complete redesign has been to simply make the default width of the layer manager larger. If everyone agrees this seems like a simple fix.

- #1844 seems to me a mix of different issues, but at least part of it seems to be related to the python script issues. I just tried with sqlite and it also hung, so this might actually be quite serious.

- #2034 concerns issues on MacOSX apparently linked to the choice of Python and wxPython versions. Cannot comment on that.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html

8

Moritz Lennert wrote:

- Two concern Windows code page issues (#995, #1288) for which I don't
really know what a possible solution would be (is it possible to create
a launcher for GRASS in Python, without using .bat at all ?)

If the Python interpreter is registered, you should just be able to
execute the grass70.py script.

Failing that, you can create a shortcut which executes a specific
python.exe (or pythonw.exe) with the path to the grass.py script as an
argument.

Failing that, a .bat/.cmd file should work fine, so long as it just
executes grass70.py via Python, and doesn't try to do anything else.

The short version is: batch files can't handle non-ASCII characters.
The longer version is that each locale has two distinct codepages, and
cmd.exe itself tends to assume that everything uses the locale's OEM
codepage while most programs use the locale's ANSI codepage. If you
use any character which isn't the same in both, you lose.

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

9

On Mon, Aug 26, 2013 at 10:24 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

- #1742 (menus hidden in non-english languages): It seems that the only
solution besides complete redesign has been to simply make the default
width of the layer manager larger. If everyone agrees this seems like a
simple fix.

Hi, I forgot to update [1] the ticked after the community sprint in Prague
(now updated). The new conception could be following:
* Main menu bar only for the main items (e.g. `g.region`) or even only for
settings and GUI window control (adding layers, opening windows).
* For finding and running a module, user should use the module tree in
the search modules tab. Here we can have a long list of basic groups
(toolboxes) such as Raster, Imagery etc.

In other words, in order to solve this issue, I vote for removal of
Database, Imagery and Volumes. According to #1742 [2] we need to remove at
least two items to get the German menu right.

Vaclav

[1] http://trac.osgeo.org/grass/ticket/1742#comment:13
[2]
http://trac.osgeo.org/grass/attachment/ticket/1742/grass_layer_manager_width.png

10

Vaclav wrote:

* For finding and running a module, user should use the module
tree in the search modules tab.

Hi,

I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt "search to run" as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore & learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know.

We are spatial creatures, so a spatial model for menu layout where we can use our spatial & muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c)

regards,
Hamish

11

Hi, moving the menu discussion to the ticked:

http://trac.osgeo.org/grass/ticket/1742#comment:16

···

On Tue, Aug 27, 2013 at 6:47 AM, Hamish <hamish_b@yahoo.com> wrote:

Vaclav wrote:

  • For finding and running a module, user should use the module
    tree in the search modules tab.

Hi,

I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt “search to run” as the primary instead of augmenting method, I fear that way is not very discoverable – at least I’d like to avoid the situation where a new user needs to know the name of what they’re looking for before they can find it, which isn’t so good to explore & learn about new modules you don’t know exist yet. Especially for a software so big as ours which takes years to fully know.

We are spatial creatures, so a spatial model for menu layout where we can use our spatial & muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there’s space for that. (2c)

regards,
Hamish

12

So, ok, I committed the fix, but I’m not comfortable with it. Please see the ticked and test the change.

http://trac.osgeo.org/grass/ticket/1742#comment:17

···

On Tue, Aug 27, 2013 at 10:48 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi, moving the menu discussion to the ticked:

http://trac.osgeo.org/grass/ticket/1742#comment:16

On Tue, Aug 27, 2013 at 6:47 AM, Hamish <hamish_b@yahoo.com> wrote:

Vaclav wrote:

  • For finding and running a module, user should use the module
    tree in the search modules tab.

Hi,

I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt “search to run” as the primary instead of augmenting method, I fear that way is not very discoverable – at least I’d like to avoid the situation where a new user needs to know the name of what they’re looking for before they can find it, which isn’t so good to explore & learn about new modules you don’t know exist yet. Especially for a software so big as ours which takes years to fully know.

We are spatial creatures, so a spatial model for menu layout where we can use our spatial & muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there’s space for that. (2c)

regards,
Hamish

13

On 26/08/13 23:24, Glynn Clements wrote:

Moritz Lennert wrote:

- Two concern Windows code page issues (#995, #1288) for which I don't
really know what a possible solution would be (is it possible to create
a launcher for GRASS in Python, without using .bat at all ?)

If the Python interpreter is registered, you should just be able to
execute the grass70.py script.

Do I understand correctly that for this to work the grass70.py script would need to be altered to

- set GISBASE
- set the environment variables as defined in mswindows/env.bat
- set the CWD to %USERPROFILE%

?

Failing that, you can create a shortcut which executes a specific
python.exe (or pythonw.exe) with the path to the grass.py script as an
argument.

Failing that, a .bat/.cmd file should work fine, so long as it just
executes grass70.py via Python, and doesn't try to do anything else.

idem

Moritz

14

Moritz Lennert wrote:

On 26/08/13 23:24, Glynn Clements wrote:
>
> Moritz Lennert wrote:
>
>> - Two concern Windows code page issues (#995, #1288) for which I don't
>> really know what a possible solution would be (is it possible to create
>> a launcher for GRASS in Python, without using .bat at all ?)
>
> If the Python interpreter is registered, you should just be able to
> execute the grass70.py script.

Do I understand correctly that for this to work the grass70.py script
would need to be altered to

- set GISBASE

It already does that if GISBASE isn't set.

lib/init/grass.py has a hard-coded fallback to @GISBASE@, which is
replaced with the actual value by the Makefile running it through sed.
The installer would need to do something similar to substitute the
install path (or the grass.py script could read it from the registry
on Windows).

- set the environment variables as defined in mswindows/env.bat

It already sets most of them if they're not already set.

- set the CWD to %USERPROFILE%

That's optional. GRASS doesn't care what the current directory is.

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