On Sep 14, 2008, at 3:02 PM, William Kyngesburye wrote:
On further inspection of the crashlog, I think it's the _grass6_wxnviz.so that it's choking on (makes sense). I see that libgrass_nviz is loaded in the binary images section, but not _grass6_wxnviz.so (_grass6_wxnviz.so and nviz2 are the only things that link libgrass_nviz). So it was in the middle of loading it and got libgrass_nviz loaded, then crash. From there I'm at a loss.
Here's an odd thought - permissions. When python source is loaded, python automatically attempts to compile bytecode as .pyc, alongside the source. I don't know what python does if it can't write these files due to lack of permissions.
When you sudo make install, you then don't have write permissions in the GRASS.app folders.
I've been running my GRASS tests in an uninstalled copy, with this procedure:
make
make bindist
the OSX bindist creates an installer package, and *also* leaves behind the assembled application in macosx/dist. Try this.
On Sep 14, 2008, at 1:25 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 3:02 PM, William Kyngesburye wrote:
On further inspection of the crashlog, I think it's the _grass6_wxnviz.so that it's choking on (makes sense). I see that libgrass_nviz is loaded in the binary images section, but not _grass6_wxnviz.so (_grass6_wxnviz.so and nviz2 are the only things that link libgrass_nviz). So it was in the middle of loading it and got libgrass_nviz loaded, then crash. From there I'm at a loss.
Here's an odd thought - permissions. When python source is loaded, python automatically attempts to compile bytecode as .pyc, alongside the source. I don't know what python does if it can't write these files due to lack of permissions.
When you sudo make install, you then don't have write permissions in the GRASS.app folders.
I've been running my GRASS tests in an uninstalled copy, with this procedure:
make
make bindist
the OSX bindist creates an installer package, and *also* leaves behind the assembled application in macosx/dist. Try this.
Tried it. Got a warning...
2008-09-14 13:34:55.327 packagemaker[52382:60b] relocate: (null) 0
Warning: Could not preserve resource forks because /Tools/SplitForks could not be found.
rm -f "GRASS-6.4.pkg/Contents/Resources/TokenDefinitions.plist"
On Sep 14, 2008, at 3:38 PM, Michael Barton wrote:
Tried it. Got a warning...
2008-09-14 13:34:55.327 packagemaker[52382:60b] relocate: (null) 0
Warning: Could not preserve resource forks because /Tools/SplitForks could not be found.
I should disable that option, but the warning is harmless.
Otherwise it seems to install.
But nviz doesn't work
I stand corrected. bindist did NOT work. It did not create a binary.
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
On Sep 14, 2008, at 1:54 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 3:38 PM, Michael Barton wrote:
Tried it. Got a warning...
2008-09-14 13:34:55.327 packagemaker[52382:60b] relocate: (null) 0
Warning: Could not preserve resource forks because /Tools/SplitForks could not be found.
I should disable that option, but the warning is harmless.
Otherwise it seems to install.
But nviz doesn't work
I stand corrected. bindist did NOT work. It did not create a binary.
So, no macosx/dist/GRASS-6.4.app?
I was looking in the target directory. Yes, it is there. I have a different result now (and in the target directory when I tried something). Nviz no longer crashes Python. It simply doesn't do anything. This is an improvement I guess.
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
On Sep 14, 2008, at 4:02 PM, Michael Barton wrote:
I was looking in the target directory. Yes, it is there. I have a different result now (and in the target directory when I tried something). Nviz no longer crashes Python. It simply doesn't do anything. This is an improvement I guess.
So, python doesn't handle lack of permissions for the .pyc generation very well... Though since the GUI runs, I wonder if that's just limited to .pyc for binary extensions?
When you say nviz doesn't do anything, do you get the nviz settings and exit tools? And behind the display window, maybe that "please wait" windoid?
On Sep 14, 2008, at 2:21 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 4:02 PM, Michael Barton wrote:
I was looking in the target directory. Yes, it is there. I have a different result now (and in the target directory when I tried something). Nviz no longer crashes Python. It simply doesn't do anything. This is an improvement I guess.
So, python doesn't handle lack of permissions for the .pyc generation very well... Though since the GUI runs, I wonder if that's just limited to .pyc for binary extensions?
Not quite. Normally, I let make install simply overwrite my existing grass app. That way, if I have any new files I'm working on, it just ignores them. I also don't have to make a new image for the dock. Once in awhile, there is a problem with this, however. I decided to rename my existing app and let make install create a totally new one (bindist did the same thing of course). In this new app, nviz no longer crashes Python, but simply does nothing.
When you say nviz doesn't do anything, do you get the nviz settings and exit tools? And behind the display window, maybe that "please wait" windoid?
None of that. I select the nviz setting in the display and absolutely nothing happens. I haven't checked yet, but I'm wondering about the problem I'm having with vdigit--i.e., not finding the *.so file. Perhaps there is a hard-coded path in vdigit.py and nviz.py that has them looking for files in the wrong place.
Maybe Martin can tell us. I'll look at the files too.
Nothing is ending up in the dist folder. It's empty. Same with vdigit. Empty.
Weird
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
On Sep 14, 2008, at 2:21 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 4:02 PM, Michael Barton wrote:
I was looking in the target directory. Yes, it is there. I have a different result now (and in the target directory when I tried something). Nviz no longer crashes Python. It simply doesn't do anything. This is an improvement I guess.
So, python doesn't handle lack of permissions for the .pyc generation very well... Though since the GUI runs, I wonder if that's just limited to .pyc for binary extensions?
When you say nviz doesn't do anything, do you get the nviz settings and exit tools? And behind the display window, maybe that "please wait" windoid?
I had accidentally set flags to 64 bit, which left nviz and vdigit not compiling. This is why nviz did not crash Python. Now that I'm compiling correctly again, nviz crashes everything again.
Sigh
I'm at a loss here. Your analysis suggests that it's the *.so file created by swig. So maybe this again is a place where we need to use distutils.
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
On Sep 14, 2008, at 2:21 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 4:02 PM, Michael Barton wrote:
I was looking in the target directory. Yes, it is there. I have a different result now (and in the target directory when I tried something). Nviz no longer crashes Python. It simply doesn't do anything. This is an improvement I guess.
So, python doesn't handle lack of permissions for the .pyc generation very well... Though since the GUI runs, I wonder if that's just limited to .pyc for binary extensions?
When you say nviz doesn't do anything, do you get the nviz settings and exit tools? And behind the display window, maybe that "please wait" windoid?
On Sep 14, 2008, at 5:20 PM, Michael Barton wrote:
Not quite. Normally, I let make install simply overwrite my existing grass app. That way, if I have any new files I'm working on, it just ignores them. I also don't have to make a new image for the dock. Once in awhile, there is a problem with this, however. I decided to rename my existing app and let make install create a totally new one (bindist did the same thing of course). In this new app, nviz no longer crashes Python, but simply does nothing.
OK, we can ignore bindist then, if a clean install doesn't crash.
None of that. I select the nviz setting in the display and absolutely nothing happens. I haven't checked yet, but I'm wondering about the problem I'm having with vdigit--i.e., not finding the *.so file. Perhaps there is a hard-coded path in vdigit.py and nviz.py that has them looking for files in the wrong place.
Maybe Martin can tell us. I'll look at the files too.
Probably not. I'm not having any .so-finding problems. More likely it's a problem in the sys.path.
One test to see if it's a compilation or runtime problem - here's my build from my Mini for MacPython and the latest wxpython:
It's definitely a compile issue. Your version works just as you describe it--AND vdigit works too.
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
On Sep 14, 2008, at 3:55 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 5:20 PM, Michael Barton wrote:
Not quite. Normally, I let make install simply overwrite my existing grass app. That way, if I have any new files I'm working on, it just ignores them. I also don't have to make a new image for the dock. Once in awhile, there is a problem with this, however. I decided to rename my existing app and let make install create a totally new one (bindist did the same thing of course). In this new app, nviz no longer crashes Python, but simply does nothing.
OK, we can ignore bindist then, if a clean install doesn't crash.
None of that. I select the nviz setting in the display and absolutely nothing happens. I haven't checked yet, but I'm wondering about the problem I'm having with vdigit--i.e., not finding the *.so file. Perhaps there is a hard-coded path in vdigit.py and nviz.py that has them looking for files in the wrong place.
Maybe Martin can tell us. I'll look at the files too.
Probably not. I'm not having any .so-finding problems. More likely it's a problem in the sys.path.
One test to see if it's a compilation or runtime problem - here's my build from my Mini for MacPython and the latest wxpython:
On Sep 14, 2008, at 6:26 PM, Michael Barton wrote:
It's definitely a compile issue. Your version works just as you describe it--AND vdigit works too.
hmmmmm
rrrrgggghhhh
The only other thing I can think of that I do a little different is maybe the OSX build target. I set the MACOSX_DEPLOYMENT_TARGET to 10.5 (or 10.4 for my Tiger builds). The default is 10.2 or 10.3 I think. There are some differences in compilation depending on this value, though I think it's mostly API differences not compiler behavior. Python code wants you to match what was used when it was compiled, which is 10.4 for Macpython (though I didn't have problems on my Mini build).
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
On Sep 14, 2008, at 5:38 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 6:26 PM, Michael Barton wrote:
It's definitely a compile issue. Your version works just as you describe it--AND vdigit works too.
hmmmmm
rrrrgggghhhh
The only other thing I can think of that I do a little different is maybe the OSX build target. I set the MACOSX_DEPLOYMENT_TARGET to 10.5 (or 10.4 for my Tiger builds). The default is 10.2 or 10.3 I think. There are some differences in compilation depending on this value, though I think it's mostly API differences not compiler behavior. Python code wants you to match what was used when it was compiled, which is 10.4 for Macpython (though I didn't have problems on my Mini build).
Try:
export MACOSX_DEPLOYMENT_TARGET=10.5
before configuring
Argh! That's not it either.
I'm getting more and more convinced that it is something to do with swig. I installed mine a long time ago. I know that swig stable hasn't changed in several years, but possibly I need to reinstall it.
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
This is my version of swig. Does it match what you have?
cmb-MBP-2:grass6_src cmbarton$ swig -version
SWIG Version 1.3.31
Compiled with g++ [i686-apple-darwin8.10.1]
Please see http://www.swig.org for reporting bugs and further information
Michael
On Sep 14, 2008, at 5:38 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 6:26 PM, Michael Barton wrote:
It's definitely a compile issue. Your version works just as you describe it--AND vdigit works too.
hmmmmm
rrrrgggghhhh
The only other thing I can think of that I do a little different is maybe the OSX build target. I set the MACOSX_DEPLOYMENT_TARGET to 10.5 (or 10.4 for my Tiger builds). The default is 10.2 or 10.3 I think. There are some differences in compilation depending on this value, though I think it's mostly API differences not compiler behavior. Python code wants you to match what was used when it was compiled, which is 10.4 for Macpython (though I didn't have problems on my Mini build).
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
On Sep 14, 2008, at 5:38 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 6:26 PM, Michael Barton wrote:
It's definitely a compile issue. Your version works just as you describe it--AND vdigit works too.
hmmmmm
rrrrgggghhhh
The only other thing I can think of that I do a little different is maybe the OSX build target. I set the MACOSX_DEPLOYMENT_TARGET to 10.5 (or 10.4 for my Tiger builds). The default is 10.2 or 10.3 I think. There are some differences in compilation depending on this value, though I think it's mostly API differences not compiler behavior. Python code wants you to match what was used when it was compiled, which is 10.4 for Macpython (though I didn't have problems on my Mini build).
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
...instead of the equivalent files in /Developer/SDKs/MacOSX10.5.sdk
Michael
On Sep 14, 2008, at 5:38 PM, William Kyngesburye wrote:
On Sep 14, 2008, at 6:26 PM, Michael Barton wrote:
It's definitely a compile issue. Your version works just as you describe it--AND vdigit works too.
hmmmmm
rrrrgggghhhh
The only other thing I can think of that I do a little different is maybe the OSX build target. I set the MACOSX_DEPLOYMENT_TARGET to 10.5 (or 10.4 for my Tiger builds). The default is 10.2 or 10.3 I think. There are some differences in compilation depending on this value, though I think it's mostly API differences not compiler behavior. Python code wants you to match what was used when it was compiled, which is 10.4 for Macpython (though I didn't have problems on my Mini build).
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
> Remind me again: why can't you use the system Python? Is wxPython not
> available for the system Python?
>
It's just a user preference. Some prefer to have the most recent
python and wxpython and other modules. The system python fits the
minimum requirements for GRASS (so far).
In that case, I really think that the first step is to get everything
working when only one version of Python is installed.
Anyone compiling from source when more than one version of a package
is installed assumes responsibility for ensuring that they don't end
up mixing versions.
>> In addition to the other macpython + wx I mentioned, I installed
>> PyOpenGl 3.0.0b5.
>
> This shouldn't be necessary to run OpenGL but maybe Martin is using
> it for something.
>
nviz wouldn't run without it.
Still some X11 libs in there, so it's probably something else outside
GRASS loading them (something in python or wx?). Dead end.
Though I do see that the wxnviz makefile unconditionally links the X11
libraries.
Fixed in SVN trunk. gui/wxpython/nviz shouldn't have any explicit
dependence upon window system libraries. That should all be hidden
behind wx. Even the OpenGL (GLX/WGL/AGL) context should be handled by
wx.GLCanvas.