Re: [GRASS-dev] GRASS 6.4.0 release branch created
Fedora 8 64bit works too. Minor complaint: r.external menu entry missing in tcltk, present in wxpython as Raster-Develop raster map-Link to GDAL. IMHO this wonderful module deserves a menu entry also in tcltk :-) Markus M Jachym Cepicky wrote: ubuntu works j 2008/12/19 William Kyngesburye wokl...@kyngchaos.com: Simple test run OK here on OSX. On Dec 19, 2008, at 2:39 PM, Markus Neteler wrote: Today the GRASS 6.4.0 release branch has been created- Please check it out and test it (now) before we tag RC1: svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 thanks, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.watershed fails in 6.4 SVN
Michael Barton wrote: I just updated and compiled today. In case you have modified front/main.c to fix that length.slope bug, there may now be a svn conflict in front/main.c. Maybe it works if you delete front/main.c and svn up again to get a new copy. Then, after updating, the patch sent by Glynn or the path for grass64 at [1] can be applied to get a proper error message. [1] http://trac.osgeo.org/grass/attachment/ticket/398 Markus M r.watershed compiles without problems, but it fails when you try to run it. It worked OK yesterday. Here is the error from Spearfish. GRASS 6.4.svn (Spearfish60_test):~ r.watershed elevation=elevation.dem accumulation=atest_delete1 ERROR: USAGE for basin delineation: /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/r.watershed.ram -4 el=elevation_map t=swale_threshold [ov=overland_flow_map] [dr=drain_direction_map] [de=depression_map] [ac=accumulation_map] [di=display_map] ba=watershed_basin_map [se=stream_segment_map] USAGE for ARMSED FILE creation: /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/r.watershed.ram [-4] el=elevation_map t=swale_threshold [ov=overland_flow_map] [dr=drain_direction_map] [de=depression_map] [ac=accumulation_map] [di=display_map] [ba=watershed_basin_map] [se=stream_segment_map] ha=half_basin_map ar=ARMSED_file_name USAGE for slope length determination: /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/r.watershed.ram [-4] el=elevation_map t=swale_threshold [dr=drain_direction_map] [de=depression_map] [ac=accumulation_map] [di=display_map] [ms=max_slope_length] [ob=overland_blocking_map] [S=slope_steepness_map] LS=length_slope_map [r=rill_erosion_map] [sd=slope_deposition value or map] WARNING: Subprocess failed with exit code 256 WARNING: category information for [atest_delete1] in [PERMANENT] missing or invalid Same (not very informative) error if I use -s or specify ls.factor for the output 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: www.public.asu.edu/~cmbarton http://www.public.asu.edu/%7Ecmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.0 release branch created
Hi Markus, On Fri, 19 Dec 2008 21:39:43 +0100 Markus Neteler nete...@osgeo.org wrote: Sorry - I haven't had enough time to test OpenSUSE yet. I will check and package when I am online again after christmas. kind regards, Otto Today the GRASS 6.4.0 release branch has been created- Please check it out and test it (now) before we tag RC1: svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 thanks, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.watershed fails in 6.4 SVN - fixed
On Dec 22, 2008, at 2:19 AM, Markus Metz wrote: Michael Barton wrote: I just updated and compiled today. In case you have modified front/main.c to fix that length.slope bug, there may now be a svn conflict in front/main.c. Maybe it works if you delete front/main.c and svn up again to get a new copy. Then, after updating, the patch sent by Glynn or the path for grass64 at [1] can be applied to get a proper error message. [1] http://trac.osgeo.org/grass/attachment/ticket/398 Markus M r.watershed compiles without problems, but it fails when you try to run it. It worked OK yesterday. Here is the error from Spearfish. GRASS 6.4.svn (Spearfish60_test):~ r.watershed elevation=elevation.dem accumulation=atest_delete1 ERROR: USAGE for basin delineation: /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/ r.watershed.ram -4 el=elevation_map t=swale_threshold [ov=overland_flow_map] [dr=drain_direction_map] [de=depression_map] [ac=accumulation_map] [di=display_map] ba=watershed_basin_map [se=stream_segment_map] USAGE for ARMSED FILE creation: /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/ r.watershed.ram [-4] el=elevation_map t=swale_threshold [ov=overland_flow_map] [dr=drain_direction_map] [de=depression_map] [ac=accumulation_map] [di=display_map] [ba=watershed_basin_map] [se=stream_segment_map] ha=half_basin_map ar=ARMSED_file_name USAGE for slope length determination: /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/ r.watershed.ram [-4] el=elevation_map t=swale_threshold [dr=drain_direction_map] [de=depression_map] [ac=accumulation_map] [di=display_map] [ms=max_slope_length] [ob=overland_blocking_map] [S=slope_steepness_map] LS=length_slope_map [r=rill_erosion_map] [sd=slope_deposition value or map] WARNING: Subprocess failed with exit code 256 WARNING: category information for [atest_delete1] in [PERMANENT] missing or invalid Same (not very informative) error if I use -s or specify ls.factor for the output Fixed now. I deleted all of r.watershed, did an SVN update, and applied the patch. Thanks for the help. Any chance that MFD will be backported to 6.4? Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] mac error in GRASS 7 compiling
Here is the mac error from compiling GRASS 7. Everything else compiled fine except for nviz_cmd of course. The error says that it's missing an Info.plist in ./macosx/app. I've kept a build.log as you suggested Glynn. So if you you need me to send more, let me know. Michael make output VERSION_NUMBER=7.0.svn /Users/cmbarton/grass_dev/grass7_src/tools/ g.html2man/g.html2man.py /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/docs/html/variables.html /Users/cmbarton/ grass_dev/grass7_src/dist.i386-apple-darwin9.6.0/man/man1/variables.1 VERSION_NUMBER=7.0.svn /Users/cmbarton/grass_dev/grass7_src/tools/ g.html2man/g.html2man.py /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/docs/html/vector.html /Users/cmbarton/ grass_dev/grass7_src/dist.i386-apple-darwin9.6.0/man/man1/vector.1 make[2]: `/Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/man/man1/vectorintro.1' is up to date. VERSION_NUMBER=7.0.svn /Users/cmbarton/grass_dev/grass7_src/tools/ g.html2man/g.html2man.py /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/docs/html/ wxGUI.Attribute_Table_Manager.html /Users/cmbarton/grass_dev/ grass7_src/dist.i386-apple-darwin9.6.0/man/man1/ wxGUI.Attribute_Table_Manager.1 VERSION_NUMBER=7.0.svn /Users/cmbarton/grass_dev/grass7_src/tools/ g.html2man/g.html2man.py /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/docs/html/wxGUI.Nviz.html /Users/cmbarton/ grass_dev/grass7_src/dist.i386-apple-darwin9.6.0/man/man1/wxGUI.Nviz.1 VERSION_NUMBER=7.0.svn /Users/cmbarton/grass_dev/grass7_src/tools/ g.html2man/g.html2man.py /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/docs/html/ wxGUI.Vector_Digitizing_Tool.html /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/man/man1/wxGUI.Vector_Digitizing_Tool.1 VERSION_NUMBER=7.0.svn /Users/cmbarton/grass_dev/grass7_src/tools/ g.html2man/g.html2man.py /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/docs/html/wxGUI.html /Users/cmbarton/ grass_dev/grass7_src/dist.i386-apple-darwin9.6.0/man/man1/wxGUI.1 make[2]: `/Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/man/man1/xganim.1' is up to date. make[2]: `/Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/man/man1/ximgview.1' is up to date. gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o at_exit_funcs.o -c at_exit_funcs.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o error.o -c error.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o tools.o -c tools.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o reg_deps.o -c reg_deps.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o reg_entries.o -c reg_entries.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o reg_html.o -c reg_html.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o actions.o -c actions.c gcc -g -Wall -pedantic -Werror-implicit-function-declaration -fno- common -o main.o -c main.c gcc at_exit_funcs.o error.o tools.o reg_deps.o reg_entries.o reg_html.o actions.o main.o -o gem7 -g -Wall -pedantic -Werror- implicit-function-declaration -fno-common -L/Users/cmbarton/grass_dev/ grass7_src/dist.i386-apple-darwin9.6.0/lib -arch i386 -Os -arch i386 -Os app make[2]: *** No rule to make target `Info.plist', needed by `macosxapp'. Stop. modbuild mkdir -p /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/modbuild cp -f License.rtf /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/modbuild/ cp -f ReadMe.rtf /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/modbuild/ mkdir -p /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/modbuild/dist.i386-apple-darwin9.6.0 cp -rf /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/demolocation /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/modbuild/dist.i386-apple-darwin9.6.0/ sed -e 's,^GISDBASE.*,GISDBASE = /Library/GRASS/7.0/modbuild/dist.i386- apple-darwin9.6.0,g' /Users/cmbarton/grass_dev/grass7_src/dist.i386- apple-darwin9.6.0/demolocation/.grassrc70 /Users/cmbarton/grass_dev/ grass7_src/dist.i386-apple-darwin9.6.0/modbuild/dist.i386-apple- darwin9.6.0/demolocation/.grassrc70 mkdir -p /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/modbuild/module mkdir -p /Users/cmbarton/grass_dev/grass7_src/dist.i386-apple- darwin9.6.0/modbuild/include/Make cp ../../include/Make/Dir.make /Users/cmbarton/grass_dev/grass7_src/ dist.i386-apple-darwin9.6.0/modbuild/include/Make/ cp ../../include/Make/Doxygen.make /Users/cmbarton/grass_dev/ grass7_src/dist.i386-apple-darwin9.6.0/modbuild/include/Make/ sed -E -e 's,@GRASS_LIB_PREFIX@,lib,g' \ -e 's,@GRASS_LIB_SUFFIX@,.dylib,g' \ -e
Re: [GRASS-dev] mac error in GRASS 7 compiling
Looks like Glynn's r33038 messed it up. I'll have to look at it to get it working again. Glynn: is OBJDIR not used now, or is there a different way of specifying custom OBJDIR/targets? I'll take a closer look later at other parts of GRASS for examples. On Dec 22, 2008, at 9:50 AM, Michael Barton wrote: Here is the mac error from compiling GRASS 7. Everything else compiled fine except for nviz_cmd of course. The error says that it's missing an Info.plist in ./macosx/app. I've kept a build.log as you suggested Glynn. So if you you need me to send more, let me know. Michael - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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] mac error in GRASS 7 compiling
William Kyngesburye wrote:
Looks like Glynn's r33038 messed it up. I'll have to look at it to
get it working again.
Glynn: is OBJDIR not used now, or is there a different way of
specifying custom OBJDIR/targets? I'll take a closer look later at
other parts of GRASS for examples.
I suspect the problem is that some of the files in $(MOD_OBJS) aren't
object files. If that ever worked, it was coincidence.
You need to add an rule which will force $(OBJDIR)/Info.plist to be
built, e.g.:
$(APPDIR)/Info.plist: $(OBJDIR)/Info.plist
-$(INSTALL_DATA) $ $@
You also need to make $(APPDIR)/Info.plist as part of the top-level
macosxapp rule. One complication is the need to ensure that $(OBJDIR)
is created first, even in parallel builds, and it seems we can't rely
upon make (particularly the OSX version) supporting order-only
dependencies.
I suggest replacing the top-level macosxapp rule with the following:
NIBSRC := $(wildcard English.lproj/MainMenu.nib/*)
NIBDST := $(patsubst English.lproj/%,$(APPDIR)/English.lproj/%,$(NIBSRC))
FILES = \
$(APPDIR)/MacOS/etc/build_html_user_index.sh \
$(APPDIR)/MacOS/etc/build_gui_user_menu.sh \
${APPDIR}/Resources/app.icns \
$(APPDIR)/Info.plist \
$(APPDIR)/PkgInfo \
$(APPDIR)/Resources/Scripts/GRASS.scpt \
$(APPDIR)/MacOS/grass.sh \
$(APPDIR)/MacOS/GRASS \
$(NIBDST)
macosxapp:
-$(MAKE_DIR_CMD) $(OBJDIR)
-$(MAKE_DIR_CMD) $(APPDIR)/Resources/Scripts
-$(MAKE_DIR_CMD) $(APPDIR)/MacOS/scripts
-$(MAKE_DIR_CMD) $(APPDIR)/MacOS/etc
-$(MAKE_DIR_CMD) $(APPDIR)/English.lproj/MainMenu.nib
$(MAKE) $(FILES)
${APPDIR}/Resources/app.icns: app.icns
$(INSTALL_DATA) $ $@
$(APPDIR)/English.lproj/%: English.lproj/%
$(INSTALL_DATA) $ $@
$(APPDIR)/Info.plist: $(OBJDIR)/Info.plist
$(INSTALL_DATA) $ $@
$(APPDIR)/PkgInfo: PkgInfo
$(INSTALL_DATA) $ $@
$(APPDIR)/Resources/Scripts/GRASS.scpt: (OBJDIR)/GRASS.scpt
$(INSTALL_DATA) $ $@
$(APPDIR)/MacOS/grass.sh: $(OBJDIR)/grass.sh
$(INSTALL) $ $@
$(APPDIR)/MacOS/etc/%.sh: %.sh
$(INSTALL) $ $@
BTW, is there a reason that main.m isn't called main.c?
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mac error in GRASS 7 compiling
On Dec 22, 2008, at 12:30 PM, Glynn Clements wrote:
William Kyngesburye wrote:
Looks like Glynn's r33038 messed it up. I'll have to look at it to
get it working again.
Glynn: is OBJDIR not used now, or is there a different way of
specifying custom OBJDIR/targets? I'll take a closer look later at
other parts of GRASS for examples.
I suspect the problem is that some of the files in $(MOD_OBJS) aren't
object files. If that ever worked, it was coincidence.
Indeed, most are scripts of some sort. But it wasn't coincidence that
it worked:
You need to add an rule which will force $(OBJDIR)/Info.plist to be
built, e.g.:
$(APPDIR)/Info.plist: $(OBJDIR)/Info.plist
-$(INSTALL_DATA) $ $@
I had:
ARCH_OBJS := $(foreach obj,$(OBJS),$(OBJDIR)/$(obj))
which took care of this.
You also need to make $(APPDIR)/Info.plist as part of the top-level
macosxapp rule. One complication is the need to ensure that $(OBJDIR)
is created first, even in parallel builds, and it seems we can't rely
upon make (particularly the OSX version) supporting order-only
dependencies.
I suggest replacing the top-level macosxapp rule with the following:
NIBSRC := $(wildcard English.lproj/MainMenu.nib/*)
Will this exclude CVS/SVN hidden files? IOW, does it behave just like
ls (without the -a flag)?
NIBDST := $(patsubst English.lproj/%,$(APPDIR)/English.lproj/%,$
(NIBSRC))
FILES = \
$(APPDIR)/MacOS/etc/build_html_user_index.sh \
$(APPDIR)/MacOS/etc/build_gui_user_menu.sh \
${APPDIR}/Resources/app.icns \
$(APPDIR)/Info.plist \
$(APPDIR)/PkgInfo \
$(APPDIR)/Resources/Scripts/GRASS.scpt \
$(APPDIR)/MacOS/grass.sh \
$(APPDIR)/MacOS/GRASS \
$(NIBDST)
macosxapp:
-$(MAKE_DIR_CMD) $(OBJDIR)
-$(MAKE_DIR_CMD) $(APPDIR)/Resources/Scripts
-$(MAKE_DIR_CMD) $(APPDIR)/MacOS/scripts
-$(MAKE_DIR_CMD) $(APPDIR)/MacOS/etc
-$(MAKE_DIR_CMD) $(APPDIR)/English.lproj/MainMenu.nib
$(MAKE) $(FILES)
${APPDIR}/Resources/app.icns: app.icns
$(INSTALL_DATA) $ $@
$(APPDIR)/English.lproj/%: English.lproj/%
$(INSTALL_DATA) $ $@
$(APPDIR)/Info.plist: $(OBJDIR)/Info.plist
$(INSTALL_DATA) $ $@
$(APPDIR)/PkgInfo: PkgInfo
$(INSTALL_DATA) $ $@
$(APPDIR)/Resources/Scripts/GRASS.scpt: (OBJDIR)/GRASS.scpt
$(INSTALL_DATA) $ $@
$(APPDIR)/MacOS/grass.sh: $(OBJDIR)/grass.sh
$(INSTALL) $ $@
$(APPDIR)/MacOS/etc/%.sh: %.sh
$(INSTALL) $ $@
I'll give this a go. I assume keep my $(OBJDIR)/* targets?
BTW, is there a reason that main.m isn't called main.c?
main.m is Objective-C. Obj-C is needed to create the OSX application
shell.
--
Glynn Clements gl...@gclements.plus.com
-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
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 6.4.0 release branch created
On Mon, Dec 22, 2008 at 9:42 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Fedora 8 64bit works too. Minor complaint: r.external menu entry missing in tcltk, present in wxpython as Raster-Develop raster map-Link to GDAL. IMHO this wonderful module deserves a menu entry also in tcltk :-) Done. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #410: v.label.editor
#410: v.label.editor -+-- Reporter: neuba| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- This is a python for editing and remove file item. Please is this a new for grass? -- Ticket URL: http://trac.osgeo.org/grass/ticket/410 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4 Nviz Windows problems
On Mon, Dec 22, 2008 at 4:44 AM, Glynn Clements gl...@gclements.plus.com wrote: Paul Kelly wrote: I had a problem compiling nviz from the 6.4 release branch on Windows, with unrecognised Tcl/Tk symbols. Reverting r32244 to put the Tcl/Tk library flags in among the other library linking flags seems to fix it: http://trac.osgeo.org/grass/changeset/32244 I haven't committed as I don't understand the reason for that change. $(XTRA_LDFLAGS) definitely should go after $(ARCH_OBJS) and $(SURFLIB). Otherwise, it won't work if either the Tcl/Tk or OpenGL libraries are static libraries. Attempt to fix in r34993 (6.4.svn) and 34994 (6.4.0svn) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #399: Added backlink functionality to r.walk, r.cost r.drain
#399: Added backlink functionality to r.walk, r.cost r.drain --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: Platform: All | Cpu: All --+- Comment (by cnielsen): Thanks for all the comments. I believe I have fixed all the errors mentioned above (except the description.html $date thing, I'm not sure how to fix that one). I removed the problem in r.drain that dylan mentioned... Something is still needed there but I couldn't find a working solution. I wanted an error to come up if the user put in an invalid direction raster, but the NULL cell value was coming up as a false positive... If someone has an idea let me know. -Colin -- Ticket URL: http://trac.osgeo.org/grass/ticket/399#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #409: v.label.editor
#409: v.label.editor --+- Reporter: neuba| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: duplicate|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by neteler): * status: new = closed * resolution: = duplicate Comment: continued in #410 -- Ticket URL: http://trac.osgeo.org/grass/ticket/409#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: GRASS 6.4.0 release branch created
On Fri, Dec 19, 2008 at 9:39 PM, Markus Neteler nete...@osgeo.org wrote: Today the GRASS 6.4.0 release branch has been created- Please check it out and test it (now) before we tag RC1: svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 If there are no objections, I would like to tag RC1 tomorrow (23 dec 2008). The feedback so far was positive for the various Linux distros, unclear for Windows (one bug fixed since then) and positive for MacOSX, too. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: GRASS 6.4.0 release branch created
There is the libnviz OSX compilation issue to take care of (I have a couple adjustments to the patch I posted). I can get to it tonight. Don't forget to remove svn from the version ;) On Dec 22, 2008, at 3:30 PM, Markus Neteler wrote: On Fri, Dec 19, 2008 at 9:39 PM, Markus Neteler nete...@osgeo.org wrote: Today the GRASS 6.4.0 release branch has been created- Please check it out and test it (now) before we tag RC1: svn co https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 If there are no objections, I would like to tag RC1 tomorrow (23 dec 2008). The feedback so far was positive for the various Linux distros, unclear for Windows (one bug fixed since then) and positive for MacOSX, too. Markus - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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] 6.4 Nviz Windows problems
On Mon, 22 Dec 2008, Glynn Clements wrote: Paul Kelly wrote: I had a problem compiling nviz from the 6.4 release branch on Windows, with unrecognised Tcl/Tk symbols. Reverting r32244 to put the Tcl/Tk library flags in among the other library linking flags seems to fix it: http://trac.osgeo.org/grass/changeset/32244 I haven't committed as I don't understand the reason for that change. $(XTRA_LDFLAGS) definitely should go after $(ARCH_OBJS) and $(SURFLIB). Otherwise, it won't work if either the Tcl/Tk or OpenGL libraries are static libraries. Yes, I was using static Tcl/Tk. Markus has fixed this now and I can confirm the fix works. Trying to run nviz brings up a further error - see attached - unfortunately no time to look into it further now. I can't reproduce this. Does the file appear to be valid? No - it's not there actually. Didn't take much further looking into... the culprit seems to be r32173: http://trac.osgeo.org/grass/changeset/32173 (-L option added to find command-line). The Msys find doesn't seem to have the -L option - but perhaps it is just a version issue? find --version reports: GNU find version 4.1 Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #410: v.label.editor
#410: v.label.editor --+- Reporter: neuba| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by neuba): can I have the first code of this script for comparison. Thank you -- Ticket URL: http://trac.osgeo.org/grass/ticket/410#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mac error in GRASS 7 compiling
William Kyngesburye wrote: You also need to make $(APPDIR)/Info.plist as part of the top-level macosxapp rule. One complication is the need to ensure that $(OBJDIR) is created first, even in parallel builds, and it seems we can't rely upon make (particularly the OSX version) supporting order-only dependencies. I suggest replacing the top-level macosxapp rule with the following: NIBSRC := $(wildcard English.lproj/MainMenu.nib/*) Will this exclude CVS/SVN hidden files? IOW, does it behave just like ls (without the -a flag)? In glob patterns, * doesn't match files or directories which begin with a dot. I'll give this a go. I assume keep my $(OBJDIR)/* targets? Yes, keep the existing rules for Info.plist, GRASS.scpt and grass.sh. You're free to use $(OBJDIR) for your own targets, so long as you ensure that it gets created and ensure that those rules get invoked somehow. BTW, is there a reason that main.m isn't called main.c? main.m is Objective-C. Obj-C is needed to create the OSX application shell. Ah. In that case, using $(CC) is less than ideal; configure.in should really use AC_PROG_OBJC to specifically detect an Objective-C compiler. Similar issues exist for CFLAGS. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mac error in GRASS 7 compiling
On Dec 22, 2008, at 12:30 PM, Glynn Clements wrote: I suggest replacing the top-level macosxapp rule with the following: NIBSRC := $(wildcard English.lproj/MainMenu.nib/*) NIBDST := $(patsubst English.lproj/%,$(APPDIR)/English.lproj/%,$ (NIBSRC)) ... Oh, and should MOD_OBJS be just main.o now? ... or, no, FILES - MacOS/ GRASS - main.o, so no MOD_OBJS? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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] GRASS 6.4 release branch on OS X
I checked out the release branch today. It compiled fine, except for nviz_cmd (./lib/nviz/render.c needs to be deleted in order for this to compile). I tried some basic display functions and it seems to be fine. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4 release branch on OS X
I just committed a patch so render.c compiles on OSX. nviz_cmd should compile, but it won't work. At least it smooths the build process. On Dec 22, 2008, at 6:58 PM, Michael Barton wrote: I checked out the release branch today. It compiled fine, except for nviz_cmd (./lib/nviz/render.c needs to be deleted in order for this to compile). I tried some basic display functions and it seems to be fine. Michael - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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] 6.4 Nviz Windows problems
Paul Kelly wrote: I had a problem compiling nviz from the 6.4 release branch on Windows, with unrecognised Tcl/Tk symbols. Reverting r32244 to put the Tcl/Tk library flags in among the other library linking flags seems to fix it: http://trac.osgeo.org/grass/changeset/32244 I haven't committed as I don't understand the reason for that change. $(XTRA_LDFLAGS) definitely should go after $(ARCH_OBJS) and $(SURFLIB). Otherwise, it won't work if either the Tcl/Tk or OpenGL libraries are static libraries. Yes, I was using static Tcl/Tk. Markus has fixed this now and I can confirm the fix works. Trying to run nviz brings up a further error - see attached - unfortunately no time to look into it further now. I can't reproduce this. Does the file appear to be valid? No - it's not there actually. Didn't take much further looking into... the culprit seems to be r32173: http://trac.osgeo.org/grass/changeset/32173 (-L option added to find command-line). The Msys find doesn't seem to have the -L option - but perhaps it is just a version issue? find --version reports: GNU find version 4.1 FWIW, -L is POSIX: http://www.opengroup.org/onlinepubs/009695399/utilities/find.html It may be that MSys dropped the option due to Windows not having symlinks, although silently ignoring it would have been better. 7.0 uses $(wildcard ...) instead of find. That could be used, or alternatively: ifneq ($(strip $(MINGW)),) FIND = find else FIND = find -L endif -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mac error in GRASS 7 compiling
I've tested compiling both GRASS 6.4 (develbranch_6) and GRASS 7 and they work fine. No errors. They seem to run fine too. No problems that I noticed. Thanks to all who worked on this. Michael On Dec 22, 2008, at 7:52 PM, William Kyngesburye wrote: OSX Makefile fixed, thanks to Glynn's help. On Dec 22, 2008, at 6:49 PM, William Kyngesburye wrote: On Dec 22, 2008, at 12:30 PM, Glynn Clements wrote: I suggest replacing the top-level macosxapp rule with the following: NIBSRC := $(wildcard English.lproj/MainMenu.nib/*) NIBDST := $(patsubst English.lproj/%,$(APPDIR)/English.lproj/%,$ (NIBSRC)) ... Oh, and should MOD_OBJS be just main.o now? ... or, no, FILES - MacOS/GRASS - main.o, so no MOD_OBJS? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com 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 6.4 release branch on OS X
William Kyngesburye wrote: I just committed a patch so render.c compiles on OSX. nviz_cmd should compile, but it won't work. At least it smooths the build process. A couple of things to try: Index: lib/nviz/render.c === --- lib/nviz/render.c (revision 35000) +++ lib/nviz/render.c (working copy) @@ -205,6 +205,7 @@ return 1; aglSetCurrentContext(rwin-contextId); +aglSetPBuffer(rwin-contextId, rwin-windowId, 0, 0, 0); #elif defined(OPENGL_WINDOWS) if (!rwin-displayId || !rwin-contextId) return 0; Index: include/nviz.h === --- include/nviz.h (revision 35000) +++ include/nviz.h (working copy) @@ -131,7 +131,6 @@ AGLPixelFormat pixelFmtId; AGLContext contextId; AGLPbuffer windowId; -GWorldPtr pixmap; #elif defined(OPENGL_WINDOWS) HDC displayId; /* display context */ HGLRC contextId; /* rendering context */ I don't think that the pixmap field is meaningful if we're using a pBuffer. The aglSetPBuffer() is from: http://developer.apple.com/DOCUMENTATION/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_offscreen/chapter_5_section_4.html The first two zeros should be correct, the third is a guess. It may also turn out to be necessary to provide more attributes to aglChoosePixelFormat(). AFAICT, leaving too many settings at default might result in choosing a render which doesn't support pBuffers. http://developer.apple.com/DOCUMENTATION/GraphicsImaging/Reference/AGL_OpenGL/Reference/reference.html#//apple_ref/doc/uid/TP3414-F15007 It might be worth using GL_RGB rather than GL_RGBA in aglCreatePBuffer(). I don't think that we need the alpha channel, and this may improve robustness (in X, asking for an alpha channel is adding one more possible reason for failure). I don't know whether you need to use aglUpdateContext() for a pBuffer. http://developer.apple.com/DOCUMENTATION/GraphicsImaging/Reference/AGL_OpenGL/Reference/reference.html#//apple_ref/doc/uid/TP3414-F15019 Also, OSX supports the use of arbitrary blocks of memory for (software-only) off-screen rendering (similar to OSMesa). That might be worth investigating as a fall-back in case pBuffers don't work. http://developer.apple.com/DOCUMENTATION/GraphicsImaging/Reference/AGL_OpenGL/Reference/reference.html#//apple_ref/doc/uid/TP3414-F15023 -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mac error in GRASS 7 compiling
William Kyngesburye wrote: The flags needed and used for the rest of GRASS also apply to Obj-C, though I suppose the user could add some bad flags to CFLAGS that would mess up the OBJ-C compilation. Any suggestions for an Obj-C flags name? autoconf uses OBJC for the name of the compiler and OBJCFLAGS for the flags (default: -g -O2). And I suppose support for it would have to be added to configure? Ideally, along with default rules in Compile.make. Initially, you can just set the variables in the Makefile, equal to CC and CFLAGS. That way, the user can always override e.g. OBJCFLAGS on the command line if there's anything problematic in CFLAGS. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mac error in GRASS 7 compiling
William Kyngesburye wrote: I suggest replacing the top-level macosxapp rule with the following: NIBSRC := $(wildcard English.lproj/MainMenu.nib/*) NIBDST := $(patsubst English.lproj/%,$(APPDIR)/English.lproj/%,$ (NIBSRC)) ... Oh, and should MOD_OBJS be just main.o now? ... or, no, FILES - MacOS/ GRASS - main.o, so no MOD_OBJS? There's no need, as you have your own linking rule for $(APPDIR)/MacOS/GRASS. MOD_OBJS is used to generate ARCH_OBJS, which is the list of prerequisites for the standard targets defined in Module.make, Etc.make, Lib.make and DB.make. As you aren't generating one of those targets, it won't be used. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #411: Makefile uses LD instead of GCC for linking leads to undefined symbol: __stack_chk_fail_local
#411: Makefile uses LD instead of GCC for linking leads to undefined symbol: __stack_chk_fail_local -+-- Reporter: RRosario | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Keywords: undefined symbol __stack_chk_fail_local |Platform: Unspecified Cpu: x86-32 | -+-- The Makefile for Python SWIG uses LD for linking rather than GCC. On some Linux systems, this causes Python to throw the error: $ python -c import _python_grass6 Traceback (most recent call last): File string, line 1, in module ImportError: ./_python_grass6.so: undefined symbol: __stack_chk_fail_local when the library python_grass6 is imported due to a stack smash guard. I have confirmed that replacing LD with CC fixes this problem. On some distributions of Linux, this can be fixed by adding -fno-stack-protector to CFLAGS. R. -- Ticket URL: http://trac.osgeo.org/grass/ticket/411 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
