[GRASS-dev] GRASS 7

Martin,

Hello, Michael,

I continued to try to debug your version of GRASS 7 that never worked for me (stopped jobs) and I found a solution.
When i start it in text mode and type

g.gui wxpython

It works.
I found that the problem lies in the script wxgui.py in line 81

mainframe = GMFrame(parent = None, id = wx.ID_ANY, workspace = self.workspaceFile)

This is a rather innocuous line. I wonder if it is having trouble finding the configuration file. Have you ever run GRASS before you installed and tried to run this? Maybe it is not creating the file and associated directories correctly. Do you get any permissions errors? Are you running this as an administrator (I assume yes, but it is worth checking)? Try adding the following before line 81:

print "workspace file = " + str(self.workspaceFile)

This should tell you what it thinks is the default workspace file

But the strangest thing is that if I start with the wxpython gui after purposely introducing an explicit error in the script wxgui.py, it works telling me the error as expected

<wxguierror2.png>

and if I corrected the script “on the fly” , and type g.gui wxpython

<wxguierror4.png>

the result is:
<wxguierror5.png>

Very, very strange thing…

the only thing not working is nviz → segmentation fault (the crash log report is very long…)

nviz does not work either with your version 6.5 (nothing appears)

I have not compiled 6.5 in several months. I recently recompiled 7 and 6.4.3 with William Kyngesburye’s latest frameworks (see readme file in the same folder as the binaries), but have not recompiled 6.5 with the newest frameworks.

<nviz65.png>

is it that this could be because I’m in version 10.6.7 and not 10.6.8 ?

No. A number my colleagues and students use my builds with different version of 10.6 and 10.7 without any problem.

Michael

···

no, it’s the standard Python but with a lot of modules because I’m a Python programmer.

Le 23 avril 2012 19:01, Michael Barton <Michael.Barton@asu.edu> a écrit :

Did you download and install python?

Michael

On Apr 23, 2012, at 10:31 AM, Martin Laloux wrote:


C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Corporation for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

No from the monitor, it is a problem of Python but why version 7 and not others ?
That’s why I thought it was in the Python script Grass70

<python.png>t

Le 23 avril 2012 17:46, Michael Barton <Michael.Barton@asu.edu> a écrit :

If that is the case, it is not something that GRASS is doing–at least directly. “stopped jobs” sounds like the printer, but that doesn’t make much sense here. Are you/were you somehow running some other kind of program? Or maybe a GRASS module did not get shut down and is running in the background. Have you opened the activity monitor to see if there is anything from GRASS running forever in the background?

Michael

On Apr 23, 2012, at 9:38 AM, Martin Laloux wrote:


C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &

University Corporation for Atmospheric Research

303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

yes, I tested everything even creating a new folder specific to GRASS 7 Locations

Martin

Le 23 avril 2012 04:45, Michael Barton <Michael.Barton@asu.edu> a écrit :

The frameworks was a wild guess. I wonder if there is a screwed up file somewhere. Have you tried starting GRASS in another mapset, including one of the demo location/mapsets?

If the demo stuff works, you can make a new location that matches your old one and move your stuff into it, and see what happens.

Michael

On Apr 22, 2012, at 2:03 PM, Martin Laloux wrote:


C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

ok, many thanks. All my frameworks are up to date.

Martin

Le 22 avril 2012 21:25, Michael Barton <Michael.Barton@asu.edu> a écrit :

I don’t think it is the .gislock. That is set whenever you start up. The stopped jobs is really puzzling. Did you update your frameworks? You might write to William Kyngesburye about it.

Michael

On Apr 22, 2012, at 12:55 PM, Martin Laloux wrote:


C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Many thanks,
First of all, i use GRASS on Mac since version 5.x of Lorenzo Moretti . I never had a problem with versions of Lorenzo, of William or yours versions 6.x.

the problem is specific to version 7.

  • when it start, i can create a new location and a new mapset but when I try to use them for the first time or after the dialog to override the lock, i get this error message in the shell:
    GRASS 7.0.svn (init_portail_sig):~ > exit

“[1]+ Stopped ‘/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/grass.sh’
logout
There are stopped jobs.”

  • The first window of GRASS appears and it freezes and i need to kill the shell.
  • looking in the folder of the mapset during this operation, I see a a gislock file that appears after selecting the location and mapset and when this first window of GRASS appears.
  • What are stopped jobs ? the gislock file ?
  • I reviewed the scripts grass.sh and GRASS70 but I do not see when and why this gislock file is created

But this is not urgent, do not worry and good traveling

Many thanks

Martin

Le 22 avril 2012 19:14, Michael Barton <Michael.Barton@asu.edu> a écrit :

Martin,

I’ve been traveling and don’t understand all of your question. Can you explain it more?

If you run GRASS on a computer and kill it without shutting it down properly, you can get a lock on a mapset. But you also get a dialog in GRASS 7 asking if you want to override the lock. This also prevents more than one person from accessing and changing the same mapset at the same time on a server.

Michael

On Apr 22, 2012, at 1:18 AM, <martin.laloux@gmail.com> wrote:

Hello,
Sorry to bother you personally but nobody answers to my problem with your version of GRASS 7 and the the locking file . gislock that is automatically created in the selected mapset when the first window appears.
Have-you any idea ?
The problem does not come from the grass.sh file but from the Python script Grass70
I reviewed the script and all its references to gislok but I do not understand why, where and when the gislock file is created.
I have no problem with your other versions (6.4.3 and 6.5)

Thank you very much for your attention
Dr. Martin Laloux


C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu