Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4
The install fails? Or it fails to run? The install doesn't care anything about what version of X11 you have. Running is already conditionalized for the X11 version. What errors are you getting? On Nov 17, 2007, at 12:55 AM, Michael Barton wrote: William, I just tried to install GRASS from the cvs. It fails on my OS X 10.4 machine because it is hard coded to look for x11r7 (with OS X 10.5) instead of x11r6. Can this be conditionalized to deal with 10.4 AND 10.5? Michael - William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4
On Nov 17, 2007, at 9:41 AM, Michael Barton wrote: Here is the error. /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/gis.m: line 17: /Applications/Grass/GRASS-6.3.app/Contents/MacOS/bin/wish: No such file or directory /Applications/Grass/GRASS-6.3.app/Contents/MacOS/scripts/gis.m: line 17: exec: /Applications/Grass/GRASS-6.3.app/Contents/MacOS/bin/wish: cannot execute: No such file or directory When I try to run wish, this is what I get wish dyld: Library not loaded: /usr/local/X11R7/lib/libX11.6.dylib Referenced from: /usr/local/lib/libtk8.4.dylib Reason: image not found Trace/BPT trap Oh, that's bizarre. Nothing to do with Leopard, though. Things to check: - Is there a wish, or any tcltk libraries, in the newly-installed GRASS app package? - if not, were there any errors in the make (not install) stage? try make inside the macosx folder. - where is your tcltk installed (from those many months ago)? /usr/ local/tcltk, as in my instructions? And is this what you configured GRASS with? (just checking) - is there really a /usr/local/bin/wish and /usr/local/lib/libtcl and libtk? Sounds like you may have installed some software that installed another copy of tcltk (which is broken because it's looking for /usr/local/X11R7). ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4
Doh! I got a little carried away with a find-n-replace and messed up a sed replacement for the grass.sh script. Fixed in cvs. After recompile and install, you can delete that symlink for 'wish'. On Nov 17, 2007, at 11:23 AM, Michael Barton wrote: OK. Figured it out. But it needs to be fixed somewhere in the make systems I think. In both my previous compile (of a few weeks ago) and the one I tried last night and today, a copy of wish8.4 is put into the $GISBASE/bin folder. In my older version (which worked fine), apparently this is launched when the GUI system is launched. In the new version, it tries to launch a symlink named "wish" instead of the embedded wish8.4. There is no such symlink and it tries to run another symlink on my system that is NOT linked to the correct version of TclTk (I'll fix that locally, but it should not affect GRASS). When I created a symlink named "wish" for the embedded wish8.4 all works well. So what has changed? Something is calling wish instead of wish8.4, but I don't know what. Michael - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4
I'm curious: are you using a bindist-created installer package? or building from source on each Mac? I haven't heard any feedback from anyone on the bindist feature (it's what I use it to create my binaries for download). On Nov 17, 2007, at 12:10 PM, Michael Barton wrote: Great. Thanks. I'm visting Stanford to give a talk. I just installed GRASS on 2 iMacs and 2 laptops in the Archaeology Center spatial analysis lab. Trying to get it on a colleague's PC laptop. This is trickier. Michael - William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4
On Nov 17, 2007, at 12:54 PM, Agustin Diez Castillo wrote: I use bindist in several Macs with some success, Some success - were there problems then? actually one of them is working in Leopard Do you mean: generating the installer on Tiger and installing on Leopard? That should work. The only thing to watch out for is that on Leopard you should NOT set DISPLAY - the Terminal startup magic takes care of this, and setting it yourself will break X displays and the GUI. but I need to write the command gis.m on the terminal. So, the GUI is not starting automatically? I'm curious: are you using a bindist-created installer package? or building from source on each Mac? I haven't heard any feedback from anyone on the bindist feature (it's what I use it to create my binaries for download). - William Kyngesburye http://www.kyngchaos.com/ "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?" - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS cvs for Mac compilation fails for OS X 10.4
On Nov 18, 2007, at 11:52 AM, Agustin Diez Castillo wrote: but I need to write the command gis.m on the terminal. So, the GUI is not starting automatically? Yes, the GUI is not starting automatically. Hm, if it doesn't start automatically, but will start manually, then the DISPLAY setting is probably OK - it wouldn't even start manually if this was wrong. It may simply be defaulting to 'text' and you need to change your GRASS_GUI setting: g.gisenv set="GRASS_GUI=tcltk" - William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Can we release 6.2.3?
On Nov 20, 2007, at 6:49 AM, Markus Neteler wrote: May I suggest using `sed' here instead? Like: MAJOR=`sed -q -e 1p include/VERSION` MINOR=`sed -q -e 2p include/VERSION` RELEASE=`sed -q -e 3p include/VERSION` Works only with a fix for me (-q not portable?): MAJOR=`sed --q -e 1p include/VERSION` MINOR=`sed --q -e 2p include/VERSION` RELEASE=`sed --q -e 3p include/VERSION` echo $MAJOR.$MINOR.$RELEASE Looks like -q/--q is GNU sed-only. I see -n in the BSD sed man page and in GNU sed. - William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] OSX TclTk 64bits update
There has been improvement on this. Tcl 8.4.16 now allows a 64bit build on OSX. But strangely Tk 8.4.16 still strips out 64bit arch flags. I found that I could use the ccub trick <http://www.macosxhints.com/article.php?story=20061025213851279 > to fool Tk into building quad-arch Intel+PPC/32+64. I think the Tcl change is just a start, or maybe unintentional backporting. The same changes are in 8.5, including Tk. When building both Tcl and Tk 8.4.16 64bits, there are a bunch of "cast from pointer to int loses precision" warnings. These are fixed in 8.5. But, 8.4.16 runs 64bit, despite the cast warnings. GUI seems to work fine. And NVIZ runs 64bit. But there is a redraw problem (bits of OSX backgrond windows showing, large portions of the window don't redraw) until the window is resized, then redraw is fine. I recall seeing some discussion of a similar (same?) problem, but a couple searches didn't turn up anything in the lists, maybe I didn't pick the right keywords. - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS SVN migration: authentication procedure
On Dec 10, 2007, at 4:03 PM, Markus Neteler wrote: For authentication, the OSGeo LDAP is used (single sign-on). Remember: - GRASS developers need to obtain an "osgeo_id" at http://www.osgeo.org/osgeo_userid Check at http://www.osgeo.org/cgi-bin/ldap_web_search.py if you forgot your "osgeo_id". I would like to point out a little possible confusion - each project seems to have their own login cookie, so if you login to one project, then switch to another, you may need to login again depending on the last time you were logged into it. So, single sign-on really means single user/pass for all projects, not login to one->login to all. ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] building TclTk 8.4 for 64bit OSX 10.5
For any who are interested, here is how I was able to get TclTk 8.4 to build 64bit on OSX 10.5 (Leopard). Note that building the default 32bit on Leopard works without problems (see the macosx/readme.rtf in the GRASS source). TclTk 8.5 builds 64bits, but the GUI doesn't work. You need at least TclTk 8.4.16. The 64bit build options are only partially complete in 8.4.16. Tcl is done, but Tk needs help. To make it simpler, build both using the ccub trick. The ccub trick is the key. The problem is that the Tk configure forcibly strips out any 64bit arch flags you add. But it still builds OK in 64bits. With the ccub trick, it doesn't see the arch flags. Here is the basic ccub info: http://www.macosxhints.com/article.php?story=20061025213851279 You can customize ccub and c++ub to make 64bit universal and 32+64bit universal versions. I have these (plus their c++ub companions): ccub_t 32bit universal, uses the Tiger SDK ccub_l 32bit universal, uses the Leopard SDK ccub_64 64bit universal ccub_3264 32+64bit universal (quad-arch) It's simple to customize the ccub.c and c++ub.c sources for these, just change the ubflags[] at the top. Valid arch choices are ppc, i386, ppc64 and x86_64. The 64bit variations can only use the Leopard SDK (MacOSX10.5.sdk). So, for a 64bit TclTk, using the 64bit ccub above, installed in /usr/ local/bin: - Tcl: CC=ccub_64 ./configure --prefix=/usr/local/tcltk --enable-threads make sudo make install -Tk: CC=ccub_64 ./configure --prefix=/usr/local/tcltk --enable-threads -- with-x --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib --with- tcl=/usr/local/tcltk make sudo make install - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] rtree 64bit OSX issue help needed
Does anyone have any ideas on this: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=572&group_id=21 I've debugged as much as I could figure out how. I don't see any obvious 64bit problems in rtreedeleterect2, but maybe something is going wrong earlier, or it's simply programming I don't understand? - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] batch search and replace from command line?
Looks like you got some response already, but on the GUI side on OSX, BBEdit's find and replace can search whole folders of files. Their free TextWrangler also can. Full GREP support in both, and you can filter files. On Jan 9, 2008, at 12:02 AM, Michael Barton wrote: I'm betting there is a Unix command to do a batch search and replace of one string with another in all text files in a directory. But I don't know what it is. I'm trying to follow Glynn's advice to create a library of common TclTk procedures that can be called without calling another instance of gm.tcl (i.e., without launching another GIS Manager window). These procedures (e.g., Gm::errmsg) get called a LOT in many modules. I'd like a way of replacing every occurance of "Gm::errmsg" with "GmLib::errmsg" in all modules in the TclTk GUI directory. Can someone tell me if this is possible and, if so, how to do it? Thanks 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 Phone: 480-965-6262 Fax: 480-965-7671 www: ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] batch search and replace from command line?
If you haven't checked yet, it's in the Find & Replace dialog - Multi- File Search at the bottom. Just drag a folder into the edit-box there, or choose a folder with the Other button. On Jan 9, 2008, at 8:19 PM, Michael Barton wrote: Thanks William. I use TextWrangler but didn't know it had this capability. This will be simple. 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 Phone: 480-965-6262 Fax: 480-965-7671 www: On Jan 9, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote: Message: 3 Date: Wed, 9 Jan 2008 09:03:09 -0600 From: William Kyngesburye <[EMAIL PROTECTED]> Subject: Re: [GRASS-dev] batch search and replace from command line? To: Michael Barton <[EMAIL PROTECTED]> Cc: GRASS developers list Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Looks like you got some response already, but on the GUI side on OSX, BBEdit's find and replace can search whole folders of files. Their free TextWrangler also can. Full GREP support in both, and you can filter files. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Python GUI requirements
REQUIREMENTS.html mentions Python for the GUI, but a couple things are missing: Is there a minimum version requirement? It doesn't have wxPython as a requirement. - William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python GUI requirements
From what I could figure out about configure and make for GRASS Python: --with-python enables wxpython. See gui/Makefile. The swig bindings are manually built -- see the note in swig/ makefile. And they don't appear to have any connection with --with- python. On Jan 13, 2008, at 1:09 PM, Maris Nartiss wrote: Hi, current trunk ./configure --help says that --with-python will enable Python support (Python bindings?). Still I don't see any switch to enable/disable wxpython. Shouldn't there be one? Maris. - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sqlite and grass64
On Jan 13, 2008, at 5:55 PM, Glynn Clements wrote: AFAIU SQLite (by default) stores the DBs for all vector maps in a single file per mapset. This makes it hard to share individual vector maps and may have LFS issues when your data + mapset gets to be huge. (??) It probably wouldn't be hard to modify the SQLite DBMI driver to allow one file per map (like for DBF), but then you lose the ability to perform joins (OTOH, if you're using DBF, you never had this ability in the first place). I also like the idea of one db file per map. But I didn't know about the join problem (I can see joins being useful). Perhaps a db extract command can be added for when one wants to isolate a map's files? - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: WinGRASS needs TclTk 8.4
From my original attempt back in November, when starting gis.m: GRASS 6.3.cvs (spearfish60):~ > X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 70 (X_PolyFillRectangle) Serial number of failed request: 2296 Current serial number in output stream: 2337 The splash shows just before the error. On Jan 15, 2008, at 1:27 PM, Moritz Lennert wrote: On 15/01/08 18:51, Michael Barton wrote: Moritz, In accidental testing, we've discovered that WinGRASS won't run with TclTk 8.5. It needs 8.4. William Kyngesbury also ran into a problem with TclTk 8.5 for Mac. Thanks for the info. I put it into the README. Any idea what specifically fails with 8.5 ? And does it also fail in Linux ? Moritz - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS needs TclTk 8.4
On Jan 31, 2008, at 3:40 AM, Glynn Clements wrote: It still needs some "internal" files on Windows and MacOSX, specifically: MacOSX: These don't appear to be in the GRASS source any more. #include This is an old Mac "Classic" (that is, pre-OSX) Tcl header. From the "Mac" readme (as opposed to Mac OS X): "Note that Tcl on Mac OS Classic is no longer supported and likely no longer compiles, the last release known to work is 8.4.2. The 'mac' source directory and all other Mac Classic code have been removed from Tk 8.5." It was probably never needed in the first place by GRASS. #include "tkMacOSX.h" #include These are only needed when using the Aqua TclTk. X11 TclTk on OSX is pure unix (and the one I recommend). tkMacOSX.h is installed on an Aqua build, so it is not needed in the GRASS source. tkMaxOSXInt.h is included in the system Tk in Leopard, in an include sub-folder "tk-private". It is not included in the system Tk in Tiger. - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Autoconf 2.13
On Jan 31, 2008, at 12:00 PM, Paul Kelly wrote: BTW: I followed the switch of qgis, from automake to cmake, and I think it was a good success (*much* less bloody than I expected). Now compilation is way smoother and faster. Would it be reasonable to do the same for GRASS? ? GRASS doesn't use automake, so I'm not sure what you mean here. I'm sure if we *were* using automake, we'd also be quite keen to move away from it towards something simpler and better! IMHO the GRASS build system is refreshingly simple to understand compared to other projects that use complex automake, libtool etc.-based systems. Again, would you be able to give a brief summary (for those unfamiliar with cmake, such as myself) of what the benefits of cmake over GRASS' current build system might be? As an end-user compiling GRASS, cmake is yet another requirement. I'm guessing that on other systems, and certainly OSX, developer tools don't include cmake, but do include the basic make and even autotools. And as you say GRASS' build system is already relatively simple. Personally, it doesn't matter (though I quietly resisted the Qgis transition for a while), as long as GRASS compiles. As a (minimal) developer, I haved learned enough of the make system to do what I need to do. I don't look forward to learning a new system, even if it turns out to be simpler. Regarding problems with GRASS' system - I am aware of the need to simplify the platform checks in the SC_CONFIG_CFLAGS macro - see: http://lists.osgeo.org/pipermail/grass-dev/2006-December/027945.html http://lists.osgeo.org/pipermail/grass-dev/2006-December/027970.html and it would be nice to be able to use an alternative build directory (not necessarily the top-level of the source), like the alternative build system in 5.3/5.4 allows, but IMHO it's really not that bad at present. An out-of-source build would be nice. Currently it's not an issue for me on OSX, since the Leopard linker has problem that is forcing me to build separately on Leopard and Tiger systems. But when that's fixed, I will build both the Tiger and Leopard binaries on Leopard, and not having to duplicate the whole source tree for each will be nice. - William Kyngesburye http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS needs TclTk 8.4
On Feb 1, 2008, at 5:09 AM, Glynn Clements wrote: #include "tkMacOSX.h" #include These are only needed when using the Aqua TclTk. X11 TclTk on OSX is pure unix (and the one I recommend). I would recommend getting the native version to build. It shouldn't be necessary to have X11 installed to use GRASS. Apart from anything else, using X11 is adding another dependency and thus another source of potential problems. For now, X11 TclTk on OSX is more reliable than Aqua TclTk. One thing we can't do much about is that TclTk Aqua is only partially "Aquafied" - some widgets still use the X11 look even though there are nearly exact Aqua equivalents. Having an application look and behave mostly native can be disconcerting and confusing to the user. At least in X11 it's all consistent and expected to behave differently. And there is a spacing/layout issue, since Aqua widgets are larger. Button labels get clipped a few pixels, and text can flow out of its area. There is also a runtime issue in NVIZ. I didn't look into it closely since GRASS is moving to the Python GUI, and for the above usability reasons. IIRC, it doesn't display correctly when resizing the window. Or maybe it was that it didn't display anything until the window was resized once. I guess that turned into a bit of a rant. Keep the tkMacOSX headers - it builds and mostly works. I just recommend X11. - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #38: configure.in: wxwidgets and python checks
On Feb 5, 2008, at 11:45 AM, Martin Landa wrote: Hi, 2008/2/5, Michael Barton <[EMAIL PROTECTED]>: That's fine Martin. Thanks. I'm trying to find out how it checks. Are the checks generic enough to work with Mac and Windows, or are they still hard coded to Linux locations? if you look at gui/wxpython/vdigit/Makefile, only one location is still hard-coded, the includes for python -I/usr/include/python$(PYTHONVERSION) The patch checks for Python.h and include directory, it should work on Mac/Windows too. Martin This is not good. Unless the --with-python include dir is also used. (RE my suggestion from the GDAL configure) I don't see anything in configure that sets a python include dir. In fact, I don't see the wxwidgets option either - are you sure it's in SVN now? - William Kyngesburye http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #38: configure.in: wxwidgets and python checks
Ah, I see. Somehow I assumed that it was SVN already... Looks good for OSX, though I'm not comfortable rebuilding configure from configure.in to be able to test it. On Feb 5, 2008, at 12:03 PM, Martin Landa wrote: Hi 2008/2/5, William Kyngesburye <[EMAIL PROTECTED]>: [snip] This is not good. Unless the --with-python include dir is also used. (RE my suggestion from the GDAL configure) I don't see anything in configure that sets a python include dir. In fact, I don't see the wxwidgets option either - are you sure it's in SVN now? the patch is attached to the ticket, see http://trac.osgeo.org/grass/attachment/ticket/38/configure_wx.diff not submitted to svn, since the review is needed... Martin -- Martin Landa <[EMAIL PROTECTED]> * http://gama.fsv.cvut.cz/ ~landa * - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] build grass on osx 10.5-leopard (can't find opengl lib)
On Feb 9, 2008, at 3:00 PM, Glynn Clements wrote: As explained in the macosx readme i need to modify the files : grass_trunk/include/Make/Platform.make.in grass_trunk/configure what i done : in Platform.make.in changed the line 160 to : OPENGLLIB = -dylib_file /usr/X11/lib/libGL.dylib:/usr/X11/ lib/libGL.dylib -undefined dynamic_lookup but in the file : configure here i'm having problems to undstand what needs a modify, i tried to replace all the : " -lGL " with : " -dylib_file /usr/X11/lib/libGL.dylib:/usr/X11/lib/libGL.dylib " or " -/usr/X11/lib/libGL.dylib:/usr/X11/lib/libGL.dylib " or again : " -/usr/X11/lib/libGL.dylib " but the ./configure ... ... fail configure: error: *** Unable to locate OpenGL library. obviously (apologize me for these) i'm wrong to modify the configure file. You left out the "-undefined dynamic_lookup" in the replacement. And be sure to find with a "whole words" option (ie in TextWrangler/ BBEdit), or it will find other things it shouldn't. If configure can't detect OpenGL itself, use --without-opengl then modify include/config.h and include/Make/Platform.make once configure has finished. Hmm, that's sounds like a better option than messing around with configure. (grr, I hope Apple fixes their linker soon.) I'll look into the details that would be needed. PS. I have a bug report for this on the GForge tracker: http://wald.intevation.org/tracker/?func=detail&aid=536&group_id=21&atid=204 More of an informational bug, really, since it's an Apple linker problem. But if Apple can't fix it soon, a workaround in configure may be necessary. -- Glynn Clements <[EMAIL PROTECTED]> _______ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #39: r.in.srtm fails to validate zip files
Makes sense. I wonder why it was changed in the past? It used to try unzipping and check if it failed. Markus? http://trac.osgeo.org/grass/changeset/19303 On Feb 9, 2008, at 3:25 PM, Glynn Clements wrote: GRASS GIS wrote: #39: r.in.srtm fails to validate zip files +--- Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major | Milestone: 6.3.0 Component: default| Version: unspecified Resolution: |Keywords: +--- Comment (by kyngchaos): I guess my main concerns are: * the "--mime" flag is standard on modern systems - it looks like it. * I've noticed that people tend to avoid the double-dash long versions of flags, but I don't know if there is a technical reason other than less typing. In this case it avoids confusion in the -i/-I short flag. If there are no objections to "--mime", I'll patch r.in.srtm. I'd suggest skipping the use of "file" altogether. It isn't a standard utility on Windows. I would assume that the filename ending in .zip is at least prima facie evidence of the file actually being a ZIP file. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #38: configure.in: wxwidgets and python checks
On OSX, python-config is included in the python.org python framework, and in Apple's python 2.5 in Leopard. It is not in Apple's old python 2.3, but most users know to install python.org's python. On Feb 9, 2008, at 6:15 PM, Martin Landa wrote: Hi, 2008/2/10, Hamish <[EMAIL PROTECTED]>: Glynn: E.g. on my system: $ python-config --cflags -I/usr/include/python2.4 -I/usr/include/python2.4 -fno-strict-aliasing -DNDEBUG Okay, so --with-python-includes=-I/usr/include/python2.4 might suffice, depending upon whether or not the code actually uses anything which violates C aliasing rules and/or the extent to which the compiler takes advantage of them (I presume the -fno-strict-aliasing flag is there for a reason). But that's on my system. There's no telling what additional flags it might need on some other system. FWIW, on my system (Debian/stable) there is no python-config in sight. $ locate python-config $ apt-file search bin/python-config $ nothin. (apt-file searches all packages in the entire Debian(/stable) archive) renamed? python-config is part of *python-dev* package (only Debian testing/unstable, it is not included in Etch). I don't know about Mac/Windows Python distribution. Martin Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- Martin Landa * http://gama.fsv.cvut.cz/ ~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling vdigit in wxPython
On Feb 24, 2008, at 11:29 AM, Michael Barton wrote: Second, I DIDN'T make the link to libgdi.so because... 1) my wx folder already has a _gdi_.so file AND 2) I don't seem to have a libgdi.so file It's the other way around - libgdi.so is the symlink you're creating to the existing _gdi_.so. cmb-MBP-2:~/grass_dev/grass_src cmbarton$ cd ./gui/wxpython/vdigit cmb-MBP-2:~/grass_dev/grass_src/gui/wxpython/vdigit cmbarton$ make Makefile:23: warning: overriding commands for target `clean' ../../../include/Make/Rules.make:72: warning: ignoring old commands for target `clean' c++ -c -fpic -I/Users/cmbarton/grass_dev/grass_src/dist.i686-apple- darwin8.11.1/include -I/Library/Frameworks/GDAL.framework/Versions/ 1.4/unix/include -I/Library/Frameworks/Python.framework/Versions/2.5/ include/python2.5 -I/Library/Frameworks/Python.framework/Versions/ 2.5/include/python2.5 -arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp- precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/usr/ local/lib/wxPython-unicode-2.8.7.1/lib/wx/include/mac-unicode- debug-2.8 -I/usr/local/lib/wxPython-unicode-2.8.7.1/include/wx-2.8 - D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ driver.cpp -o OBJ.i686-apple-darwin8.11.1/driver.o driver.cpp:1: warning: -fpic is not supported; -fPIC assumeddriver.cpp:1: warning: -fpic is not supported; -fPIC assumed lipo: can't create output file: OBJ.i686-apple-darwin8.11.1/driver.o (No such file or directory) make: *** [OBJ.i686-apple-darwin8.11.1/driver.o] Error 1 cmb-MBP-2:~/grass_dev/grass_src/gui/wxpython/vdigit cmbarton$ That's strange - I wonder where that "-dynamic" came from? That's a linker option, and this is just a compile step. That may be what is causing the unhelpful error. - William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling vdigit in wxPython
On Feb 24, 2008, at 3:48 PM, Michael Barton wrote: OK. I made the link and still got a similar, but a bit different error Michael cmb-MBP-2:~/grass_dev/grass_src/gui/wxpython/vdigit cmbarton$ make Makefile:23: warning: overriding commands for target `clean' ../../../include/Make/Rules.make:72: warning: ignoring old commands for target `clean' c++ -c -fpic -I/Users/cmbarton/grass_dev/grass_src/dist.i686-apple- darwin8.11.1/include -I/Library/Frameworks/GDAL.framework/Versions/ 1.4/unix/include -I/Library/Frameworks/Python.framework/Versions/2.5/ include/python2.5 -I/Library/Frameworks/Python.framework/Versions/ 2.5/include/python2.5 -arch ppc -arch i386 -isysroot /Developer/SDKs/ MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp- precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/usr/ local/lib/wxPython-unicode-2.8.7.1/lib/wx/include/mac-unicode- debug-2.8 -I/usr/local/lib/wxPython-unicode-2.8.7.1/include/wx-2.8 - D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ driver.cpp -o OBJ.i686-apple-darwin8.11.1/driver.o driver.cpp:1: warning: -fpic is not supported; -fPIC assumed driver.cpp:1: warning: -fpic is not supported; -fPIC assumed lipo: can't create output file: OBJ.i686-apple-darwin8.11.1/driver.o (No such file or directory) make: *** [OBJ.i686-apple-darwin8.11.1/driver.o] Error 1 Same error, just not strung out on one line. It's not getting to the link step yet, so the libgdi symlink hasn't come into play yet. I tried it on Leopard and it's compiling the .o's, but I get errors in the linking. It's strange, but I have all the same compile options, just in a different order, like it's ignoring the makefile's object target (yours looks like it is according to the makefile). - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] diglib and x86_64 problems
I don't know about the missing symbols problem, but are you aware of the OSX 64bit issue in diglib? There is a bug report (got stuck on the old gforge tracker, and is misnamed): http://wald.intevation.org/tracker/index.php?func=detail&aid=572&group_id=21&atid=204 When you built it a couple weeks ago, did you see any problems running vector commands? I built from SVN sources a week ago and still had the problem. On Mar 5, 2008, at 8:36 AM, Henning Lorenz wrote: Hello! I compiled GRASS 6.3.cvs for the x86_64 architecture about two weeks ago. After a svn update today (30478) I get the error "ld: symbol(s) not found for architecture x86_64". Have there been any changes which could cause this? Cheers, Henning Below the complete output after "make" in the diglib directory: - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: diglib and x86_64 problems
On Mar 5, 2008, at 9:54 AM, Henning Lorenz wrote: Hi William! No, I'm not aware of this issue - simply because grass compiled without any errors in diglib. The vector commands I use right now, mostly v.digit, work fine. Henning The error is a runtime. On Mar 6, 2008, at 1:45 AM, Henning Lorenz wrote: 2. For the time being I use mostly v.digit, and I did not have any problems with it in my or your build. Why can it be an OSX-x86_64 problem only and not on other systems with the same architecture? The one definite example was importing a shapefile, but the place it crashed was in the cleaning. Did you try v.in.ogr? Or maybe a v.clean (break tool)? Do you still have the 64bit build to try that? My builds are 32bit, because of this problem, so you won't see it then. IT is indeed a mystery why OSX 64bit has this problem. Though I didn't try it on PPC 64bit (no access PPC Macs with Leopard). - William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] OSX Leopard libGL linking problem solved
Thanks to Apple - the libGL linking issue on Leopard has been fixed. http://wald.intevation.org/tracker/index.php?func=detail&aid=536&group_id=21&atid=204 Their recent iPhone SDK is really a full Xcode 3.1 beta. The updated GCC/LD (4.0) fixes the linking problem. Interestingly, they also include GCC 4.2.1, but 4.0 is still the default. I'll try it out soon to see how that works. iPhone SDK beta is available now, projected final release (Xcode 3.1, iPhone SDK separate I hope) is June. It's HUGE - 2.1GB, over the previous Xcode 3's 1.1GB - that's a lot for the iPhone. - William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: GUI support for TclTk 8.5
I can build an OSX GRASS app with TclTk 8.5 for others to test, and try it myself. If we intend to support multiple versions of TclTk, it would be helpful to have a TCLTKVER variable in Platform.make for the configured major.minor version. On Mar 8, 2008, at 9:06 AM, Michael Barton wrote: IMO we should at least attempt to support Tcl/Tk 8.3 - 8.5. For 8.3 there is just the one problem with v.digit, AFAIK. For 8.5 it apparently mostly works, if it is just a few little issues which are not so hard to fix, then we should try and solve them. i.e. we should at least look into 8.5 problems, it is probably just 1-5 lines of code to be adjusted, and that's not a huge drain on development resources. You are right that fixing issues is probably pretty simple. It's figuring out what to fix that is time consuming. Right now, I'm heavily overcommitted timewise. And on top of that, I'm using my laptop (primary development box) for my GIS class and can't afford to have GRASS broken for more than a couple days. So I have no problem in theory, fixing the GUI for 8.5 if it doesn't involve NVIZ internals or something like that, but won't have time to do much for awhile. Michael - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] how to start wx vdigit?
I'm testing a possible solution to compiling the wx vdigit on OSX, but I can't figure out how to start it. In the wx gui, Vector->Develop vector map->Digitize vector map runs the TclTk v.digit, not the wxpython digitizer. I have my vdigit test built and it looks like it's installed (etc/wxpython/vdigit/ _grass6_wxvdigit.so and grass6_wxvdigit.py). I don't see anything in bin/ or scripts/ that looks like it might run vdigit. - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] how to start wx vdigit?
OK, here's what I got: I wanted to start with an empty vector map, so I tried to create one from the GUI. Error in console: Traceback (most recent call last): File "/Applications/GRASS-6.3.app/Contents/MacOS/etc/wxpython/ wxgui.py", line 433, in OnMenuCmd menuform.GUI().ParseCommand(cmd, parentframe=self) File "/Applications/GRASS-6.3.app/Contents/MacOS/etc/wxpython/ gui_modules/menuform.py", line 1390, in ParseCommand get_dcmd=get_dcmd, layer=layer) File "/Applications/GRASS-6.3.app/Contents/MacOS/etc/wxpython/ gui_modules/menuform.py", line 608, in __init__ mainFrame=self) File "/Applications/GRASS-6.3.app/Contents/MacOS/etc/wxpython/ gui_modules/menuform.py", line 1050, in __init__ txt3.SetValue(p['value']) # parameter previously set File "/BinaryCache/wxWidgets/wxWidgets-11~57/Root/System/Library/ Frameworks/Python.framework/Versions/2.5/Extras/lib/python/wx-2.8-mac- unicode/wx/_controls.py", line 2249, in SetValue TypeError: in method 'SpinCtrl_SetValue', expected argument 2 of type 'int' So I used v.edit from the Terminal to create one. Now, added to the GUI display list, right-click (yes, the toolbar combo box is not there), start editing, and I get a dialog: " Unable to initialize display driver, see README file for more info. Details: 'NoneType' object has no attribute 'OpenMap' (dynamic module does not define init function (init_grass6_wxvdigit)) " It looks like the vdigit toolbar appears, and stays up, but the display list contextual menu still says "start editing" (stop is disabled), so it's probably not fully initialized, as the error says. I'm not sure if this is from the way I setup my test build or something else. Here is what I did to get it compiled: since _gdi_.so is technically an extension to [wx]Python, I figure that it should get loaded (maybe automatically?) by wxPython. So instead of directly linking it into vdigit, I used an OSX linker flag "-undefined dynamic_lookup" to tell the linker that the gdi.so symbols will be found at runtime. But, I'm not sure it gdi is guaranteed to be loaded. Maybe it needs something in the vdigit code to trigger loading the extension, equivalent to import in Python code? Or maybe import it in grass6_wxvdigit.py, before importing _grass6_wxvdigit.so? On Mar 9, 2008, at 1:26 PM, Martin Landa wrote: Hi, there currently two ways 1) add vector map layer into the layer tree, right click and from contextual menu choose 'Start editing' 2) select in Map display window toolbar 'Digitize' (the last tool in the toolbar), then from enabled vdigit toolbar choose vector map layer you want to edit (this map must be present the current layer tree). I remember there was bug on Mac connected to wxComboBox inside wxToolbar instance. So maybe you cannot see these comboboxes in the toolbars. Then first way should work for you. Martin - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] how to start wx vdigit?
On Mar 9, 2008, at 2:43 PM, Martin Landa wrote: Now fixed in trunk, http://trac.osgeo.org/grass/changeset/30510 Yep, works now. important is the last part of the message which comes when you try to import grass6_wxvdigit Python module . Try: cd gui/wxpython/vdigit python import grass6_wxvdigit you will get this error So is there a bug in grass6_wxvdigit.py? I'm not sure if this is from the way I setup my test build or something else. Here is what I did to get it compiled: since _gdi_.so is technically an extension to [wx]Python, I figure that it should get loaded (maybe automatically?) by wxPython. So instead of directly linking it into vdigit, I used an OSX linker flag "-undefined dynamic_lookup" to tell the linker that the gdi.so symbols will be found at runtime. Hm, the last days I have not so much time to work on this, the way you suggest maybe could solve it. I'm guessing "import wx" should import _gdi and load _gdi_.so, since _core imports _gdi. Didn't help with the init_grass6_wxvdigit error. - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] how to start wx vdigit?
Oops, forgot the -shared flag in the vdigit makefile. It ended up linking as a program. See: http://trac.osgeo.org/grass/ticket/61 Changed the shared flag to something appropriate for OSX, and I didn't need to add the "import wx" to grass6_wxvdigit.py. I successfully digitized a boundary. Lots of messages in the Terminal - failed assertions and context errors. I'll add to http://trac.osgeo.org/grass/ticket/58 with my results. On Mar 9, 2008, at 3:18 PM, William Kyngesburye wrote: important is the last part of the message which comes when you try to import grass6_wxvdigit Python module . Try: cd gui/wxpython/vdigit python import grass6_wxvdigit you will get this error So is there a bug in grass6_wxvdigit.py? I'm not sure if this is from the way I setup my test build or something else. Here is what I did to get it compiled: since _gdi_.so is technically an extension to [wx]Python, I figure that it should get loaded (maybe automatically?) by wxPython. So instead of directly linking it into vdigit, I used an OSX linker flag "-undefined dynamic_lookup" to tell the linker that the gdi.so symbols will be found at runtime. Hm, the last days I have not so much time to work on this, the way you suggest maybe could solve it. I'm guessing "import wx" should import _gdi and load _gdi_.so, since _core imports _gdi. Didn't help with the init_grass6_wxvdigit error. - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: GUI support for TclTk 8.5
On Mar 8, 2008, at 9:06 AM, Michael Barton wrote: For 8.5 it apparently mostly works, if it is just a few little issues which are not so hard to fix, then we should try and solve them. i.e. we should at least look into 8.5 problems, it is probably just 1-5 lines of code to be adjusted, and that's not a huge drain on development resources. You are right that fixing issues is probably pretty simple. It's figuring out what to fix that is time consuming. Right now, I'm heavily overcommitted timewise. And on top of that, I'm using my laptop (primary development box) for my GIS class and can't afford to have GRASS broken for more than a couple days. So I have no problem in theory, fixing the GUI for 8.5 if it doesn't involve NVIZ internals or something like that, but won't have time to do much for awhile. Michael Some initial tests for TclTk 8.5.1 on OSX. 10.4/Tiger: the GUI runs and seems to work properly. NVIZ won't run - with Spearfish: " nviz elev=elevation.10m alloc: invalid block: 0x5202b4: 61 0 0 [2]+ Abort trap " Even just "nviz --help" gives that alloc error. 10.5/Leopard: won't run at all. There appears to be some problem between Leopard's fontconfig/freetype and TclTk 8.5 (TclTk 8.4 works). Thread 0 Crashed: 0 libfontconfig.1.dylib 0x004a620a FcConfigAddCache + 149 1 libfontconfig.1.dylib 0x004a63b8 FcConfigAddDirList + 157 2 libfontconfig.1.dylib 0x004a6471 FcConfigBuildFonts + 123 3 libfontconfig.1.dylib 0x004b1dc0 FcInitLoadConfigAndFonts + 45 4 libfontconfig.1.dylib 0x004b1e0c FcInit + 41 5 libfontconfig.1.dylib 0x004a650a FcConfigGetCurrent + 30 6 libfontconfig.1.dylib 0x004a8302 FcConfigSubstituteWithPat + 25 7 libfontconfig.1.dylib 0x004a8a07 FcConfigSubstitute + 39 8 libtk8.5.dylib 0x001c3613 InitFont + 72 ... (This is 32bit mode. In 64bit mode it made it into freetype before crashing.) Unfortunately, I think tcltk/X11 on OSX is forced to used the X11 freetype/fontconfig build, instead of the one I configure for GRASS (my freetype framework). - William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: GUI support for TclTk 8.5
Ah, it looks like --enable-xft is a new option in Tk 8.5, and is enabled by default. In the working Tiger TclTk 8.5 GUI, the menu fonts look nice, compared to the 8.4 GUI. So, disabled xft and now TclTk 8.5 GUI works on Leopard. NVIZ also works. NVIZ still won't run on Tiger though. On Mar 9, 2008, at 6:01 PM, William Kyngesburye wrote: Some initial tests for TclTk 8.5.1 on OSX. 10.4/Tiger: the GUI runs and seems to work properly. NVIZ won't run - with Spearfish: " nviz elev=elevation.10m alloc: invalid block: 0x5202b4: 61 0 0 [2]+ Abort trap " Even just "nviz --help" gives that alloc error. 10.5/Leopard: won't run at all. There appears to be some problem between Leopard's fontconfig/freetype and TclTk 8.5 (TclTk 8.4 works). Thread 0 Crashed: 0 libfontconfig.1.dylib 0x004a620a FcConfigAddCache + 149 1 libfontconfig.1.dylib 0x004a63b8 FcConfigAddDirList + 157 2 libfontconfig.1.dylib 0x004a6471 FcConfigBuildFonts + 123 3 libfontconfig.1.dylib 0x004b1dc0 FcInitLoadConfigAndFonts + 45 4 libfontconfig.1.dylib 0x004b1e0c FcInit + 41 5 libfontconfig.1.dylib 0x004a650a FcConfigGetCurrent + 30 6 libfontconfig.1.dylib 0x004a8302 FcConfigSubstituteWithPat + 25 7 libfontconfig.1.dylib 0x004a8a07 FcConfigSubstitute + 39 8 libtk8.5.dylib 0x001c3613 InitFont + 72 ... (This is 32bit mode. In 64bit mode it made it into freetype before crashing.) Unfortunately, I think tcltk/X11 on OSX is forced to used the X11 freetype/fontconfig build, instead of the one I configure for GRASS (my freetype framework). - William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] how to start wx vdigit?
I put bits of what I did in: http://trac.osgeo.org/grass/ticket/58 http://trac.osgeo.org/grass/ticket/61 On Mar 10, 2008, at 6:59 AM, Martin Landa wrote: Hi William, I'm guessing "import wx" should import _gdi and load _gdi_.so, since _core imports _gdi. Didn't help with the init_grass6_wxvdigit error. yes, it should work, I have tried few days ago but I always get error something like grass6_wxvdigit.so: undefined symbol: _ZN10wxPseudoDC9AddToListEP5pdcOp Can you send me your Mac-related Makefile for inspiration? Thanks, Martin -- Martin Landa * http://gama.fsv.cvut.cz/ ~landa * - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: GUI support for TclTk 8.5
I put an OSX SVN build on my GRASS page with TclTk 8.5. NVIZ works on Leopard but not on Tiger. It installs in /Applications/GRASS-SVN so it doesn't overwrite the RC5 release. http://www.kyngchaos.com/wiki/software:grass For further testing, it also includes the wxpython vdigit that seems to be working. On Mar 10, 2008, at 6:07 AM, Agustin Diez Castillo wrote: I could try it. On Mar 9, 2008, at 6:36 PM, William Kyngesburye wrote: I can build an OSX GRASS app with TclTk 8.5 for others to test, and try it myself. If we intend to support multiple versions of TclTk, it would be helpful to have a TCLTKVER variable in Platform.make for the configured major.minor version. On Mar 8, 2008, at 9:06 AM, Michael Barton wrote: IMO we should at least attempt to support Tcl/Tk 8.3 - 8.5. For 8.3 there is just the one problem with v.digit, AFAIK. For 8.5 it apparently mostly works, if it is just a few little issues which are not so hard to fix, then we should try and solve them. i.e. we should at least look into 8.5 problems, it is probably just 1-5 lines of code to be adjusted, and that's not a huge drain on development resources. You are right that fixing issues is probably pretty simple. It's figuring out what to fix that is time consuming. Right now, I'm heavily overcommitted timewise. And on top of that, I'm using my laptop (primary development box) for my GIS class and can't afford to have GRASS broken for more than a couple days. So I have no problem in theory, fixing the GUI for 8.5 if it doesn't involve NVIZ internals or something like that, but won't have time to do much for awhile. Michael - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Can't connect to osgeo.org today
I'm having some problems here. trac.osgeo.org timed out once, then took a long time to load when I retried. SVN worked fine. On Mar 10, 2008, at 9:51 AM, Patton, Eric wrote: Has anyone had success synching their source code to the repositories on osgeo.org today? I can't update my source, nor connect to osgeo.org via the main website either. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: GUI support for TclTk 8.5
Tiger or Leopard? On Mar 10, 2008, at 12:31 PM, Agustin Diez Castillo wrote: It's working here, nice and easy On Mar 10, 2008, at 4:19 PM, William Kyngesburye wrote: I put an OSX SVN build on my GRASS page with TclTk 8.5. NVIZ works on Leopard but not on Tiger. It installs in /Applications/GRASS- SVN so it doesn't overwrite the RC5 release. http://www.kyngchaos.com/wiki/software:grass For further testing, it also includes the wxpython vdigit that seems to be working. ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] v.in.db - dylb failure
Looks like that symbol isn't linking in from the mysql library. _all_charsets appears to be a "common" symbol, which is known to cause linking problems in OSX's default 2-level namespaces. Mysql is supposed to compile with the -fno-common flag on OSX, but for some reason this _all_charsets made it in there. I'll see what I can do... On Mar 10, 2008, at 5:21 PM, Richard Chirgwin wrote: Greetings all, I seem to be coming up with too many posts, for which I apologise! This time, I have run into a v.in.db error on a colleague's machine. It's running William Kyngesburye's build (6.3 RC5 for Tiger) under OSX 10.4, and generating the following error: dyld: Symbol not found: _all_charsets Referenced from: /Applications/GRASS-6.3.app/Contents/MacOS/driver/ db/mysql Expected in: /Applications/GRASS-6.3.app/Contents/MacOS/lib/ libgrass_dbmibase.dylib Would this have something to do with directory links at start? Richard ___ grass-user mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/grass-user - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] v.in.db - dylb failure
I don't have anything I can easily test this on here, so can you try this: http://www.kyngchaos.com/files/software/unixport/grass-mysql.zip unzip it. Right-click the GRASS application and Show Package Contents. Dig into Contents/MacOS/driver/db and replace the "mysql" there with this one. On Mar 10, 2008, at 7:19 PM, William Kyngesburye wrote: Looks like that symbol isn't linking in from the mysql library. _all_charsets appears to be a "common" symbol, which is known to cause linking problems in OSX's default 2-level namespaces. Mysql is supposed to compile with the -fno-common flag on OSX, but for some reason this _all_charsets made it in there. I'll see what I can do... On Mar 10, 2008, at 5:21 PM, Richard Chirgwin wrote: Greetings all, I seem to be coming up with too many posts, for which I apologise! This time, I have run into a v.in.db error on a colleague's machine. It's running William Kyngesburye's build (6.3 RC5 for Tiger) under OSX 10.4, and generating the following error: dyld: Symbol not found: _all_charsets Referenced from: /Applications/GRASS-6.3.app/Contents/MacOS/driver/ db/mysql Expected in: /Applications/GRASS-6.3.app/Contents/MacOS/lib/ libgrass_dbmibase.dylib Would this have something to do with directory links at start? Richard ___ grass-user mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/grass-user - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.3.0
On Mar 14, 2008, at 10:28 PM, Hamish wrote: As r.in.wms has been reported to work on Mac 10.5, I infer that the #!/bin/bash used by r.tileset makes it use bash's internal echo (which supports echo -n) instead of a system BSD /bin/echo which does not. (??) Even if that is so, it's probably a good idea to fix anyway. The eval within a function within another function and array quoting makes my head hurt, so for clarity's sake I am leaning towards going with Paul's suggestion of using GRASS's own $GISBASE/etc/echo there and keeping the -n, versus Glynn's patch which I find hard to review beyond trial & error tests which I can't properly do without OSX 10.5, which I don't have. I was just comparing the 10.4 and 10.5 man pages for echo and bash - ALL have the -n flag. So really, it must be broken in 10.5's bash. Or not? Just to verify, on its own: echo -n "asdf" /bin/echo -n "asdf" both suppress the newline. Strange. Was it reported to not work in r.tileset, or was it relation to another command? - William Kyngesburye http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] re: various Mac problems today
I just tried r.resamp.interp with my 3/8 svn build (Tiger and Leopard) in the spearfish data (elevation.10m). OK here. Was the build working right after you built it, or is this the first chance you had to test it? - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] re: various Mac problems today .2
(...sent previous before finished...) Applied any system updates recently? r.random - verified bus error on Leopard, I added some crash details to the bug report - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.3.0
On Mar 21, 2008, at 1:29 AM, Glynn Clements wrote: Another problem with vdigit: the C++ wrapper file grass6_wxvdigit_wrap.cpp is *not* a source file (it is built from the .i files using SWIG), and should not be stored in the SVN repository. It should be generated by SWIG during the build process. Correct or not, I'vee seen it as a convention in many projects to include pre-SWIG'd sources (ie Mapserver, Qgis, GDAL). While developers may be OK with adding SWIG to their toolbox (though I haven't installed it on my new Mac because I don't need it any more), users who build from source may not have SWIG, and may not want to install something that's not used at runtime but only for compilation. - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.3.0
Understood, that intermediate files need to rebuilt as developers make changes. But we should try to include them in releases. That was my main point. Hopefully it's something that could be automated. On Mar 22, 2008, at 2:25 AM, Glynn Clements wrote: Even if we include the file as a convenience, the Makefile should still have the appropriate dependency information so that any changes to the .i files are handled correctly. However, this is complicated by the fact that grass6_wxvdigit.i isn't stored in SVN, so that file gets generated, then grass6_wxvdigit_wrap.cpp gets regenerated from that, which may make it out of sync with the SVN version. Also, there's no guarantee that the local timestamps (which indicate when the files were checked out) accurately reflect the relationships between the files. ... If the SWIG issues are considered problematic for end users (who build from source), it may be worth considering including the SWIG-generated files in source tarballs. Note that you already need SWIG if you want to build the wrappers for the GRASS libraries (i.e. if you want to call GRASS functions directly from Python). I would expect this to be an issue sooner or later (I had assumed that vdigit was already doing this, but it turns out that only the C part calls GRASS directly). -- Glynn Clements <[EMAIL PROTECTED]> - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] backporting help for SVN
Back in November there was discussion on how to backport in CVS. How about SVN? I have one old change that hasn't made it to the RCs yet. - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
Markus, Are there any policies on developers backporting their changes to release branches? Do it theirselves? Ask another to do it (ie you) to keep some review sanity? I don't want to mess it up in attempting to do it myself. I was hoping it would be as simple as "apply this trunk changeset to that branch", but it looks like I now need to have a local copy of the branch so I can commit the merges. Though, mine are simple enough (mostly), and isolated, that I could just do a diff and commit. On Mar 24, 2008, at 1:19 AM, Glynn Clements wrote: William Kyngesburye wrote: Back in November there was discussion on how to backport in CVS. How about SVN? I have one old change that hasn't made it to the RCs yet. http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html -- Glynn Clements <[EMAIL PROTECTED]> - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
Thanks for the clarifications. I'll go ahead with some backport fixes. On Mar 26, 2008, at 6:23 AM, Markus Neteler wrote: Do it theirselves? Ask another to do it (ie you) to keep some review sanity? It depends: preferably a developer should be able to backport him/herself but - do not break the release branch - make tests - only fix bugs, do not introduce new features - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
I backported some minor Mac-only bugfixes. They have worked well for me so far. And I did manually apply them to my recent RC binaries, and haven't heard of any problems. A couple were build fixes, so they would only affect those that compiled SVN source. A pair I haven't done yet (ran out of time this morning), that are companions to Glynn's r29926 and r30066, which were applied to the release branch: http://trac.osgeo.org/grass/changeset/30347 http://trac.osgeo.org/grass/changeset/30704 These affect some lib/init stuff, but are important to return what Glynn removed, in another form. These also have worked well for me so far, and are in my binaries, and no reports of problems yet. Comments? On Mar 26, 2008, at 5:44 PM, Hamish wrote: Markus: It depends: preferably a developer should be able to backport him/herself but - do not break the release branch - make tests - only fix bugs, do not introduce new features William Kyngesburye wrote: Thanks for the clarifications. I'll go ahead with some backport fixes. At this point in the RC cycle, it is best to play it very conservative as RC6 was most likely be the last before 6.3.0 and so any changes you make in the release branch will go into 6.3.0 with little to no community testing. Hamish - William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
On Mar 27, 2008, at 4:44 AM, Glynn Clements wrote: Platform-specific targets should be implemented using make conditionals, rather than an unconditional target which performs the test within the commands. IOW: ifneq ($(MACOSX_APP),) FILES += \ $(ETC)/grass-xterm-mac \ $(ETC)/html_browser_mac.sh endif Thanks for the tip. I'll work on that. - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
On Mar 28, 2008, at 6:29 AM, Markus Neteler wrote: I would say yes - I am travelling next week to the FOSSGIS 2008 (http://www.fossgis.de) and could hand out the installer there. The German GRASS association will prepare take-away Linux-based live DVDs. If the Mac Version could be packaged, too, we could cover most relevant operating systems there. Markus If you mean binary installer ready - done last weekend. A CD? Dumping the installer + frameworks + python (+ maybe R) onto CD shouldn't be hard. I could do a quick ordered list of installation if you like. - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
On Mar 28, 2008, at 9:11 AM, Markus Neteler wrote: On Fri, Mar 28, 2008 at 2:53 PM, William Kyngesburye <[EMAIL PROTECTED]> wrote: If you mean binary installer ready - done last weekend. ah, perfect (I didn't check). Note: I *do* have the python vdigit in my build. A CD? Dumping the installer + frameworks + python (+ maybe R) onto CD shouldn't be hard. I could do a quick ordered list of installation if you like. would be nice. Maybe on your Web page? Can do. It's been sitting at the back of my mind to do something like that, some people need things spelled out ;) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
On Mar 27, 2008, at 4:44 AM, Glynn Clements wrote: William Kyngesburye wrote: A pair I haven't done yet (ran out of time this morning), that are companions to Glynn's r29926 and r30066, which were applied to the release branch: http://trac.osgeo.org/grass/changeset/30347 http://trac.osgeo.org/grass/changeset/30704 These affect some lib/init stuff, but are important to return what Glynn removed, in another form. These also have worked well for me so far, and are in my binaries, and no reports of problems yet. Comments? Platform-specific targets should be implemented using make conditionals, rather than an unconditional target which performs the test within the commands. IOW: OK, add this to the above list, to be backported (if OK) as a unit: http://trac.osgeo.org/grass/changeset/30773 ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] WinGRASS-6.3.0RC6 Self Installer
On Mar 28, 2008, at 9:11 AM, Markus Neteler wrote: A CD? Dumping the installer + frameworks + python (+ maybe R) onto CD shouldn't be hard. I could do a quick ordered list of installation if you like. would be nice. Maybe on your Web page? Markus On my downloads page -> Support -> Installation Guide. Hopefully understandable. To simplify the optional stuff, I made Python a requirement for the guide. ----- William Kyngesburye http://www.kyngchaos.com/ "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?" - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
On Mar 28, 2008, at 4:43 PM, Glynn Clements wrote: One minor point: $(INSTALL) -m 755 grass-xterm-mac $(ETC) Makefiles shouldn't hard-code the permissions. The user should be able to override this by setting INSTALL. Typically. $(INSTALL) will use 755 while $(INSTALL_DATA) will use 644. -- Glynn Clements <[EMAIL PROTECTED]> Ah, I must have done that as a quick fix a while back (and it propogated to later changes) without reading the install docs completely (and missed that install defaults to 755). I have that in my osx makefiles also... on to cleanup... ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] backporting help for SVN
Oh, looks like all the installs there hardwired the -m 755 flag. I'll let you take care of cleaning up the init makefile if you want. On Mar 28, 2008, at 4:43 PM, Glynn Clements wrote: One minor point: $(INSTALL) -m 755 grass-xterm-mac $(ETC) Makefiles shouldn't hard-code the permissions. The user should be able to override this by setting INSTALL. Typically. $(INSTALL) will use 755 while $(INSTALL_DATA) will use 644. -- Glynn Clements <[EMAIL PROTECTED]> - William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] forking on OSX Leopard (or earlier for that matter)
A change in OSX Leopard (10.5) that may affect GRASS, though I haven't seen any problems yet. From a release note for the developer tools: " CoreFoundation and fork() Due to the behavior of fork(), CoreFoundation cannot be used on the child-side of fork(). If you fork(), you must follow that with an exec*() call of some sort, and you should not use CoreFoundation APIs within the child, before the exec*(). The applies to all higher-level APIs which use CoreFoundation, and since you cannot know what those higher-level APIs are doing, and whether they are using CoreFoundation APIs, you should not use any higher-level APIs either. This includes use of the daemon() function. Additionally, per POSIX, only async-cancel-safe functions are safe to use on the child side of fork(), so even use of lower-level libSystem/ BSD/UNIX APIs should be kept to a minimum, and ideally to only async- cancel-safe functions. This has always been true, and there have been notes made of this on various Cocoa developer mailling lists in the past. But CoreFoundation is taking some stronger measures now to "enforce" this limitation, so we thought it would be worthwhile to add a release note to call this out as well. A message is written to stderr when something uses API which is definitely known not to be safe in CoreFoundation after fork(). If file descriptor 2 has been closed, however, you will get no message or notice, which is too bad. We tried to make processes terminate in a very recognizable way, and did for a while and that was very handy, but backwards binary compatibility prevented us from doing so. " If a process forks and a corefoundation unsafe function is used, you get a warning in the console: " The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ () to debug. " This can quickly clog the console and log files. While it doesn't seem to affect GRASS, an improperly-built TclTk can cause trouble. I ran into this when testing NVIZ for the pixmap/pbuffer export bug. I've updated the OSX Readme TclTk build example to include an extra configure option: --disable-corefoundation Since the example is for an X11 TclTk build, CoreFoundation isn't really necessary, so this is OK. And, though the warning log problem is Leopard-only, the forking is still a potential issue with earlier OSX versions, so this option should be used for all OSX versions. For a TclTk Aqua build (for those that are willing to brave other problems), CoreFoundation is needed. It is currently only partially fixed in Tcl (8.4 and 8.5) - for 64bit only, though it also happens in 32bit mode. - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #104: saving display to tiff or ppm garbled when NVIZ is not top window
lip, GL_SGIS_generate_mipmap, GL_ARB_shading_language_100, GL_ARB_texture_border_clamp, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_texture_cube_map, GL_ARB_texture_env_dot3, GL_ARB_texture_env_combine, GL_ARB_texture_compression, GL_ARB_texture_mirrored_repeat, GL_ARB_shadow, GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_point_sprite, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ARB_pixel_buffer_object, GL_EXT_framebuffer_object, GL_EXT_texture_rectangle, GL_ARB_texture_rectangle, GL_EXT_texture_env_add, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_lod_bias, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_stencil_wrap, GL_EXT_texture_filter_anisotropic, GL_EXT_separate_specular_color, GL_EXT_secondary_color, GL_EXT_blend_func_separate, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_texture_compression_s3tc, GL_EXT_texture_compression_dxt1, GL_EXT_blend_equation_separate, GL_EXT_packed_depth_stencil, GL_EXT_geometry_shader4, GL_APPLE_flush_buffer_range, GL_APPLE_ycbcr_422, GL_APPLE_texture_range, GL_APPLE_pixel_buffer, GL_APPLE_object_purgeable, GL_NV_blend_square, GL_ATI_texture_env_combine3, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None Save PPM: Create PixMap Using GLX 1.1 Final Assembled Image will be 2048 x 2048 Writing Tile 1 of 9 Writing Tile 2 of 9 Writing Tile 3 of 9 Writing Tile 4 of 9 Writing Tile 5 of 9 Writing Tile 6 of 9 Writing Tile 7 of 9 Writing Tile 8 of 9 Writing Tile 9 of 9 Assembling Tiles Destroy Context Destroy GLXPixmap Destroy Pixmap glXSwapBuffers: no context for this drawable PPM image is OK. ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #104: saving display to tiff or ppm garbled when NVIZ is not top window
On Mar 31, 2008, at 7:03 AM, Glynn Clements wrote: Destroy Pixmap glXSwapBuffers: no context for this drawable Does this actually cause any problems for subsequent use of NVIZ? When the zoom code completes, there shouldn't be a current context or current drawable; the window's expose handler should re-instate them each time. If this causes a problem, we could probably restore them. NVIZ still works after the save. (tried zoom, resize window, add vector) ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: failure compiling GRASS svn trunk on Mac OS X 10.4.11
On Mar 31, 2008, at 8:36 PM, Michael Barton wrote: cmb-MBP-2:~/grass_dev/grass_src cmbarton$ cd ./gui/wxpython/vdigit cmb-MBP-2:~/grass_dev/grass_src/gui/wxpython/vdigit cmbarton$ make cc -dynamiclib -compatibility_version 6.3 -current_version 6.3 - install_name /Applications/Grass/GRASS-6.3.app/Contents/MacOS/lib/ libgrass6_wxvdigit.dylib -o OBJ.i686-apple-darwin8.11.1/ _grass6_wxvdigit.dylib -L/Users/cmbarton/grass_dev/grass_src/ dist.i686-apple-darwin8.11.1/lib OBJ.i686-apple-darwin8.11.1/ cats.o OBJ.i686-apple-darwin8.11.1/digit.o OBJ.i686-apple- darwin8.11.1/driver.o OBJ.i686-apple-darwin8.11.1/ grass6_wxvdigit_wrap.o OBJ.i686-apple-darwin8.11.1/line.o OBJ.i686- apple-darwin8.11.1/select.o OBJ.i686-apple-darwin8.11.1/vertex.o - lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz - lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime - lz -lgrass_gis -lgrass_datetime -lz -lgrass_dgl - lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree - lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree - lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree - lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient - lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis - lgrass_datetime -lz -lgrass_dbmibase -lgrass_gis - lgrass_datetime -lz -L/Library/Frameworks/GDAL.framework/ Versions/1.5/unix/lib -lgdal -lgrass_gis -lgrass_datetime -lz -L/ Library/Frameworks/GDAL.framework/Versions/1.5/unix/lib -lgdal - lgrass_vedit -lgrass_gis -lgrass_datetime -lz -lgrass_vect - lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz - lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime - lz -lgrass_gis -lgrass_datetime -lz -lgrass_dgl - lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree - lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree -L/ usr/local/lib/wxPython-unicode-2.8.7.1/lib -framework IOKit - framework Carbon -framework Cocoa -framework System -framework QuickTime -lwx_macud-2.8 -L/Library/Frameworks/Python.framework/ Versions/2.5/lib/python2.5/config -ldl -lpython2.5 -lgdi /usr/bin/libtool: can't locate file for: -lgdi /usr/bin/libtool: file: -lgdi is not an object file (not allowed in a library) make: *** [OBJ.i686-apple-darwin8.11.1/_grass6_wxvdigit.dylib] Error 1 vdigit needs work - on all platforms I think - but especially for OSX. See these for info, though it may be hard to put that all together right away. I could post my vdigit makefile if you like. http://trac.osgeo.org/grass/ticket/61 http://trac.osgeo.org/grass/ticket/58 - William Kyngesburye http://www.kyngchaos.com/ "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?" - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Shapelib and dbf not compiling for Mac
I just added a couple comments. Summary - revert to previous shapelib. On Apr 3, 2008, at 10:26 AM, Michael Barton wrote: I'll add my comments. But is there a workaround? I don't really understand the problem. Is it related to the new version of gdal? Michael ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS_BATCH_JOB vs GUI
I was discussing with someone running GRASS in batch mode, and it's not clear what is possible with respect to X11, display windows, TclTk or Python. I see that in init.sh, a batch script is forced to run in text mode. Still, a module run without options (intentionally or not) would try to bring up a TclTk window and require user interaction, thus potentially disrupting the flow of the script. Certainly running either the TclTk or Python GUIs in a batch script is not desirable, but maybe there are possibilities I don't see? Display windows may be useful in a batch script - or not? ----- William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS_BATCH_JOB vs GUI
On Apr 5, 2008, at 9:52 PM, Hamish wrote: the first thing I do after installing X11 on Mac OSX is to stop it from launching a xterm upon X11 startup. We got that straightened out - Joe forgot to do that (it's mentioned in the OSX readme). I also worked out some improvements in the app startup script to minimize the X11 focus switching. Now it doesn't "open" (*) X11 if it's already running, thus avoiding a focus switch. It also records which term application the script is running in (**) and returns focus to that. So now, starting X11 before GRASS (ie on login), or just leaving it running after the first run of GRASS, seems to work well. (*) 'open' runs an OSX application, and since an OSX application normally can only have one instance running, it only activates it when it's already running. I used this as a shortcut to checking if it's running in the startup script. (**) If run from a double-click or drag-n-drop, GRASS.app will always use Terminal.app, but the grass script, as Joe is doing, could be run directly from a different term app such as xterm or iTerm. - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] creating location from the command line
On Apr 6, 2008, at 10:55 AM, Glynn Clements wrote: 1. Individual modules can write whatever they want under cell_misc. E.g. the fftreal and fftimag files written by i.fft are in host byte order. Ugh, didn't know about that one (we took care of the stroke fonts and portable.h already). This would make it impossible to work with the same fft map data on PPC and Intel OSX, or sharing fft map data between different platforms (most Mac users consider "OSX" the platform, not the "processor" type). 2. Even when portable formats are used, the precise choice of format may be platform-specific. Maybe we need to specify that anything written must be in a portable format. And provide some library functions (maybe already there?) for writing data in a portable way. Another item for GRASS 7, I suppose... - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.3.0 to be released
This weekend would be fine for me, for packaging OSX binaries. It'll mesh well with the Qgis 0.10 packaging. On Apr 18, 2008, at 3:26 PM, Markus Neteler wrote: On Fri, Apr 18, 2008 at 10:25 PM, Marco Pasetti <[EMAIL PROTECTED] > wrote: Hi all, When do you think that 6.3.0 will be released? This weekend could be an option since Hamish downgraded his blocker (PNG offset) to annoying. I wonder if we could put out source code and binaries more or less at the same time? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.3.0 is out! please prepare binaries...
My Mac OS X binaries are ready. I also updated the system and extra requirements on the OSX download page (should be online on the next cron sync). On Apr 19, 2008, at 7:09 AM, Markus Neteler wrote: Before making the big announcement, let's prepare binaries and the final release announcement. Tarball here: http://grass.osgeo.org/grass63/source/grass-6.3.0.md5sum http://grass.osgeo.org/grass63/source/grass-6.3.0.tar.gz Release announcement under preparation in http://trac.osgeo.org/grass/browser/grass-web/trunk/announces/announce_grass630.html (to be moved to tac Wiki afterwards!) Congrats to all! Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.3.0 is out! please prepare binaries...
I thought the binary package size looked a bit small, and did notice that some i modules were missing, but figured there was a good reason. I reverted my download page to the RC6 download, awaiting a new 6.3.0 source tarball. On Apr 21, 2008, at 9:16 AM, Glynn Clements wrote: Markus Neteler wrote: Before making the big announcement, let's prepare binaries and the final release announcement. Note: most of the imagery modules are missing in 6.3.0. The reason is that changes to the way that SUBDIRS was handled in imagery/Makefile resulted in most of the modules not being built. The specific change in question is r30999. Essentially, only the modules listed in $(FFTWBASED) and $(XMONBASED) are actually built (assuming that FFTW and X11 respectively are enabled). The modules which are supposed to be built unconditionally are actually never built. I have just committed a fix to the trunk (r31065), but all of the 6.3.0 binary packages which people have built will be missing the following modules: i.ask i.atcorr i.cluster i.find i.gensig i.gensigset i.group i.his.rgb i.maxlik i.rectify i.rgb.his i.smap i.target i.pca i.cca -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.3.0 is out again (6_3_0_1)
OSX binaries are ready. On Apr 23, 2008, at 3:02 PM, Markus Neteler wrote: Hi, the GRASS 6.3.0 re-release is done: http://grass.osgeo.org/grass63/source/grass-6.3.0.tar.gz http://grass.osgeo.org/grass63/source/grass-6.3.0.md5sum Please package again... so we can update also the release announcement again. thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.digit linking error on osx
The current wxpython vdigit makefile is incompatible with OSX. There hasn't been a decision yet how to handle it. Here is a vdigit makefile I sent to Michael that works: Makefile Description: Binary data On Apr 29, 2008, at 3:29 PM, Colin Rundel wrote: I'm attempting to compile a svn snapshot on my macbook and I'm running into a roadblock with getting v.digit to compile. I've followed the instructions in the wxpython readme and created the symlink to _gdi_.so from wxpython but I get the following error: cc -dynamiclib -compatibility_version 6.4 -current_version 6.4 - install_name /usr/local/grass-6.4.svn/lib/libgrass6_wxvdigit.dylib - o OBJ.i686-apple-darwin9.2.2/_grass6_wxvdigit.dylib -L/Users/rundel/ Desktop/grass/grass6_devel/dist.i686-apple-darwin9.2.2/lib OBJ.i686-apple-darwin9.2.2/cats.o OBJ.i686-apple-darwin9.2.2/digit.o OBJ.i686-apple-darwin9.2.2/driver.o OBJ.i686-apple-darwin9.2.2/ grass6_wxvdigit_wrap.o OBJ.i686-apple-darwin9.2.2/line.o OBJ.i686- apple-darwin9.2.2/select.o OBJ.i686-apple-darwin9.2.2/undo.o OBJ.i686-apple-darwin9.2.2/vertex.o -lgrass_vect -lgrass_dbmibase - lgrass_gis -lgrass_datetime -lz -lgrass_dbmiclient - lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis - lgrass_datetime -lz -lgrass_dgl -lgrass_dig2 -lgrass_gis - lgrass_datetime -lz -lgrass_rtree -lgrass_gis -lgrass_datetime - lz -lgrass_linkm -lgrass_rtree -lgrass_dig2 -lgrass_gis - lgrass_datetime -lz -lgrass_rtree -lgrass_dgl -lgrass_rtree - lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis - lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz - lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -L/Library/ Frameworks/GDAL.framework/Versions/1.5/unix/lib -lgdal -lgrass_gis - lgrass_datetime -lz -L/Library/Frameworks/GDAL.framework/ Versions/1.5/unix/lib -lgdal -lgrass_vedit -lgrass_gis - lgrass_datetime -lz -lgrass_vect -lgrass_dbmibase -lgrass_gis - lgrass_datetime -lz -lgrass_dbmiclient -lgrass_dbmibase - lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime - lz -lgrass_dgl -lgrass_dig2 -lgrass_gis -lgrass_datetime - lz -lgrass_rtree -lgrass_gis -lgrass_datetime -lz - lgrass_linkm -lgrass_rtree -L/usr/local/lib -framework IOKit - framework Carbon -framework Cocoa -framework System -framework QuickTime -lwx_macu_richtext-2.8 -lwx_macu_aui-2.8 - lwx_macu_xrc-2.8 -lwx_macu_qa-2.8 -lwx_macu_html-2.8 - lwx_macu_adv-2.8 -lwx_macu_core-2.8 -lwx_base_carbonu_xml-2.8 - lwx_base_carbonu_net-2.8 -lwx_base_carbonu-2.8 -L/Library/ Frameworks/Python.framework/Versions/2.5/lib/python2.5/config -ldl - lpython2.5 -lgdi ld: in /usr/local/lib/libgdi.so, can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) collect2: ld returned 1 exit status make: *** [OBJ.i686-apple-darwin9.2.2/_grass6_wxvdigit.dylib] Error 1 This seems to have something to do with how I've compiled wxpython on my system, but playing with the obvious build flags for wxpython has had no effect ( I've tried both the current stable release and svn). Just as a philosophical aside, I havent had much time to explore the wxpython code yet, but what was the compelling reason for the use of the PseudoDC in the first place? Does the C++ driver provide a significant speed up or is it something else that I am missing? Thanks, -Colin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] build problems on Mac OS X 10.5.2.
On May 8, 2008, at 9:26 PM, John Kern wrote:
Hello,
I am trying to build Grass from source on Leopard(Mac OS X 10.5.2
with gcc 4.0.1).
While PROJ.4 built and installed without problem, configure failed
for GRASS proper. The resulting error is ...
"checking External PROJ.4 version... configure: error: *** Could not
determine External PROJ.4 version."
Consider this line from the trace output of the configure script.
+ eval echo configure:6910: '"${CC-cc}' -o conftest '$CFLAGS'
'$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"'
++ echo configure:6910: 'gcc -o conftest.dSYM -g -O2
conftest.c 1>&5'
The dSYM file extension on the output file is the critical bit. If
the output file ends with a dSYM file extension, only supporting
data is generated. No executable. (see example below). I worked
around the problem by deleting references to ${ac_exeext}. What's
the right fix for the configure script? Apparently there is a
supporting script to autoconf which needs to be updated, right?
These dSYM errors don't necessarily mean there is something wrong with
configure. When configure is testing for things and they fail, a dSYM
error is more likely a symptom of that failure, not a bug in configure.
I have seen some problems when compiling with debug symbols (-g) on
Leopard. I usually force my own CFLAGS so rarely run into this. Try
setting CFLAGS and CXXFLAGS to "-Os" before running configure.
Another note: you will probably run into a libGL linking problem if
you are using Xcode 3.0. This has been fixed in the Xcode 3.1 beta,
so I recommend installing that - it's included for now in the iPhone
SDK beta. The -g issue may also be fixed in Xcode 3.1, I haven't
tried that yet.
See the macosx/ReadMe.rtf for all my current OSX notes (hmm, I don't
have the -g issue in there).
-
William Kyngesburye
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] build problems on Mac OS X 10.5.2.
On May 8, 2008, at 11:27 PM, John Kern wrote: Thanks for the prompt reply. I missed the macosx subdirectory. I will read it. Also, your wiki entry (http://www.kyngchaos.com/wiki/software:grass ) is informative. I have installed the iPhone SDK. Those build instructions are a bit old, though mostly still valid. The readme in the source is basically an updated version of that. You're response doesn't acknowledge a key point. The error results in the configure script failing. This check breaks down to a trivial c program. When I extracted it from the configure script(see try.c) and compile it as we see in the trace output, it fails. Consider the try.c testcase. That was my suggestion - to try configuring by setting CFLAGS to -Os only, so the -g flag (default) is not used. If you want debug symbols, the workaround is to configure without, then add -g to platform.make after configuring. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] build problems on Mac OS X 10.5.2.
On May 9, 2008, at 3:02 AM, crundel wrote: William pointed out the issue is with the -g flag being passed which for some unknown reason seems to result in the test programs compiling as OSX applications, hence that directory organization you were seeing, and then I never really thought about it. It may be because of the way GCC handles compilation vs linking. In configure, for a run test, it compiles *and* links the test program in one step ($ac_link). When the debug flag is used, GCC may be assuming that we want an OSX application and quietly packages one up for us. -g works in GRASS compilation later because all programs are compiled to object files first (even if there is only one), then linked into the program binary. So, maybe it is kindof a broken configure - this app packaging problem started in Xcode 3.0 on Leopard, and GRASS' configure doesn't know about it yet. ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] build problems on Mac OS X 10.5.2.
On May 10, 2008, at 11:57 PM, Glynn Clements wrote:
The dSYM file extension on the output file is the critical bit. If
the
output file ends with a dSYM file extension, only supporting data is
generated. No executable. (see example below). I worked around the
problem by deleting references to ${ac_exeext}. What's the right fix
for the configure script? Apparently there is a supporting script to
autoconf which needs to be updated, right?
It's autoconf's AC_EXEEXT macro which is the problem. It attempts to
determine the executable suffix automatically, with the following
code:
Essentially, it deletes conftest.*, compiles and links a test program
named "conftest", then searches for any files matching conftest.*
whose extension isn't recognised as an intermediate file. If any such
file exists, it is assumed to be the executable, and its suffix is
treated as the executable suffix.
Clearly this fails if linking produces any unexpected files, such as
conftest.dSYM (which presumably contains debug symbols).
We should probably eliminate the use of that macro in favour of a
simple "if cygwin or mingw then .exe else nothing" test. I don't know
of any other supported platform where executables have a suffix.
Ah, yes, I see. Even though the .dSYM bundle is created when debug
sysmbols are ON, there is also a normal executable without an
extension. But AC_EXEEXT sees the bundle first (and ignores that it
is a directory) and assumes that's the executable.
Note that with the correct extention (ie none), run tests will still
produce that .dSYM bundle. It seems to only happen when the compile
and link steps are one, and not when object files are compiled, then
linked in a separate step (so GRASS compilation won't be so messy).
It's also only for the default OSX debug format, DWARF.
-
William Kyngesburye
http://www.kyngchaos.com/
"Mon Dieu! but they are all alike. Cheating, murdering, lying,
fighting, and all for things that the beasts of the jungle would not
deign to possess - money to purchase the effeminate pleasures of
weaklings. And yet withal bound down by silly customs that make them
slaves to their unhappy lot while firm in the belief that they be the
lords of creation enjoying the only real pleasures of existence
- the wisdom of Tarzan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass6_devel, problems to find gdal library
Finally had a chance to try it myself. Looks like changes in r31909 broke it. The tests are now including gdal.h, yet the GDAL include path isn't added to the test compile: configure:7677: gcc -o conftest -Os -arch ppc -arch i386 -arch ppc - arch i386 -arch ppc -arch i386 conftest.c -L/Library/Frameworks/ GDAL.framework/Versions/1.5/unix/lib -lgdal 1>&5 configure:7671:18: error: gdal.h: No such file or directory On Jul 4, 2008, at 12:28 PM, Glynn Clements wrote: Massimo Di Stefano wrote: i'm tring to update grass from svn, on osx . the configure find gdal-config but fail to find gdal libraries . .. checking for location of JPEG includes... /Library/Frameworks/ UnixImageIO.framework/unix/include checking for jpeglib.h... yes checking for location of JPEG library... /Library/Frameworks/ UnixImageIO.framework/unix/lib checking for jpeg_start_compress in -ljpeg... yes checking whether to use GDAL... yes checking for gdal-config... /Library/Frameworks/GDAL.framework/ Programs/gdal-config configure: error: *** Unable to locate GDAL library. Look in config.log for the command which fails and any error messages which it generates. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass6_devel, problems to find gdal library
On Jul 6, 2008, at 1:52 PM, Markus Neteler wrote: On Sun, Jul 6, 2008 at 8:33 PM, Glynn Clements <[EMAIL PROTECTED] > wrote: Markus Neteler wrote: On Sun, Jul 6, 2008 at 7:29 PM, William Kyngesburye <[EMAIL PROTECTED]> wrote: Finally had a chance to try it myself. Looks like changes in r31909 broke it. The tests are now including gdal.h, yet the GDAL include path isn't added to the test compile: ... Fixed in trunk in r32030. Backported to 6.4.svn in r32031. Works for me now on OSX. - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
On Jul 6, 2008, at 3:23 PM, Markus Neteler wrote: Errors in: /Users/cmbarton/grass_dev/grass7_src/lib/nviz /Users/cmbarton/grass_dev/grass7_src/gui/wxpython/vdigit /Users/cmbarton/grass_dev/grass7_src/gui/wxpython/nviz /Users/cmbarton/grass_dev/grass7_src/visualization/nviz2/cmd -- ... cmb-MBP-2:grass7_src cmbarton$ cd /Users/cmbarton/grass_dev/ grass7_src/lib/nviz ... Users/cmbarton/grass_dev/grass7_src/dist.i386-apple-darwin9.4.0/ include/grass/gstypes.h:13:19: error: GL/gl.h: No such file or directory Do you lack some devel package? On My Mandriva box, it is in rpm -qf /usr/include/GL/gl.h lib64mesagl1-devel-7.0.1-10mdv2008.0 OR the GL include path is missing? error: conflicting declaration 'typedef int Cursor' /usr/X11/include/X11/X.h:108: error: 'Cursor' has a previous declaration as 'typedef XID Cursor' lipo: can't figure out the architecture type of: /var/folders/AK/AKpYwDw1EoWI+fFF02nvRk+++TI/-Tmp-//cc8d1b5h.out make: *** [OBJ.i386-apple-darwin9.4.0/change_view.o] Error 1 Looks like a Mac specific error to me. Yeah, I vaguely recall seeing a workaround for errors like this - something to do with Cursor being used in Carbon I think. Maybe the workaround is in TclTk? I haven't attempted trunk yet. I'll give it a spin today and see if I think of anything. - William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
On Jul 6, 2008, at 3:36 PM, William Kyngesburye wrote: On Jul 6, 2008, at 3:23 PM, Markus Neteler wrote: Errors in: /Users/cmbarton/grass_dev/grass7_src/lib/nviz /Users/cmbarton/grass_dev/grass7_src/gui/wxpython/vdigit /Users/cmbarton/grass_dev/grass7_src/gui/wxpython/nviz /Users/cmbarton/grass_dev/grass7_src/visualization/nviz2/cmd -- ... cmb-MBP-2:grass7_src cmbarton$ cd /Users/cmbarton/grass_dev/ grass7_src/lib/nviz Just noticing that nviz gets its own library now, probably so that there can be a tcltk nviz and wxpython nviz without duplicating the core nviz features. Now here's something that gets tricky with OSX. TclTk in OSX has never really worked all that well for NVIZ in the "Aqua" OpenGL configuration. Only the X11 configuration has worked reliably for NVIZ. So most people will be configuring for X11. So, assuming that you configure for X11 OpenGL/TclTk, the NVIZ library will be made for X11 OpenGL. But wxPython OpenGL will be "Aqua" no matter what. I don't know if this is the source of the current errors, but it will certainly be a problem later. Either the GUI will have to be an either/or choice (or just ignore TclTk GUI), or we need to make sure NVIZ TclTk works in the OSX Aqua configuration so they can be configured together. For the immediate problems, I'd say configure with Aqua and disable TclTk NVIZ compilation. --with-opengl=aqua --without-tcltk --without-x - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
On Jul 6, 2008, at 6:58 PM, Michael Barton wrote: Here is the location of the native OGL (called AGL on Mac). /System/Library/Frameworks/AGL.framework/Versions/A/Headers/gl.h Which is a symlink to /System/Library/Frameworks/OpenGL.frameworks/ Headers/gl.h. Which is what you get when you configure with --with- opengl=aqua. Which spits out a bunch cpp errors in the Carbon includes, from the AGL include. More than I can wrap my brain around at the moment, but it looks like we need to work on this. - William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
On Jul 6, 2008, at 9:05 PM, William Kyngesburye wrote:
On Jul 6, 2008, at 6:58 PM, Michael Barton wrote:
Here is the location of the native OGL (called AGL on Mac).
/System/Library/Frameworks/AGL.framework/Versions/A/Headers/gl.h
Which is a symlink to /System/Library/Frameworks/OpenGL.frameworks/
Headers/gl.h. Which is what you get when you configure with --with-
opengl=aqua.
Which spits out a bunch cpp errors in the Carbon includes, from the
AGL include. More than I can wrap my brain around at the moment,
but it looks like we need to work on this.
Learned a new trick today (probably standard stuff for the programming
gurus) - I added -E to the compile flags and found that an unexpected
macro was substituted for a buried Carbon struct:
typedef struct CMFixedXYZColor {
Fixed X;
Fixed Y;
Fixed Z;
} CMFixedXYZColor;
which came out as:
typedef struct CMFixedXYZColor {
Fixed 0;
Fixed 1;
Fixed 2;
} CMFixedXYZColor;
It appears X, Y and Z (all caps, that is) are defined in gstypes.h in
GRASS. I was able to fix the problem by moving the lines in nviz.h:
#include
#include
to *after* the GL includes.
-
William Kyngesburye
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
Which I would have found if I had updated my SVN today... Sorry, I wasn't paying attention, and it moved too fast ;) On Jul 9, 2008, at 9:39 PM, William Kyngesburye wrote: It appears X, Y and Z (all caps, that is) are defined in gstypes.h in GRASS. I was able to fix the problem by moving the lines in nviz.h: #include #include to *after* the GL includes. - William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
On Jul 9, 2008, at 9:44 PM, William Kyngesburye wrote: Which I would have found if I had updated my SVN today... Sorry, I wasn't paying attention, and it moved too fast ;) On Jul 9, 2008, at 9:39 PM, William Kyngesburye wrote: It appears X, Y and Z (all caps, that is) are defined in gstypes.h in GRASS. I was able to fix the problem by moving the lines in nviz.h: #include #include to *after* the GL includes. But, there is this in gui/wxpython/nviz/nviz.h: #include #include #include #include Since already includes gsurf.h and gstypes.h, perhaps those should be removed to let handle the proper include order? - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: nvizlib compile error
I think there may still be some GLx vs AGL vs WGL differences to take care of? At least, I'm now getting this: In file included from change_view.c:20: /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:120: error: syntax error before ‘AGLPixelFmtID’ /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:120: warning: no semicolon at end of struct or union /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:122: error: syntax error before ‘windowId’ /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:122: warning: data definition has no type or storage class /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:127: error: syntax error before ‘}’ token make: *** [OBJ.i386-apple-darwin9.3.0/change_view.o] Error 1 Checking with -E, I see that I'm getting the "struct render_window" as expected, so I don't know what's wrong. Maybe that should be a typedef? since render_window is used in render.c as: struct render_window* Nviz_new_render_window(); On Jul 9, 2008, at 6:08 PM, Michael Barton wrote: Are we at a place yet where I can compile and test this on a Mac, given it's location of OpenGL in the agl directory? Michael - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] errors compiling nviz in GRASS 7
On Jul 9, 2008, at 11:23 PM, Glynn Clements wrote: William Kyngesburye wrote: But, there is this in gui/wxpython/nviz/nviz.h: #include #include #include #include Since already includes gsurf.h and gstypes.h, perhaps those should be removed to let handle the proper include order? Any source or header file which uses types or macros from a header file should explicitly include that header file. Header files should guard against repeated inclusion; AFAICT, all of the headers mentioned here do so. OK. Haven't got that far anyways - stuck on my struct render_window error in the nviz lib. - William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile wxPython NVIZ
On Jul 15, 2008, at 10:21 PM, Michael Barton wrote: On Jul 15, 2008, at 2:18 AM, Glynn Clements wrote: FWIW, I have made some changes to lib/nviz/render.c to get it to compile on Windows, which may also help on OSX (there were some X-specific portions which weren't conditionalised). It doesn't work on Windows yet (G_malloc() fails), but I don't have a native version of GDB installed, so I haven't looked into it any further. Glynn and Martin, I tried this out on my Mac. It still doesn't compile, but it gets different errors this time. Michael cmb-MBP-2:grass7_src cmbarton$ cd ./lib/nviz cmb-MBP-2:nviz cmbarton$ make cc -dynamiclib -compatibility_version 7.0 -current_version 7.0 - install_name L/Library/Frameworks/GDAL.framework/Versions/1.5/unix/lib -lgdal -L/ usr/X11/lib -L/usr/X11R6/lib -lGL -L/usr/X11R6/lib -lGLU - Undefined symbols: "_XOpenDisplay", referenced from: _Nviz_create_render_window in render.o "_XFreePixmap", referenced from: _Nviz_destroy_render_window in render.o "_XCreatePixmap", referenced from: _Nviz_create_render_window in render.o "_XFree", referenced from: _Nviz_create_render_window in render.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [/Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.4.0/lib/libgrass_nviz.7.0.svn.dylib] Error 1 As I mentionaed a while back, for the nviz library to operate cleanly with wxpython, which is "Aqua", or AGL-based, you should configure OpenGL for Aqua, not X11. This means you should also disable X11 and TclTk features, or you will get some header confusion for OpenGL. Something like: --without-tcltk --without-x --without-motif --without-glw --with- opengl=aqua But, when I do this I get: gcc -I/Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/ include -Os-fno-common -DPACKAGE=\""grasslibs"\" -I/Library/ Frameworks/GDAL.framework/Versions/1.5/Headers -DPACKAGE= \""grasslibs"\" -I/System/Library/Frameworks/OpenGL.framework/Headers -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Users/ Shared/unix/ffmpeg-leo/include/ffmpeg -I/Users/Shared/src/GRASS/svn/ trunk/dist.i386-apple-darwin9.3.0/include -o OBJ.i386-apple- darwin9.3.0/change_view.o -c change_view.c In file included from change_view.c:20: /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:120: error: syntax error before ‘AGLPixelFmtID’ /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:120: warning: no semicolon at end of struct or union /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:122: error: syntax error before ‘windowId’ /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:122: warning: data definition has no type or storage class /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/include/ grass/nviz.h:129: error: syntax error before ‘}’ token make[2]: *** [OBJ.i386-apple-darwin9.3.0/change_view.o] Error 1 It seems to be some AGL programming issue. - William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile wxPython NVIZ
On Jul 15, 2008, at 10:36 PM, William Kyngesburye wrote: In file included from change_view.c:20: /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/ include/grass/nviz.h:120: error: syntax error before ‘AGLPixelFmtID’ Hmm, I can't find AGLPixelFmtID *anywhere* in the OSX headers, and there are no hits at Apple. Google only returns a few hits, all mentioning that it's the AGL equivalent of "XVisualInfo" for pixel info. - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile wxPython NVIZ
On Jul 16, 2008, at 2:45 AM, Glynn Clements wrote: William Kyngesburye wrote: On Jul 15, 2008, at 10:36 PM, William Kyngesburye wrote: In file included from change_view.c:20: /Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/ include/grass/nviz.h:120: error: syntax error before �AGLPixelFmtID� Hmm, I can't find AGLPixelFmtID *anywhere* in the OSX headers, and there are no hits at Apple. Google only returns a few hits, all mentioning that it's the AGL equivalent of "XVisualInfo" for pixel info. According to: http://developer.apple.com/documentation/GraphicsImaging/Reference/AGL_OpenGL/Reference/reference.html it should be AGLPixelFormat (without the "ID" suffix). And that's exactly what togl.c uses. That works, but now it chokes on AGLPixmap... Also, I note that aglCreateAGLPixmap isn't mentioned on that page. However, it does describe aglCreatePBuffer, which is probably the appropriate function to use (similarly, the X11 implementation should probably use pBuffers if they are available). ... so I wonder if "AGLPixmap windowId;" should also be changed to "AGLPbuffer windowId;"? Doing that works. But I imagine that the rest of the nviz library must be changed to use AGLPbuffers. I didn't get errors elsewhere about missing AGL pixmap functions. I only see those in render.c, which I disabled to be able to compile libnviz. - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trying to compile wxPython NVIZ
I got further now. By ignoring render.c, libnviz compiles.
Now I'm in wxpython/nviz. I see that there is still the nviz header
include order problem here. In wxpython nviz.h, the order should be:
extern "C" {
#include
#include
#include
#include
}
And I see one in nviz.i:
%{
#include "nviz.h"
#include
#include
%}
Now I get an error in the swig wrapper:
c++ -I/Users/Shared/src/GRASS/svn/trunk/dist.i386-apple-darwin9.3.0/
include -Os -fno-common -I/Library/Frameworks/GDAL.framework/
Versions/1.5/Headers -I/System/Library/Frameworks/Python.framework/
Versions/2.5/include/python2.5 -I/System/Library/Frameworks/
Python.framework/Versions/2.5/include/python2.5 -fno-strict-aliasing -
Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -
DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -
DENABLE_DTRACE -I/usr/lib/wx/include/mac-unicode-debug-2.8 -I/usr/
include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -
D__WXMAC__ -DPACKAGE=\""grasslibs"\" -I/Users/Shared/src/GRASS/
svn/trunk/dist.i386-apple-darwin9.3.0/include -o OBJ.i386-apple-
darwin9.3.0/grass7_wxnviz_wrap.o -c grass7_wxnviz_wrap.cpp
cc1plus: warning: command line option "-Wstrict-prototypes" is valid
for C/ObjC but not for C++
/usr/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning:
‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/
AGL.framework/Headers/agl.h:61)
/usr/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning:
‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/
AGL.framework/Headers/agl.h:61)
grass7_wxnviz_wrap.cpp:3165: error: expected unqualified-id before ‘{’
token
grass7_wxnviz_wrap.cpp:3173: error: expected unqualified-id before ‘{’
token
grass7_wxnviz_wrap.cpp:3180: error: expected unqualified-id before ‘{’
token
grass7_wxnviz_wrap.cpp:3241: error: expected unqualified-id before ‘{’
token
grass7_wxnviz_wrap.cpp:3781: error: expected unqualified-id before ‘{’
token
grass7_wxnviz_wrap.cpp: In static member function ‘static int
swig::traits_asptr_stdseq::asptr(PyObject*, Seq**)’:
grass7_wxnviz_wrap.cpp:3889: error: expected unqualified-id before ‘?’
token
make: *** [OBJ.i386-apple-darwin9.3.0/grass7_wxnviz_wrap.o] Error 1
The relevant lines (first case):
template
struct traits_check {
static bool check(PyObject *obj) {
int res = obj ? asval(obj, (Type *)(0)) : SWIG_ERROR;
return SWIG_IsOK(res) ? true : false;
}
};
It's the check(PyObject) line. All the other errors are also on
check(PyObject) lines (except that last one), which is:
return pyseq.check() ? SWIG_OK : SWIG_ERROR;
I'm using the SWIG included in OSX Xcode 3.1: v1.3.31.
On Jul 16, 2008, at 8:33 AM, William Kyngesburye wrote:
On Jul 16, 2008, at 2:45 AM, Glynn Clements wrote:
According to:
http://developer.apple.com/documentation/GraphicsImaging/Reference/AGL_OpenGL/Reference/reference.html
it should be AGLPixelFormat (without the "ID" suffix).
And that's exactly what togl.c uses.
That works, but now it chokes on AGLPixmap...
Also, I note that aglCreateAGLPixmap isn't mentioned on that page.
However, it does describe aglCreatePBuffer, which is probably the
appropriate function to use (similarly, the X11 implementation should
probably use pBuffers if they are available).
... so I wonder if "AGLPixmap windowId;" should also be changed to
"AGLPbuffer windowId;"?
Doing that works. But I imagine that the rest of the nviz library
must be changed to use AGLPbuffers.
I didn't get errors elsewhere about missing AGL pixmap functions. I
only see those in render.c, which I disabled to be able to compile
libnviz.
-
William Kyngesburye
http://www.kyngchaos.com/
"Time is an illusion - lunchtime doubly so."
- Ford Prefect
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python script test
On Jul 21, 2008, at 4:17 AM, Glynn Clements wrote: Michael Barton wrote: Init.sh is not updating PYTHONPATH on my Mac for some reason. I've looked at the code and it seems fine. I DO have a PYTHONPATH. So I'm not sure why it is not updating it. If I change it manually, by simply pasting your code (export PYTHONPATH="$GISBASE/etc/python: $PYTHONPATH") into the GRASS prompt, PYTHONPATH IS modified appropriately and r_in_aster.py works fine with the new grass.py library. I suspect that /etc/profile resets PYTHONPATH. Init.sh creates a .bashrc script in the mapset directory (which, at the point that the session shell is started, is $HOME), and that script sources /etc/profile. That's almost certainly bogus. /etc/profile is only meant to be sourced by login shells, not by subshells, largely for reasons such as this. I have fixed this in SVN trunk. As far as I can tell, the OSX /etc/profile only *adds* to PATH and MANPATH, and doesn't touch python stuff. Are you sure you added PYTHONPATH code to init.sh? I don't see anything that sets PYTHONPATH. (just updated SVN, checked trunk also) - William Kyngesburye http://www.kyngchaos.com/ "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?" - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python script test
On Jul 21, 2008, at 10:47 AM, Glynn Clements wrote: William Kyngesburye wrote: Are you sure you added PYTHONPATH code to init.sh? I don't see anything that sets PYTHONPATH. (just updated SVN, checked trunk also) http://trac.osgeo.org/grass/browser/grass/trunk/lib/init/init.sh#L299 Hehe, I said I checked trunk, but I forgot to update first (I updated on dev branch). oops, coffee hadn't kicked in yet ;) ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python script test
On Jul 21, 2008, at 12:14 PM, Michael Barton wrote: On Jul 21, 2008, at 2:17 AM, Glynn Clements wrote: I suspect that /etc/profile resets PYTHONPATH. Init.sh creates a .bashrc script in the mapset directory (which, at the point that the session shell is started, is $HOME), and that script sources /etc/profile. That's it. PYTHONPATH is set in my .profile. So it overwrites whatever GRASS has set. I can fix this for me, but yours fixes this more generally. See my other reply - /etc/profile doesn't touch PYTHONPATH. ~/.profile is not /etc/profile, and /etc/profile doesn't load ~/.profile, as far as I can tell. - William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 7:17 AM, Glynn Clements wrote: Mac OS X 10.5 comes with TclTk aqua 8.4 and 8.5. But I also have to install an x11 version that I compile (in /usr/local/tcltk) in order to compile and run GRASS with the standard x11 tcltk. Actually, OSX 10.5 only comes with 8.4 Aqua. I'd say it's a fairly safe bet that Togl is being compiled with the 8.5 headers but linked against the 8.4 library. That's certainly possible. I have to watch some projects when I compile them when I want to use dependencies that I've built newer versions than are available in the system - if the project adds -L/usr/ lib to the linking, the system version will usually link instead of mine. Since /usr/lib is always in the default link path, it's not needed. OSX -L ordering rules in the linker are a bit different than linux, and can be troublesome at times. GRASS is good about this, but there are a couple things in the system that can add that, from .la info or config scripts. Michael, for the line that links nviz, do you see -L/usr/lib? - William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 8:38 AM, William Kyngesburye wrote: I'd say it's a fairly safe bet that Togl is being compiled with the 8.5 headers but linked against the 8.4 library. Michael, for the line that links nviz, do you see -L/usr/lib? Another possibility is my OSX app startup script is confusing things, so that it's building correctly with 8.5 but running with 8.4. Are you compiling with the TCLTK_INTERNAL and TCLTKVER exports I have in the Mac readme? And configuring with opengl=aqua? - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 9:05 AM, William Kyngesburye wrote: On Jul 23, 2008, at 8:38 AM, William Kyngesburye wrote: I'd say it's a fairly safe bet that Togl is being compiled with the 8.5 headers but linked against the 8.4 library. Michael, for the line that links nviz, do you see -L/usr/lib? Another possibility is my OSX app startup script is confusing things, so that it's building correctly with 8.5 but running with 8.4. No, that's silly, nviz links against a specific version of tcltk, duh. - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 10:42 AM, Michael Barton wrote: Actually, OSX 10.5 only comes with 8.4 Aqua. Well, I don't remember installing 8.5 (though the absence of memory is not necessarily a memory of absence in my case). It doesn't look to be an Active States installation and I'm sure that I didn't compile 8.5 aqua. So I'm not sure where it came from if it didn't come with some system update. What comes with OSX is in /System/Library/Frameworks, and all that is in my system is 8.4. If you have 8.5 in /Library/Frameworks, then that that must have been installed by something. Michael, for the line that links nviz, do you see -L/usr/lib? Where do I look for this? I don't have a recent compile log handy, but I think you can search for "-o nvwish" in the Terminal after compiling. But then... ./configure ... --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers / Library/Frameworks/Tk.framework/Headers /Library/Frameworks/ Tk.framework/PrivateHeaders" In my local notes, I set --with-tcltk-libs=/usr/local/lib. Without that, the 8.5 includes are used, but the libraries are found in /usr/ lib, which are the 8.4 libs. This assumes that there are symlinks to the frameworks in /usr/local/ lib. I don't remember if the aqua tcltk build automatically adds these or not, or if the binaries available (ie Activestate) include these. Ideally, I think GRASS needs to detect a framework TclTk Aqua and use -framework Tcl -framework Tk instead of -ltcl -ltk to link tcltk, then the symlinks and -L flag would not be necessary. - William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 12:28 PM, Glynn Clements wrote: William Kyngesburye wrote: Ideally, I think GRASS needs to detect a framework TclTk Aqua and use -framework Tcl -framework Tk instead of -ltcl -ltk to link tcltk, then the symlinks and -L flag would not be necessary. Presumably this would be handled similarly to OpenGL, which already has suitable configure checks. Hmm, it IS related. Though it's a little more complicated. OSX 10.4+ has a true TclTk 8.4 Aqua, but 10.3- only appears to be, but is really X11 (and it's the old v8.3). So we can't make any assumptions about the header locations. To make it simple for the user, tests for /Library/Frameworks/ Tcl.framework then /System/Library/Frameworks/Tcl.framework[/Versions/ 8.4] would be needed to get the appropriate -I flags. The framework flags are simple because no path is needed - the linker looks first in /Library/Frameworks, then /System/Library/frameworks, so a user 8.5 would override the system's. Disabling/uninstalling /Library/Frameworks is simple, if a user wanted to build GRASS for the system framework. - William Kyngesburye http://www.kyngchaos.com/ "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?" - The Ruler of the Universe ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 3:48 PM, Glynn Clements wrote: Michael Barton wrote: Something else to keep in mind. The header I posted is needed by Togl I think. But I also think that it is 8.5 only. Do you mean that the packages for earlier versions don't include tkMacOSXInt.h? Togl definitely requires that header, so if it's only available with 8.5, then your only choice is 8.5. Which means that you have to link against 8.5. OSX 10.5's system TclTk 8.4 includes this, there's a PrivateHeaders folder in the framework that's an alias to Headers/tk-private. OSX 10.4 didn't include it. I'm not sure how OSX handles shared library versions. On Linux, a library named e.g. libtk.so will normally be a symlink to the actual library, which will include the version number. The linker embeds the versioned library name in the executable, and that is used for locating the library at run time. The unversioned symlink is only needed at compile time (and many distributions keep the symlink in the -devel package, along with the headers). The end result is that you can have multiple versions of a library installed, and control which version is used at compile time (without affecting the loading of libraries at run time) by changing the unversioned symlink. If OSX is similar, then you may just be able to delete the symlinks for the older versions. Compiling does make use of symlinks to current versions. For unix libraries, it's the same. But for frameworks it's in the framework folder layout. Since frameworks are complete packages of a library, different versions can simply be in a different location. ie, to override the system tcltk framework v8.4 with your own 8.5, just install yours in /Library/Framworks and it will be found first, if -framework link flags are used. Yet, even system frameworks that are unix ports often have symlinks in /usr/lib, so you need to make sure that you have -L/path/to/your/ lib in the linking, or link the framework directly instead of the library with -framework FWName. Alternatively, you could try changing the linking command in visualization/nviz/src/Makefile, moving XTRA_LDFLAGS (which will contain the --with-tcltk-libs= directory) to the beginning of the command, so that it takes precedence over other directories (where the 8.4 libraries are presumably being found by accident). Or in include/make/platform.make, replace the TCLTKLIBS line with: TCLTKLIBS = -framework Tcl -framework Tk - William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua
On Jul 23, 2008, at 4:18 PM, Michael Barton wrote: I don't know enough about make to offer suggestions. But if you get a procedure sorted out, I'm happy to try it. It's possible you can get it right purely by configuration. Do you have symlinks to /Library/Frameworks versions of tcl and tk in /usr/ local/lib? Then just add --with-tcltk-libs=/usr/local/lib to your configure. - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
